https://forums.garmin.com/developer/fit-sdk/A place to ask and answer questions related to the Flexible and Interoperable Data Transfer (FIT) Protocol.en-USTelligent Community 13https://forums.garmin.com/developer/fit-sdk/f/discussion/436873/rust-no_std-library-for-decoding-and-encoding-fit-filesMon, 25 May 2026 06:27:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:9b10cda5-58b2-46a4-82bb-d5b3b049d63cmuktihariHi, I created a Rust library for decoding and encoding FIT files with #![no_std] support, making it portable across a wide range of environments; from baremetal, WebAssembly to server applications, and potentially mobile platforms such as Android and iOS as well. The library is designed to work in baremetal Rust, where performance and memory efficiency are carefully considered. Repository: https://github.com/muktihari/rustyfit I originally started this project to learn Rust, and also because the official FIT SDK currently does not support Rust. I previously built a FIT library in Go ( https://github.com/muktihari/fit ), so I thought it would be interesting to do a Rust version as well. I Hope it could be useful for others working with FIT files in Rust ecosystems. The project is open source and still evolving, so feedback, bug reports, and contributions are very welcome. If companies or teams using Garmin FIT technologies need assistance integrating or extending it, I’d also be happy to collaborate professionally. And of course, if Garmin is ever interested in making this capability official or collaborating on maintenance, I’d be excited to discuss that as well.https://forums.garmin.com/developer/fit-sdk/f/discussion/361181/transfer-data-to-strava/2033102Fri, 22 May 2026 13:37:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:ad2fd30a-2ee8-43e3-af7e-e55ee085d32acbanksDid you ever figure this up Gazz? Running into the same issue with not being able to refresh/re-sync the data to Strava after updating the workout info on the Garmin Connect app.https://forums.garmin.com/developer/fit-sdk/f/discussion/413370/c-sdk-version-21-171-0-compile-issues-under-xcode-swift-package/2032521Tue, 19 May 2026 22:19:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:6253139d-effd-4a96-bc39-6c4d057baf20Ben FITI apologize for the very late response to your question. We had a few posts get unintentionally stuck in a moderation queue, and the queue was recently purged. Are you still having this issue? About the time of your post we did add FIT_CAST to the C SDK to help with compiling the C SDK with a C++ compiler. That change would be a suspect since it is the only change to the C SDK in a while. The "work-around" is to use the FIT Swift SDK. It will not be as fast as the C SDK, but the latest release included a handful of performance improvements. https://github.com/garmin/fit-swift-sdkhttps://forums.garmin.com/developer/fit-sdk/f/discussion/355839/type-definitions-for-garmin-fitsdk-typescript-or-jsdoc/2032515Tue, 19 May 2026 21:47:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:c40e31de-32cc-45e1-8dca-5c856cd38750Ben FITv21.205 of the JavaScript SDK added type definitions. https://github.com/garmin/fit-javascript-sdk/tree/main/src/types See the post here for more information v21.205 of the JavaScript SDK added type definitions.https://forums.garmin.com/developer/fit-sdk/f/discussion/436584/v21-205-of-the-javascript-sdk-added-type-definitionsTue, 19 May 2026 21:46:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:0ea4e4cf-a6dc-4669-a930-d614a6b7804eBen FITv21.205 of the JavaScript SDK added type definitions. https://github.com/garmin/fit-javascript-sdk/tree/main/src/types Along with the types definitions, the decoder now adheres to the profile for array fields. Array fields will always be returned as arrays, even when there is only one element Non-array fields will always return a single value, even when there are multuple values The binary protocol allows for any field to be an array, whereas the profile provides an unenforceable contract of what fields are arrays. That is true for all SDKs. Previously, the JavaScript SDK would decode a field and then check the array length. If the length as one, then it would return the value at index zero, else it would return an array. We did not want to carry that behavior forward when adding the type definitions. So now, the decoder references the profile to see if a field is an array or not and returns an array or scalar based on the profile. While this change has the potential to be a breaking change, we don't think it will. The reason being is, most people should have discovered by now that sometimes a field that was not expected to be an array might be. i.e. any string field and any field with a name that starts with "enhanced", and everyone should have checks in their code to handle this. If so, then that defensive code can be removed. If this change does break your code, the read() method of the Decoder class has a new legacyArrayMode option. The default is false. Setting the option to true will revert back to the previous behavior. The v21.205 release did not include many profile changes, a few product ids, so the other option is to stay with 21.202 and update to 21.205 at a later time. The new legacyArrayMode option is marked as deprecated since we plan to remove it by EOY26. Even if you do not use TypeScript, the type definitions should provide better auto-complete and context sensitive help when using the JavaScript SDK.https://forums.garmin.com/developer/fit-sdk/b/news-announcements/posts/fit-sdk-21-205-00-releaseTue, 19 May 2026 20:59:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:7c8ade89-46bd-423c-bd0e-24f7302b78c2Ben FITVersion 21.205.00 of the FIT SDK is available for download at https://developer.garmin.com/fit/get-the-sdk/ In this release: JavaScript SDK Performance improvements when decoding files Added TypeScript support Decoder now adheres to the profile for array fields. Array fields will always be returned as arrays, even when there is only one element Non-array fields will always return a non-array value New behavior can be overridden with the read() method legacyArrayMode option Profile Updates Garmin Product Ids fr170 fr170_music fr70_2026 d2_mach2_prohttps://forums.garmin.com/developer/fit-sdk/f/discussion/435087/persistent-429-on-api-login-account-blocked-for-48-hours/2032311Tue, 19 May 2026 10:21:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:9bf49f41-d961-4bd6-a8c8-64ae8ab8df007174550I use a python script to grab the session cookies whilst logging in manually, that I store.https://forums.garmin.com/developer/fit-sdk/f/discussion/435087/persistent-429-on-api-login-account-blocked-for-48-hours/2031937Mon, 18 May 2026 01:35:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:1dfdd47e-52cc-45bf-ab32-d7a5b05a7e0d3139143same issue for me - does anyone know what conditions cause this error to be raised, or how to avoid it?https://forums.garmin.com/developer/fit-sdk/f/discussion/389942/looking-for-corrupt-fit-files/2031699Sat, 16 May 2026 03:58:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:a06922e5-6411-42ad-bb75-80f8e77d06f5AlanI have fixed file, but it is much smaller than the original one. Please check if it works: https://drive.google.com/file/d/17m2PA01UW1f5sFwRDTnUSeB0elJVtCBk/view?usp=sharing You may also try other tools mentioned in this article https://www.datanumen.com/fit-repair/guides/repair-fit-file/ to see if one of them can fix your file.https://forums.garmin.com/developer/fit-sdk/f/discussion/436246/parsing-transitions-in-multi-sport-fit-files-best-practice/2031395Thu, 14 May 2026 20:20:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:00510ad4-94fc-4b25-8397-13fe4beb3ab4Ben FITIf the user is creating separate Activity files for each leg of a multi-sport event, the timestamps will be serial and the individual files will not overlap. So the data could be easily combined, appended really, or kept separate. The trick will be autodetecting this vs asking the user to manually link them. Go with what works best for your users and platform. The source code that goes with that article can be found here. github.com/.../ActivityDecodehttps://forums.garmin.com/developer/fit-sdk/f/discussion/436246/parsing-transitions-in-multi-sport-fit-files-best-practice/2031381Thu, 14 May 2026 19:05:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:e85ba0a7-98d7-4649-9539-23651856a6d8Sébastien DONVALThanks Ben — very clear, especially the LINQ Where() / Within() pattern combined with First Lap Index / Lap Count for matching Laps to Sessions. The Figure 2 diagram on multi-sport sessions answers our initial question completely. One follow-up if you have a moment: in practice we'll see some athletes recording a full triathlon as a single multi-sport file (with the transition sessions you described), while others split swim and bike/run into separate Activity files — they start a new Activity at T1, often on older devices or out of habit. The cookbook mentions Chained FIT files in the HRM-Swim context but not directly for this multi-sport split case. Is there a recommended pattern for stitching multiple standalone Activity files into one continuous multi-sport view, or should we treat them as independent activities and offer manual linking on our side? Either way, thanks for the responsive answer. Sébastienhttps://forums.garmin.com/developer/fit-sdk/f/discussion/436278/como-faz-para-ser-um-desenvolvedorThu, 14 May 2026 18:22:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:6575475a-7ed0-4482-bf47-fefcceaab9ca2190895eu trabalho com programação e recentemente fiz um programa de corrida e preciso ser um desenvolvedor para pega algunhas informaçõeshttps://forums.garmin.com/developer/fit-sdk/f/discussion/436246/parsing-transitions-in-multi-sport-fit-files-best-practice/2031366Thu, 14 May 2026 17:30:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:fc19c06e-cfeb-4941-941b-0de6c7eb19caBen FITIf the user has transitions enabled, then transitions will be denoted in the file as their own Sessions with the sport type transition. About halfway down this page is a diagram of the a multi-sport file with transitions. https://developer.garmin.com/fit/cookbook/decoding-activity-files/ You can slice up the record messages based on the start time and total elapsed time of the sessions. The first_lap_index and num_lap values in the Session message can be used to match Laps to Sessions. An example of triathlon-aware parsing on FIT files would be Garmin Connect.https://forums.garmin.com/developer/fit-sdk/f/discussion/436246/parsing-transitions-in-multi-sport-fit-files-best-practiceThu, 14 May 2026 06:01:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:c5dc50a4-aad1-4732-9ace-4f40be381736Sébastien DONVALHi all, I'm building the activity ingestion layer for Triscale.eu, a multi-sport coaching platform (triathlon, cycling, running) based in France. We're preparing to receive .FIT files from athletes via the Garmin Connect Activity API once our Developer Program access is approved. Quick question on multi-sport file structure: when an athlete records a triathlon as a single multi-sport activity (swim → T1 → bike → T2 → run), what's the recommended way to identify the transitions in the FIT file? From what I've read so far, it looks like multi-sport sessions are exposed as a session per sport with sport_type changes, but I'd like to confirm two points: - Are transitions (T1/T2) emitted as their own session, or as a gap between sport sessions? - Is there a recommended message type or flag to differentiate "real" sport segments from transitions for downstream analytics? If anyone here has built triathlon-aware parsing on FIT files, would value a pointer to your approach. Thanks, Sébastien D. Triscale.eu — multi-sport coaching platform, FRfit-sdkactivity-apimulti-sporttransitionstriathlonhttps://forums.garmin.com/developer/fit-sdk/f/discussion/435087/persistent-429-on-api-login-account-blocked-for-48-hours/2030994Tue, 12 May 2026 17:30:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:bf2e69dd-a1c3-4fa1-b329-2691e8e4d6d65764184I have the same issue as well, I am trying to pull the data to my own tool so I can analyze it, after first run I am just getting mobile+cffi returned 429: Mobile login returned 429 mobile+requests returned 429: Mobile login returned 429https://forums.garmin.com/developer/fit-sdk/f/discussion/353344/dive-fit-file-for-conditions/2030882Tue, 12 May 2026 07:15:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:cfa145f9-4643-4d05-9e41-6a1debe4490fGuymDiveSince I wasn’t able to get the answers I needed, I stopped the development. The support is disappointing. I still have the prototype online, but it can only process one dive at a time and there are still quite a few bugs. All processing is done locally in the browser, no data is uploaded. Your dives stay with you. You can try it there : https://convert.laplongee.info/convert Maybe two years later the SDK has improved — I haven’t checked. Garmin discouraged me a bit.https://forums.garmin.com/developer/fit-sdk/f/discussion/436118/obj-c-sdk-negative-sint32-developer-field-values-return-0/2030848Mon, 11 May 2026 23:46:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:9c8f130b-a5b0-4c68-8298-5cdd384179c3Ben FITThe Objective-C SDK is a wrapper around the C++SDK. The C++ SDKs rely on the overflow behavior of the compiler to wrap instead of clamp. I am not sure if the clamping is happening in Clang or the LLVM or if there is a compiler option that can change this behavior. This is the first report of this in four years, so we have not spent anytime on a fix. The "fix" is to use the Swift SDK, see my reply to your other question about that SDK.https://forums.garmin.com/developer/fit-sdk/f/discussion/413497/swift-sdk-is-not-handling-invalid-mesgnum-and-endianness-raw-values/2030846Mon, 11 May 2026 23:34:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:ca67268d-8cac-4fc0-829b-2e6a833be2d5Ben FITWe had a bunch of posts get stuck in a moderation queue, this was one of them, so I apologize that it took 11 months to respond. Eleven months ago the Swift SDK was still very new. The initial release was on May 5, 2025. There have updates in the last 11 months, so the issues that you were seeing may have been addressed. If you can provide an example file, we will take a look at it. Or if you want to put up a PR with a failing unit test, we will look at that too. We only publish to this repo, so we can't merge any PRs, but we can make the fixes upstream. https://github.com/garmin/fit-swift-sdk There was an issue where the decoder could be off by a byte, which could explain what you were seeing. Endianness can only be 0 or 1. If the decoder is off by a byte and any other raw value is passed then the unwrap will fail. But that is an indication of an up stream error. We recently released performance updates to the decoder. Our testing shows a 5-20% decrease in the time to decode files. The Objective-C SDK is a wrapper on top of the C++ SDK, so it will probably always be faster.https://forums.garmin.com/developer/fit-sdk/f/discussion/436118/obj-c-sdk-negative-sint32-developer-field-values-return-0Mon, 11 May 2026 23:33:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:ad8a669e-5d00-4435-9b07-5d2bc74a4adckrooneywaIn the Obj-C SDK, FITDeveloperField.getValueFor(0) returns 0 for developer fields with base type sint32 (0x85 / 133) when the value is negative. Positive sint32 values decode correctly on the exact same code path. Java SDK (via FIT CSV Tool and fitfileviewer.com) reads the same files correctly, including negatives. Same field name ( calibration on device_info ), same base type, same SDK build — only the sign differs. Reading code (called from a MesgListener): SWIFT EXAMPLE let name = devField . definition . getFieldNameforIndex ( 0 ) let rawNumber = devField . getValueFor ( 0 ) let baseType = devField . definition . getFitBaseTypeId ( ) print ( "name: \( name ?? "nil" ) rawNSNumber: \( rawNumber ) baseType: \( baseType ) " ) Output: // File with negative values on disk (e.g. -45 per Java SDK): dev field — name:calibration rawNSNumber:0 baseType:133 dev field — name:calibration rawNSNumber:0 baseType:133 // File with positive values: dev field — name:calibration rawNSNumber:108 baseType:133 dev field — name:calibration rawNSNumber:107 baseType:133 Looks like the sint32 path isn't sign-extending — values with the sign bit set get clamped to 0 instead of returned as negative. Worth checking sint8/sint16/sint64 too. Happy to share test files. Thanks!https://forums.garmin.com/developer/fit-sdk/f/discussion/413497/swift-sdk-is-not-handling-invalid-mesgnum-and-endianness-raw-values/2030840Mon, 11 May 2026 22:42:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:27fef204-6bc6-41e3-b16e-527f0aa6a694krooneywaThanks Ben. Closing this out: I confirmed these files parse cleanly with the Obj-C SDK on the same bytes, so they're not corrupt — the Swift SDK's force-unwraps on LocalMesgNum(rawValue:) and Endianness(rawValue:) were the failure point. I'm happy to take this offline... I really wanted to use your Swift SDK... but just kept encountering issue after issue (and couldn't find any support)... everything worked fine in your FIT CSV Tool and Fit File VIewer and obviously Obj-C as I'm still using it. If you think you've fixed these issues in the last 11 months happy to try it again and see if I get some performance improvements... I also have negative number SINT32 bug I would love some help with if you or anyone else wants to take a look at it... I can repro that too.