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.
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.
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.
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.
Especially the version commands seems to be sensitive to errors. Once
the initialization phase is over, a delay is usually not necessary, but
it should cause a noticable slowdown either because errors are supposed
to be rare.
When trying to read the last memory page from an Oceanic Atom 2, the
device does not respond. Strangely, other compatible devices are not
affected by this problem.
The Geo 2 appears to respond with a single NAK byte instead of three.
The issue is fixed by expecting only a single byte, and flushing the
serial line to discard all other bytes (if there are any).
To be able to cancel an operation, an application should register a
callback function that returns a non-zero value whenever the active
operaton should be cancelled. A backend can invoke this callback function
to query the application for a pending cancellation request.
A helper function is added to simplify implementing the devic_dump()
function on top of the device_read() function, and enable progress
events automatically.
Using a resizable memory buffer allows to allocate the right amount of
memory inside the backend, avoiding having to know the required buffer
size in advance.
The logbook ringbuffer is now considered empty if any of the pointers is
outside the valid ringbuffer area. Compared to checking only against a
special empty value, this approach makes the code more robust against
invalid pointers.
Introducing a common base class allows to share more code between the
backends. Sharing the fingerprint data eliminates the need to pass it
with a function parameter.
