The frog parameter and field are not only used for the Frog, but also
for all hwOS based models. Therefore, using the more generic hwos as the
name is more meaningful.
For applications supporting offline parsing (like libdivecomputer's own
dctool application), some device specific knowledge is still required in
order to map a particular model to the corresponding backend. The new
convenience function will take care of that internally.
The already existing dc_parser_new() function does the same, but
requires an open device handle, which makes it unsuitable for offline
parsing.
The Aeris 500AI is quite different from the other vtpro compatible
models. First, it uses the INTR protocol variant. Next, it doesn't
appear to have a logbook ringbuffer. Instead it supports a new read
logbook index command (0x52) that returns the logbook entries. This
requires a custom implementation of the logbook function.
There are two variants of the vtpro communication protocol: the existing
MOD variant and the new INTR variant. The main difference is in the
initialization sequence, with two completely different response packets:
MOD--OK_V2.00
INTR-OK_V1.11
The INTR variant does not appear to return useful information in the
version packet.
By adding the logbook and profile functions to the vtable, a dive
computer backend can now easily replace the default implementation with
a custom one, without having to duplicate the common code.
The large and complex oceanic_common_device_foreach() function is
refactored into two independent helper functions. One for reading the
entries in the logbook ringbuffer, and another for reading the profile
data.
To guard applications from divisions by zero, the progress event code
asserts the maximum value should always be non-zero. The eonsteel does
trigger this assert when there are no dives present.
Mares Darwin compatible devices support a nitrox mode. The nitrogen
percentage should only be taken into account when the dive mode is set
to nitrox, because the last used value remains in place for air dives.
Errors reported by system calls are now converted to the corresponding
libdivecomputer status code. This results in a more descriptive and
meaningfull return value.
The low level serial and IrDA functions are modified to:
- Use the libdivecomputer namespace prefix.
- Return a more detailed status code instead of the zero on success and
negative on error return value. This will allow to return more
fine-grained error codes.
- The read and write functions have an additional output parameter to
return the actual number of bytes transferred. Since these functions
are not atomic, some data might still be transferred successfully if
an error occurs.
The dive computer backends are updated to use the new api.
The devinfo event with the device serial number is required for the
fingerprint feature. Without this event, applications won't be able to
load (or save) the correct fingerprint. All necessary information is
already available in the initial handshake packet.
A new buffer is allocated for each dive, but only the last one is freed.
Since the code is already prepared to simply re-use the same buffer,
there is no need to allocate those extra buffers.
Just like the D4i and D6i, the new header is a few bytes larger. The
correct variant can again be detected by means of the logbook id tag at
the start of the header.
The Shearwater devices support adding, removing or editing gas mixes
during the dive. The pre-defined gas mixes available in the opening and
closing block are only a snapshot of the configuration at the start and
at the end of the dive. Thus by editing the gas mixes during the dive
it's possible to switch to a gas mix that is not present in the opening
(or even the closing block). The parser doesn't support that.
To avoid this problem, we now collect the available gas mixes from the
sample data. As a side effect we only return those gas mixes that are
effectively used during the dive.
One of the newer D4i and D6i firmware versions (for example v1.5.9),
introduces a new variant of the data format. The new dive header is 8
bytes larger. The correct variant can be detected by means of the
logbook id tag at the start of the header.
By reading the hardware descriptor immediately after entering download
or service mode, we can identify the specific model and adapt to minor
differences in the communication protocol.
For the OSTC3 compatible devices, a missing initial gas mix (e.g. no gas
marked as the first gas) leaves the initial gas mix index at its default
value of zero. This is different from the OSTC2 compatible devices,
where a missing initial gas is stored as the value 0xFF.
By initializing the index with the value 0xFF, the existing detection
works for both variants.
Unlike the other socket functions, the WSAStartup() function returns the
extended error code directly. A call to the WSAGetLastError() function
is not needed and should not be used.
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.
