field_definition_number is sequential in fit definition but different

[Abasz]

In the fitRecorder.js I noticed that the fit file definition uses different IDs than the specification on the develop branch: https://github.com/sanderroosendaal/rowingdata/blob/develop/docs/FIT_EXPORT.md

In the devlop branch it is sequential (and also in your sample fit file) but the fitRecorder.js has non sequential numbering.

I am pretty sure this inconsistency is just because of the changes that have been made but I wonder which one is correct?

[Abasz]

Also I think rowsandall uses sint16 for force curve data and we are using unit16. Generally I think this is fine I dont even understand why there would be negative force, but I would still align this.

EDIT: Actually negative would make sense on a real boat if you would paddle backwards may be? :D

[JaapvanEkris]

Also I think rowsandall uses sint16 for force curve data and we are using unit16. Generally I think this is fine I dont even understand why there would be negative force, but I would still align this.

Our npm package doesn't allow sint16 arrays. And binary, sin16 and uint16 are compatible as you don't go big or negative...

Is already reported to Sander a couple of weeks ago: sanderroosendaal/rowingdata#63 (comment)

EDIT: Actually negative would make sense on a real boat if you would paddle backwards may be?

In NK equipment a negative force is measured during the recovery. One might debate if it is a usefull measure, but its there.

[JaapvanEkris]

In the fitRecorder.js I noticed that the fit file definition uses different IDs than the specification on the develop branch: https://github.com/sanderroosendaal/rowingdata/blob/develop/docs/FIT_EXPORT.md

In the devlop branch it is sequential (and also in your sample fit file) but the fitRecorder.js has non sequential numbering.

I assume you are referencing the ID's for the developer fields? It is a bit of a moving target as they've changed a lot of times. I gave up on keeping up with their numbers scheme. So it works now, and we'll see where they end once it becomes final.

Not sure if external sites look for id's or names. But for us it is no big issue to change to whatever they land on.

[Abasz]

Our npm package doesn't allow sint16 arrays. And binary, sin16 and uint16 are compatible as you don't go big or negative...
It is a bit of a moving target as they've changed a lot of times. I gave up on keeping up with their numbers scheme. So it works now, and we'll see where they end once it becomes final.

Ok, I did not know that :D As I said in the other thread, the ecosystem is a bit messy to navigate in :D

I assume you are referencing the ID's for the developer fields?

Yes. And its understood now.

[JaapvanEkris]

Ok, I did not know that :D As I said in the other thread, the ecosystem is a bit messy to navigate in :D

Agreed. Partially because Garmin really should open up a lot of undocumented fields, as it makes the underlying data structure and its possibilities a lot clearer to everybody. But Sander's approach of mixing his migration needs to Intervals.icu and a common FIT-data standard across manufacturers isn't helpfull. He sometimes indicates stuff isn't supported (like laps), but it then becomes unlear whether he says that as owner of RowsAndAll.com not migrating that kind of data, or as member of the development team of Intervals.icu importing the FIT-data that still contain lap data.

I found that Intervals.icu basically ignores any interval/lap data (opened an issue, see https://forum.intervals.icu/t/intervals-icu-messes-up-fit-lapdata/127532). I'm not too happy about it as in our plan for 0.9.8 I still have the ambition to set training tagets, which might not translate to Intervals.icu as they might simply ignore that. I'll do an architectual spike in a couple of weeks and see what happens when I sent in this data. Just attaching a (2:15-intervalnumber)/500m pace target to each interval should do the trick I guess.

[Abasz]

I found that Intervals.icu basically ignores any interval/lap data

That explains actually a lot... I was trying to figure out stuff and I did not understand why my fit file generated with the esprm gui does not work but your sample does. Actually when you wrote that they ignore it, I realized that they generate that lap dataset from a heart rate perspective somehow... . When I added heartrate suddenly I saw some laps :D

[Abasz]

I noticed that in GC avg stroke rate is empty with the sample fit (and as a matter of fact empty with any fit I generate manually :))

I have been checking what the difference is if we include or do not include splits in the fit message or only laps, and interestingly when you only include Laps this avg stroke rate part is filled in correctly.

Also as a side note, avg stroke rate shows up correctly if I take an activity generated by my watch.

Have you encountered this issue?

[JaapvanEkris]

Didn't have this issue to be honest:

[Abasz]

2026-03-29_18-12-39_rowing.fit.json

What about the attached file? This is the one that you have sent to Sander a few weeks back as an example.

(json extention is only for being able to attach, for some reason fit is not accpeted)

[JaapvanEkris]

2026-03-29_18-12-39_rowing.fit.json

What about the attached file? This is the one that you have sent to Sander a few weeks back as an example.

Then I have the same issue. Might it be related to the presence of multiple intervals, or the presence of rest intervals?

[Abasz]

Might it be related to the presence of multiple intervals, or the presence of rest intervals?

Yes could be, originally I suspected that the length of the respective split. But its extremely difficult to test (this was the reason for asking you first so I avoid reinventing the wheel). The strange part is that in my case I have "identical" split and lap (meaning that I treat all laps as splits basially

2026-04-19 22-55-55 - session.zip (note data is simulated)

This is without split (it actually groups the consecutive active intervalls automatically)

With split (it adheres the fact that every lap is a split).