Discussion - Recent Threads

JS SDK decoder crash in #setAccumulatedField when a component field precedes its accumulated target field

ravel — Fri, 02 Oct 2026 07:41:28 GMT

Hi,

I ran into a second crash in #setAccumulatedField in the JS SDK. It's related to this thread but has a different cause. The .components fix from this thread is already in 21.217.0. This one still happens there, with the default read() options and without includeUnknownData.

Affected version: 21.217.0 (latest)

Error: TypeError: Cannot read properties of undefined (reading '0')

Trigger: a message definition contains a field with components that target an accumulated field, and that accumulated field itself, in that order. Real-world example: a Forerunner 255 triathlon file whose swim records contain both cycles (field 18, component → total_cycles) and total_cycles (field 19, accumulated).

Cause: in src/decoder.js, #setAccumulatedField (around line 725 in 21.217.0):

value = (((value / field.scale) - field.offset) + containingField.offset[i]) * containingField.scale[i];
containingField comes from Object.values(message), so it's the decoded value entry { rawFieldValue, fieldDefinitionNumber }, not the profile field. It has no offset/scale arrays.

Impact: read() aborts and every following message is lost. With files that write the summary first, the sessions are decoded but every record is lost.

Minimal reproduction:

import { Decoder, Encoder, Profile, Stream } from "@garmin/fitsdk";

const { messages, errors } = new Decoder(Stream.fromByteArray(encoder.close())).read();
console.log(messages.recordMesgs.length, errors.map(String));
// 21.217.0: 0 [ "TypeError: Cannot read properties of undefined (reading '0')" ]
Suggested fix: look up the profile field of the containing field:

if (targetField?.num == field.num && targetField?.isAccumulated) {
- value = (((value / field.scale) - field.offset) + containingField.offset[i]) * containingField.scale[i];
+ const containingProfileField = messageDefinition.fields[containingField.fieldDefinitionNumber];
+ value = (((value / field.scale) - field.offset) + containingProfileField.offset[i]) * containingProfileField.scale[i];
}

With this change the reproduction decodes all 3 records (cycles/totalCycles 10, 11, 12), and the triathlon file decodes completely (4043 records, no errors).

Other affected field pairs: in the profile, the same crash can occur for:

record: cycles → total_cycles
record: compressed_speed_distance → distance
record: compressed_accumulated_power → accumulated_power
hr: event_timestamp_12 → event_timestamp

Thanks!

Add LICENSE(.txt) file to garmin/fit-python-sdk

Matěj Hájek — Sat, 26 Sep 2026 07:44:14 GMT

Hello, all FIT SDK repositories have a LICENSE(.txt) (Flexible and Interoperable Data Transfer (FIT) Protocol License) file, but the fit-python-sdk does not.

Yes, the licence is in the file headers, but the full licence text is nowhere to be found in the repo.

Adding LICENSE.txt (or without extension) would also require checking and updating the pyproject.toml file so it points to the license file correctly.

I mention the .txt extension because all other FIT SDK repositories use it.

Bug report for https://github.com/garmin/fit-python-sdk

9678801 — Sat, 19 Sep 2026 00:19:01 GMT

As there is no way on github to submit an bug report, please find it here:

Subject:

Encoder: _MesgDefinition.equals() ignores field order, causing silent data corruption when the same field set is written in a different order

Description:

When using garmin_fit_sdk.Encoder to write two messages with the same mesg_num and the same set of field names, but inserted in a different order in the dict passed to write_mesg(), the second message's data gets silently corrupted on decode — with zero errors raised anywhere in either the encode or decode path.

Root cause

_MesgDefinition.equals() (garmin_fit_sdk/mesg_definition.py) compares two field-definition lists using an order-insensitive check:

 for lhs in self.field_definitions:
     found = any(
         lhs['num'] == rhs['num']
         and lhs['size'] == rhs['size']
         and lhs['base_type'] == rhs['base_type']
         for rhs in other.field_definitions
     )
     if not found:
         return False

This only checks that the same fields are present, never that they're in the same position. But the FIT wire format is strictly positional: a Definition Message declares field order once, and every following Data Message for that local slot is raw bytes with no field names — the decoder matches byte N to whatever field is in position N of the last Definition Message it saw for that slot.

