The vendor_product_parser_create() and vendor_product_device_open()
functions should be called indirectly, through the generic
dc_device_open() and dc_parser_new() functions. And the
vendor_product_extract_dives() functions are internal functions that
should never have been part of the public api in the first place.
The Aqualung i450T appears to ignore the fixed sample rate and instead
store a timestamp in each sample.
The presence of the surface samples in combination with this timestamp
based format is odd. Even the official Diverlog software is confused:
the Windows versions seems to ignore them, but the Mac version takes
them into account.
After the previous commit, the raw data is now reported with one large
vendor sample. Because that makes the data more difficult to interpret
(for example during debugging), a small helper function is added to
split the data again in multiple vendor samples.
Originally, the time and vendor sample values are emitted immediately
after the previous sample is complete. This is now postponed until all
raw samples are available.
This will be required for the Aqualung i450t. That model appears to
ignore the fixed sample rate and instead store a timestamp in each
sample. That means the timestamp is only available once the last raw
sample data has been reached.
Skipping the extra samples by increasing the length is not always
reliable. If there are empty samples present, they will get skipped
instead of the real samples. And if the number of samples isn't an exact
multiple of the samplerate, we're accessing data beyond the end of the
dive profile.
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.
