stadelmanma
commented
3 months ago I don’t remember exactly what made parsing them difficult since I haven’t touched the parsing routines in awhile. If I’m remembering things correctly, it was two things. Where they get defined in the FIT file made it not possible to parse them with my implementation during the initial pass. Then byte endianness information getting lost made it difficult to do it as a post processing step.
I think step one would be to simply return them as raw bytes included with the normal output. Probably gated behind a new DecodeOption variant. Once you’ve got a raw output we can figure out how best to implement the “second pass” to actually decode them. It may be sufficient to track some additional metadata during the initial pass to resolve them after the fact.
Hi,
the README states:
This is an issue for me, as the Stryd running footpod writes its measurements into the fitfile as Developer data field (at least with Garmin watches), so I would like to add this functionality, ideally in a way that I can contribute back :).
Any pointers where to start and which approach would be desirable would be helpful. Otherwise I will just try my best and post a PR when I have something.