The set_latency function is the perfect example of a feature that should
be implemented as an ioctl: it's only implemented by a single driver,
and the functionality is also highly platform specific.
This new ioctl function allows to perform I/O stream specific requests
through a generic interface. This provides an easy way to extend the I/O
interface with some driver specific features, without having to modify
the public api.
Replace the manual polling, implemented using a combination of the
dc_iostream_get_available and dc_iostream_sleep functions, with the new
and more efficient poll function.
The Linux implementation is very straighforward and just a lightweight
wrapper around the select function. But the Windows implementation is
much more complex, because the Windows event notification mechanism
behaves very different:
The WaitCommEvent function does not support a timeout and is always a
blocking call. The only way to implement a timeout is to use
asynchronous I/O (or overlapped I/O as it's called in the Windows API),
to run the operation in the background. This requires some additional
book keeping to keep track of the pending background operation.
The event mechanism is also edge triggered instead of level triggered,
and reading the event with the WaitCommEvent function clears the pending
event. Therefore, the state of the input buffer needs to be checked with
the ClearCommError function before and after the WaitCommEvent call.
The check before is necessary in case the event is already cleared by a
previous WaitCommEvent call, while there is still data present in the
input buffer. In this case, WaitCommEvent should not be called at all,
because it would wait until more data arrives.
The check afterwards is necessary in case WaitCommEvent reports a
pending event, while the data in the input buffer has already been
consumed. In this case, the current event must be ignored and
WaitCommEvent needs to be called again, to wait for the next event.
I'm not sure why it wasn't there originally, but it definitely should
be on that list of ignored files, to keep 'git status' happy.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The Mares BlueLink Pro BLE dongle is the beast from hell, and introduces
lots of extra slowdowns into the Mares communication protocol.
In particular, it turns out that we really can't send the command bytes,
then wait for the ACK byte, and then send the command argument data as a
separate packet. Because of the delays that the dongle adds, the dive
computer will have given up on the command arguments by the time it sees
them.
At the same time we don't want to always pass the command and arguments
as one single packet in all situations, because at least the Mares
Matrix really seems to want that "wait for ACK before sending
arguments". See commit 59bfb0f3189b ("Add support for the Mares
Matrix") for details.
So introduce a new "splitcommand" flag, which is set by default, but
gets disabled for the BLE transport case.
Also, because bluetooth is slow, we don't want to ask for big packets of
data. It seems to cause a buffer overflow on the BlueLink Pro when the
serial data from the dive computer arrives faster than the bluetooth
data can be sent to the downloading side.
So when using the BLE transport, we also limit the packet size to 128
bytes in addition to disabling the command splitting.
With this, I can download hundreds of kB of data from the Mares Quad Air
successfully over BLE. It's *slow*, but it works.
This is a re-application of commit 5be8c17ea1 ("Mares bluetooth support
tweaks"), with small changes for how the libdivecomputer IO interfaces
have changed in the meantime.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The Mares Bluetooth dongle is some seriously messed up stuff, and takes
forever to answer anything. I'm not sure what we do wrong, because the
Mares mobile App seems to be able to work with it without the excessive
delays, but it is really incredibly slow when we talk to it.
I suspect the dongle has has some "wait until buffer is half full"
timeout, and it then triggers for every command and short reply in both
directions, and there's likely some way to flush it, but I didn't see
anything back when I had one for testing.
Anyway, as a result, one second is just about the latency that the
dongle itself adds regardless of anything else, so when the dive
computer itself needs a timeout to think about things, the overall
timeout needs to be noticeably more than one second.
Three seconds seems to be a somewhat reasonable compromise, and we do
have documentation for it being the right value:
"Then shalt thou count to three, no more, no less. Three shall be the
number thou shalt count, and the number of the counting shall be
three. Four shalt thou not count, neither count thou two, excepting
that thou then proceed to three. Five is right out."
because we do have strong reasons to believe that the Mares Bluetooth
dongle is a beast from hell. Everybody who has ecver met it has
certainly gone "Arrrghhh" at some point.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge with upstream Jef.
This is mainly just the (already merged as a separate patch) support for
th eOceanic Pro Plus 4, Jef committed the identical patch but without
marking it as BLE-capable (which is kind of pointless, since it doesn't
seem to work over anything _but_ BLE).
And a couple of trivial fixlets.
* git://github.com/libdivecomputer/libdivecomputer:
Fix the Aeris Manta memory layout
Add support for the Oceanic Pro Plus 4
Strip the source directory from file names
The BLE communication is significant slower than usb-serial. The first
BLE data packet of each response often takes longer than one second to
arrive. This causes the first attempt to fail with a timeout. The second
attempt will appear to succeed, because it actually receives the
response of the first attempt. But now the next command will fail,
because it will receive the response of the second attempt of the
previous command.
Increasing the timeout and adding an extra delay before retrying, avoids
this problem.
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
For the Aeris Manta, the end of the profile ringbuffer appears to depend
on the firmware version. For older firmware versions (1x), the end of
the ringbuffer is at address 0xFFF0, while for the newer versions (2x),
it's 0xFE00.
The code checks for firmware version 2B, because that's the lowest known
version in the 2x range.
Reported-by: Nick Shore <support@mac-dive.com>
This is _partial_ support for the Oceanic Pro Plus 4 from Jef, based on
a partial dump by John Clark. Quoting Jef in the email thread:
"I'm not sure why downloading the memory dump fails. All 4 attempts
fail around the same memory address (0x3140), but not exactly the
same. Strange, but the good news that there is already enough
information to figure some things out.
Linus and Dirk: Attached is a patch with the things I figured out so
far. Can you make a build for John to try?
Most of the info looks reasonable, but there are probably still a few
things missing or wrong. I don't have any ground truth data to compare
against for things like the temperature sign"
This is that patch for testing.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge upstream libdivecomputer updates from Jef.
Misc small updates all over, the biggest thing (code wise) is probably
the Ratio firmware update support.
* 'master' of git://github.com/libdivecomputer/libdivecomputer:
Fix the Oceanic Geo 4.0 memory layout
Ignore all empty logbook entries
Add a workaround for the hwOS ppO2 firmware bug
Use macros to encode the firmware version
Use symbolic constants for the sample types
Remove the obsolete hwos parameter
Limit the tank pressure workaround to hwOS devices
Fix the OSTC tank pressure decoding
Fix the Scubapro G2 HUD udev rule
Add the Mares Genius to the bluetooth filter
Add firmware upgrade support for the Ratio computers
The logbook ringbuffer is always updated sequentially. Therefore, emtpy
entries can only be present after the oldest dive. However it appears
that under some special conditions (for example an empty battery during
the dive), the logbook entry is not always stored correctly, which can
result in an empty entry after all.
I suspect that at the start of each dive, the OSTC erases the next
available entry in the logbook ringbuffer and updates the internal write
pointer. Once the dive is finished, the actual content of the erased
logbook is written. Thus, when the OSTC runs out of battery power during
the dive, that last step never happens, and the erased entry remains in
place.
As a workaround, ignore all empty logbook entries instead of assuming we
reached the last dive.
Due to a bug in the hwOS Tech firmware v3.03 to v3.07, and the hwOS
Sport firmware v10.57 to v10.63, the ppO2 divisor is sometimes not
correctly reset to zero when no ppO2 samples are being recorded.
Usually this condition can be detected by the fact that the length of
the extended sample will not have enough space left for the ppO2 sample
(9 bytes). As a workaround, reset the divisor back to zero to manually
disable the ppO2 samples.
In theory this detection method is not 100% reliable. There can still be
other sample types present in the extended sample. If their total size
is larger than 9 bytes, the bug will not be detected at all. Instead,
those bytes will get interpreted as the ppO2 sample, resulting in bogus
ppO2 values. Additionally, one of the other sample types will now run
out of space and cause the parsing to fail with an error. However, in
practice this risk is relative low. Most of the other samples are
relative small (1 or 2 bytes), so you would need many of them. That's
rather unlikely in most configurations. The only exception is the large
deco plan sample (15 bytes).
In commit 2829f7ebf9902170bf653d67dbe412a0a4f140cf, the hwos parameter
of the hw_ostc_parser_create() function was kept to preserve backwards
compatibility. Since the function has been removed from the public api,
the parameter can be removed now.
The workaround for the tank pressure in the previous commit is only
relevant for the newer hwOS based devices, and not for the original OSTC
devices. In practice this doesn't cause any problems because the
original OSTC doesn't support a tank pressure sensor, but nevertheless
it's better to use the correct condition.
The tank pressure is stored with a resolution of 1 bar instead of 0.1
bar. There is however one exception. The hwOS Sport firmware used a
resolution of 0.1 bar between versions 10.40 and 10.50.
Unfortunately the only way to distinguish the Sport from the Tech
variant is the different range of the version number (10.x vs 3.x). The
consequence is that this workaround will start to produce wrong results
once the firmware version number of the hwOS tech variant reaches the
10.x range. If that ever happens, this workaround should be removed
again!
Merge misc fixes from Jef's upstream.
This fixes the incorrect and partial Oceanic Geo 4.0 support from commit
e38406b353bb ("Start adding IDs for the Oceanic Geo 4.0"), where I was
assuming it looked like the I770R.
* https://github.com/libdivecomputer/libdivecomputer:
Add support for the Oceanic Geo 4.0
Fix a buffer overflow
Merge upstream updates from Jef Driesen:
- clean up Shearwater tank pressure handling
- minor fixlets
The Shearwater pressure sensor changes by Jef means that I also changed
how we handle the battery level for the pressure sensors, and integrated
it with the tank handling.
* jef/master:
Improve the support for multiple tank transmitters
Extract the log version immediately
Use a struct for the gasmix data
Use a prefix match for the Suunto bluetooth name
Update the Shearwater Nerd bluetooth names
Check condition before entering the loop
Some of the newer Shearwater dive computers support up to 2 tank
pressure sensors. The tank pressure samples were already reported, but
the tank field with the corresponding begin/end pressure was still
missing.
To be able to collect the tank begin/end pressure, the log version needs
to be available earlier, because it's needed for parsing the tank
pressure data in the samples. Therefore, extract the log version
immediately after locating the opening record.
Add the Shearwater Nerd 2 bluetooth device name.
The change to uppercase is purely cosmetic. The string comparisions are
not case-sensitive. But for documentation purposes it's good practice to
list the exact name as reported by the device.
Merge upstream libdivecomputer updates from Jef:
- Jef took my i200C support patch, so merge that up (only difference
was that we mark it as BLE-capable)
- support for multiple cylinders and transmitters for the Ratio iDive
dive computers
- Fix Mares BLE packet cache missed invalidation
* 'master' of git://github.com/libdivecomputer/libdivecomputer:
Discard the cached BLE packet
Add support for Aqualung i200c
Take the tank transmitter flags into account
Add support for multiple tank transmitters
Use a struct for the gasmix and tank data
When using a BLE connection, it's not sufficient to purge the buffers of
the underlying I/O stream. The locally cached BLE packet needs to be
discarded also.
It's exactly the same as the regular i200, but has a new version number
and string.
Tested-by: Tiago Thedim Dias <tiagotsoc@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Suppress the tank pressure sample when there is no active transmitter
available, or the connection with the transmitter is (temporary) lost.
In the latter case, the pressure is recorded as zero.
The Ratio dive computers support up to 10 tank pressure sensors. The ID
of the active tank sensor is stored in the sample data, and gets mapped
to the corresponding tank index.
I've tried to find where the firmware version and serial number are, and
have failed miserably. Some of the commands I have sent instead cleared
the memory of the dive computer. Whee.
But let's document the responses to the commands anyway, and flesh out
the fingerprinting code (which is useless without a device ID, which we
do not currently have).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
.. and also support cancellation of dive downloading in the middle.
The Cosmiq+ doesn't remember all that many dives, but BLE is slow and
there's no point in downloading more than necessary.
I'll look at fingerprinting next, so that we can avoid downloading the
profile data if we have already seen the header. That's a further small
optimization.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When I added more parsing of the dive data of the Cosmiq+ in commit
4dff291a1a53 ("Deepblu Cosmiq+: fill in some parsing details") I got the
gasmix units completely wrong and clearly never tested it.
The DC_FIELD_GASMIX reporting uses floating point percentages, not
integer percentages, and instead of reporting 21% as 0.21, we used to
report it as 21.0. It all looked fine in my profiles, because I'd only
tested simulated air dives, and subsurface defaults to air even if
somebody reports crazy impossible gases.
Easy enough to fix, and now actually tested by doing a simulated nitrox
dive.
Reported-by: Michael Werle <mwerle@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It's exactly the same as the regular i200, but has a new version number
and string.
Tested-by: Tiago Thedim Dias <tiagotsoc@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
