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>
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>
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>
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>
