Where to get a COMPLETE list of FIT profile and message definitions?

I've written a tool to convert FIT files to GPX some years ago which does not work with the newest generation of Garmin devices.

The FIT files seem to contain the message type 327 (0x147) which is not seen on the latest list (Profile.xlsx in the FitSDKRelease_21.84.00 archive). So I am unsure if the list is incomplete or I forgot to implement something in my code (still investigating if anything has changed in newer FIT file definitions)...

..

  • Hi PUFFOLINO,

    I have a similar problem if I decode or encode a Locations.fit from or for my Garmin Edge 1000 Disappointed

    Such a file contains 2 messages (unknown in FIT SDK) with message number 29 and message number 189.

    A message with number 29 contains a 'WayPoint' with Name, Details, Latitude, Longitude, TimeStamp, Symbol and Altitude.

    A message with number 189 contains information (one byte), how a Garmin Edge should handle such a Locations.fit file.
    = 0 List of WayPoints will be added to existing Locations.fit (on Edge).
    = 1 List of WayPoints will replace existing Locations.fit (on Edge).
    = 2 All WayPoints will be deleted in the existing Locations.fit (on Edge).

    And the File ID ( = 8 ) is also unknown in the SDK :-(

    At the moment I 'write' my own C# message files for both messages and update related MesgBroadcaster.cs, Profile.cs, File.cs, ... manually

    Has anybody an idea, how to 'integrate' such unknown messages in next FIT SDK releases ?

    Best regards.

    Roland

  • There have been unknown messages and fields in the FIT SDK since its inception, so that was also the case "some years ago" as well and is probably a red herring. 

    In the message definitions the three byte field definitions include a one byte field definition number, a one byte size, and a one byte base type. The size value is the number of bytes written to the file for that field. With that information a FIT file can be read start to finish without any knowledge of the Profile. The various FIT SDKs actually read the file start to end and then apply the offset after the fact. 

  • Thanks for these valuable informations, will give it a try in the next days. Fine to read, that here are some experts and also other programmers (Slight smile

    Will do another post in a week or so to tell you if I had success or not Wink

  • A short update: I've managed to deal with the messages now, but I'm not happy that some message types used by Garmin devices are not specified. As Songokuonbike said, #29 is a good example for that - not fine to hardcode that id to be able to decode the values correctly (I found a check in my old code where Uint16 values are represented different then).

    However - here's my command line tool Fit Tool for Windows (64 Bit), which is able to read and analyze FIT files. Beside that it creates GPX files automatically but hopefully it will help some of you dealing with FIT files as it is able to do compact or detailed debugging if you want so.

    ------------------------------------------------------

    Command:  Fit [options] fit_file
    Options:  -og   gpx export file format (default)
              -x    export extensions (heartrate)
              -g    convert semicircles to degrees
              -p#   output path options (0-2)
              -d#   set debug level 0-5
              -n#   dec/hex number output (0-2)
              -c**  dec/hex prefix chars (*=default)

    ------------------------------------------------------

    The program is free for all - enjoy it!

  • Sounds like the kind of program I was asking about in another thread.  I was thinking of rolling my own; but I'm still struggling to understand the contents of the SDK and some of the algorithms in FitCSVTool.jar.

    I'll definitely try your program.  Can you explain the options -p and -n: how to interpret the number (0 to 2)?

    Also, I don't understand the need for -x, if you are simply formatting all records.

    -----
    Just tried to run without options with a FIT file exported by Garmin Connect.  Got a "checksum error" after outputing a line with 4 zeros.

    My guess:  the checksum is zero, which means "no checksum", IIRC, and you are not allowing for that?

  • Hi km408,

    I also checked PUFFOLINO's programm and it works as expected, decoded my avtivities, recorded by an Edge 1000 some days ago without any problems :-)
    Same result with my own program :-)

    So, something must be wrong with your fit file, because CRC calculation is the second part after reading fit file header.

    Is it possible to share a screenshot with your CRC error?

    Best regards

    Roland

  • Hi PUFFOLINO,

    I checked your program with some of my activities and this is a great program Ok hand

    In particular, the various debug levels are fantastic Grinning

    Just an idea:
    If you decode a record message, you display distance fied (ID = 5) as a timestamp Thinking

    I'm using internal function GetDistance() to get distance in meter as a float value (sorry for C# code) Upside down

    Thanks again sharing your program.

    Best regards

    Roland

  • Hi, Roland.

    Re: ``Is it possible to share a screenshot with your CRC error?``

    Looks like the screenshot you provided.

    -----
    Re: ``something must be wrong with your fit file``

    Unlikely.  As I said previously, the FIT file was exported from Garmin Connect.  The source of FIT data is Garmin Forerunner 310XT watch.  And the FitCSVTool.jar has no problem decoding the FIT file; but of course, I don't know if it checks the CRC.

    -----
    Re: ``CRC calculation is the second part after reading fit file header``

    As you probably know, there are two CRCs:  the last 2 bytes of the 14-byte file header; and that last 2 bytes of the file.

    Looking at a hex dump of the 14-byte file header, we see that the CRC is zero (highlighted in red).

    000000   0E 10 83 00 CF 88 00 00 2E 46 49 54 00 00 40 00  .........FIT..@.

    The FIT Protocol description at https://developer.garmin.com/fit/protocol states:  ``Computing the CRC [sic; just the header CRC, I think] is optional when using a 14 byte file header, it is permissible to set it to 0x0000. [.... Bytes 12 and 13] Contains the value of the CRC (see CRC ) of Bytes 0 through 11, or may be set to 0x0000. This field is optional.``

    Looking at the end of the file, we see the last definition and data records followed by the data CRC (highlighted in red):

    034992   FF FF 00 49 00 00 22 00 07 FD 04 86 00 04 86 01  ...I..".........
    035008   02 84 02 01 00 03 01 00 04 01 00 06 01 02 09 1E  ................
    035024   CF 46 3D B7 7F 17 00 01 00 00 1A 01 FF 67 F6     .F=..........g.

    I cannot verify the CRC.

    Aside.... It is common practice to allow a CRC to be zero, which means that it should be calculated.

  • Hi, PUFFOLINO.

    As I wrote before (and see details in my explanation to Roland), I get a CRC error when I try to use your program, even with -d5 (highest debug level).

    And now, sigh, Norton removed the exe file as a "threat", and it will not permit me to download it again.  Norton people will get an earful from me next week.

    So arguably, my problems are moot.

    But please consider ignoring any CRC error, at least at some debug level.

    Alternatively, add a command line option to ignore any checksum error.

    Also, please consider displaying which CRC is in error; there are two.

    And when you report a CRC error, please show the CRC that you calculate as well as the CRC in the file.

    That might be the line of zeros that I saw.  (See Roland's screenshot.)  But it is unclear to me.

    Thanks.

    -----
    BTW, where does the program output go?  Stdout?

    Norton would not permit me to create a file with the command:  fit.exe mydata.fit >out.txt

    I don't understand why not.  Again, I'll deal with Norton next week.

  • Hey, thanks to all of your comments (try to read them all as soon I've more time)...

    Just some additionall information (hopefully this are answers to some of your questions):
    - actually an GPX file is created automatically (later I'll try to change that to export nothing / fit / gpx)
    - when creating a GPX file, the location will be the local path (of your cmd:exe), the path of the read fit file or a subdirectory (GPX) of that. You can choose between these three options by -p0, -p1 or -p2 (or -pl, -pf, -ps).
    - option -n0 means all number are shown in decimal, -n1 (default) only dump numbers are in hex, -n2 all numbers are hex
    - option -x includes the heartrate in the GPX export file. As this can't be handled by older programs (Garmin Map Center), I decided to add this option

    Thanks also for the point I am decoding things not correctly (timestamp), will have a look at that somewhen...
    ...BTW if you find some bugs (the CRC thing for example), please post a example file here so I will be able to check that.

    Concerning Norton and other virus checker - bad luck I am using a programming language (Purebasic) which is also used by some hackers and some antivirus companies just check for a simple signature of the exe file.
    Redirecting should work with no problems - just don't use it with option -d1 as you would see the statistic values in one row.

    PS - took me an hour to post this - "an error occured" is not perfect to understand, you are not allowed to write cmd  . exe in the post!