I am trying to pull data from an Instinct Solar for a little side project. Nothing fancy, just want some basic data so I can correlate metrics like heart rate with another data stream.
As a software engineer, every step of this experience has been horrifying.
1. I couldn't just download CSVs of individual data timeseries. Even though Garmin Connect does the conversion, and shows me a graph, I can only download the original FIT binary data. What end user could have any conceivable use for this?
2. Converting these FIT files requires use of a poorly documented SDK and command line tool.
3. These files have evolved over time, without documentation or logs, making utilities created by individuals as recently as 2018 completely useless (see https://maxcandocia.com/article/2017/Sep/22/converting-garmin-fit-to-csv/). See other threads in this forum with people making comments to the effect of "oh I guess they changed it so I'm looking through previous versions of the SDK to do so-and-so..."
4. The protocol data is inexplicably confusing. Many data streams don't even use the correct field names, structure is malformed, conventions not followed, timestamps are unix epochs shifted by 20 years, except for timestamp_16s which are relative to... Something? I still can't tell what they are relative to. There's no excuse for any of this, as these bluetooth messages have no real data limitation, and the difference between a normal unix epoch at a timestamp_16 is all of 32 bytes (tops).
So what gives? How are people dealing with this? Has Garmin not learned their lesson? Security by obscurity is not an option, and these problems are not just surface-level frustrations. They're indicative of a deeply flawed engineering organization. Garmin needs to pivot immediately to leverage their community and start pushing updates that make these devices useful and secure.