The Veo 1.0 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.
Sometimes there are a few garbages bytes received before the preamble
bytes. This typically happens when trying to download again after a
failed attempt. However trying to flush them immediately after opening
the serial port doesn't work.
When the OSTC receives the download dives command, it responds
immediately with the preamble bytes. But then it does a linear search
through its internal memory to locate the end-of-profile marker. As a
result the response time increases when the marker is located near the
end of the memory area. In the worst case scenario, the response time
can exceed the 3 second read timeout with a few milliseconds.
Since the required timeout depends on the total amount of profile
memory, this problem was indirectly introduced with firmware v1.91,
which doubled the amount of profile memory from 32K to 64K.
When using half-duplex communication (e.g. only a single wire for both
Tx and Rx) a data packet needs to be transmitted entirely before
attempting to switch into receiving mode.
For legacy serial hardware, the tcdrain() probably works as advertised,
and waits until the data has been transmitted. However for common
usb-serial converters, the hardware doesn't provide any feedback to the
driver, and the tcdrain() function can only wait until the data has been
transmitted to the usb-serial chip. There is no guarantee that the data
has actually been transmitted by the usb-serial chip.
As a workaround, we wait at least the minimum amount of time required to
transmit the data packet over a serial line, taking into account the
current configuration.
The OSTC doesn't store the start of the dive, but the exit time. Hence
the dive time needs to be substracted.
For dives with format version 0x21, we prefer the total dive time in
seconds stored in the extended header. This time value also includes the
shallow parts of the dive, and therefore yields the most accurate start
time. The dive time is rounded down towards the nearest minute, to match
the value displayed by the ostc. For dives with the older format version
0x20, this value isn't available and we default to the normal dive time.
When the dive mode setting is set to air, the oxygen percentage stored
in the header is different from the expected 21%. It might be the last
used nitrox percentage.
The assumption that two consecutive dive profiles are stored without any
gaps in between them, appears to be incorrect in some cases. Instead of
failing with an error we just skip those gaps now.
We received a report of a Darwin Air device which has a very high error
rate. The majority of the echo packets is incorrect, but since this
doesn't seem to have any effect on the actual data packet, we can just
ignore this error. If there happens to be a more serious error, it will
be detect in the data packet.
Sometimes there were also a some garbage bytes received at startup.
Adding a small delay seems to fix this.
The linux USB CDC-ACM driver, which is used by the Mares Icon HD
interface, doesn't support the ioctl's to configure a custom baudrate.
But since the actual baudrate doesn't seem to matter at all, we revert
back to the nearest standard baudrate.
Because custom baudrates are confirmed to be supported on Windows and
Mac OS X, those platforms can keep using the non-standard baudrate.
When trying to send the commands as fast as possible, without any delay,
the failure rate is very high. Almost every single packet fails with a
timeout at first. Retrying the packet works, but those many timeouts
make the download extremely slow. Adding a small delay avoids the much
more expensive timeout and speeds up the transfer significantly.
The Darwin and Darwin Air share a very similar layout, but with a few
differences here and there. Unfortunately, there seems to be no way to
autodetect the exact model during the download. Therefore, an extra
model parameter is added to select the appropriate model manually.
A side effect is that the mares_darwinair_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 init command appears to behave more like a hard reset. If the
command is sent during the communication, the device immediately closes
the connection and no further communication is possible without
disconnecting and reconnecting the device.
Sending the command at the start of the communication seems to require a
long delay before sending the next command. However the communication
works equally well without sending this command. For some devices it
even improves the success rate of the initialization sequence, and thus
there is no reason to keep it.
The packet size for the nemo and puck backends happens to be identical.
But the value for the nemo backend is truly fixed, while the value for
the puck backend can be adjusted. To avoid breaking the nemo backend
when changing the default value, we redefine the packet size explicitly
to the correct value.
The common device structure was used only for sharing the fingerprint
and layout descriptor, but the nemo backend doesn't even store a layout
descriptor, and the fingerprint can equally well be passed around as a
function argument.
Some devices are having problems during the initialization sequence. The
extra delay appears to improve the success rate for the affected
devices. There is obviously a small performance penalty, but being able
to establish a reliable connection with all devices is more important.
We received data from an Icon HD Net Ready with a model code equal to
0xFF, which is an invalid value. Fortunately we can figure out the
correct model code from the data in the version packet.
