This method can be used by external applications to open a
device and to pass their custom implementation for the
serial communication.
Signed-off-by: Claudiu Olteanu <olteanu.claudiu@ymail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Create a custom open method for HW OSTC3 family.
This method can be used to pass a reference to a dc_serial_t
structure. In this way the applications can implement their
own implementation for a serial communication and set their
callbacks for the basic serial functions.
Signed-off-by: Claudiu Olteanu <olteanu.claudiu@ymail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Open a native serial device and use it in the HW OSTC3
implementation.
This patch replaces the old serial structure with the
new one, which can be used for custom serial implementations.
Signed-off-by: Claudiu Olteanu <olteanu.claudiu@ymail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Add a structure which holds references to basic operations
on a serial communication. This can be used to pass a set
of function pointer callbacks in order to create a custom
implementation for serial communication.
Add a generic structure to represent the needed information
for a serial communication.
Implement the initialization method where the user can
pass a set of function pointer callbacks and set some
custom data for the serial device.
Create open method for the native serial implementation.
Signed-off-by: Claudiu Olteanu <olteanu.claudiu@ymail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Add a new transport type which can be used to identify
Bluetooth serial communication.
Signed-off-by Claudiu Oleanu <olteanu.claudiu@ymail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We have the correct firmware in the devinfo, but that's the firmware the
dive computer is on NOW, not necessarily the firmware it was using when
recording the dive.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This has been verified with a few of the models, it needs much more
testing to make sure this is generally correct.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This can be used to return almost arbitrary information to the dive log
application at dive parse time, by returning a number of strings (with a
descriptor) for dive state.
NOTE! The strings are supposed to be human-readable, so that the dive
log application can just show them unedited - and without understanding
them - to the user, together with the description. So if your dive
computer supports returning a battery voltage, for example, you can
return it as a
{ "Voltage", "4.449V" }
descriptor/value string pair, and the application could then put these
string pairs together and show (somewhere) an informational line like
"Voltage: 4.449V" along with the other information you return.
Some dive log applications migth recognize particular descriptor strings
and use them specially to fill in other information (ie serial numbers,
weight and suit information etc), but in general the interface is very
much meant to be informational free-form for a human user.
So do *not* use this interface to encode things that are not human-
readable. Serial numbers or version information that is meaningful to
humans are fine. But random encoded data structures are not.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
reefnet_sensusultra_device_set_maxretries was killed off back in v0.3,
but was still lying around in the public header.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
The latest firmware v1.75 introduced a new hardware descriptor byte to
identify the different models based on their hardware features. This new
hardware descriptor is now used as the libdivecomputer model number. For
older firmware versions, which do not support the descriptor yet, there
is an automatic fallback to the previous method based on the serial
number.
This change will be necessary for the Oceanic VTX, because it uses a
higher baudrate.
To maintain backwards compatibility, the existing function remains
unchanged and a new function is introduced instead.
This connects the bits and implements firmware upgrade for the OSTC3.
This code is inspired by JeanDo ostc-companion.
Reviewed-by: Jef Driesen <jef@libdivecomputer.org>
Signed-off-by: Anton Lundin <glance@acc.umu.se>
All entry point functions (e.g. public functions or functions called
through the vtable) use the backend name as the prefix. The same applies
to the main device and parser structures.
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>
There are two different ways to specify the volume of a tank. In the
metric system, the tank volume is specified as the water capacity, while
in the imperial system the tank volume is specified as the air capacity
at the surface (1 ATM) when the tank is filled at its working pressure.
To avoid mistakes, the tank volume is now always returned as the metric
volume. For imperial tanks, the tank volume is converted to the metric
representation.
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>
Starting with firmware v1.23, the OSTC3 settings can be configured
through the USB interface. There are new commands for reading, writing
and restoring the settings to their default values.
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>
Unlike the corresponding mktime C library function, the libdivecomputer
function will never modify its argument. By marking the parameter as
const this is made more explicit.
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).
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 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 SAFETYSTOP is conceptually somewhere in between the NDL and the
DECOSTOP, so it makes sense to re-order the constants in the enum to
reflect this order.
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!
Having these as events seems less useful since for many dive computers
there are data with every sample - so it makes much more sense to have
these as part of the sample.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
So far only OSTC and Shearwater Predator are supported. For the OSTC we
support CNS and setpoint changes in the samples (the current hardware
doesn't actually support ppO2 sensors and for the older hw that does I
don't have the correct encoding information).
For the Predator we support only the "average ppO2 during the sample".
The Predator also gives us a CNS value at the end of the dive - I don't
quite know yet how to deliver that back to the consumer. Possibly as CNS
value in the very last sample? That would at least be consistent.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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.
