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.
The "\\.\" prefix allows to access the Win32 device namespace directly,
without going through the file system. This is required to support
non-standard port names, and COMx ports with a number greater than 9.
The Aeris Elite T3 appears to update the global logbook pointer
incorrectly when overwriting old dives. As a result there can be logbook
entries pointing to profile data that has already been overwritten with
newer dives, and those cause problems when calculating the total amount
of bytes in the profile ringbuffer.
As a workaround we validate the logbook pointers immediately after
downloading. At this early stage we can check manually for ringbuffer
overflows without having to rely on the values stored in the data.
Because the user needs to initiate the transfer on the device itself, we
have to wait for an unknown amount of time. The infinite timeout works,
but causes problems if the data never arrives. By polling the serial
line, an application can at least cancel the operation.
