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>
When compiling a 32bit dll with the mingw-w64 compiler, some 64bit
integer arithmetic operations are implemented using functions from
libgcc (e.g. __divdi3 and __moddi3 from libgcc_s_sjlj-1.dll). This
unexpected dependency is inconvenient for applications.
The run-time dependency can be avoid by linking statically.
reefnet_sensusultra_device_set_maxretries was killed off back in v0.3,
but was still lying around in the public header.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
At least one Oceanic Geo is unable to download the last memory page.
However, another device with an older firmware version (version 1D
instead of 2B), does not have this problem. So in theory the correct
layout depends on the firmware version.
But since the profile ringbuffer also appears to end at the address
0xFE00 instead of 0x10000, we'll never need to download that last page
in practice. Thus we can be lazy and simply use a single layout for all
firmware versions. The only drawback is that the last page might be
missing when downloading a full memory dump.
Applications are supposed to lookup the fingerprint when the devinfo
event is emitted. For the Uwatec Smart devices, the fingerprint is the
raw device timestamp. But because this timestamp was already used to
initialize the command before emitting the event, an outdated value
(typically the default value of zero) was used instead of the correct
one set by the application.
