I thought this wasn't needed any more (incorrectly thinking that Jef had
knowledge we didn't - he had merged the other changes), and had just
taken Jef's version of the code.
Berthold Stöger tells me otherwise. The Aladin Sport Matrix returns 0
instead of 1 to the initial handshake, and makes libdivecomputer
unhappy. This just skips the handshake entirely for the Sport Matrix,
since apparently LogTrak doesn't do any either.
See also commit 8a84ece7d0ef ("Support for the Scubapro Aladin Sport
Matrix") in our old Subsurface branch.
Reported-by: Berthold Stöger <berthold.stoeger@tuwien.ac.at>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This adds the string field interface to the Shearwater family of dive
computers.
That includes proper serial number formatting, but it also has a lot of
new fields for battery information (both the dive computer itself and
the transmitter) but also deco model information.
Much of the deco model cases come from Anton Lundin in the original
subsurface branch, and Dirk Hohndel added the battery type and serial
number and firmware version data. And I ended up massaging it even in
that original branch, so it blamed me for all these lines even back
there.
The sign-offs from Dirk and Anton are from the original commits.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This adds the string field interface to the Suunto EON Steel and EON
Core.
This is actually a big deal, because it gets rid of all the ad-hoc
string parsing, and actually just uses the strings that the EON Steel
events and warnings natively use.
It also reports the severity of the notification/warning/alarm, so that
Subsurface can then use the proper icon. An event isn't just an event,
there's a big difference between a warning and just a notification.
It also fills in the tank information data for closed-circuit cylinder
use.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This adds the string field interface to the Suunto D9 family.
It's really just the proper serial number handling. From Dirk's
original commit:
"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"
so thus just serial number.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This adds the string field interface to the Oceanic Atom2 family,
including the proper serial number handling.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This adds the string field interface to the HW OSTC family, including
the proper serial number handling.
The deco model information was done by Anton Lundin in the original
subsurface branch, and the salinity, serial number, battery voltage and
desat information was added by Dirk Hohndel. Jan Mulder added the
battery percentage.
[ The sign-offs have been taken from the original commits in that old
subsurface branch, and I'm marking Dirk as the main author because on
the whole most of the lines come from him - Linus ]
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The libdivecomputer serial number handling is very very messy.
There are multiple issues that make it messy:
- it's not actually figured out at parse-time, it's figured out at
download time and passed up through the DC_EVENT_DEVINFO as part of
the devinfo structure.
- it's passed around as an "unsigned in" in the devinfo structure,
which is entirely useless to anybody but libdivecomputer, since a
serial number isn't actually a number, but a string, and the format
of the string depends on the dive computer.
- it is *not* passed to the parser, so the parser can't do a better job
at it later.
But it turns out that the sane "create new parser" helper function does
actually get it, as part of the "devinfo" that is passed to it. So as
long as you use that sane interface, we can now pass it in to the actual
parser creation, and then the dive computer parsers that want to do a
reasonable job of actually generating a real serial number string can
now save it off and do so.
This just adds the infrastructure to make this possible. I'll do the
dive computers one by one.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Dirk seems to have some documentation about the different ID's, plus it
just makes sense to order the switch statement by number.
This is partly based on Dirk's original commit to do the different model
numbers, with various changes over time due to merge conflict
resolution. Dirk's sign-off comes from Dirks commit in the original
subsurface branch.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Not a lot of fields, but give the serial number in the proper format,
and other version information (Software version and bootloader version).
And the Nofly time that the dive computer reports.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This extends the libdivecomputer notion of "dc_tankvolume_t" to not just
have the tank volume type (imperial or metric), but be a "dc_tankinfo_t"
that shows other information about the cylinder.
The imperial-vs-metric data remains the same two values:
1 - metric
2 - imperial
but instead of being an enumeration of volume types, it is extended to a
bitmap of tank information, and the other bits currently are
4 - CC diluent cylinder
8 - CC O2 cylinder
with possible future extensions (bailout gas, perhaps).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The default libdivecomputer fields are good for structured data that has
a well-defined format, like the cylinder information, or the temperature
data.
But it is entirely useless for miscellaneous divecomputer-specific
information, where there is no standard way of representing the data
across different kinds of dive computers.
Examples of this include simple things like deco calculation algorithm
(what kind of Buehlmann, gradient factor information or is it some
vendor-specific mode?) and even something as trivial as a serial number.
No, serial numbers aren't numbers. They are strings. Really.
But this also includes much more complex data that is really specific to
a particular dive computer or family: what the battery status is for the
dive computer or the wireless transmitters it is connected to (sometimes
it's a voltage, sometimes it's a percentage, sometimes it's just "good"
or "marginal").
It also includes random incidental information like firmware version
numbers (again, these are strings, not numbers, despite the name) or
dive mode and personal adjustment information.
So allow the dive computer to just give "extra information" in the form
of an array of { key, value } string pairs. For my Perdix AI the
information could be
{ "Serial", "370d1f24" }
{ "FW Version", "44" }
{ "Deco model", "GF 40/85" }
{ "Battery type", "3.6V Saft" }
{ "Battery at end", "3.4 V" }
and for my EON Steel with three wireless transmitters connected it can
look like this:
{ "Serial", "1742104730" }
{ "FW Version", "1.6.5" }
{ "HW Version", "70.3.0" }
{ "Battery at start", "Charge: 83%, Voltage: 4.012V" }
{ "Deco algorithm", "Suunto Fused RGBM" }
{ "Personal Adjustment", "P-2" }
{ "Battery at end", "Charge: 79%, Voltage: 3.977V" }
{ "Dive Mode", "Trimix" }
{ "Desaturation Time", "7:53" }
{ "Transmitter ID", "1519107801" }
{ "Transmitter Battery at start", "87 %" }
{ "Transmitter Battery at end", "87 %" }
{ "Transmitter ID", "1550110028" }
{ "Transmitter Battery at start", "100 %" }
{ "Transmitter Battery at end", "100 %" }
{ "Transmitter ID", "1719102387" }
{ "Transmitter Battery at start", "100 %" }
{ "Transmitter Battery at end", "100 %" }
so this data is inherently unstructured and dependent on the dive
computer, but quite relevant to the diver. Subsurface shows this in the
"Extra Info" panel for each dive computer.
Also teach the example output-xml code about the new string field
extension. That example output-xml code was written by Anton Lundin in
the old Subsurface branch, and signed-off-by Dirk. The sign-offs here
are taken from that original work.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We _really_ find the standard libdivecomputer event enumeration much too
inflexible and not giving us enough useful information. This is
particularly noticeable with the Suunto EON Steel/Core, where there are
no fixed event enumerations, but instead the dive computer literally
gives you event strings.
Do the same thing in the libdivecomputer interface: allow an event of
type SAMPLE_EVENT_STRING which instead of the useless "value" gives an
actual string describing the event.
Also, extend the "flags" field to have not just a NONE/BEGIN/END marker,
but a severity level. The severity level is 3 bits, so 0-7, with the meaning being
0 - 'no severity info'
1 - state change (so 'surface' event or similar - don't even show it by default)
2 - notification (informational, eg "safety stop", "tank change")
3 - warning ("ascent speed")
4 - alarm (some actual dive violation).
5-7: future expansion?
Think of 0 as "legacy - missing information", 1 as "internal DC thing",
and 2-4 as (green-yellow-red).
This makes it possible for the dive computer back-end to give the user
actual useful information for events.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This changes the dc_version_suffix to show that this is the subsurface
'next generation' branch, and does minor tweaks to the build system: we
add the 'build' subdirectory to the .gitignore branch because that's
where we typically do our builds, and we tweak the default compiler
warning flags to not be as annoying.
No real semantic changes.
This is partially based off patches in the original Subsurface-branch by
Dirk Hohndel (configure.ac) and Jan Mulder (gitignore). The sign-offs
for those come from those patches:
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Instead of reading data packets, the code is actually sending some
random data to the dive computer! A small typo with bad consequences!
This is a critical bug because it not only causes the download to fail,
but also appears to change random settings on the dive computer. I
suspect that the garbage data that gets send to the dive computer
happens to contain some valid write settings commands.
For most I/O stream implementations the serial communication specific
functions are meaningless. Implementing them as no-ops allows the dive
computer backends the call the I/O stream functions unconditionally.
However, implementing the no-op with a dummy function returning
DC_STATUS_SUCCESS, does not only add some (small) overhead at runtime,
but also requires many such functions. This is inconvenient and the same
result can easily be obtained by using a NULL pointer instead.
The consequence is that the logic is reversed now. To obtain the
previous behaviour of returning the DC_STATUS_UNSUPPORTED error code
again, you'll need to implement a dummy function. But that's fine
because it's the less common case.
I/O functions with output parameters, should always initialize those
output parameters, even when an error is returned. This prevents the
(accidental) use of uninitialized variables, whenever the caller forgets
to check the return code.
As a nice side effect, the use of a local variable guarantees that the
underlying I/O implementation will always receive a valid pointer.
When two or more identical (or very similar) dive computers are
connected, the USB VID/PID can be ambiguous. That's because the VID/PID
identifies the type of the USB device, and not the individual device.
But each USB HID device descriptor returned by the device discovery
represents a single connected device, and thus guarantees to open the
correct USB device.
To obtain the same behaviour as before, an application can simply open
the first discovered device.
Replace the global USB library context with a reference counted session
to manage the lifetime of the USB library context. For the libusb based
implementation, this is actually a much better match for the underlying
libusb api, and allows to eliminate the global state. For the hidapi
based implementation, the global state is unavoidable because the hidapi
doesn't support multiple sessions. Therefore we use a singleton session.
The main difference with the serial communication is that the BLE
communication transmits each SLIP encoded data packet as one or more BLE
data packets. The BLE packets have an extra two byte header with the
total number of packets and the current packet number.
The main difference with the serial communication is that the BLE
communication uses data packets (with a maximum size of 20 bytes)
instead of a continuous data stream.
The main difference with the USB HID communication is that the BLE data
packets have a variable size and are no longer padded to the full 32
(Tx) or 64 (Rx) bytes.
The main difference with the USB HID communication is that the BLE data
stream is encoded using HDLC framing with a 32 bit CRC checksum. Due to
this encoding, the data packets can no longer be processed one by one
(as is done for the USB HID packets). The entire HDLC encoded stream
needs to be received before it can be processed. This requires some
additional buffering.
Setting a default transport type avoids the need to explicitely set a
transport using the the new --transport command-line option. This also
preserves backwards compatibility with previous versions where the
option didn't exist yet.
The dctool example application is updated to the latest changes:
- The I/O stream is opened and closed by the application.
- A new (mandatory) option is added to select the desired transport
type. This is nessecary because several dive computers support
multiple transport types now.
Currently the dive computer backends are responsible for opening (and
closing) the underlying I/O stream internally. The consequence is that
each backend is hardwired to a specific transport type (e.g. serial,
irda or usbhid). In order to remove this dependency and support more
than one transport type in the same backend, the opening (and closing)
of the I/O stream is moved to the application.
The dc_device_open() function is modified to accept a pointer to the I/O
stream, instead of a string with the device node (which only makes sense
for serial communication). The dive computer backends only depend on the
common I/O interface.
With the support for multiple transports per device, the
dc_descriptor_get_transport() function became obsolete because it does
support only a single transport type. Applications should use the new
dc_descriptor_get_transports() function instead.
With the support for multiple transports per device and the possibility
to use custom I/O implementations, libdivecomputer no longer knows which
devices are actually supported. Hence libdivecomputer needs to always
report all the devices it knows about, and it's up to the application to
filter out entries for which there is no suitable transport available
(either built-in or custom).
Because the list of supported built-in transports depends on the
availability of external libraries (libusb, hidapi) and the operating
system, the application needs some mechanism to retrieve this
information at runtime. Therefore, a new dc_context_get_transports()
function is added, which returns a bitmask with all the available
built-in transports.
Several dive computers support multiple transports. For example the
Suunto Eon Steel supports both USB HID and BLE. All devices using
bluetooth classic communication support both the native bluetooth
transport and the legacy serial port emulation.
To support this feature, the values of the dc_transport_t type are
changed into bitmasks, and the dc_descriptor_t struct is extended with a
bitfield with all the supported transports.
Add a function to query the underlying transport type. This allows the
dive computer backends to implement transport specific behaviour where
necessary.
For the built-in I/O implementations, the transport type is obviously
always hardcoded, but for a custom I/O implementation the application
needs to provide the correct type. Hence the transport type can't be
hardcoded in the vtable and needs to be passed as a parameter.
Trying to purge the input buffer by reading and discarding data packets,
results in an annoying and confusing error message if no data packet is
received. To avoid this error, the functionality should be integrated in
the USB HID code, either automatically during initialization or by
implementing the purge function.
But since there seems to be no evidence that this is actually necessary,
let's remove this code.
Check the fingerprint before downloading the dive. If a match is found,
this avoids some unnecessary communication and thus makes the download a
little bit faster.
The file list isn't freed when an error occurs, and the strings returned
from the lookup_enum function are dynamically allocated and thus should
be freed as well.
