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!
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.
