Is there really no "jacket mode"?

Good point!

Newfiles/ still exists and can be used to manually add certain things like courses, locations and workouts.

I didn't realize Garmin "officially" supported hacking settings.fit, but I wouldn't be surprised if it still works on 955, via newfiles/.

I was thinking about trying the NEWFILES directory as well, but figured it was a (too) long shot. The HRV turn on by file was a documented piece you could 'compile' yourself from a .csv-source. This Data entry in Settings.fit where the byte is switched... well, it was identified as OHR, but with 'unknown' parts. So I'm sceptic about trying that route.

Years ago I experimented with hand-editing the Locations/Lctns.fit (filename?) on the Fenix5X both directly and through NEWFILES but my memory pushes forth an image of doubled entries in the final outcome, then having to delete... ah, can't remember. I'll try NEWFILES for Settings.fit tomorrow (the whole file). Let's hope there won't be double stuff in the outcome! Though, the file will probably just be silently deleted and ignored.

Reading the .xml file in the root directory one can see which files are expected to use the NEWFILES directory when updating.

soptunna said:

This Data entry in Settings.fit where the byte is switched... well, it was identified as OHR, but with 'unknown' parts. So I'm sceptic about trying that route.

You mean when you use FIT2CSV in the FIT SDK? I don't think that's indicative of anything, since 99% of valid Garmin FIT files (whether activity, settings, or otherwise) seem to have "unknown" data when you use that tool.

I think it's more indicative of the fact that the tool is just bad, as:

- it doesn't even know all the valid Garmin data (and it's ignorant of more than just the newest stuff)

- when it converts unknown data, it throws away the underlying numerical data, so when you convert the CSV back to FIT, you lose any data it didn't know about. It would've been so simple to preserve the underlying numerical data, by rendering it as "Unknown (42)" (for example) as opposed to "Unknown"

The FIT file repair tool in the FIT SDK is maybe even worse, as it throws away a ton of valid activity data that even the FIT2CSV tool might preserve.

The "unknowns" are so frustrating, here is the gist of what Garmin said about all the undocumented FIT formats and unkown fields: these are new developments and may change, it is too resource-intensive to document them and update the SDK.

I guess they started off using the FIT standard back when it was fully documented and built it out in all manner of ways. Some files are really simple to guess/parse; sleep, hrvstatus, and device (on devices with solar). Some are still relatively well documented but gained lots of "unknowns" over the years; activity, monitoring. Monitoring files I always found a challenge with the full and partial timestamps, running totals, keeping track of summer/wintertime for the day totals, and so on. 

I suppose one could train an AI to learn what the fields are when one has sufficient data. I have 10 years worth. Maybe it is time for a big fat GPU, or is black friday already past..

This thread has gone out of scope quite a bit but I find it highly enjoyable! 

Well, I could have been knocked over by a feather; it worked! Copying the whole Settings.fit file (with the one byte change) into GARMIN/NewFiles flipped "Source Switching". And that was the only change performed - phew...

I also tried the old 'Flip HRV logging On/Off' through a .fit file in NewFiles, and that worked as well. And now? Crafting a one-liner for "Source Switching"?

Here is a csv for the HRV toggle (On):

Type,Local Number,Message,Field 1,Value 1,Units 1,
Data,0,file_id,type,2,,
Data,0,hrm_profile,log_hrv,1,,

file_id,type,2 means a configuration/setting. Based on different Settings.fit changes I did directly on the watch, we can see the following positions:

Data,13,ohr_settings,unknown,"1",,enabled,"1",,unknown,"0",,unknown,"0",,unknown,"1",,unknown,"1",,
                                           |                                      |            |
[FR955 FW 19.18 Menu -> Health & Wellness  |                                      |            |
  -> Wrist Heart Rate -> Status Auto|Off]  |                                      |            |
                                           |                                      |            |
Auto --------------------------------------.                                      |            |
                                                                                  |            |
[While Swimming On|Off] On -------------------------------------------------------.            |
                                                                                               |
[Source Switching On|Off] On ------------------------------------------------------------------.

I am not a .fit file expert, not even an intermediary. Does the top line need alterations with a multi-value Data entry? And what about commas in the data. I believe double commas are used to separate values, so tentatively:

Type,Local Number,Message,Field 1,Value 1,Units 1,
Data,0,file_id,type,2,,
Data,0,ohr_settings,1,,1,,0,,0,,1,,1,,

Would that turn all three options ON? I'll grab a bit of breakfast, and do a trial run with those lines while digesting.

Well done! That is amazing! I can't wait until tonight to do this myself! And have a look at your questions.

