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/437310/python-sdk-weight_scale-weight---potential-bug/2038763Wed, 17 Jun 2026 14:00:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:48b8ae07-ddc8-4a68-85c3-2f59fd03532dEli FITWith the release of the 21.208 SDK, this behavior is now fixed. Weight in the weight_scale mesg is now properly a uint16 and will apply scale as expected when either encoding or decoding data. The new version was published to PyPi available here: https://pypi.org/project/garmin-fit-sdk/https://forums.garmin.com/developer/fit-sdk/f/discussion/437845/create-workout-with-steps-using-the-sdkWed, 10 Jun 2026 17:04:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:aff0d127-5cf5-4cfe-ab45-7b5e1bf51df6ReiterPeterHi, I am currently developing a strength training application for my Garmin watch. The application is able to record an activity using the Toybox.ActivityRecording.Session. After running the workout with session.start(), session.stop() and session.save(), the activity is stored on my device and is uploaded to Garmin Connect. If I create a strength training with my watch using the standard strength training app, I have a number of sets including reps, the time of the set and the time of the pause. It looks like this in Garmin Connect: When I create an activity with my self made application, I cannot add any sets to the strength training. The method 'createFIeld(...) is not creating the correct data field in the FIT file. By decoding the FIT file from my watch, I found the required data that is used to create the sets inside the Garmin Connect app: [ {...}, { "frame_type": "definition_message", "name": "set", "header": { "local_mesg_num": 2, "time_offset": null, "is_developer_data": false }, "global_mesg_num": 225, "endian": "<", "field_defs": [ ... ], "dev_field_defs": [], "chunk": { "index": 13, "offset": 1546, "size": 51 } }, {...} ] Therefore, I tried to create the data inside my application, but haven't found any way to create the data field for sets. Does anybody know, how to add the sets to my application, so I can view the sets inside the Garmin Connect app?fieldsdkFIT datahttps://forums.garmin.com/developer/fit-sdk/f/discussion/389942/looking-for-corrupt-fit-files/2036743Sun, 07 Jun 2026 05:58:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:d8a504d6-b0ee-4366-ad24-a0e7c3b7b295AlanNo worries. Next time when you have such files, you can upload them here.https://forums.garmin.com/developer/fit-sdk/f/discussion/389942/looking-for-corrupt-fit-files/2036619Sat, 06 Jun 2026 12:12:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:dca9b199-17ee-4478-9cbd-016129e572e4Duma-70thanks Alan but it's been so long that I don't have the file anymore.https://forums.garmin.com/developer/fit-sdk/f/discussion/389942/looking-for-corrupt-fit-files/2036618Sat, 06 Jun 2026 11:51:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:2197af98-22a1-4b21-8b67-5e7c1417fd3fDuma-70thank you for trying. it didn't work.https://forums.garmin.com/developer/fit-sdk/f/discussion/389942/looking-for-corrupt-fit-files/2036564Sat, 06 Jun 2026 03:16:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:33d9ddda-a867-4183-9c36-627b97f593ccAlanCan you upload your corrupt files to Google Drive or attached to a reply so that I can analyze them for you? Currently my understanding of the FIT file is on the official FIT file format specification at https://developer.garmin.com/fit/protocol/ . So if a file is corrupt, I can try to make it follow the specification. It is interesting to see other possible corruption patterns which makes the data look strange though the file still follow the specification.https://forums.garmin.com/developer/fit-sdk/f/discussion/389942/looking-for-corrupt-fit-files/2036383Fri, 05 Jun 2026 10:42:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:565734a5-2d5c-4193-9f3c-9e8094b2c9f84870762I may be able to help with testing. I have encountered several corrupted FIT files over the years due to interrupted syncs, device freezes, and incomplete activity saves. Corrupt FIT files are unfortunately a fairly common issue in the Garmin ecosystem, and many users rely on repair tools such as FIT File Repair Tool or FIT File Tools to recover activity data. It would be interesting to see whether your analysis can help identify common corruption patterns across different devices and firmware versions.https://forums.garmin.com/developer/fit-sdk/f/discussion/437310/python-sdk-weight_scale-weight---potential-bug/2035633Tue, 02 Jun 2026 17:17:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:519de691-7e92-4455-8e05-454090b800eaEli FITHello, this is the correct place to raise this question. You are right that the issue is due to the weight field in the weight_scale mesg having a type of weight (enum) rather than a uint16. The weight type is a uint16 value under the hood but is interpreted by the Python and JavaScript SDKs as an enum rather than the intended numeric type. This causes both the encoder and decoder to handle the value without applying or reversing the scale/offset. For example, when encoding a weight with a decimal e.g. 85.56, the encoder will currently truncate the value to 85 rather than apply the scale of 100. 'weight': { '0xFFFE': 'calculating', }, Thanks for bringing this to our attention! We'll work on getting this fixed in both SDKs and address this post when it has been released.https://forums.garmin.com/developer/fit-sdk/f/discussion/437346/does-garmin-firstbeat-silently-track-aerobic-threshold-in-fitTue, 02 Jun 2026 13:22:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:79bfca8c-001b-48ef-a152-95d8b74c6492RinseRepeatIs it plausible on the newest Garmin watches they silently track Aerobic Threshold in the Firstbeat ecosystem? The advanced historical projected LTHR is new since Fenix7/Fenix8 since the Fenix6 Firstbeat doesn't do that Which makes me wonder if buried particularly in Run activities they are silently tracking Aerobic Threshold It cannot be done from a single run, it would have to be over several activity/weeks, so it would have to be forwarded in each FIT file Just to clarify, LTHR is actually anaerobic threshold (aka Ventilatory Threshold 2) Aerobic Threshold is sometimes rarely called "fatmax" or Ventilatory Threshold 1 aka AeT AeT is typically half of vo2max but not always depending on training/genetics I'm kinda surprised Garmin doesn't openly expose/track Aerobic Threshold as of 2026, they've practically exhausted every other metric in Firstbeat But it basically MUST silently do it since you are given an Aerobic+Anaerobic score for each Runhttps://forums.garmin.com/developer/fit-sdk/f/discussion/437310/python-sdk-weight_scale-weight---potential-bugMon, 01 Jun 2026 17:58:00 GMTa9571b57-dd57-479e-8763-8f8a603e40aa:477e7794-958a-46ca-8bcd-a660429fc3ba8294519I wrote an encoder based on the pythonSDK test_encode_activity_recipe.py. It seemed to work well except for the weight key like below: mesgs.append({ 'mesg_num': Profile['mesg_num']['WEIGHT_SCALE'], 'timestamp': scale_date, 'weight': 8400, #decoding issue? 'muscle_mass': 66.0, })Code The 'weight' is a weight type and supposed to be in kilograms; however, it seems to scale incorrectly (8400 instead of 84.0kg). The other keys that use mass (eg/ muscle_mass) all convert from to kilograms okay when uploading the FIT file to Connect. Perhaps it's a type weight vs type unit16 issue? Thoughts? Thanks! PS Hopefully I'm writing this in the correct place, apologies if not.fitsdkpythonscalehttps://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/.../ActivityDecode