This is ignoring a ton of data that the dive computer provides. But it
gives profile, tank pressure and temperatures - so it's a start.
This patch adds a set_dtr and set_rts call to the serial interface prior
to interacting with the device. This change is required for the A300CS to
talk to the computer.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Although the OSTC Sport uses bluetooth communication, the new model
remains fully compatible with the OSTC3, because it provides a virtual
serial port interface. As usual, the new model can be detected based on
the serial number.
The Hollis TX1 has several new features compared to the other models. It
supports trimix and up to 6 different gas mixes can be configured. It
also has twice the amount of memory, which requires an extra bit for the
ringbuffer pointers.
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.
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.
The new Oceanic OCi appears to be almost identical to the already
supported Oceanic OC1. The most important change is the different
location for the logbook ringbuffer.
This dive computer has the same enclosure as the Mares Puck, but the
wire protocol is that of the Puck Pro. The original software identifies
it as a "Mares Puck 2", and the handshake string also contains the
sequence "PUCK 2", so this string is used to identify the device.
The Aeris XR-1 NX 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 only difference with the two other Oceanic OC1 variants is the new
model number. I have absolutely no idea what's the purpose of such a
silly change.
The Suunto DX has support for 8 gas mixes (OC) and 3 diluents (CC).
Because it's still unknown how rebreather dives are stored, we simply
return all 11 gas mixes. For the rest, the DX data format is very
similar to that of the existing Suunto models, with only a few
different offsets here and there.
Currently all device descriptors are included, regardless of whether
the device is actually supported by the library. If IrDA or USB support
is unavailable, a dummy backend is build which will always fail with
DC_STATUS_UNSUPPORTED. Thus there is no point in listing those devices
as being supported. Doing so will only confuse end-users.
Although the communication protocol of the OSTC3 is nearly identical to
that of the Frog, the different size parameters make it hard to share
the code easily. On top of that, if we ever implement native bluetooth
communication support, we'll need a completely separate backend anyway.
Therefore the Frog backend is simply duplicated, with a few OSTC3
specific changes applied here and there.
The existing ostc parser is upgraded to support the new OSTC3 data
format.
The React Pro White appears to be a newer variant of the React Pro. For
the communication it uses the newer atom2 protocol, but the data format
remains (almost) the same as the older React Pro.
The Petrel (with updated firmware) supports an enhanced communication
protocol, which is more efficient and powerfull than the legacy Predator
compatibility mode. The new protocol uses data compression for faster
transfers and supports the ability to selectively download individual
dives. Last but not least, the new protocol isn't limited to the last
128kB of logbook data, but can access the full logbook capacity (16MB).
With the new interface, an application can easily retrieve the
underlying transport type from the device descriptors and present a
custom user interface element to the end-user for supplying transport
specific parameters. For example the serial port for devices using
serial communcication.
For devices using a usb-serial chipset or the bluetooth Serial Port
Profile (SPP/rfcomm), the transport type is DC_TRANSPORT_SERIAL, because
internally the serial emulation layer is used for the communication.
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.
