This way Subsurface can show different icons depending on what kind of
event we report.
This also fixes a bug where the begin/end marker was mistakenly added as
the value instead of as flag.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The event numbers are an indecipherable mess, and Suunto EON Steel has
notifications, events and warnings that just don't fit. Plus they
really come as strings from the EON Steel anyway.
So add a "SAMPLE_EVENT_STRING" type, and for that type the event has a
"const char *name" instead of the odd and meaningless flags/value pair.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Right now it only has an indication of whether the cylinder size is
imperial or metric, which is frankly quite useless.
Turn it into a bitmask instead, where we keep the imperial/metric data
for compatibility, but add another two bits that say that it's a CC
cylinder, and whether it's the oxygen or diluent cylinder.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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.
The protocol of the iX3M series is almost identical to the protocol of
the iDive series. The main difference is that the command bytes and the
size of the response packets have been changed. In order to be able to
communicate with the correct set of commands, the user needs to supply
the correct number now. To maintain backwards compatibility, a new
variant of the open function is added.
The new callback will be usefull when we will implement the support
for Windows. The implementation of native serial set_timeout method
uses a HANDLER on Windows and we will use the WinSock2 API which has
a socket descriptor.
Signed-off-by: Claudiu Olteanu <olteanu.claudiu@ymail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Create a custom open method for SHEARWATER 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>
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.
