The Uwatec Meridian protocol is identical to the Uwatec Smart/Galileo
protocol, except for some additional framing around each data packet,
and the switch from IrDA to usb-serial communication. For parsing, the
data format appears to be identical to the Galileo data format.
When updating the firmware while the OSTC is running in normal mode, the
V2 protocol should be used. However, the OSTC can also be rebooted from
the menu or reset using the magnetic switch, and then the V1 protocol
should be used. The only difference with the V2 protocol is the slower
baudrate (19200 vs 115200).
True autodetection of the protocol variant is difficult, because the
bootloader will abort the firmware update when not receiving a 0xC1
byte. But we can still take advantage of the fact that the normal
firmware does ignore any 0xC1 bytes sent at the wrong baudrate, and
probe with the V1 protocol first. If the bootloader is already running,
it will respond immediately and we're done. If the normal firmware is
still running, it won't respond and the probing with the V1 protocol
will fail. If we then switch to the V2 protocol, the firmware update
will continue as before.
The result is a firmware updater which supports both bootloader
protocols without requiring any manual configuration.
This is only a cosmetic change, to make the IrDA device address on
Windows consistent with the address Linux. There is no functional
difference because the address is always serialized and deserialized
internally, and applications shouldn't care about the actual number.
Anyway, the difference in endianness is easy to notice because the
Uwatec Smart family of devices use the serial number as the IrDA device
address. On Linux, the address was identical to the serial number, while
on Windows the byte order was reversed.
For the time being, the serial port enumeration code is of very limited
use. It's not used anywhere in the library, and as an internal api it's
also not available to applications. It serves mainly as a reference
implementation for future use.
The Aeris XR-1 NX has very limited memory and doesn't have a
logbook and profile ringbuffer. Hence downloading dives isn't
really supported, but even this limited amount of data might be
useful for someone.
Unlike the corresponding mktime C library function, the libdivecomputer
function will never modify its argument. By marking the parameter as
const this is made more explicit.
The firmware version and serial number are stored in the final block
of each dive. That makes it very tricky to support the devinfo event
correctly. For an efficient implementation of the fingerprint feature,
the devinfo event should be emitted before downloading the manifests
or the dives. Fortunately it turns out it is actually possible to
retrieve the firmware version and serial number independently, using
the special identifier command.
A shutdown command should be send to the device, before the connection
is actually closed. In the absence of this command, the device will
display an error, even if the data transfer itself was successful!
The only difference with the two other Oceanic OC1 variants is the new
model number. I have absolutely no idea what's the purpose of such a
silly change.
The Mares Matrix, Puck Pro and Nemo Wide 2 have only 256K of memory,
which is 4 times less compared to the Icon HD. However for some unknown
reason, trying to download 1024K succeeds, and these devices just
repeat the same data 4 times. That's why we never noticed the
difference in memory capacity before.
The Suunto DX has support for 8 gas mixes (OC) and 3 diluents (CC).
Because it's still unknown how rebreather dives are stored, we simply
return all 11 gas mixes. For the rest, the DX data format is very
similar to that of the existing Suunto models, with only a few
different offsets here and there.
When the number of parameters is zero, there are no sample values, and
the offset variable is never increased. The result is an infinite loop.
In practice this shouldn't happen because there should always be at
least one sample value (e.g. depth). But if a new data format is
available, which is not yet supported by the parser, we might be trying
to interpret the wrong byte.
A side effect is that the mares_iconhd_extract_dives function now
requires a valid device handle. This shouldn't cause any real problems
because this function will likely become private some day.
The new xml element makes the the gaschange events stand out more
against the other less important events. At the same time it also
demonstrates the decoding of the packed oxygen and helium percentages.
Without the root element the output isn't valid xml. Although the
output is supposed to provide a human readable representation for
internal use only, and thus never really intended for processing by
third-party applications, it doesn't hurt to turn it into valid xml
either.
In the public header files, all symbols are marked extern C. When using
a C compiler, there is usually no problem if the header isn't included
in the C file. But the msvc build system uses the C++ compiler (due to
the use of some C99 features not supported by the msvc C compiler).
Currently all device descriptors are included, regardless of whether
the device is actually supported by the library. If IrDA or USB support
is unavailable, a dummy backend is build which will always fail with
DC_STATUS_UNSUPPORTED. Thus there is no point in listing those devices
as being supported. Doing so will only confuse end-users.
Although the communication protocol of the OSTC3 is nearly identical to
that of the Frog, the different size parameters make it hard to share
the code easily. On top of that, if we ever implement native bluetooth
communication support, we'll need a completely separate backend anyway.
Therefore the Frog backend is simply duplicated, with a few OSTC3
specific changes applied here and there.
The existing ostc parser is upgraded to support the new OSTC3 data
format.
The Frog stores the index of the initial gas mix at the same location
as the OSTC, but the gas mix percentages are at a different offset, and
the number of gas mixes is different too. Parsing all the gas mixes in
advance makes the code easier to read and more future proof.
With the layout descriptors, most hardcoded constants are now in a
central place, which will make it easier to add support for new data
format variants.
If the gas model flag is set to air, the individual gas mix definitions
are ignored, and a single mix with air is returned instead. For non-air
dives, only the gas mixes marked as active are returned.
Sometimes there are garbage bytes present after opening the serial
port, which causes the communication to fail. Flushing the buffers
after a small delay is all it takes to get rid of those bytes.
The React Pro White appears to be a newer variant of the React Pro. For
the communication it uses the newer atom2 protocol, but the data format
remains (almost) the same as the older React Pro.
This model doesn't support a 2 second sample rate. It appears the
possible sample rate values have been shifted by one to map the value
zero to a 15 second sample rate.
To avoid any trouble with possible out of range values, the index is
shifted in a circular way.
There are two good reasons for this change. First of all, it makes the
Predator data format more consistent with the Petrel data format, which
also has the final block appended to each dive. But even more important
is that we might actually need the information stored in the final block
someday.
The final block contains important information about the device, such as
the firmware and logbook version. Right now this information is simply
lost after the download. But if the data format ever changes to support
some new feature, we'll likely need that information to autodetect the
correct format.
Unfortunately this also changes the dive format in a non-backwards
compatible way. However, to minimize the inconvenience, the legacy
format (without the extra final block) remains supported in the parser.
Because the size of a dive isn't known in advance, we use the worst case
value of 0xFFFFFF (or nearly 16MB). However in practice, the real size
is many orders of magnitude smaller, even after the decompression.
Instead of pre-allocating a huge memory buffer, we now start with a much
smaller one, and increase when necessary.
For the predator and petrel manifests, where the size is known in
advance, we continue to pre-allocate the exact amount of memory as
before.
The Petrel (with updated firmware) supports an enhanced communication
protocol, which is more efficient and powerfull than the legacy Predator
compatibility mode. The new protocol uses data compression for faster
transfers and supports the ability to selectively download individual
dives. Last but not least, the new protocol isn't limited to the last
128kB of logbook data, but can access the full logbook capacity (16MB).
