This gets me real profiles, with depth and temperature information.
Sadly, the temperature data seems to be in whole degrees C, which is not
good for diving. But certainly not unheard of.
Also, while this does actually transfer a lot of other information too,
there are certainly things missing. No gas information is gathered
(although we do parse it, we just don't save it), and none of the events
are parsed at all.
And the GPS information that we have isn't passed on yet, because there
are no libdivecomputer interfaces to do that. I'll have to come up with
something.
But it's actually almost useful. All the basics seem to be there. How
*buggy* it is, I do not know, but the profiles don't look obviously
broken.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There aren't that many relevant ones left, and I have reached the point
where I think the remaining missing fields just aren't that important
any more. You can always get them by saving the libdivecomputer
log-file and see the debug messages that way.
Now I'll need to turn the parsing skeleton into actually generating the
actual libdivecomputer data.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This actually seems to cover almost all of the relevant dive fields.
There's a lot of different GPS coordinates, I have no idea what they all
are, but they are at least marked in the definitions.
NOTE! None of this actually fills in any information yet. It's all
about just parsing things and getting the types etc right.
On that note, this also adds a bit of dynamic type checking, which
caught a mistake or two.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Make it easier to see which of the unknown fields don't contain anything
interesting.
Soon this will be at the stage where the parser skeleton itself doesn't
need much work, and I should look at the actual data and turn it into
samples instead.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Oops. I used array_uint16_le() to get the data size. Too much
copy-and-paste from the profile version (which is indeed 16 bits).
The data size is a 32-bit entity, and this would truncate the data we
read.
Also, verify that there is space for the final CRC in the file, even if
we don't actually check it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The invalid values skip the parser callback function entirely. Of
course, since it's not really doing anything right now, that's mostly
costmetic.
Extend the FIT type declarations to also have the invalid values.
Also, add a few timestamp entries, and print them out to show the
timestamps in a human-legible format.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It turns out that the timestamp field can exist across all message
types, as can a few other special fields.
Split those out as "ANY" type fields, so that we get the field
descriptor without having to fill in every message descriptor.
This also makes the message descriptors smaller, since we no longer need
to worry about the high-numbered (253) timestamp field in the arrays.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is _very_ incomplete. The FIT file is really fairly generic, but
this has the basics for parsing, with tables to look up the low-level
parsers by the FIT "message ID" and "field nr".
It doesn't actually parse anything yet, so consider this a FIT decoder
skeleton.
Right now it basically prints out the different record values, and names
then for the (few) cases where I've found or guessed the numbers.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
It's really just reading files from storage, but with the proper sorting
and fingerprint handling.
The Garmin back-end does no actual parsing yet, so the end result is
garbage, but now the data has technically been downloaded. Without the
parser, I haven't actually verified that any of it is remotely correct,
but it all looks good.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This does absolutely nothing, but it adds the basic skeleton for a new
dive computer support.
Not only don't I have any real code for any of this yet, but I actually
think it might be useful to have a "this is how to add a new dive
computer" example commit.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We now have at least two dive computers that enumerate as USB storage
devices: the Uemis Zurich and the Garmin Descent Mk1.
The Uemis is handled purely inside of subsurface, with no
libdivecomputer support. That was likely a mistake, but it was not
practical to do a libdivecomputer backend for it at the time.
The Garmin Descent Mk1 support would be much nicer to have natively in
libdivecomputer, and looks much more relevant and practical than the
Uemis situation was.
So start off with defining a new transport type.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
There is also an i300C that is Bluetooth capable, but I don't know if
that's the same model as the i300 or a different variation.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Merge with misc fixes upstream.
This fixes a couple of small error cases.
* 'master' of git://github.com/libdivecomputer/libdivecomputer:
Don't pass a NULL pointer to memcpy
Fix an uninitialized variable
The memcpy and related functions expects a valid pointer, even if the
size is zero. Most libc implementations will handle a NULL pointer just
fine, but that's not guaranteed.
Simply skip the call when there is nothing to copy.
In the error handling code, the dc_buffer_free() function can be called
with an unitialized "buffer" variable as parameter. Fixed by adding an
extra label.
Reported-By: Linus Torvalds <torvalds@linux-foundation.org>
Merge with upstream libdivecomputer from Jef.
This fixes some sleeping functions, and also implements support for the
Tecdiving DiveComputer.eu dive computers.
There's also various minor cleanups. Most notable is perhaps the
unification of the Uwatec dive computer backends.
* git://github.com/libdivecomputer/libdivecomputer:
Initialize the socket library for the bluetooth discovery
Fix the length of the Suunto D6i gas change event
Add support for the Tecdiving DiveComputer.eu
Fix the Mac OS X timer implementation
Add the average depth to the xml output
Skip the handshake for BLE communication
Unify the Uwatec Smart, Meridian and G2 backends
Re-organize the packet send/receive code
Use symbolic constants for the commands
Implement an rfcomm filter function
Remove the filter for HW OSTC's without bluetooth
Implement the sleep function for IrDA and bluetooth
On Windows, the WSAStartup() function needs to be called, to initialize
the socket library, before using any of the other WSA socket functions.
This includes the functions used for the bluetooth device discovery.
The Mac OS X timer implementation returned timestamps with nanoseconds
as unit instead of microseconds.
Reported-by: Rick Balsano <rick.balsano@gmail.com>
The Scubapro LogTrak application doesn't send the handshake commands for
BLE communication. Also the Aladin Sport Matrix, which supports only
BLE, responds with a 0x01 byte instead of the expected 0x01 byte and
that causes the handshaking to fail. Thus simply omit the handshaking
for BLE communication.
Reported-by: Berthold Stöger <berthold.stoeger@tuwien.ac.at>
The Uwatec Smart, Meridian and G2 backends are almost identical, except
for the low-level packet sending and receiving code. With the new I/O
layer, those three backends can easily be unified in a single backend.
The Meridian and G2 are completely removed, only the family types are
kept for backwards compatibility.
Merge upstream updates from Jef Driesen.
This fixes the parsing of the Uwatec Aladin Tec (and Tec 2G) by adding a
missing event descriptor.
* 'master' of https://github.com/libdivecomputer/libdivecomputer:
Add a missing event descriptor
If we can't find any calibration values for the individual sensors,
fallback to emitting the average/voted ppo2 instead, so users always get
a ppo2 value.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The Aladin Tec (and Tec 2G) sample descriptor table supports up to two
event bytes, but there is only a single event descriptor. This missing
descriptor causes a fatal error during parsing. Add a dummy descriptor
to avoid the error.
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.
