The serial number is stored as a plain 32bit integer, and the device
shows the hexadecimal representation. Because a BCD encoding can only
represent the lower digits (0-9) of a hexadecimal number, the upper
digits (A-F) got mangled.
Reported-By: Nick Shore <support@mac-dive.com>
Although the settings sample will most likely always be located at the
start, it's better to be on the safe side and use an offset relative to
the start of the settings sample.
Reported-By: Nick Shore <support@mac-dive.com>
Starting with firmware v1.23, the OSTC3 settings can be configured
through the USB interface. There are new commands for reading, writing
and restoring the settings to their default values.
The workaround in the previous commit has a bug. If after a reset, the
first entry happens to be located near the end of the TOC, then after a
few dives, the TOC will overflow and new entries will be written at the
start of the TOC. But the current algorithm starts scanning the TOC from
the start and abort the scan as soon as an empty entry is found. Thus if
there are less than 256 dives present, those entries near the end will
never be reached.
We now ignore all uninitialized entries, when searching for the most
recent dive. An explicit safety check is added in case dives are
unexpectedly interleaved with empty entries.
Normally, the OSTC3 will always start writing dives at the first entry
in the TOC (Table of Contents). Therefore, uninitialized entries can
only be present after the last dive. However due to a minor firmware
bug, resetting the logbook erases the TOC but leaves the internal dive
counter unchanged. The consequence is that the next dive will still be
stored at the corresponding next TOC entry, while all previous TOC
entries have been erased.
As a workaround, we simply ignore uninitialized entries, unless we have
already found at least one dive.
With the switch to 4K data packets in the Icon HD backend, the internal
log buffer is no longer large enough for hexdumps of these data packets.
A hexdump needs twice the size of the binary data, plus some extra bytes
for the header and the terminating null byte.
The switch from downloading the entire data with a single large packet
to multiple smaller 256 byte packets, resulted in a considerable
performance regression. In one particular case, the difference was a
factor 6.7 slower!
I performed a small tests (using an Icon HD Net Ready) with 256, 1024
and 4096 byte packets, and the total time was respectively 21.0, 11.3
and 6.5 seconds. For a single large packet, the total time is only 5.9
seconds. Thus the difference with a 4096 byte packet is negligible.
The model number stored in the main memory isn't always the most
reliable source of information, because there are devices where the
model number has not been filled in properly. Instead, we check the
product name in the version packet against the list with valid names,
and return the corresponding model number.
As an additional advantage, we no longer depend on the model number
supplied by the application for selecting the correct memory layout.
Nevertheless, the model parameter is kept for backwards compatibility.
The recommended packet size is 256 bytes, which matches the maximal
amount of data that can be read back from the internal memory chip.
Larger requests are split by the firmware into multiple blocks of
maximum 256 bytes.
Note that initially, we already used 256 byte packets for the newer
models, but it seems this was accidentally changed to only 64 bytes in
commit ad0e187c0c932121efa50763afc02771633cbd61.
The main benefit of this change is a simplification of the code, because
now there is no longer a difference between the Icon HD and Matrix
variant of the protocol.
The Mares Icon HD use a processor with integrated USB circuit, which
presents itself to the host system as a CDC-ACM device. Since there is
no external usb-serial chip involved, the baudrate and other serial
line parameters are irrelevant. By choosing the same settings as the
later models, which do use an usb-serial chip, we can completely avoid
the problem of unresponsive devices due to using the wrong baudrate.
The serial number appears to be either a 24 or a 16 bit number, but
certainly not a 32bit number. Whether it's 24 or 16 bit is hard to
tell because the data we have available always contains a zero value
in the third byte.
The communication protocol and memory layout of the Cressi Giotto
appears to be identical to that of the Leonardo. The first byte seems
to be the model number, with 0x01 for the Leonardo and 0x04 for the
Giotto.
Gas mixes that have been marked as disabled are stored as the value 0xF0.
When interpreted as an oxygen percentage, this results in an out of range
value. Therefore, these gas mixes should simply be ignored.
Reading the data packet in multiple smaller chunks greatly improves the
progress events. Instead of just two events, before and after the
download, there are now many intermediate events. This change also
allows to significantly reduce the timeout, from 30 seconds to just one
second, which avoids blocking for too long in case the device doesn't
respond at all.
An infinite timeout causes major problems, because if the device doesn't
respond at all, the read call will block forever. With the eon serial
line settings (1200 8N2), the total time to read the 2305 byte packet is
about 21.129 seconds. A timeout of 30 seconds should be plenty of time.
The VT4.x memory layout appears to be slightly different from the Atom
3.x memory layout. The logbook ringbuffer does start at offset 0x420
instead of 0x400.
When using up to 14 bits for the depth, the resulting values are too
large in some cases. Most likely the upper bits are used to store
something else. Even with only 11 bits, the resulting depth range
(0-204.7m) should still be more than sufficient.
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.
The XTender 5 is identical to the other models in the Zeagle N2iTiON3
family, and can be added to the list of supported devices without any
further changes.
On Mac OS X, sending the slip packet byte by byte results in an abysmal
performance. The first byte takes up to 160ms to send, and each next
byte approximately 250ms. The packet to request a data block is
typically 7 bytes large, and therefore takes about 1660ms to send.
Because a dive is transmitted as multiple smaller packets (typically
144 bytes without protocol overhead), downloading a single dive can
easily take several seconds.
However, when sending the entire slip packet at once, the time remains
roughly identical to sending just the first byte. The result is that
the time for sending a packet reduces significantly, proportional to
the length of the packet.
Under the hood, the slip packet is now internally buffered, and the
buffer is send only when the entire packet is complete, or whenever the
buffer gets full. But in practice, the buffer is large enough to always
store an entire packet.
In the original bug report, downloading 57 dives took about 40 minutes.
After applying the patch, that time reduced to only 5 minutes!
The new Oceanic OCi appears to be almost identical to the already
supported Oceanic OC1. The most important change is the different
location for the logbook ringbuffer.
The profile ringbuffer appears to be slightly smaller than expected for
some models. For the Mares Matrix (and all compatible devices) it ends
earlier, while for the Icon HD Net Ready it starts later.
This bug resulted in missing dives, because all remaining dives were
getting dropped once a dive that crossed the ringbuffer boundary was
reached.
The logbook ringbuffer appears to start at offset 0x400 instead of
0x240. Since these ringbuffer boundaries have to be taken taken into
account only once the ringbuffer has been filled completely, this bug
affects users with more than 200 dives only. Thus, no surprise it didn't
get noticed earlier.
Several backends require a shutdown command to be send before closing
the connection. If such a command gets cancelled, that might result in
an unclean shutdown. Backends where this is problematic can always
ignore cancellation requests internally, but it's less error-prone (and
much easier) to simply disable the cancellation callback for all
backends, before closing the connection.