I'm using FitCSVTool.jar from a modern SDK that Garmin maintains nowadays. But it behaves as you describe.

Data,0,ohr_settings,1,,1,,0,,0,,1,,1,, in a .csv compiles to .fit which decompiles as a .csv with zero data points: Data,0,ohr_settings,,,, (which does nothing when sent through NewFiles).

Using: Data,0,ohr_settings,unknown,"1",,enabled,"1",,unknown,"0",,unknown,"0",,unknown,"1",,unknown,"1",, results in the message "Ignored 5 unknown field(s) and 0 unknown message(s) during encoding" and results in a

Data,0,ohr_settings,enabled,"1",,

file. Had to put that line in code tags because it broke the forum message posting...

I even tried with

Data,0,ohr_settings,,1,,enabled,1,,,0,,,0,,,1,,,1,,

but it turns into the empty 

Data,0,ohr_settings,,,,

.fit file.

I'm out of ideas. Of course, people can hexedit their own Settings.fit like I did in the first step, but it requires them to know the exakt address. The 1ba7 for "Source Switching" toggle has probably changed from FW 19.18 (forum breaks on full hex address today, for me...)

Here's the hex-diff I got yesterday:

--- hex-off.txt 2024-11-28 04:03:20.861314478 +0100
+++ hex-on.txt  2024-11-28 04:03:44.565431354 +0100
@@ -440,7 +440,7 @@
 00001b70  ff ff ff ff ff 0c ff ff  ff ff 1d 00 ff ff ff ff  |................|
 00001b80  ff ff ff ff ff ff ff ff  4d 00 00 bc 00 06 01 02  |........M.......|
 00001b90  84 00 01 00 02 01 00 03  01 00 04 01 00 06 01 00  |................|
-00001ba0  0d 01 00 00 00 00 01 00  4e 00 00 de 00 0a 01 04  |........N.......|
+00001ba0  0d 01 00 00 00 00 01 01  4e 00 00 de 00 0a 01 04  |........N.......|
 00001bb0  8c 05 04 86 06 20 07 fe  02 84 00 02 84 02 01 00  |..... ..........|
 00001bc0  03 01 00 04 01 00 07 01  02 08 01 00 0e 7f 00 00  |................|
 00001bd0  00 ec bf 71 3f 00 00 00  00 00 00 00 00 00 00 00  |...q?...........|
@@ -631,5 +631,5 @@
 00002760  ff ff 0a 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 00002770  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 00002780  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
-00002790  00 00 00 13 00 ff ff ff  04 5c                    |.........\|
+00002790  00 00 00 13 00 ff ff ff  8a 5e                    |.........^|
 0000279a

I had WHR turned OFF (1ba3) and "While Swimming" turned ON (1ba6) in both Settings.fit files.

After hexediting the .fit file it is easy to find the new CRC. Just run "java -jar [path-to] FitCSVTool.jar -d Settings.fit and it will decompile to a .csv version and debug to screen.

Text to long again...

First example here is the untouched file. At the end of the debug output comes:

Fit.Decode: Expecting next 2 bytes to be end of file CRC = 0x5E8A
Fit.Decode: 0x8A - RECORD
Fit.Decode: 0x5E - RECORD

That is byteswapped as usual in *nix. When running a hacked .fit through this (before CRC edit) it screams:

Fit.Decode: Expecting next 2 bytes to be end of file CRC = 0x5C04
Fit.Decode: 0x8A - RECORD
Fit.Decode: 0x5E - RECORD
Error: A problem occurred while decoding the file. The decoded CSV file may be truncated Settings-switch-on*.csv files.

And then just hexedit in the 04 5C at the last two bytes in the file.

Wow... such a fight with this forum editor and size limits and forbidden strings... Now time for a little run and dinner!

soptunna said:

The 1ba7 for "Source Switching" toggle has probably changed from FW 19.18

And another fact places it definitely at different addresses for all of us. The spot in the Settings.fit file is _below_ the area where we have our list of saved or connected gadgets like Stryd and HR sensors, Ear Buds etc. In my file they are prefixed by Data,11. Data 12 are watchface_settings before we reach the target of our interests, ohr_settings.

A _lot_ of empty file-space between the sections!

flowstate said:

It would've been so simple to preserve the underlying numerical data, by rendering it as "Unknown (42)" (for example) as opposed to "Unknown"

In this link there seems to be a programmer who has done something of the sort on github:

https://forums.garmin.com/developer/fit-sdk/f/discussion/385131/unable-to-convert-csv-to-fit-file

Muktihari says there:

I make a program to convert FIT to CSV and then convert it back CSV to FIT without losing any unknown data, by make a custom values: message number and field number in the unknown name and print type as units: