Correctly skip the 4 byte length in front of the sample data. The
previous code happened to work by accident, because the header after the
sample data was assumed to be 4 bytes larger, and thus those two errors
cancelled each other out.
These new models use a faster baudrate. The correct baudrate is detected
by probing with the version command. To speedup the detection, the model
code can be supplied by the caller as a hint, which is then used to
start the autodetection directly with the correct baudrate.
To maintain backwards compatibility, the model hint is not enabled yet.
The sample configuration data describes which sample data is available
and how it is stored. Using this data should be more reliable than using
a hardcoded configuration.
With the support for custom baudrates on all systems, there is no need
anymore to use the nearest standard baudrate. Using the exact baudrate
should make the communication more reliable on Unix systems.
Some of the older firmware versions contain a critical bug that can
possibly crash the device when trying to download dives, and also a bug
in the checksum calculation. To avoid these problems we simply refuse to
download when an old firmware is detected and require the user to
upgrade the firmware first.
The detection is performed by means of a new version command which
allows to retrieve the device information prior to downloading the
dives, but is only supported by recent firmware versions.
As a side effect, we gain access to the current firmware version, which
may be different from the one recorded during the last dive. And we can
get the info even if there are no dives present.
For the devices in the list below, the last 512 bytes of the memory area
are not part of the profile ringbuffer. The real purpose of these bytes
is currently unknown.
Oceanic Atom 2.0 (firmware 3I or greater)
Oceanic Geo 2.0
Oceanic OC1
Oceanic ProPlus 2.1
Oceanic Veo 2.0
Oceanic Veo 3.0
Sherwood Insight
Sherwood Wisdom2
Tusa Element II
Tusa Zen
Tusa Zen Air
Some but not all of these devices also have an unreadable last page,
making the autodetection code even more complex.
Some Veo devices never respond to the initialization command, but have
no problem to continue the communication. Therefore a timeout with no
data received is ignored. If there happens to be a real problem, it will
be catched when sending one of the other commands afterwards.
