Merge upstream updates from Jef:
- better Mares Bluelink Pro downloading
- Suunto DX CCR and gas mix fixes
* 'master' of git://github.com/libdivecomputer/libdivecomputer:
Add support for the Mares Bluelink Pro interface
Check the correct vtable pointer
Report the setpoint data
Take the CCR diluents into account
Implement the initial gas mix
Get the gas mix index directly from the event data
The main difference with the serial communication is that the BLE
communication uses data packets (with a maximum size of 20 bytes)
instead of a continuous data stream.
Occasionally, the device responds with an empty packet (with just the
ACK and EOF byte) or with a short packet where one or more payload bytes
are missing. The empty packet is most likely caused because the device
didn't receive the second part of the command (with the parameters) in
time. The missing bytes might be caused by a buffer overflow on the
Bluelink Pro, when the data from the dive computer arrives faster over
the serial link than the device can forward it over the slower bluetooth
link to the host system.
One way to address this problem is to lower the packet size from 256 bytes
to only 128 bytes. The main disadvantage is that this also impacts the
download speed considerably. In one particular example, the total
download time increased from about 135 to 210 seconds (which is already
slow compared to the 62 seconds the same download takes over usb)!
An alternative solution is to simply retry the failed command. That way
there is only a performance penalty for the few bad packets, and not for
every single packet. In the above example, only two packets needed a
retransmission.
Note that the iconhd communication protocol uses no checksums. Hence
it's not possible to detect corrupt data packets. Only short packets can
be detected, because they result in a timeout.
The Suunto DX supports 3 CCR diluents and 8 OC gas mixes. Since the gas
mix index in the data is relative to either the set of CCR diluents or
OC gas mixes (depending on the dive mode) and libdivecomputer reports
both sets, the index needs to be adjusted.
There is no need to lookup the gas mix index, because the number is
stored directly in the event data, right next to the oxygen and helium
values. This actually removes an ambiguity in cases where the user has
configured two or more identical gas mixes. In that case, the lookup
would always find the first gas mix.
This logs every INFO_EVENT record and provides a SAMPLE_EVENT_BOOKMARK event for
the only INFO_EVENT we can parse so far, the TAG event. Three bits in the flag
value in that event structure are now used to hold the tag type, and if a
non-zero type has been set, then the value is the heading in degress.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Merge with upstream from Jef:
- ignore empty pressure samples from OSTC
- skip empty Oceanic logbook entries
- update Ratio parsing
* 'master' of git://github.com/libdivecomputer/libdivecomputer:
Ignore zero tank pressure values
Add filters for BLE communication
Skip empty logbook entries
Add clock synchronization support
Use symbolic constants for the commands
Don't pass a NULL pointer to memcpy
Update the list of the Ratio dive computers
This re-applied commit 902dbf4d6d24 ("shearwater: Fallback to
average/voted ppo2") which got lost in the last merge with upstream when
I synced with Jef's rewrite of the PNF parser.
Reported-by: Martin Long <martin@longhome.co.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
On certain devices, for example the Aeris Elite T3, the logbook
ringbuffer can sometimes contain an empty logbook entry in between the
valid entries. Because the presence of such an empty entry is currently
being interpreted as having reached the last valid entry, the download
is aborted. The result is that all remaining valid entries, located
after the empty entry, can't be downloaded.
This can be avoided by skipping the empty entry instead of aborting the
download.
The Ratio dive computers support synchronizing the internal clock. One
complication is that recent firmware versions (4.0.56 or 4.1.10) support
two timezones (home and abroad), while the libdivecomputer api only
supports one timezone. To deal with this, the most recent firmware
versions (4.0.58 or 4.1.12) will interprete an invalid timezone index
(0xFF) as leaving the timezone unchanged.
If the firmware doesn't support the dual timezone command, or if the
firmware doesn't have the invalid timezone index modification yet, then
a fallback to the single timezone command is provided. Note that in the
latter case the side effect is that both timezones will be changed!
The memcpy and related functions expects a valid pointer, even if the
size is zero. Most libc implementations will handle a NULL pointer just
fine, but that's not guaranteed.
Simply skip the call when there is nothing to copy.
There were quite a few models missing in the list. And because the
lowest iX3M model number has changed, the iX3M detection needed to be
updated as well.
The merge with Jef's upstream ended up taking a lot of Jef's changes to
how the Shearwater PNF parsing was done, and in the process inadvertdly
lost some of the code from our side of the branch that Jef hadn't taken.
In particular, the initialization of the string cache, and the
logversion string.
Put them back.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
As of firmware 11 at least my Teric identifies as 0x1F0A.
Also, just like libdivecomputer upstream, don't assume that an unknown
model is a Petrel - that was a stupid thing to do and caused downloads
with the Teric to break.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Update with Jef's upstream:
- add support for Cressi Goa and Cartesio
- update the Shearwater PNF parser to Jef's version
- misc minor fixes
* git://github.com/libdivecomputer/libdivecomputer:
Use the timezone setting of the dive computer
Add support for the Cressi Goa and Cartesio
Add an extra parameter for the initial CRC value
Add support for the Ratio iDive Color series
Shearwater Petrel Native Format parsing
Shearwater: detect which logbook format is support
Shearwater: add Teric to list of supported dive computers
Shearwater: skip deleted dives
Fix a potential buffer overflow
The Ratio dive computers with the latest APOS4 firmware support a
timezone setting. Take this timezone into account instead of using the
timezone of the host system.
This will allow parsing dives from the Shearwater Teric, but depending on the
firmware could also be used on older models.
Based on ideas and code from Dirk Hohndel
The Log Upload RDBI (Read Data by Identifier) response tells us which
format the dive computer supports.
Shearwater recommends to use the 'Petrel Native Format' for all dive
computers which support it, even those pre-Teric models which (depending
on firmware) might support both PNF and the older 'Predator-Like
Format'.
They also recommend to ignore the 0x90000000 format which is very
similar to PNF but without the final record and to use the older
Predator Like Format in that case.
The 0xDD000000 format is never an option by the time you got here, but
in the old code (prior to the PNF addition) we would have fallen back to
0xC0000000, so let's do the same here.
Any other value is actually an unknown format and should be treated as
such.
Which format we use is determined by the base address used to download
the logbook entries.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Merge with upstream from Jef.
Small trivial fixlets.
* 'master' of git://github.com/libdivecomputer/libdivecomputer:
Fix the Cobalt 2 memory size
Use the travis homebrew plugin to install packages
Increase the internal log buffer
Fix undefined behaviour in left shifts
It seems that the BLE communication protocol is somewhat different from
the serial one in the version string: while the serial version tends to
show the memory size, the BLE version string has some other numeric
pattern.
We don't have enough information to guess what it is, although normally
the BLE pattern is just "0001" instead of some memory size string. But
I've seen the i770R once report 0090 instead. Some status code?
Regardless, make the Pro Plus X and the I300C pattern simply ignore the
last four digits, since they clearly vary, and those two computers
support BLE.
The i770R pattern already did that, since I saw it myself. The Pro Plus
X I have a communication trace from Brett Woods, and the i300C I just
assume follows the same pattern.
Reported-by: Brett Woods <brett@jeepswag.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The Cobalt 2 has a bit more flash memory available for storing dives
compared to the original Cobalt 1. This larger amount of memory can
cause the progress events to exceed past 100% if there are many dives
present. This will trigger the assert in the event code and crash the
application.
It really looks (very superficially) like the Oceanic Pro Plus X might
act exactly the same as the Aqualung i770R over bluetooth: it has the
exact same bluetooth name pattern ("ER001299", where "ER" is the ASCII
represetnation of the model number (0x4552) and the 001299 looks like
the serial number that we then use for "authenticating" with the device.
I haven't actually tested this at all, but Brett Woods sent the
bluetooth scan information, and it looks promising. So let's just test
it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The Atomic Aquatics Cobalt backend uses 8K data packets. Since a hexdump
of such a data packet needs at least twice the size of the binary data,
the internal log buffer should be increased to 16K bytes.
Due to the integer promotion rules of the C language, the unsigned char
values are promoted to a signed integer (and not an unsigned integer)
before being shifted. But the result of a left shift on a signed type is
undefined if the resulting value can't be represented in the signed
type.
GCC's Undefined Behavior Sanitizer (ubsan), enabled with the option
-fsanitize=undefined, detects this type of problem at runtime with the
following warning: "left shift of X by Y places cannot be represented in
type 'int'".
Fixed with an explicit cast to unsigned integer.
Sync up with Jef's upstream changes.
About half of it was stuff we'd already done: i770R support (together
with the Oceanic dive truncation) and the change to the Scubapro G2 BLE
protocol.
And once again, Jef has taken the work of others (me and Janice) and
made pointless changes to it just to make merging harder.
And once again, I tried to match up with upstream as much as possible to
make future merges easier. But it annoys me.
This *may* also get the Aqualung i300C working over bluetooth. I have
no real way to test, but the basic parsing support is there thanks to
Jef, and Janice implied that the BLE handshaking is the same as the
i770R.
* 'master' of git://github.com/libdivecomputer/libdivecomputer:
Add support for the Aqualung i300C
Add support for the Aqualung i770R
Fix the Pro Plus X gas mixes
Oceanic: fix up dive truncation issues
Scubapro G2: update BLE downloading for new 1.4 firmware version
Add a workaround for invalid ringbuffer begin pointers
It appears that the Aqualung i770R looks almost the same as the Pro Plus
X, but has an additional pO2 field for each gas by the O2 field, which
impacts the offset calculations.
This fixes the dive truncation that happened with long dives due to the
removal of extra padding (commit a2100843b9cf: "Remove extra padding
from the end of the profile"). It turns out the rest of the profile was
in bits 13-15 (with bit 12 being something else).
The packetization format for the BLE communication used to be that the
first byte of the BLE GATT payload was the size of the payload (1-19
bytes).
That seems to no longer be true as of fw version 1.4. It is still the
size of the payload for the simple small reply packets, but for the long
data stream it ends up being an odd sequence of 13 different values that
are almost - but not quite - 19 apart.
Whatever. Modify our strict "length byte must make sense" rule to be
more of a guidline than a hard rule. This makes the download succeed
again.
Very weird.
Reported-by: Adric Norris <landstander668@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull upstream updates from Jef Driesen.
This is mainly the Pelagic (Oceanic, Sherwood, Aeris, Aqualung etc)
download interface reset sequence.
* https://github.com/libdivecomputer/libdivecomputer:
Fix the RTS signal handling for Pelagic interface
Fix a memory leak in the error handling
Unfortunately there are several devices with an invalid ringbuffer begin
pointer. In such cases, the strict validation of the pointer causes the
download to fail, without being able to download any dives at all.
Since the begin pointer is only needed to detect the start of the oldest
dive, we can fall back to downloading the entire profile ringbuffer.
Usually we can still detect the start of the oldest dive in some other
(indirect) way. For example when reaching past the end of the
ringbuffer, or the presence of invalid pointers in the linked list
structure. The result is that, we'll be able to download at least some
dives before hitting some other error.
The packetization format for the BLE communication used to be that the
first byte of the BLE GATT payload was the size of the payload (1-19
bytes).
That seems to no longer be true as of fw version 1.4. It is still the
size of the payload for the simple small reply packets, but for the long
data stream it ends up being an odd sequence of 13 different values that
are almost - but not quite - 19 apart.
Whatever. Modify our strict "length byte must make sense" rule to be
more of a guidline than a hard rule. This makes the download succeed
again.
Very weird.
Reported-by: Adric Norris <landstander668@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The "I have NO IDEA" 0xE5 command seems to be a handshake packet with a
passphrase based on the serial number of the device.
Sadly, we can't actually read the serial number from the device until
after this handshake as successfully completed, which makes it a bit of
a chicken-and-egg problem from a communication standpoint.
However, the serial number is also exposed in the bluetooth name that
the device advertizes, which is the reason for the newly added
"dc_iostream_get_name()" function - so that whoever set up the IO for us
can give us the name.
Annoying, yes, but less annoying than "I have NO IDEA".
Thanks to Janice McLaughlin for pointing out the logic of this magic
handshake, which is apparently also the case for the Aqualung i300C.
This also simplifies the command sequence handling: if you use
oceanic_atom2_ble_transfer() and ask for an answer (even if the answer
size is zero, and only the ACK is returned), the BLE transfer code will
handle the sequence number on its own.
Only if you send a packet without expecting an answer at all do you need
to manage the sequence number manually. This is mainly used for
oceanic_atom2_device_write(), although I suspect that code gets an ACK
and could use a zero answer size too.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Some of the transport types have meaningful names.
The BLE transport has a device name that was exposed during device
discovery, for example, and some back-ends (ok, right now only the
Aqualung i300C and i770R) need to know what that device name was in
order to handshake with the device properly.
Other transports, like the USBSTORAGE one, could usefully use this to
get the basename of the path to the storage, although right now that
transport makes do with simply doing a "dc_iostream_read()" on the
transport instead.
For now, this is just the infrastructure, ready to get hooked into.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
