idea: improve decoding of not officially documented fields

[ThomasKuehne]

Might be interesting to decode FIT messages that aren't documented - or only partially documented - in the Profile.xlsx.

The Gadgetbridge project has a fit_profile.json describing a lot of FIT fields. While that isn't in the Profiles format it may still be interesting to include that as a secondary definition source.

[roznet]

Thanks — I had a look at their fit_profile.json and the coverage is genuinely interesting. Diffed against Profile.xlsx (SDK 21.158) it has 93 message types Garmin doesn't document at all (location, personal_record, best_effort, golf_course, physiological_metrics, sensor_settings, …) plus ~1,000 extra field definitions on messages we already decode — 37 on session, 18 on lap, 17 on record. All of that currently surfaces as mesg_num_29 / mesg_num_20_field_num_90: the values are parsed fine, they just have no name.

Two things to sort out before any code.

Licence. Gadgetbridge is AGPL-3.0 and that JSON is a source file in their repo. FitFileParser is MIT, and I have no visibility into who has embedded it — some of those apps may well be closed-source. So I can't vendor the file, or generated code derived from it, without pushing an AGPL question onto consumers I can't identify or warn. I'd rather ask the Gadgetbridge maintainers whether they'd put just that data file under a permissive licence (MIT/CC0) for interoperability. Happy to open that request.

Design, if the licence clears. Not a second input to the generator — that would break the "Profile.xlsx is the single source of truth" invariant and make every SDK bump a reconciliation exercise. Instead a runtime overlay: an optional JSON profile consulted only when the generated lookup falls back to mesg_num_<n> / ..._field_num_<n>. No cost on the hot path, no behaviour change when no overlay is supplied, and the repo ships the loader and format rather than third-party data. A user who is fine with AGPL can point it at their own copy today.

Worth noting their names are community guesses rather than Garmin's (record field 100 is literally unknown_latitude), so overlay-sourced names should be distinguishable in the API — otherwise a later SDK release renames a field out from under callers. Their scale/offset coverage is also thinner, so units would be partial.