Several devices (e.g. Oceanic Geo, Oceanic Veo 2.0 and Tusa Zen) report
a maximum depth that is clearly too large. The problem is easily fixed
by ignoring the higher bits. The exact bit mask is an educated guess. A
12 bit value is plausible because it's also used for the sample depths.
In freedive mode, samples are only 2 or 4 bytes large, thus a sample
containing all 0x00 bytes represents a zero depth value and not some
invalid data that should be ignored.
I originally assumed the second byte contains the hour, but that turns
out to be wrong. At least some of the bits have a different meaning.
With only seconds and minutes, the maximum divetime is limited to at
most 99 minutes and 59 seconds. That shouldn't be a problem for
freedives.
The Oceanic and Aeris F11 have a configurable sample rate. The possible
sample intervals are 2, 1, 0.5 and 0.25 seconds. Since our smallest unit
of time is one second, we can't represent the last two, and the extra
samples will get dropped for now.
Both the allocation and initialization of the object data structure is
now moved to a single function. The corresponding deallocation function
is intended to free objects that have been allocated, but are not fully
initialized yet. The public cleanup function shouldn't be used in such
case, because it may try to release resources that haven't been
initialized yet.
Instead of freeing the object data structure in the backend specific
cleanup function, the memory is now freed automatically in the base
class function. This reduces the amount of boilerplate code in the
backends. Backends that don't allocate any additional resources, do no
longer require a cleanup function at all.
To store the day (range 1 to 31) as a binary encoded value, only 5 bits
are required. The extra 6th bit is part of the year. The year is also
not BCD encoded. This happened to work by accident, because for a single
nibble, the current implementation of the bcd2dec() function returns the
binary value.
The new gasmix sample contains the index of the active gas mix.
This new sample is intended as a replacement for the existing gas change
events (SAMPLE_EVENT_GASCHANGE and SAMPLE_EVENT_GASCHANGE2). To maintain
backwards compatibility, the legacy events are marked as deprecated but
not removed yet.
In freedive mode, the Oceanic Veo 2.0 and 3.0 have samples that are only
4 bytes long, instead of the normal 8 bytes.
The Oceanic VT3 and Hollis DG03 use the same logbook layout, and
although I haven't been able to confirm this with real data, it's very
likely they need the same fix.
The Oceanic VTX is very similar to the Aeris A300 CS. The main
difference is the higher baudrate (115200 vs 38400). This is annoying
because without the correct baudrate, no communication is possible and
thus the existing autodetection based on the version packet doesn't
work. As a workaround, we now rely on the model number from the device
descriptor. The consequence is that the user must select the correct
model now (or at least a model with the same baudrate).
In freedive mode, the Aeris Elite T3 has samples that are only 2 bytes
long, instead of the normal 8 bytes.
Since there are many other models which support a freedive mode, the new
implemention provides the necessary infrastructure to easily integrate
those other models too.
Adds the new model and treats it like a Wisdom 2 (and many other, similar
versions of the Oceanic Atom2 style dive computers).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This change was already present in the oceanic_atom2_parser_get_field()
function, but not in the oceanic_atom2_parser_samples_foreach()
function. These two should always be kept in sync.
This fixes a bug in the tank pressure detection.
Most of the changes needed for the F11 are the standard model specific
tweaks. But the F11 also has another interesting "feature". If you try
to download a full memory dump using the standard B1 read command, then
the data starts to repeat after the first 64K. It seems that somehow,
the B1 command can only address the first 64K of the memory. To avoid
this problem, the newer B4 read command needs to be used instead.
This might be a firmware bug, or maybe internally they store the address
in a 12bit variable, which causes the upper bits to get lost? That would
explain the repeating data.
