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.
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.
A small typo introduced with the Tusa Talis support in commit
b188c414206daaa5b6de464ced98d78f6da7cde1 accidentally disabled the tank
pressure reporting for all models.
The Mares Genius supports a new command to download different types of
objects (e.g. dive header, dive profiles, etc) directly, without needing
to manually read and parse the contents of the flash memory.
The data structure also changed significantly. The profile data is now
organized into different records. Each record starts and ends with a 4
byte ascii marker:
DSTR: Dive start record
TISS: Tissue record
DPRS: Sample record
AIRS: Air integration record
DEND: Dive end record
and contains a CRC checksum. The contents of the records remains very
similar to the existing iconhd data format.
Based-on-code-by: Janice McLaughlin <janice@moremobilesoftware.com>
Split the offset calculation in two steps: first the offset to the
header data, and then the date/time field. The main advantage is that
the resulting code now follows the same logic as in the other functions.
The Mares Genius dive header is no longer located at the end of the data
(after the dive profile), but at the start. Therefore we don't need the
offset to the dive header anymore. Replace with the size of the header
instead.
The two byte commands are in fact a single byte command. The second byte
is some kind of checksum, containing the command byte xor'ed with the
value 0xA5.
The latest variant of the Mares Quad has 4 times more flash memory
compared to the original variant (1M vs 256K). Therefore this variant
supports a new command to read the size of the flash memory.
At the moment, it's unknown whether the previous variant also supports
this new command or not. Probably not, because none of the other
compatible models seems to support it either. Hence we only attempt to
read the flash memory size for the Quad, and a failure is not considered
a fatal error. The disadvantage of this approach is that a temporary
communication problem can result in a misdetection of the flash memory
size.
Reported-by: Janice McLaughlin <janice@moremobilesoftware.com>
In the EON Steel descriptor for the temperature field, the "nillable"
value is -3000:
int16,precision=2,nillable=-3000
So the missing equals sign is just a small oversight.
The length field in the data is checked for the maximum size (e.g. the
size of the buffer), but there is no such check on the minimum size
(e.g. the size of the header). If the length is smaller, the code
accessed data before the start of the buffer.
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.
