Discussion - Recent Threads

希望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?

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

RE: Activity Profile Editor for Edge devices

dscurtis — Mon, 07 Sep 2026 17:10:23 GMT

Follow up on my earlier reply in this thread, where I quoted my project's
README describing a hard limitation around Connect IQ data fields. That
limitation turned out not to be a limitation at all — it was a message my
tooling wasn't writing. Posting the details here since it's undocumented in
the published FIT Profile and may save someone else the same investigation.

**Background.** Activity Profile files contain screen definitions where each
screen carries an array of numeric data field IDs. Third-party Connect IQ
data fields appear in that array as ID **216**. Editing such a file directly —
reordering fields, adding or removing fields on a screen holding a Connect IQ
field — produced a file that looked correct by every measure I could apply,
but rendered the Connect IQ field as **"Timer"** on the device. Whole-profile
copies preserved it; any structural edit broke it. I had concluded the linkage
was device-side and unreachable from the file.

**That was wrong.** The linkage is in the file, in **`mesg_num` 170** — which
is absent from the published `Profile['mesg_num']` table entirely (I checked
directly against `garmin_fit_sdk` 21.213.0; there are gaps at 163, 166, 168,
170–173, 175–176).

**The record.** One message-170 record exists per Connect IQ app used by the
profile, with exactly two fields:

| field | size | meaning |
|---|---|---|
| 1 | 16 × `uint8` | the Connect IQ app's UUID, big-endian |
| 2 | 5 × `uint32` (20 bytes) | packed placement list, see below |

**Field 2** is a packed array of **15-bit entries**, one per placement of that
app within the profile:

```
bits 0-4 screen slot index (the screen record's message_index), 0-31
bits 5-14 ONE-HOT field position within that screen, bit (5 + position)

entry = (1 << (5 + field_position)) | slot_index
```

Entries are stored in ascending slot order. Five slot bits (31 slots) plus ten
position bits (the ten-field-per-screen maximum) is exactly 15.

**Field ID 216 is not an app identity.** This was the part that misled me
longest. 216 is a generic "a Connect IQ data field goes here" marker — I
confirmed this by placing two *different* Connect IQ apps on the same screen
at adjacent positions, and both were stored as 216. All app identity lives in
the message-170 records and nowhere else.

**So the "Timer" behavior has a simple explanation.** 216 tells the device to
render a Connect IQ field at that position. The device then looks for a
message-170 entry claiming that exact (slot, position) pair. No matching
entry, nothing resolves, and Garmin's generic Timer fallback renders instead.
Every symptom I'd seen follows from that one rule: whole-profile copies work
because the records come along unchanged; moving a *screen* in the display
order works because that changes a different field and not the slot index;
editing a screen's field layout breaks it because positions shift and the
record doesn't follow.

**Confirmed on hardware.** All of the following were verified by round-trip
on a real Edge 530 — write the file, deploy, check the device:

- moving a Connect IQ placement to a different position on the same screen
- adding a placement to a screen that never had one
- choosing *which* app renders, by choosing which record receives the entry
- removing a placement cleanly, with no Timer left behind
- a position shift occurring as a side effect of inserting a neighbouring
field, which is the ordinary "add a field" case that broke originally

The one case I have **not** yet tested is creating a message-170 record from
scratch in a profile that carries none — i.e. adding a Connect IQ field to a
profile that has never had that app. Everything above involves editing records
the device itself wrote.

**Credit:** the idea to look at this record's second field came from the
author of Fit File Viewer (fitfileviewer.com), who had independently labeled
170 as a Connect IQ record with a "field bits" column. That column is exactly
bits 5–14 above.

---

## What this means in practice

This is now implemented and working in my toolkit, so for anyone doing the
same kind of file editing, here's where the line actually falls.

**Works:** moving a Connect IQ field to a different position on a screen,
adding or removing ordinary fields around one, removing a Connect IQ field
outright, and reordering or deleting whole screens that hold one. All of it
just requires updating that app's entry alongside the field-array write.

**Doesn't work, and this is a property of the format rather than a choice:**
adding a Connect IQ field where one isn't already. Since 216 is generic and
carries no app identity, nothing in the edit says which app a new marker
should resolve to — you'd be writing a field the device can't resolve, which
renders as "Timer". Likewise, a screen holding *two* Connect IQ fields can't
be safely rearranged from a field array alone: both are 216, so there's no
way to tell which app ended up where afterward.

