Sixteen bytes change, and nothing else. In our reference ride, 14 bytes sit in the two places that name the recording device, and the last 2 bytes are the file’s checksum, which has to be recalculated because the content changed.
We measured this on 12 September 2026 with a ride recorded on a Wahoo ELEMNT ROAM on 31 August 2026: 51.8 km, 2 h 07 min of riding time, 227’041 bytes. We wrote a copy with the identity of a Garmin Forerunner 570 and compared the two files with cmp -l, which lists every byte that differs.
Which fields change?
The fields that change are manufacturer, product, serial number and software version, in two messages: File ID, which every FIT file starts with, and Device Info for the recording device (device index 0). The time the file was created, the file type and the device type stay as they were.
| Field | Wahoo original | After the rewrite |
|---|---|---|
| File ID, manufacturer | 32 (Wahoo Fitness) | 1 (Garmin) |
| File ID, product | 47 | 4570 (Forerunner 570) |
| File ID, serial number | the Wahoo unit’s | the watch’s |
| File ID, time created | 31.08.2026 | unchanged |
| Device Info 0, manufacturer | 255 (development) | 1 (Garmin) |
| Device Info 0, product | 47 | 4570 |
| Device Info 0, serial number | the Wahoo unit’s | the watch’s |
| Device Info 0, software version | 170.81 | the watch’s |
The changed bytes all lie between offset 42 and offset 106 of the file. The FIT format stores these values in fields of fixed width, so a new value fits into the space of the old one and the file does not grow or shrink.
What stays exactly the same?
Everything you rode stays byte for byte identical: 7’632 records with heart rate, power, speed, distance and altitude, 1 lap, 1 session, 40 events, 1 activity message and the developer fields with their 4 field descriptions. Both files are 227’041 bytes long. The FIT protocol puts every record after the header and the definitions, and in this file the device is named in exactly the two messages above, which come before the first record.
Why does the checksum change?
A FIT file ends with a 2-byte CRC calculated over all bytes before it, as described in the FIT protocol. Change one byte anywhere and the old CRC no longer matches, and any program that checks it sees a damaged file. Our rewritten file passed the check over the whole file, which is the condition for Garmin Connect to accept it at all.
Where does Nabe get the values?
Nabe takes manufacturer, product, serial number and software version of your own watch, either from your Garmin Connect device list or from a FIT file your watch recorded. On 13 September 2026 both sources gave us exactly the same four values for the same Forerunner 570. Nabe writes them only when it sends a ride to Garmin Connect, never when it writes to Apple Health.
Do I lose the original file?
No. Nabe keeps the original, and “Export FIT” in every activity exports the original file, never the rewritten copy. The rewrite exists only in the file that goes to Garmin.
What did Garmin make of it?
Garmin Connect accepted the rewritten file through its import page and has listed it since then with the device picture of a Forerunner 570, its software version and the note that the summary data is original. One day later the app itself uploaded a test ride the same way, and Garmin’s activity record named the watch as the recording device with Garmin as the manufacturer. Why the device matters for your watch is explained in why an uploaded ride does not count toward Training Status.