• State Verified Answer
  • Replies 4 replies
  • Subscribers 10 subscribers
  • Views 1303 views
  • Users 0 members are here
Options
Related

Is it normal to log field_description/206 that is never used?

jlar

In the Wahoo Rival file here https://analyze.dcrainmaker.com/#/public/47656b80-1b0a-412b-4882-62ba8df09c20 there are several field_description:s/206 that are never used for developer data. Is this up to the developer to decide? In previous fit-files field_description seems to be logged more dynamically whenever needed.

This mostly for what I should expect for a parser I'm trying to finish. CSVFitTool agrees with my own parser's findings so far.

  • +1

    FIT files from a Garmin device will only contain developer fields if there was a Connect IQ app or data field in use that was contributing data to the FIT file. Whereas other devices or apps may use developer fields to extend existing messages.

    In the file you pointed out, it does look like all potential developer fields are being defined up front regardless if they are used during the activity or not. This is not necessarily wrong, it just leaves it up to the consumers of data to make sense of it. 

    The other thing I noticed in the file is that there are multiple Developer Data Id messages. Since all of the developer fields can be attributed to a single developer, there only needs to be one Developer Data Id message. In the field_description message the developer_data_index field should be zero and the field_definition_number should be the thing that increments. In the file you pointed out it is the opposite. 

    Also missing from the Developer Data Id message is the Application Id. That is a GUID that uniquely identifies the source of the developer data. In a Garmin file this GUID identifies the Connect IQ app or data field that contributed the data. When developer data is added to a file programmatically, the developer should create their own GUID and use the same GUID every time. This keeps consumers of data from relying on strings to identify the source of the data.

    All of that said, most of this was not documented until recently so it is understandable that things may be implemented differently by different vendors.
    developer.garmin.com/.../

  • 0 in reply to Ben FIT

    Thanks for the heads up! The field_descriptions going unused did seem a bit odd.

    On the developer_data_index field and the field_definition_number, this file had me change how I use and incorporate developer data into the "normal" parsing flow. Before I stored the field_definition_number  as key and field_description as values into a hashmap to "convert" and incorporate into a "normal" definition message, but since the field_definition_number was overwritten because it was never incremented, so were my "developer data definitions", meaning most dev data was never extracted. Now I use the tuple (developer_data_index, field_definition_number) as a unique key to get the stored away field_description_message while parsing, which I guess should never be needed if I understood you correctly.

    Yes for developer_data_id I can only see manufacturer_id and developer_data_index. The developer_data_index field in developer_data_id increases in accordance with the corresponding developer_data_index in field_description, so maybe Wahoo simply implemented the protocol incorrectly.

    It kind of works if one hacks the parsing a bit though. ;)

  • 0 in reply to jlar

    The other reason that you want to use both the developer_data_index and the field_definition_number as the key into your lookup is, if you get a file with developer data from multiple CIQ data fields then the field_definition_number values will more than likely collide. Whereas as the combination of developer_data_index + field_definition_number will be unique. This assumes that the developer used unique values for the field_definition_number in their data field, but that is a documented in the CIQ SDK as a best practice.

  • 0 in reply to Ben FIT

    I didn't realise this, thanks. Have some SDK reading up to do it seems. But, it does mean I can keep my current parse method without calling it a hack. :)

Copyright © 1996-2025 Garmin Ltd. or its subsidiaries