**The practical workaround is cloning.** Place the Connect IQ fields once
using the device's own editor, then copy that profile — the records come
along byte-for-byte — and edit the copy freely. That gives you as many
variants as you want off one on-device setup, which covers most of what you'd
otherwise want a "place a Connect IQ field" feature for.

One deliberate design note, in case it's useful to anyone building something
similar: I kept the marker id as a small constant set and specifically did
*not* build any table of known Connect IQ apps or their UUIDs. The tool
describes the file format and never needs to know which apps exist, so there's
no registry to keep current as people install new ones.

Happy to answer questions if anyone's working in the same area.

RE: Developer onboarding blocked

3236378 — Mon, 07 Sep 2026 06:15:11 GMT

Same here. This is rubbish. I've bought expensive garmin stuff and now I can't connect with my application. Guess I'll go back to hammerhead. Their support and developers are great.

Developer onboarding blocked

Noah — Wed, 29 Apr 2026 13:19:37 GMT

I have emailed connect-support@developer.garmin.commultiple times with no response. The developer onboarding form has been down for more than a month. Has anyone had any success recently onboarding to the developer account or getting access to the activity API?

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 965[View:/cfs-file/__key/communityserver-discussions-components-files/502/rennen.zip:320:240]
File attached.

Thanks!

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

instezz — Sat, 05 Sep 2026 14:29:26 GMT

This was very interesting. The very own Fit SDK recognizes this file as legit and just fine, with absolutely no troubles.

The fitfileviewer reports are false positives and the resulting file would actually mess up your training.

I tried to run this through multiple passes by a) stripping out everything non-essential data b) spltting the file in its own 5 separate activities and c) trying to increase the first transition time a bit (since it is just 1s) with https://fitsplit.fit .

Nothing worked, Connect would still not accept this.

The kicker is that both https://intervals.icu and https://app.trainingpeaks.com/ happily accept the file without an issue.

So all of this points to a bug in Garmin Connect upload processing system... I would open a bug to them since there is nothing wrong with your file.

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

[mention:a5e36cb1ed8d46cfadc9697fec0d1f11:f586769b0822468ab7f3a94d480ed9b0]

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

RE: Activity Profile Editor for Edge devices

dscurtis — Thu, 03 Sep 2026 17:29:22 GMT

NOTE: SEE UPDATE IN MY REPLY BELOW

Ran into an interesting issue while testing this toolkit against my Edge 530: a Connect IQ third-party data field (WindField, in my case) that I'd set via the GUI on a screen showed up correctly in the file and in the toolkit's own display — but rendered as Timer on the actual device. Same thing happened whether I moved it to a full-width slot, a half-width slot, a brand new screen, or a completely fresh test profile.

After a lot of byte-level comparison between working and broken files, a few things came out clearly:

Every Connect IQ field gets assigned a plain numeric ID by the device itself — not by the app's author. WindField's author (Scott Beam) confirmed this directly: "that's not anything I set in the code at all." He also commented that Timer may be Garmin's generic fallback whenever a Connect IQ reference can't be resolved, which matched exactly what I was seeing.
That numeric ID isn't tied to one specific app. I installed a second, completely free Connect IQ app on the same device, and the device reused the same numeric ID that had previously meant WindField — now pointing at the new app instead. Since one of the two apps involved has no license or subscription at all, this rules out any licensing/anti-piracy explanation; it's just how Garmin links a screen slot to whichever Connect IQ app is currently installed in that device-assigned slot.
The file itself doesn't carry enough information to recreate this link. There's a secondary record in the file that looks like a per-app identifier, but it's constant no matter where the field is placed, and copying it byte-for-byte into a fresh slot didn't make it work. Whatever actually resolves a Connect IQ field must be checked against state that lives on the device, not in the file.

Practical result: this toolkit can reliably preserve a working Connect IQ field placement (cloning a whole profile that already has one) and can relocate it within a profile that already has it working — but it can't originate one in a slot that's never had it. Only Garmin's own on-device editor can do that first placement, at least with the testing I've done.

