On Android we appear to mis-interpret the response to the RDBI command.
Instead of failing, fall back to the default value (PNF for Teric,
Predator-like for everything else).
With this I can successfully download dive data from my Teric on
Android.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This will allow parsing dives from the Shearwater Teric, but depending on the
firmware could also be used on older models.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
RDBI response tells us which format the dive computer supports.
Shearwater recommends to use the 'Petrel Native Format' for all dive computers
which support it, even those pre-Teric models which (depending on firmware)
might support both PNF and the older 'Predator-Like Format'.
They also recommend to ignore the 0x90...... format which is very similar to
PNF but without the final record and to use the older Predator Like Format in
that case.
Which format we use is determined by the base address used to download the
logbook entries.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Based on information from Ryan January, who got it from his Garmin
contacts and got the go-ahead to share the data.
This is mainly the water density and deco model. It has a few other
fields troo, but nothing necessarily worth reporting.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Based on information from Ryan January, who got it from his Garmin
contacts and got the go-ahead to share the data.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
While it seems like a safe assumption, the cost of being careful and assembling
the full record and taking the one for device_index 0 seems worth it to me.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
A typical FIT file contains several DEVICE_INFO messages. We need to
identify the one(s) for the creator (i.e. the actual device, not a
sub-component).
Note, Garmin identifies the Descent Mk1 as product 2859. I think we
should use this as the model number (instead of currently using 0.
Also, the vendor event is not to send the vendor name of the device, but
in order to send vendor specific events :-)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Dives are identified by a sub_sport range of 53-57 in the SPORT message.
This means that we need to parse the files before we actually offer them to the
application, which means we parse them three times all together, but I don't
see a way around that. Thankfully parsing a memory buffer is reasonably fast.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Yes, the hexdump was simple, but it was really hard to read, and we can
do so much better, including taking empty data into account, and
formatting it by the actual size of the individual fields.
So this improves on the debug log, so that when we decide to try to
parse new field information, the data will be in a somewhat more legible
format that makes more sense. And getting rid of the empty fields makes
it much clearer what data might be even remotely interesting.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The magic numbers in the decoding are all based on Wojciech Więckowski's
fit2subs python script.
The event decoding is incomplete, but it should be easy enough to add
new events as people figure them out or as the FIT SDK documentation
improves, whichever comes first.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The logic to suppress multiple redundant time samples in the garmin
parser also always suppressed the time sample at 0:00, which was not
intentional.
Fix it by simply making the "suppress before" logic be "suppress until"
instead.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Several dive computers support this, so why not have the proper
interface for it in libdivecomputer?
Triggered by the fact that the Python scripts to generate XML files from
the Garmin FIT files can import this information, but the native
libdivecomputer model couldn't.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge the initial Garmin Descent Mk1 support.
This actually works well enough to be useful, even though there are a
few ugly details yet to be sorted out.
The download itself is fairly complete, but all event handling is
currently missing (warnings, gas changes, things like that).
Also, because of how libdivecomputer works, the "downloading" of dives
is entirely separate from the "parsing" of dives in the libdivecomputer
world. And that is actually problematic for the Garmin Descent
downloader, because you actually need to parse the data to even figure
out whether it's actually a dive at all!
The Garmin Descent is also a fitness and general excercise tracker, so
people can (and do) use it for other sports than just diving, and so the
activities we download may end up not being dives at all, but other
events.
But before we parse them, we don't know, and we aren't really supposed
to parse them until after we've passed the data to the application and
it passes it back for parsing. Nasty chicken-and-egg problem there..
So right now non-diving activities will just show up as very short
and/or shallow dives.
This is fixable by just parsing things an extra time, but I really wish
libdivecomputer would just stop thinking that downloading and parsing
are separate events.
* garmin-descent:
Add dc_usb_storage_open to the symbols list
garmin: only record gasmixes for cylinders that aren't enabled
garmin: don't emit fake device info and vendor event
garmin: add support for downloading gas mixes
garmin: add GPS coordinate data and improve parser_get_field() reports
garmin: actually start using the parsed data
garmin: turn all the remaining unrecognized fields into DEBUG messages
garmin: add a lot of new field definitions
garmin: teach the parser to show undefined values for unknown fields too
garmin: fix file length header parsing
garmin: teach the parser about invalid values and more dates
garmin: some fields are defined in all message types
Garmin: start parsing definition records
Garmin Descent Mk1: flesh out the actual downloading part
Add Garmin Descent Mk1 skeleton
Add 'USB storage' transport enumeration
Apparetly the Windows build needs this for the library building.
Reported-by: Wojciech Więckowski <xplwowi@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Merge upstream libdivecomputer changes from Jef Driesen.
* https://github.com/libdivecomputer/libdivecomputer:
Add Travis CI integration
Fix the transport command-line parameter
Document dc_descriptor_get_model
Include stddef.h in iostream.h
Add support for the Mares Smart Air
Fix the average depth for older OSTC dives
Add support for the Oceanic Pro Plus X
This actually takes the gas status information into account, and doesn't
show gas mixes that are disabled.
All the Garmin Descent data now looks reasonable, but we're not
generating any events (so no warnings, but also no gas change events
etc).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The libdivecomputer model is just broken - we don't know this
information before parsing the dive. But let's not emit a fake event
that generates bogus serial number data. I thought I'd be able to fill
it in, but this really isn't reasonable, so disable it entirely for now.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This clarifies and generalizes the "pending sample data" a bit to also
work for gas mixes, since it's one of those things where you get
multiple fields in random order, and it needs to be batched up into one
"this gas for this cylinder" thing.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This adds all the GPS information I found, although for dives the
primary ones do seem to be the "session" entry and exit ones.
But I'm exporting all of them as strings, so that we can try to figure
out what they mean.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
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>
The Smart Air uses almost the same data format as the Quad Air. Only the
4 bytes containing the dive mode and number of samples moved from the
beginning of the header to the end. This is a change adopted from the
regular Smart.
For older OSTC dives, using logbook format version 0x20, the average
depth is not available in the dive header. It's only available since
version 0x21, which increased the header size from 47 to 57 bytes.
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>
The Oceanic Pro Plus X is quite different from the previous models. The
profile data is now stored in a dedicated memory area, and hence there
are a few important differences:
Reading data from the new profile memory area is done with a new F6
command. This new command is very similar to the existing B8 command,
but accesses a completely different memory area. In order to integrate
those two memory areas as transparantly as possible into the existing
infrastructure, a virtual memory space is introduced. The lower part of
the virtual memory is mapped onto the main memory area, while the upper
part is mapped onto the new profile memory area.
The page size of the new profile memory area also increased from 16 to
256 bytes. If the profile size is not an exact multiple of 256 bytes,
the dive computer pads the profile data with 0xFF bytes.
The other changes are the usual Oceanic device specific changes.
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>
