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