Encoder.on_mesg() uses equals() (via _lookup_local_mesg_num) to decide whether it can skip writing a new Definition Message and reuse the currently-active one. Because equals() ignores order, it answers "yes, same" for two messages whose fields are actually in a different order — so the Encoder skips emitting a new Definition Message, while still writing the new message's data bytes in its own (different) order. The decoder is left using the stale Definition Message's field order to interpret data bytes that were actually written in a different order — every field after the first divergence point gets misinterpreted.

Minimal reproduction:

 from garmin_fit_sdk import Encoder, Decoder, Stream
 import datetime

 encoder = Encoder()
 encoder.write_mesg({
     'mesg_num': 0, 'type': 'workout', 'manufacturer': 'development',
     'product': 1, 'product_name': 'x', 'serial_number': 1,
     'time_created': datetime.datetime.now(datetime.timezone.utc),
 })
 encoder.write_mesg({'mesg_num': 26, 'wkt_name': 'repro', 'sport': 'cycling', 'num_valid_steps': 2})

 # Same 5 field NAMES as the second message below, different insertion order
 encoder.write_mesg({
     'mesg_num': 27, 'message_index': 0,
     'intensity': 'active', 'duration_type': 'time', 'duration_value': 300000,
     'target_type': 'power', 'target_value': 2,
 })
 encoder.write_mesg({
     'mesg_num': 27, 'message_index': 1,
     'duration_type': 'repeat_until_steps_cmplt', 'duration_value': 1,
     'target_value': 3, 'intensity': 'active', 'target_type': 'open',
 })

 data = encoder.close()
 messages, errors = Decoder(Stream.from_byte_array(data)).read()
 print('errors:', errors)  # []  <-- no error reported at all
 for step in messages['workout_step_mesgs']:
     print(step)

Expected: the second workout_step message decodes with duration_type='repeat_until_steps_cmplt', duration_value=1, target_value=3.

Actual: it decodes as complete nonsense (e.g. duration_type='distance', target_type='speed', intensity='other', with garbage large integer values) — silently, with errors == [].

Suggested fix:

In _MesgDefinition.__init__, sort field_definitions into a canonical order (by FIT field number, which is already available on each entry as fp['num']) right after they're built, before the existing equals() check ever runs:

# in _MesgDefinition.__init__, right after the "for field_name in mesg:" loop
# that builds self.field_definitions, before the developer-fields section:

self.field_definitions.sort(key=lambda fd: fd['num'])

This makes the already-existing (order-insensitive) equals() check safe: since every definition is now built in the same canonical order for a given field set, "same fields present" and "same order" become equivalent, so no divergence between what equals() considers identical and what's actually written to the wire is possible anymore. It also has a nice side benefit over the alternative fix (making equals() order-sensitive instead): callers that produce the same field set via different code paths/insertion orders now correctly collapse into the same reused Definition Message, rather than each needing its own — smaller output, not just correct output.

Alternative fix

Instead of canonicalizing field order, equals() could be made order-sensitive — comparing fields positionally rather than via any(...) membership:

 def equals(self, other):
     if (self.global_message_number != other.global_message_number
             or len(self.field_definitions) != len(other.field_definitions)
             or len(self.developer_field_definitions) != len(other.developer_field_definitions)):
         return False
  
     for lhs, rhs in zip(self.field_definitions, other.field_definitions):
         if lhs['num'] != rhs['num'] or lhs['size'] != rhs['size'] or lhs['base_type'] != rhs['base_type']:
             return False

     # ... developer field comparison unchanged
     return True

This also fixes the corruption — two definitions with the same fields in a different order would now correctly be treated as different, so the Encoder would emit a fresh Definition Message before the differently-ordered data, and decoding would work correctly again either way.

The trade-off versus the canonical-ordering fix: it's correct but not optimal. Two calls to write_mesg() that happen to produce the same field set via different insertion orders (exactly the case in the reproduction above) would now always be treated as distinct definitions, each needing its own Definition Message written to the stream — larger output than necessary, since the data itself is equivalent either way. Canonicalizing field order fixes the same bug while also letting those calls collapse into one reused definition, producing smaller files as well as correct ones.

