Due to a firmware bug, the deco/ndl info is incorrect for all OSTC4
dives with a firmware older than version 1.0.8. Since it's not possible
to correct the info again, it's ignored and not returned to the
application.
The OSTC4 firmware version uses four digits for the firmware version
(X.Y.Z.Beta), while all other hwOS models use two digits (X.Y). To
preserve backwards compatibility with the existing two byte data format,
the OSTC4 firmware version is packed into a 16 bit integer as follows:
XXXX XYYY YYZZ ZZZB
and stored with little endian byte order.
To be able to pass the OSTC 3 model number to the parser, and preserve
backwards compatibility, we need a new function. The new function should
also be used for the Frog, by passing zero as the model number.
Using the hw_ostc_parser_create() function with the hwos parameter set
to one, is now deprecated but will remain supported for backwards
compatibility.
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.
When the device family is provided without an explicit model number, we
simply choose the first available model. But since new models are being
added all the time, this default model is not guaranteed to remain the
same. That's not desirable because it can alter the behaviour of the
application.
The introduction of the Aeris 500AI is an example of this problem. The
default model in the vtpro family used to be the Oceanic Versa Pro. But
because the Aeris 500AI has a lower model number, it automatically
became the new default model. Since both use a different protocol
variant (MOD vs INTR) they are not interchangable.
The default model is now hardcoded. The best option is of course to
provide the model number explicitly!
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.
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.
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.
Libdivecomputer always uses metric units internally. But when reverse
engineering a device that stores everything using imperial units, it's
very convenient to be able to switch the output to imperial units too.
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.
