Making the C-SDK read stance_time_balance and step_length

Greetings,

  I finally figured out how to add missing fields to the C-SDK FIT_RECORD_MESG structure and configure the SDK so it populates the fields.

However, I discovered (it took a while for that to happen) that when adding new fields at the end or FIT_RECORD_MESG, decoding the new field values only works correctly when the new struct field's boundaries are 16bit aligned.

I found it curious that heart_rate having a very low FIT_RECORD_FIELD_NUM (3) is not declared until half of the other fields in the record struct.

I guess that's because this is an intentional limitation of the C-SDK decoder. Sure enough there are no 16 or 32 bit values declared after heart_rate FIT_RECORD_MESG.

My question: Is the assumption correct and when adding new fit fields that are missing in the C-SDK one just has to be careful to add 16bit or 32bit value BEFORE the first 8bit value heart_rate?

Thanks for any comments on that!

Best Regards

Herb

  • The source code, or at least the message and type definitions, for the C SDK is not hand-coded, it is generated by the Fitgen.exe app which is included with the SDK. Take a look at the "Customizing the FIT SDK with FitGen" recipe, specifically the section on "Optimizing the FIT C SDK". 

    https://developer.garmin.com/fit/cookbook/fitgen/ 

    To add stance_time_balance and step_length to the generated C SDK, you need to edit config.csv (change a few zeros to ones) and run Fitgen.exe. Fitgen calculates the order of the fields in the message structs to achieve the byte alignment specified in config.csv.

    The C SDK is primary used by devices where minimize code size, memory usage, and file size is important. Config.csv provides a way to pare down the C SDK to just the messages and fields being used by a particular device.

  • Many thanks for the quick and exhaustive response.

    I went ahead and regenerated the SDK using the updated field configuration from config.csv as suggested and it generated exactly the same layout that I had put in there manually.

    Switching to the C++ SDK would be great but it's not something we can do at the moment for reasons of code stability.

    Thanks again!

    Herb