BOA TARDE. COMO CONSIGO TRAINING API DA GARMIN PARA UM APP PARTICULAR,TENHO PROVAS REAIS QUE O APP FUNCIONA

5166054 — Wed, 16 Sep 2026 20:30:17 GMT

BOA TARDE. COMO CONSIGO TRAINING API DA GARMIN PARA UM APP PARTICULAR,TENHO PROVAS REAIS QUE O APP FUNCIONA

希望SDK增加字段“下一个闹铃启动时间”，便于表盘设计，实现用户能在表盘上直接看到下一个闹铃时间

3020145 — Wed, 09 Sep 2026 10:07:36 GMT

用户可以在表盘直观地看到下一个闹铃时间。

Why REM and AWAKE colors so similar?

1449457 — Wed, 09 Sep 2026 07:23:02 GMT

If there are tiny awake moments vs REM you can't tell. UI should be much simpler, especially for metrics that are so vastly different.

what are the GPS "mode change" event message codes?

RinseRepeat — Tue, 08 Sep 2026 19:46:13 GMT

DC Rainmaker documented this series of events for GPS mode changes in the FIT file?

This is neat, I was not aware that was recorded? Apparently that was in a Fenix7 series so I assume it survived to F8 and F9?

Is it recorded in the single-band models?

Would definitely like to decode those, curious of BeiDou is being used in continental US (hope so)

ps. any chance a CIQ datafield can watch for these events in realtime and show on the screen the GPS band status?

Recomputing session/lap HR aggregates after structural FIT edits: sane approach? (+ looking for weird multi-session files to test against)

instezz — Sat, 05 Sep 2026 11:47:44 GMT

Hi,

been building a browser tool on the JS SDK (currently 21.178.0) that does a few structural rewrites to FIT files: splicing in a second sensor's HR stream record-by-record (nearest-timestamp match against a chest-strap export), moving the boundary between sessions in a multisport file, and cropping/splitting a recording.

After any of these, the original session/lap HR (and speed/cadence/power) aggregates are obviously stale, so I recompute avg/max by re-scanning the record window rather than trusting the device-written values.

Two things I'd like a sanity check on from people who've been deeper in the profile than I have:

1. Lap→session linkage: I'm matching a lap/length to its owning session purely by timestamp overlap against the session's window, since there's no explicit foreign key from lap/length to session in the profile as far as I can tell. Is that the right assumption, or is there an index-based chain (message_index/first_lap_index/num_laps) that's meant to be authoritative instead, that I'd be wrong to ignore? I couln't figure it out.

2. Boundary rounding: when I split a lap that straddles a moved session boundary, I've had to add a ~1s tolerance because start_time is 1-second resolution while total_elapsed_time (which I use to derive an end timestamp) is sub-second, so a lap's recorded start and an adjacent session's derived end can disagree by up to a second for what's really the same instant. Is that a known quirk of the encoding, or something specific to how certain devices round on write?

Separately:

