The universal application works well, but is quite difficult to extend
with more functionality. Therefore a new and more modular application is
needed. The new dctool application will support multiple sub-commands,
to carry out specific actions. Extending the application will be as easy
as adding new commands.
The new gasmix sample contains the index of the active gas mix.
This new sample is intended as a replacement for the existing gas change
events (SAMPLE_EVENT_GASCHANGE and SAMPLE_EVENT_GASCHANGE2). To maintain
backwards compatibility, the legacy events are marked as deprecated but
not removed yet.
Basic Suunto EON Steel downloading copied from my test application.
This parses all the core dive data, including sample data (time, depth,
cylinder pressure, deco information etc).
The deco information returns ceiling and TTS rather than ceiling and
"time at ceiling", because that's what the dive computer has, and I
don't see any other way to return the information.
We don't report any events yet, though.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Devices that only reports a single temperature in the header
will now be able to report it as well when they implement this.
Signed-off-by: Calle Gunnarsson <calle.gunnarsson@gmail.com>
The resolution of the GetTickCount function is limited to the resolution
of the system timer, which is typically in the range of 10 to 16
milliseconds. This is unsufficient for measuring very short time
intervals in the milliseconds range. The QueryPerformanceCounter
function provides much higher resolution timestamps. We already use it
for the half-duplex workaround.
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.
This event is on when accumulating deco time. Once you reach the floor
deco time will start decreasing and the event will stop. Going below the
floor again will re-activate the event.
Signed-off-by: Michael Andreen <harv@ruin.nu>
The new xml element makes the the gaschange events stand out more
against the other less important events. At the same time it also
demonstrates the decoding of the packed oxygen and helium percentages.
Without the root element the output isn't valid xml. Although the
output is supposed to provide a human readable representation for
internal use only, and thus never really intended for processing by
third-party applications, it doesn't hurt to turn it into valid xml
either.
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 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).
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 application shouldn't have to deal with the delay between packets.
If the default value isn't good enough, that should be fixed internally
and not on the application side.
The version.h header file is generated by autoconf and therefore
located in the build directory and not the source directory. If
building out-of-tree, and a version.h header file is accidentally
present in the source tree, the wrong file will be picked up.
By reversing the order of the include directories, the build directory
is searched first, and the correct header file will be used.
The new vendor event provides a mechanism to deliver auxiliary data,
which is automatically retrieved during the data transfer, but not
accessible through the library interface otherwise. Possible examples
include handshake data and/or device identification data.
This event is mainly intended for diagnostic purposes, in combination
with the memory dumping support. Very few applications will actually
need it for anything else.
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 example application is updated to support the new setpoint,
ppO2, CNS and decompression samples that have been introduced. The
NDL event is removed again.
The Uwatec Smart protocol supports reading individual settings. However
the version functions only reads those three values that we use
internally (model, serial number and device clock). That's a very
arbitrary subset and it would be much better to support reading
specific values. But that's something for later...
The version function requires device specific knowledge to use it (at
least the required buffer size), it is already called internally when
necessary, and only a few backends support it. Thus there is no good
reason to keep it in the high-level public api.
These macros are used internally and don't need to be exposed. In some
cases, the actual values are not even constant, but dependant on the
model and/or the firmware version.
