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

FIT SDK C# changes field base type in some fields

9881454

Hi,

I'm re-encoding fit files to add extra data. For some reason, after 20+ reencodes, I'm now debugging an issue with producing invalid files.

I noticed that the C# SDK changes the field base type, at the very least since I didn't check every other field base type, on the FieldIdMesg definitions,

during the decoding process. So the FitMessages produced, already have a different field base type for some field definitions.

For example, the original file has uint16 data type (value: 4) for Manufacturer, Product and Number and uint32(value: 6) for TimeCreated.

But, during decoding of the file, the parser looks up predefined `Mesg` definitions for FileId messages, created here:

https://github.com/garmin/fit-csharp-sdk/blob/5462684d8f34aaea1d36b2fd5b134f732bc2ec9b/Dynastream/Fit/Profile.cs#L853

For some reason, the base data type is set to 132(0x84), which is ExdQualifiers. Does anyone know what that is?

And why it's changed like that?

  • +1


    Look at Table 7. The base type value for a uint16 is 0x84 (132). That same line says Type.Manufacturer‎ at the end, not Type.ExdQualifiers, which is how  the base type is mapped to a custom type. So the issue is probably elsewhere. 
    https://developer.garmin.com/fit/protocol/


    Decoding files creates artifacts in the messages. If you are decoding and then encoding messages, you will want to call mesg.RemoveExpandedFields() before passing the message to the encoder. That should remove most of the artifacts. 

  • 0 in reply to Ben FIT

    Thanks, I had found the xls with all enums much later than the first demos. Also the input fit files are generated by third party so they seem to not be correct, as per the table you pointed out. Still, encoding uses different msg defs so it encodes using right values.

    Still, for whatever reason, there were some problems with the size generated. Assuming that your suggestion to use RemoveExpandedFields fixed this, as the resulting file passed the validation. Hopefully that's that.