if anyone has a genuinely odd multi-session FIT lying around (COROS, Suunto, Wahoo, or a Garmin multisport structure that doesn't follow the usual swim→bike→run shape), I'd genuinely like to try my tool against it and see where it breaks. Free QA for me, and I'll tell you if I find anything wrong with the file too. Or if you want to do that yourself and let me know how it went you can find the tool in live beta at https://thesplit.fit

Thanks in advance for your help
Stefano

could a developer make a tiny FIT file to toggle the auto-brightness setting despite missing menu option

RinseRepeat — Fri, 04 Sep 2026 18:21:16 GMT

please take a look at my idea over here to force auto-brightness to turn off despite no menu option to do so

I found in the settings.fit file there is such an option and I remember from the early HRV days we had the same problem with no menu option to turn on logging so garmin released a tiny FIT file to import and toggle the option directly

I'd like to try setting it to zero to see if it disables adaptive brightness on AMOLED on FenixE/8 series

RE: 23.27 Screen Brightness issue

https://forums.garmin.com/beta-program/fenix-8-series/f/community-discussion/443109/23-27-screen-brightness-issue/2060207

Upload.fit datei nicht möglich

4653394 — Wed, 02 Sep 2026 19:41:47 GMT

ich würde gerne eine .fit datei hochladen, erstens wird meine .fit datei nicht erkannt, d.h. wenn ich sie hochladen will muss ich sie über drag&drop rein ziehen. Beim Hochladen kommt die fehlermeldung: „Beim Hochladen der Daten ist ein Fehler aufgetreten. Versuche es erneut.“

können sie mir weiterhelfen

Activity Profile Editor for Edge devices

dscurtis — Mon, 31 Aug 2026 16:49:23 GMT

For anyone who is interested in editing their Edge Activity Profile screens and data fields on a computer vs the Edge itself, this project may have what you’re looking for.

github.com/.../Activity-Profile-Editor

I only have my own Edge 530 to test this on, so the confirmed field IDs, screen types, and layouts are all specific to that model. The underlying screen/data-field mechanism looks like it should carry over to other Edge models (same 10-field-per-screen cap, same layout patterns from what I've seen in demo videos of newer touchscreen units), but that's unconfirmed without real testing on other hardware — collaboration from anyone with a different model would help a lot.

You can use it in purely a “read” mode, if you just want to start by viewing existing Profiles. The deploy method pushes the changed Activity Profile .fit files through the NewFiles folder/restart mechanism to make the changes.

Here are the features that are built into this toolkit and available in the GUI:

- Cloning - copy an existing Activity Profile to a new name
- Backups - backup Activity Profiles to local disk
- Backup pruning - delete old backups
- Change Screens - Add/Delete/Reorder/Hide/Layout-A/B
- Data Fields - Add/Delete/reorder/Modify the data fields within a screen
- Startup.txt - Change the text and display timer value of the boot message file
- Restore - restore a deleted Activity Profile if it was previously backed up by the toolkit
- Import - import a Profile from another source or other backup method
- Favorite - save a favorite screen to reuse/transfer to another Activity Profile

The code is written in Python and uses the garmin-fit-sdk and wxPython for the GUI interface.
There are also a set of CLI tools, in case you want to use individual aspects of the toolkit without the gui_app.
The tools are compatible with MacOS (tested on MacOS 26) as well as Windows (tested on Win 11). It was also tested on Win 10 - 32-bit, but requires manual install of the Python version and the wxPython (see the README for those details).

Here’s a sample output of a couple of the cli tools:

% python3 garmin_device.py detect
Garmin device found at: /Volumes/GARMIN/Garmin
Manufacturer: garmin
Product: edge_530
Serial: xxxxxxxxxxxx <-not showing my actual serial number
Software version: 981

% python3 fit_dump.py screens ./CyclingRoadClonebox.fit
=== Screen order as viewed on-device (reorderable via --swap-order) ===
POS SLOT CNT LAY FLAG TYPE FIELDS
1 [ 0] 6f B Screen 1 Timer, Distance, Power Graph, Heart Rate Graph, Speed, Cadence
2 [ 7] 7f Screen 4 Cadence Bars, Lap HR, Last Lap HR, EPOC, HR Zone Graph, Anaerobic TE, Aerobic Training Effect
3 [ 1] 2f Lap Summary Speed, Distance
4 [ 2] 0f Map
5 [ 3] 2f Elevation Percent Grade, Elevation (ft)
6 [ 8] 0f GroupTrack List
7 [13] 2f ClimbPro Percent Grade, Elevation (ft)
8 [ 4] 2f Cycling Dynamics Power Phase Left, Power Phase Right
9 [ 5] 2f Screen 2 Avg Speed, HR Zone Graph
10 [ 6] 7f Screen 3 Speed Bars, HR Bars, Power Bars, Lap HR, Last Lap HR, Lap %Max HR, Respiration
11 [ 9] 10f Screen 5 Lap Time, Odometer, Dest. Ahead, Lap Dist., Last Lap Speed, Total Descent, Lap Speed, Reps to Go, Lap Power, Target Power
12 [11] 10f Screen 6 Target, Step Time, Duration, Workout Comparison, Workout Step, Light Battery, Last Lap Power, Lap Time Standing, Lap Time Seated, Avg PCO

Also, here's a few screen shots of the GUI

Types sheet in Profile.xlsx needs some explanation

BESSELING.FRANK — Wed, 26 Aug 2026 20:29:13 GMT

I need some clarification regarding the Types sheet in Profile.xlsx. It may be documented somewhere, but I haven’t been able to find it. Two things are unclear to me.

First, I noticed that of the roughly 200 documented Types, only about 140 are actually used in the Messages. For example, "language_bits_1" through "language_bits_4" do not appear in any Message. The same applies to "sport_bits_1" through "sport_bits_6". What is the purpose of these unused Types?

Second, the use of hexadecimal values in the Value column is not always explained. In some cases it’s clear, such as in the comments for "file.mfg_range_min" and "file.mfg_range_max". But for the type "file_flags", it could be interpreted that the bits can be used cumulatively. In that case, 0x0E would correspond to readable & writable & erasable. And maybe other uses of hexadecimal values are applicable elsewhere.

Can someone clarify this, or provide a link to existing documentation?
Many thanks!

Title: Garmin Connect Activity API access

4019245 — Wed, 26 Aug 2026 13:40:06 GMT

Hi,
I’m interested in using the Garmin Connect Activity API to access activity data from Garmin devices with user authorization.

I understand that new Garmin Connect Developer Program API access requests may currently be paused.

Is there currently any way to request access to the Activity API, or any waitlist I can join for when applications reopen?

I would also be interested in the Health API and Training API in the future.

Thanks.

Multisport FIT file rejected as "invalid" by Garmin Connect (unknown_233 message type)

1337595 — Sun, 23 Aug 2026 15:32:16 GMT

Hi all,

I recorded a multisport activity (run-bike-run duathlon) on my Forerunner
965 on 2026-08-23. Garmin Connect rejects the file as "invalid" via all
import paths (auto-sync, Garmin Express, manual web import).

Inspecting the file with a third-party FIT tool shows it's complete and
readable (7,394 messages, 1,561 record entries, 11 laps, all sessions
present). It contains an unofficial/undocumented message type
(unknown_233, 2,632 occurrences) that isn't in the official FIT SDK
profile — possibly what's tripping Connect's server-side validator.

Has anyone seen this before, or is there someone here who could take a
look with FFRT (Fit File Repair Tool)?

Device: Forerunner 965forums.garmin.com/.../rennen.zip
File attached.

Thanks!

Where can I find the name of the product whose ID is 16338

KenDuffill — Wed, 19 Aug 2026 15:33:57 GMT

When decoding the Device Info message from y Forerunner 45 watch I cannot find a description for product ID 16338

Where can I find the name of the manufacturer whose ID is 36084

KenDuffill — Wed, 19 Aug 2026 15:30:11 GMT

When I decode Device Info Messages from my Forerunner 45 watch I find that manufacturer ID 36084 is Unknown.

JS SDK: decoder crash on unknown field before an accumulated field

Ufie — Tue, 18 Aug 2026 19:45:14 GMT

Decoding with Decoder.read({ includeUnknownData: true }) fails with:

"Cannot read properties of undefined (reading 'components')"

Decoding stops at that point, so all remaining messages in the file are lost.

Cause is in src/decoder.js, #setAccumulatedField() (line 719 in 21.213.0):

let components = messageDefinition.fields[containingField.fieldDefinitionNumber].components ?? []

With includeUnknownData: true, fields that have no Profile entry are present in message, so this lookup returns undefined. It only triggers when the unknown field comes before an accumulated field (distance, total_cycles, accumulated_power) in the message definition — the same fields in the opposite order decode fine.

Fix is the optional chaining already used on the next lookup two lines down:

let components = messageDefinition.fields[containingField.fieldDefinitionNumber]?.components ?? []

Reproduced on 21.208.0 and 21.213.0, Node 22. Happy to post a minimal repro script if that helps.

has anyone got a developer field to render in connect recently? mine decode fine and show up nowhere

jpcams — Sat, 08 Aug 2026 20:31:36 GMT

i've got a connect iq strength app that records sport 10 / sub sport 20. it writes seven developer fields through fitcontrib: reps, load and hold on MESG_TYPE_LAP, then total reps, total sets, volume and avg rpe on MESG_TYPE_SESSION.

i've already decoded it with the fit sdk (export original out of connect rather than pulled off the watch over usb, happy to redo it that way if that matters). everything is in there and looks correct to me. unique ids in developer index 0, base types matching the declared sizes, units present, each one bound through native_mesg_num. values check out too: total sets 19 against 19 laps carrying reps, total reps 209 against 209, volume 4019.5 kg summing reps × load. 44 laps, and 0 set messages, which i understand is why the sets table is empty and is a ciq limitation rather than anything i can fix.

what i can't work out is the developer fields. connect displays none of the seven, on web or in the phone app. no chart series offered beyond heart rate on either. the sdk docs for createField say a developer field can show up as a graph, as lap information or as workout summary information, and i'm getting none of the three.

so:

has anyone actually seen a developer field render in connect recently, on any sport? i've got no other ciq app in my history writing them, so i can't tell if this is strength specific or general.
does native_field_num matter here? mine is unset on all seven and i can't tell from the docs whether connect keys the display off it.
is the strength page fed purely by set messages, so laps and developer fields have nowhere to go on that activity type by design?

happy to post the full decode if it's useful.

Can a commercial Android app bundle the FIT Java SDK (com.garmin:fit) for distribution?

Sugoi — Thu, 06 Aug 2026 12:47:21 GMT

Hi, I'm building an Android app (not yet published) that uses the official FIT Java SDK (com.garmin:fit, via Maven Central) to read FIT files recorded by Edge/VIRB devices, and I plan to distribute it commercially through Google Play.

Section 1 of the SDK License Agreement permits using the FIT protocol "in any software created by Licensee", but Section 2(c) separately restricts distributing the Licensed Technology to third parties. Since an Android APK bundles its compiled dependencies inside the package it distributes, I want to confirm: does shipping an app that includes the compiled FIT SDK count as "distributing the Licensed Technology" under 2(c), or is that covered as normal use under Section 1?

Would appreciate any clarification - want to be compliant before launching. Thanks!

Battery life

2886759 — Mon, 03 Aug 2026 11:33:56 GMT

After the last update on the Fenix 8, the battery life is very bad. Fully charged on Saturday, and today it's at 55%

The always-on display is one, but it was on before the update,

Privacy and ability for offline mode

6856588 — Sun, 02 Aug 2026 23:15:30 GMT

I’ve had 4 Forerunners in 10 years and I want to be able to have my watch sync with my phone, without syncing with the Cloud…I’d like this setting for privacy as Garmin doesn’t have end-to-end encryption. This should be an easy add to benefit those who are in the wilderness or want additional digital privacy.

Requesting a FIT manufacturer ID as an individual developer — process and timing?

8531634 — Sat, 01 Aug 2026 14:45:20 GMT

Hello,

I am an individual developer in Japan, working on an Android cycling app that writes

FIT files. I would like to obtain a FIT manufacturer ID so that my files identify the

application correctly — they currently use manufacturer = 255 (development).

Following the guidance posted in this forum, I contacted Garmin business development

by email about a week ago. I have not heard back yet, and I understand these requests

may simply take time.

Could anyone advise:

1. Is contacting Garmin business development by email still the correct route for

manufacturer ID requests, now that the ANT+ Adopter request form is no longer

available to non-members?

2. What is the typical turnaround for such a request?

3. Is there any additional information that helps — company details, a product

description, or a sample FIT file? I am happy to provide whatever is needed.

Thank you.

How to get RR intervals from FIT hr messages (Fit file message 132)?

pepe — Tue, 28 Jul 2026 18:53:16 GMT

Garmin units write RR intervals to Fit file from Garmin HRM 600 and other Garmin HRM with memory at the end of a offline activity,(like swimming) writing 11 RR intervals per message,

= TYPE=12 NAME=hr NUMBER=132
--- timestamp=1126167485=2025-09-07T08:18:05Z
--- event_timestamp=1778373632=1736693.000 s
--- fractional_timestamp=0=0.0000 s
--- filtered_bpm=71=71 bpm
--- xxx251=0=0
==
= TYPE=11 NAME=hr NUMBER=132
--- filtered_bpm=71=71 bpm,71 bpm,71 bpm,71 bpm,71 bpm,71 bpm,71 bpm,71 bpm
--- event_timestamp_12=0=0.000 s,0.031 s,0.068 s,0.214 s,0.117 s,0.206 s,0.075 s,0.108 s,0.021 s,0.022 s,0.083 s,0.135 s
==

Type‑12 Anchor Processing

timestamp (absolute Unix time) and the scalar event_timestamp (a 32‑bit integer in 1/1024‑second units).
The anchor’s absolute time is calculated as:
anchor_abs = timestamp + event_timestamp / 1024.0
This event_timestamp scalar is used as the baseline for the first beat of the subsequent Type‑11 message (if present).

Type‑11 Message Processing (The Core RR Extraction)

When a Type‑11 message is encountered, GC processes two fields:

1. Scalar `event_timestamp`

This is a 32‑bit integer representing the cumulative offset (in 1/1024 seconds) of the first beat of this message from the start of the activity (or midnight).

2. Packed `event_timestamp_12` (field 10)

This field contains 12 bytes (0–255). They are not RR intervals – they are packed 12‑bit cumulative offsets that extend the 32‑bit timestamp for the subsequent 11 beats.
Needs unpacking the bytes using a specific bit‑twiddling algorithm (overlapping pairs, alternating extraction).
For each pair of bytes, reconstruct a 12‑bit value
Result per Type‑11 Message
- 1 absolute beat time from the scalar event_timestamp.
- 11 additional absolute beat times from the unpacked bytes.
- Total: 12 absolute beat times per message.
- 11 RR intervals (differences between consecutive absolute beat times).

Fenix 6 product names in fit sdks seem to be wrong?

HermoT — Sat, 25 Jul 2026 17:41:33 GMT

Hi Ben FIT

Correct me if I am wrong, but it seems to me the fenix 6 series have the wrong names in the fit sdks.
https://github.com/garmin/fit-javascript-sdk/blob/main/src/profile.js#L24921-L24925

My belief is that the "Sport" is the regular fenix 6, and what appears to be the regular fenix 6 in the sdk should be the Pro.

I have confirmed this with a fit file from my own fenix 6 Pro.

SDK	Reality	Notes
3287: "fenix6SSport"	fenix6S
3288: "fenix6S"	fenix6SPro
3289: "fenix6Sport"	fenix6
3290: "fenix6"	fenix6Pro
3291: "fenix6x"	fenix6XPro	Based on naming convention of "S" in fenix6S, "x" should be uppercase "X"

Same most likely applies for the Asia versions too:
https://github.com/garmin/fit-javascript-sdk/blob/main/src/profile.js#L24955-L24959

Accidental duplicate post. Please delete this Discussion copy and retain the Question version.

Wilson — Wed, 22 Jul 2026 12:37:27 GMT

【Duplicate submission created accidentally. Please delete this Discussion thread. The Question version is the intended thread:

How should more than five RR intervals from one BLE notification be serialized into FIT hrv messages? 】

I would like to distinguish between the capacity of one FIT hrv message and the number of RR intervals delivered by a sensor in one BLE notification.

In a previous FIT SDK discussion, Ben FIT explained that the hrv.time array contains between one and five valid RR intervals, with five physical slots provided because the maximum heart rate representable in a FIT Record message is 254 bpm:

https://forums.garmin.com/developer/fit-sdk/f/discussion/255690/fit-file-hrv-data-array-interpretation/1220787

However, an incoming BLE Heart Rate Measurement notification does not necessarily represent one second of measurements and does not necessarily correspond one-to-one with a FIT hrv message.

The Bluetooth Heart Rate Service specification states that:

the RR-Interval Present flag may change during a connection;
a Heart Rate Measurement may contain no RR intervals or multiple RR intervals;
with the default 23-byte ATT MTU, one notification may contain up to eight or nine RR-Interval fields, depending on the other fields present;
the notification interval is determined by the sensor and may vary.

Specification:

https://www.bluetooth.com/wp-content/uploads/Files/Specification/HTML/HRS_v1.0/out/en/index-en.html

A valid sensor implementation may therefore send several heart-rate-only notifications and then include the accumulated RR intervals in a later notification. If it batches approximately two seconds of data, a single notification can contain more than five RR intervals when heart rate exceeds approximately 150 bpm.

My FIT-format questions are:

Is the five-value capacity only a limit of each individual FIT hrv message?
If a recording device receives six to nine RR intervals in one BLE 0x2A37 notification, is the expected FIT representation to write the first five values in one hrv message and the remaining values in one or more immediately following hrv messages?
Is it valid for multiple consecutive FIT hrv messages to originate from the same incoming BLE notification?
Since hrv messages have no independent timestamps, are the values in these consecutive messages simply interpreted as one continuous RR-interval sequence in file order?

This question was prompted by an actual Forerunner 955 activity:

Approximately 2,004 seconds / one-second Record messages
1,018 FIT hrv messages
Average spacing of approximately 1.968 seconds per hrv message
Physical capacity: 1,018 × 5 = 5,090 RR-interval slots
Valid RR intervals in the FIT file: 5,012
RR intervals in the aligned sensor-local sequence: 5,294
Difference: 282 RR intervals

If only one five-slot hrv message is written every 1.968 seconds, the maximum storage rate is:

5 × 60 / 1.968 ≈ 152.4 RR intervals per minute

This is very close to the heart-rate range above which the discrepancy becomes apparent.

In a separate low-heart-rate test, an nRF Connect log showed that the sensor sent a Heart Rate Measurement notification approximately every 700 ms but included accumulated RR intervals only about once every two seconds. All 136 RR intervals covered by that capture were present in the BLE payloads, in the correct order.

I have not yet captured the BLE payloads during the high-heart-rate portion, so I am not claiming that the FR955 has definitively discarded the missing values. I am first trying to establish the intended FIT serialization behavior.

Could the FIT team confirm whether more than five RR intervals received together should be preserved by writing multiple hrv messages, and whether that representation is supported by Garmin activity files?

Discussion - Recent Threads

JS SDK decoder crash in #setAccumulatedField when a component field precedes its accumulated target field

Add LICENSE(.txt) file to garmin/fit-python-sdk

Bug report for https://github.com/garmin/fit-python-sdk

BOA TARDE. COMO CONSIGO TRAINING API DA GARMIN PARA UM APP PARTICULAR,TENHO PROVAS REAIS QUE O APP FUNCIONA

希望SDK增加字段“下一个闹铃启动时间”，便于表盘设计，实现用户能在表盘上直接看到下一个闹铃时间

Why REM and AWAKE colors so similar?

what are the GPS "mode change" event message codes?

Recomputing session/lap HR aggregates after structural FIT edits: sane approach? (+ looking for weird multi-session files to test against)

could a developer make a tiny FIT file to toggle the auto-brightness setting despite missing menu option

Upload.fit datei nicht möglich

Activity Profile Editor for Edge devices

Types sheet in Profile.xlsx needs some explanation

Title: Garmin Connect Activity API access

Multisport FIT file rejected as "invalid" by Garmin Connect (unknown_233 message type)

Where can I find the name of the product whose ID is 16338

Where can I find the name of the manufacturer whose ID is 36084

JS SDK: decoder crash on unknown field before an accumulated field

has anyone got a developer field to render in connect recently? mine decode fine and show up nowhere

Can a commercial Android app bundle the FIT Java SDK (com.garmin:fit) for distribution?

Battery life

Privacy and ability for offline mode

Requesting a FIT manufacturer ID as an individual developer — process and timing?

How to get RR intervals from FIT hr messages (Fit file message 132)?

Type‑12 Anchor Processing

Type‑11 Message Processing (The Core RR Extraction)

1. Scalar event_timestamp

2. Packed event_timestamp_12 (field 10)

Result per Type‑11 Message

Fenix 6 product names in fit sdks seem to be wrong?

Accidental duplicate post. Please delete this Discussion copy and retain the Question version.

1. Scalar `event_timestamp`

2. Packed `event_timestamp_12` (field 10)