As of the latest version, the toolkit reflects this directly: any field ID known to behave this way now shows up as a generic "CIQ Data Field" (rather than guessing at a specific app name that might be wrong on someone else's device), and both the CLI and GUI refuse outright to try writing one into a new slot — rather than silently producing a file that looks right and doesn't work.

Full write-up with the byte-level detail is on github in PROJECT_NOTES.md (Doc rev 95–97) if anyone wants to dig further or has a different device/app combination to compare against.

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

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.

RE: Title: Garmin Connect Activity API access

Álvaro7914606 — Sun, 30 Aug 2026 18:37:25 GMT

Me uno a este mensaje, ya que yo tambien estoy interesado, deberia ser mas facil poder acceder a tus "propias actividades" e información, ya sea de una ruta realizada o un FIT cargado para realizar un trayecto y poder leer su información.

RE: Types sheet in Profile.xlsx needs some explanation

Eli FIT — Fri, 28 Aug 2026 20:58:48 GMT

The sport and language bits types are used in the CapabilitiesMesg's sports and languages arrays respectively. For Activity FIT files, the types "sport" and "sub_sport" are what are used to classify an activity's sport(s). Other types may be publicly documented but used in undocumented messages, files, etc.

Regarding the second point, "file_flags" is a "uint8z" type, meaning that it is a uint8 where "0" is the invalid value, rather than 255. Almost all "z" types in the SDK are used as bitmasks for bitfields. so it is exactly the case where a value of 0x0E would correspond to readable, writable, and erasable. Another example of a "z" type is workout_capabilities, which is a uint32z bitmask type used in a WorkoutMesg's capabilities bitfield.

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!

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

HermoT — Sun, 23 Aug 2026 17:39:17 GMT

If you load this in https://www.fitfileviewer.com

it detects and auto correct issues and you can download a corrected file.

For your file the following errors were detected:

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

Ufie — Thu, 20 Aug 2026 12:09:26 GMT

Thanks for taking a look. I wrote up a minimal reproduction, but the forum's spam
filter hid the post and the appeal was declined, so it never became visible. Happy to
send it directly if there's a better channel, or to link a GitHub gist if links are
allowed here.

In the meantime the repro is short enough to describe in words. Build a FIT file with
one record message (global mesg num 20) whose field definitions are, in this exact
order:

field 253, size 4, base type uint32 (timestamp)
field 200, size 1, base type uint8 (not present in the profile)
field 5, size 4, base type uint32 (distance -- isAccumulated in the profile)

(Field 200 is only an example -- any field number with no entry in the record profile
reproduces it. Note 200 IS defined in the session message, so it has to be a record.)

Decode it with includeUnknownData: true. Because field 200 has no profile entry but is
still added to the message, the lookup in #setAccumulatedField returns undefined and
throws "Cannot read properties of undefined (reading 'components')". Decoding then
stops, so every remaining message in the file is lost.

Swap the order of field 5 and field 200 and the same file decodes cleanly -- when the
accumulated field is read first, the unknown field isn't in the message yet.

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.

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.

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

Grace FIT — Wed, 19 Aug 2026 14:31:34 GMT

We will look into this. A minimal reproduction script would be useful, thanks.

RE: Developer onboarding blocked

dobssi — Wed, 19 Aug 2026 07:12:05 GMT

I got this in July: does not seem like anything has changed since then. Really want to connect MyRunningDashboard app beta to the Garmin API.

Thank you for your interest in the Garmin Connect Developer Program.
We are currently evolving and modernizing the Garmin Connect Developer Program.
During this transition, we have temporarily paused the review and approval of new API access requests.

We appreciate your understanding as this work continues.
At this time, we are unable to provide a specific timeline for when new application processing will resume.

We will share additional updates as they become available.
Thank you again for your interest in Garmin's Developer Programs.

Suggestion: Show estimated recovery date and time (not only hours)

1181255 — Mon, 16 Mar 2026 12:30:43 GMT

Hello,

I would like to suggest a small improvement regarding the Recovery Time metric shown after workouts.

Currently, Garmin devices display recovery as a number of hours (for example: 38 hours). While this is helpful, it could be even more practical if the device or app also showed the estimated date and time when full recovery is expected.

For example:

Current time: 16 Mar 2026, 14:00
Recovery time: 38 hours

Instead of displaying only 38h, it could also show something like:
Estimated full recovery: 18 Mar 2026, 04:00

This would make it much easier for athletes to plan their next training session without having to manually calculate the time.

If such a feature already exists in FIT SDK fields or Garmin APIs, I would appreciate any guidance. Otherwise, it might be a useful enhancement for future updates.

Thank you!