The internal Uwatec tank id should be converted to the libdivecomputer
tank index. If there is no corresponding tank, the tank pressure samples
are dropped for the following reasons:
Some models appear to record an absolute tank pressure sample, even if
there is no pressure sensor attached to the corresponding tank. In this
case only the tank index changes. The sample value simply retains the
last pressure of the previous tank. Since we don't have any real
pressure data, dropping those samples is fine.
Dives are downloaded using bulk transfers with an 8K buffer. Normally
the 2 second timeout is more than sufficient, and the timeout should
never expire, unless there is some serious communcation problem. But
nevertheless, users are reporting timeouts for dives having a length
that is an exact multiple of the USB packet size (64 bytes). In that
case, libusb reports a timeout with an non-zero amount of bytes
received. Despite the timeout, the received data contains a complete
dive.
I suspect libusb is somehow unable to determine whether the transfer is
complete and therefore waits until the timeout expires. For transfers
that are not a multiple of the USB packet size, the end of the transfer
is indicated by the last incomplete packet. This is not the case if the
length is an exact multiple of the USB packet size. This problem is
usually solved by sending a zero-length packet. Maybe the USB stack of
the Cobalt is not sending such a zero-length packet?
Atomics will address the problem with a Coblat 2 firmware upgrade, that
will simply append two zero bytes if the length is a multiple of 64
bytes. As a workaround for older firmware versions, we ignore the
timeout and process all received data. This shouldn't have any
disadvantages. An incomplete dive, for example due to a real timeout,
will now be detected by means of the minimum length and/or the checksum.
The Mares Smart Apnea uses a different data format than the regular
Smart, because it records not only a summary of each freedive in the
session, but also a full depth profile.
Because both the regular Smart and the Smart Apnea have the same model
number (0x10), another way to distinguish the two variants is needed.
Therefore, the Smart Apnea gets a modified model number, with one of the
higher bit set. The actual type is detected from the contents of the
version packet.
The new Smart Apnea is also capable of recording multiple samples per
second (e.g. 2, 4 or 8). But since our smallest unit of time is one
second, we can't represent this, and the extra samples will get dropped
for now.
The Galileo Trimix supports up to 10 tanks and gas mixes. However, the
existing alarm based gas switch events have only 2 bits available, and
can support at most 4 gas mixes. Therefore, the trimix variant stores
another 4 bit value in the second alarm byte.
For the first three gas mixes (and possibly also the fourth), both alarm
bytes appear to be always set to the same value. For the higher mixes,
the value in the first alarm byte is always zero. This doesn't cause any
problems, because in the data stream the second alarm byte is stored
after the first one, and our final value is always the last one.
The non-trimix variant also has the second alarm byte, but the gas mix
bits appear to be always zero. In order to avoid taking this zero as the
final value, a separate table is used for the trimix variant.
The air integrated uwatec aladin models do record the total consumption,
and not the begin/end pressure. Returning the total consumption as the
begin pressure, combined with a zero end pressure is strictly speaking
not correct, but it still provides useful information.
Even if there are no O2 sensors connected (for example in auto or fixed
setpoint mode), the device records a ppO2 sample with all three values
set to zero. Such samples are now ignored, as if there was no ppO2
sample present.
Reported-by: Anton Lundin <glance@acc.umu.se>
The Atomics Cobalt backend uses libusb directly, without going through
an internal I/O layer that support logging. Therefore the logging needs
to be done in the backend itself.
The logbook ringbuffer starts at address 0x03E0 instead of 0x240. Since
none of the other models uses the same address, a completely new layout
structure is necessary.
The begin/end pressure for unused tanks is normally zero. But I noticed
that in some cases both pressure values are stored as 0xFFFF. Since that
corresponds to a pressure of 511.99 bar, this is most likely some
special magic value, and not a valid pressure.
Tanks where either the begin or end pressure is 0xFFFF are now ignored
too.
When the PPO2 sample was introduced, we didn't take into account the
fact that rebreathers usually support multiple O2 sensors. The HW OSTC
supports for example three sensors. In order to support multiple values,
without having to introduce a new data structure with an additional
sensor id field, we simply relax the assumption of allowing only one
DC_SAMPLE_PPO2 value per sample. Applications that are not prepared for
multiple values, will automatically use only one of them (probably the
last one).
With firmware version 1.84 (beta), a more compact logbook header is
introduced. Due to their smaller size (16 vs 256 bytes), the total
amount of data that needs to be transferred is much smaller (4K vs 64K).
Therefore, downloading these compact headers is roughly 16 times faster
then downloading the full headers.
For backwards compatibility with older firmware versions, there is an
automatic fallback to the full logbook headers.
The Shearwaters store the current dive mode for each sample, and not one
single value for each dive. Therfore we need to process all samples. If
there is at least one sample marked as closed circuit, we classify the
dive as a closed circuit dive. Otherwise we default to open circuit.
For devices without a logbook ringbuffer, such as the Oceanic Veo 1.0
and the Aeris XR-1 NX, the ringbuffer begin and end are identical. In
this case, the changes in the previous commit will always result in a
fatal error due to an invalid ringbuffer pointer. To avoid the error, we
exit before trying to use the pointers.
Until now, an invalid logbook pointer was silently ignored and handled
as an empty ringbuffer. But this hides real errors, which is worse than
failing if no dives are present. Trying to download dives from an empty
device should be a rather uncommon scenario anyway.
Now that we are able to parse the event bytes properly, there is no need
to pass the raw event bytes to the application.
In the current implementation, the vendor event was broken for devices
with multiple event bytes anyway. Because we deliver all event bytes at
once, the application doesn't know which bytes contain a valid value
(originating from the profile data) or just a dummy zero value.
Right now only gas switch and bookmark events are supported, because
none of the other uwatec events can easily be mapped onto the existing
libdivecomputer events. But the basic infrastructure for supporting more
events is in place now.
For obvious reasons, the -static-libgcc linker option is not supported
by non gcc compilers, like clang. Since we only need this option when
building Windows DLL's, we can easily avoid the problem with a
conditional on the mingw compiler.
The Shearwater Petrel 2 uses exactly the same communication protocol as
the original Petrel. Therefore the new model has always been supported
out, and we only need to add the new model to the list of supported
devices.
The id of the uwatec deco mix is always 2, even for devices which
support maximum two gas mixes. Strictly speaking, this change is more
correct than commit 4fd825cdac341a2d4a1366c6deb7d4a71bbdf94d, allthough
in practice they are equivalent.
The bitmask for the gas mix bits was wrong. With the new mask we also no
longer have to disable the alarm based gas switches for the Meridian and
Chromis.
Originally I assumed it's not possible to enable a gas mix if the
previous gas mix has already been disabled. However, this assumption
turns out to be wrong. For devices with support for 3 gas mixes, it's
possible to enable only the first and the third gas mix, and leave the
second gas mix disabled.
This is fixed by checking all gas mixes, instead of aborting once the
first disabled gas mix has been found. Due to this change the uwatec gas
mix id's are no longer sequential and need to remapped to the
corresponding internal array index.
It looks like the SAMPLE_EVENT_AIRTIME is actually meant for just
airtime warnings (as in the dive computer warning about low air).
If we ever care, I think we'd need to add a new interface for this.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Now that I actually have dives with the new format and with air
integration, I could test it all out and noticed some missing pieces.
This adds parsing for gastime and ventilation events (although we don't
*do* anything with the ventilation data, I have no idea what the number
means).
Also, this fixes an annoying warning message problem, which caused these
missing events to cause a SIGSEGV rather than just a bening warning.
Stupid bug, and only went unnoticed because libdivecomputer isn't built
with format string warnings.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This gets rid of the fixed sample indexes and the hardcoded grouping
code, and replaces them with proper parsing of the type descriptions.
This should mean that the new Suunto firmware v1.1.15 is now fully
supported by libdivecomputer.
There are still parts of the event description that we should really
parse better, notably the 'enum' descriptions of what the different
enumerated types mean, because it looks like those will change too. But
that is not nearly as important as getting the basic infrastructure done
for the core sample types.
Almost accidentally, this also ends up now parsing the compass heading
event.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
I was initially fooled into thinking that the field type numbers have
some meaning: the types didn't change if the upper byte of the type
number was zero. So I assumed that meant "fixed".
But the most recent firmware update made clear that no, they aren't
fixed, and the upper byte of the type must be some other thing.
This moves some more of the parsing over to comparing the strings,
rather than looking at the type index. It still leaves the sample data
alone, and I really want to do something more efficient than comparing
the type descriptor string for that, but at least the dive header fields
are now just comparing strings.
The actual marshalling that Suunto uses also describes the encoding, and
it's all ignoring that for now.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Suunto's new v1.1.15 firmware ends up terminating some final descriptor
lines with a newline, rather than just using newlines as separators. So
the last newline may not be followed by further data, but simple be the
end of the string. Accept that case.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is some small cleanup after the whole reply size rewrite. It
further improves on the error log reporting a bit, and it undoes the
"read exact size" thing introduced in "suunto eon steel: fix file
reading special case", because it is no longer necessary.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When reading data from the EON Steel, we'd generally continue reading
until we saw that a response was done by seeing a packet that wasn't
full.
That broke for the case of the data boundary matching the packet
boundary, fixed by the commit "suunto eon steel: fix file reading
special case".
However, that commit only fixed it for the case of reading a file, where
the result has a size that is known up-front. And most other situations
really don't matter, because the result size is fixed and fits in a
single packet, so it all works.
However, there are still a few cases that could trigger the problem,
notably reading the directory contents.
So change the send_receive() logic to actually read the expected size
from the receive header in the first packet of the reply. This means
that we need to re-organize the packet reception code a bit, but the end
result is that we are much more careful about data sizes,
This also changes the packet logging to be much more readable, by
logging just the actual data, and not the (uninteresting) per-packet
header, or the stale data at the end of the packet.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The "receive_data()" function would continue to try to read packets as
long as the previous packet was full-sized, but with just the right size
of file and the right chunking, the file might end at a packet boundary.
Then receive_data() would try to read more data, which fails - there are
no more packets, despite the last packet being full.
This never triggered for me, but Robert Helling forwarded a data dump of
a filure to read a dive due to this.
Since I don't trigger this case, I can't really test it, but I did check
that the new "stop early" logic works for me (ie never triggers ;).
Reported-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
