The resolution of the GetTickCount function is limited to the resolution
of the system timer, which is typically in the range of 10 to 16
milliseconds. This is unsufficient for measuring very short time
intervals in the milliseconds range. The QueryPerformanceCounter
function provides much higher resolution timestamps. We already use it
for the half-duplex workaround.
Parsing the gas switch events is somewhat complicated, because depending
on the actual model, they can be stored in different ways.
The table below lists the number of gas mixes (G), tanks (T) and alarm
bytes (A) supported by each model. Note that only the representative
model in each group is listed.
Model | G | T | A
==============|===|===|===
Pro | 1 | 0 | 1
Com | 1 | 1 | 1
Tec | 3 | 3 | 1
Aladin Tec | 1 | 0 | 2
Aladin Tec 2G | 3 | 0 | 2
Galileo | 3 | 3 | 3
Models without support for multiple gasmixes only need to set the
initial gas mix correctly. Models with support for one or more tank
pressure sensors can link the gas switches to the tank switches. Models
with at least two alarm bytes can store a gas switch event in the second
alarm byte.
As can be observed from the table, some models can use several different
methods to store the gas switches. The current implementation supports
all of them. In the case of a conflict, the last used method always
takes precedence. That's simply due to the fact that each method just
sets the gasmix index, and only the final value is used. If this
approach turns out to produce wrong results, it can always be fixed
later.
The initial gasmix is always assumed to be the first configured gasmix.
One byte is already more than sufficient to store an oxygen percentage.
Using two bytes doesn't cause any problems for some models, because the
upper byte is always zero, but for other models that's not the case.
Most likely this upper byte is used to store something else.
Internal, these two models use exactly the same data format. For those
features which are only available on one of the models, the
corresponding data fields are set to their unused values. For example,
the Smart Tec supports up to three gasmixes, while the Smart Z supports
only one gasmix. But although the Smart Z has storage reserved for up to
three gas mixes, only the first one is ever used.
For the Galileo Trimix, the header length isn't fixed. The actual length
depends on whether the dive has the trimix setting enabled or not.
Because at this point we're still trying to determine the length of the
header, it hasn't been checked yet and an extra check is necessary.
Because for selecting the correct header and sample tables (and
associated data) only the model number is necessary, they can easily be
stored inside the device handle. The main benefit is less duplicated
code.
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.
