This is only a preliminary version. There is certainly some room for
improvement, but the basic functionality is already in place. That
should be sufficient for daily use, and possibles issues can always be
fixed when discovered.
The Matrix uses the same communication protocol as the Nemo Wide 2,
except that the sending the request packets with just a single write
operation doesn't seem to work. That's very surprising because it
caused no problems for the Nemo Wide 2 or the Icon HD!
The first two bytes of each request packet are probably some kind of
command type. These two bytes are answerred immediately with an ACK
byte (0xAA). Once this ACK byte has been received, the payload of the
command (if any) can be sent, and finally the response packet can be
received.
I suspect that when trying to send the entire command at once, the
device somehow doesn't receive the payload bytes correctly. Maybe it's
still busy processing those first two bytes, which causes the remainder
of the packet to get dropped? That might explain why the version
commands is not affected, because it doesn't have any payload bytes!
The Nemo Wide 2 uses the same communication protocol as the Icon HD,
except for two differences:
The Nemo Wide 2 requires a different baudrate and parity setting.
Unfortunately it doesn't seem possible to autodetect the correct
protocol variant at runtime. Attempting to proceed with incorrect
settings will render the device unresponsive and requires a battery
reset to recover.Therefore the model code needs to be provided as an
extra parameter, when opening the connection.
The Nemo Wide 2 also appears to have trouble downloading the entire
memory with a single request. Therefore the single large request is
split into many smaller ones. The offical Mares application uses 256
byte packets, and so do we. The Icon HD keeps using the large packets
because they are significant faster.
The extra model parameter breaks backwards compatibility!
The Petrel is slightly different from the Predator because the device
reorders the internal ringbuffer before sending the data. The most
recent dive is always the first one, and there is no need to search for
it, like we have to do for the Predator.
The exact OSTC variant can be detected by means of the serial number.
Each of the three variants is now assigned an artifical model number,
and included explicitly in the list of supported models.
There appears to be two very different versions of the Sherwood Insight.
The old Insight needs the veo250 backend, while the newer Insight 2
needs the atom2 backend. Currently only the newer version was included
in the list of supported devices, and to increase the confusion it was
even named after the old version.
With this patch, the old version is added to the list, and the new
version is renamed to "Insight 2".
Applications can now enumerate all the supported devices at runtime,
and don't have to maintain their own list anymore. The internal list
does include only those devices that have been confirmed to work at
least once without any major problems.
As the name already indicates, a device descriptor is lightweight
object which describes a single device. Currently, the api supports
getting the device name (vendor and product) and model number. But
this can extended with other features when necessary.
