[clarify] use of other Garmin native fields

[JaapvanEkris]

Section

4 Native FIT Field Mappings

The text in question

There are many more native Garmin fields relevant for rowing, which might be considered optional, but require a common definition to be usefull. Many of the fields mentioned here are based on inspection of how Garmin uses these fields in indoor rowing. So for backward compatibility, it is often needed.

They are also usefull for compatibility with other platforms, as these fields are encountered in Garmin Native recordings. For example at the record level:

• Accumulated power, which in essence is the "total work done". I interpret this as the accumulated "Work per stroke" for the session
• Force. As Garin defines it as the average force across 3 seconds, I use the Average Force of the Force curve.
• Respiration rate: copied from Garmin FIT data, but extremely relevant in rowing.
• Resistance: we put the dragfactor here, clipping it to 255, which works for RowErgs, but not many other machines

On a lap level (most granular division of a training):

• Total distance: length of the lap, in meters
• total elapsed time: wall clock time passed in the lap
• total timer time: session time passed in the lap (typically matches the elapsed time, we actually copy that value)
• total moving time: time spent moving, thus exclusing pauses
• total cycles total number of strokes inside the lap
• total calories: total calories spent in the lap
• average HR/max HR: obvious
• average cadence/max cadence: obvious
• average Power/max Power: obvious
• average Speed/max Speed: obvious
• average respiration rate/max respiration rate: obvious
• Average stroke distance: average distance per stroke
• average force: this is the average of all average forces across all strokes inside the lap
• maximum force: this is the maximum of all average forces across all strokes inside the lap

On a split level (groups laps):

• Start distance: Absolute distance travelled in the session at the start of the split
• Total distance: length of the split, in meters
• total elapsed time: wall clock time passed in the split
• total timer time: session time passed in the split (typically matches the elapsed time, we actually copy that value)
• total moving time: time spent moving, thus exclusing pauses
• total calories: total calories spent in the lap
• average HR/max HR: obvious
• average cadence/max cadence: obvious
• average Power/max Power: obvious
• average Speed/max Speed: obvious

On a session level:

• Total distance: length of the session in meters
• total elapsed time: wall clock time passed in the session
• total timer time: session time passed (typically matches the elapsed time, we actually copy that value)
• total moving time: time spent moving, thus exclusing pauses
• total cycles total number of strokes inside the lap
• total calories: total calories spent in the lap
• average HR/max HR: obvious
• average cadence/max cadence: obvious
• average Power/max Power: obvious
• average Speed/max Speed: obvious
• minimum respiration rate/average respiration rate/max respiration rate: obvious
• Average stroke distance: average distance per stroke
• average force: this is the average of all average forces across all strokes inside the lap
• maximum force: this is the maximum of all average forces across all strokes inside the lap

The readings you can see

FOr processing the data well, it might help to have these standard fields. We at least have to decide how we handle them.

What did you do?

We already create them for backward compatibility with Garmin.

Your context

Garmin, OpenRowingMonitor, ESPRowingMonitor

[CrewNerd]

This all looks fine to me. I don't currently use splits at all. If a session (practice, outing, etc.) consists of multiple different workouts, those are exported as a flat list of laps representing each workout interval (work or rest). I could use splits to group the laps of a workout together, but I haven't had any calls for that so far.

Does anyone else use splits? If so, it would be nice if we all used them in the same way and called that out in the standard.

[JaapvanEkris]

Does anyone else use splits? If so, it would be nice if we all used them in the same way and called that out in the standard.

We use them, and Garmin does as well (please note, they typically use laps and when intervals are present they record them as splits). Don't know if any others do.

[CrewNerd]

I haven't been able to find anything about splits in the SDK docs, which I think is why I didn't use them. In my app, I use the following terms:

• Practice - an entire session on the water. Starts when the user selects the first workout, and ends when the user presses "End workout", and then "End practice". All sensors are running during a practice, and the practice is (optionally) uploaded to the user's selected services. A practice is exported as a single FIT session.
• Workout - can be "Just Row", a fixed time or distance, a series of alternating work (dist, time, strokes) intervals and rest intervals, or a custom series of work and rest intervals. Workouts are not directly represented in the FIT file.
• Interval - either unbounded (Just Row), or based on time, distance, or strokes. Can be a work or rest interval. Rest intervals are always based on time. Intervals are exported as FIT laps.

It's easy for me to change the FIT encoding of this, and I'd be happy to use a scheme that allows me to represent both workouts and intervals, to better describe what the user actually did.

[JaapvanEkris]

It's easy for me to change the FIT encoding of this, and I'd be happy to use a scheme that allows me to represent both workouts and intervals, to better describe what the user actually did.

Laps are described here: https://developer.garmin.com/fit/cookbook/encoding-activity-files/

Splits (or intervals as the rowing world likes to call them) are named here: https://developer.garmin.com/fit/file-types/activity/ Beyond that, we did a lot of reverse engineering based on what Garmin records if we introduce intervals. I attached a Garmin recording of a Full Marathon, with three intervals with planned pauses (every 10.5K), where every interval has 500 meter splits (laps in Garmin terms) and is followed by a 5 minute rest.

Please observe the split summary, which sums up the active and rest splits (which Garmin uses for its summaries).

The workout contains the workout steps by the way, defining the workout.

C2_RowErg_2024-05-05_1600_Rowing_FM_Garmin.zip

[CrewNerd]

Thanks for this example. This makes more sense than laps, really, and I can easily switch over.

If the athlete goes out with a clear plan for the entire practice, everything is very clear. There can be a FIT workout file describing the plan, and it can be recorded in a FIT activity file as a single session.

But let's talk about cases where there isn't a full plan in advance (or the plan is altered by weather or water conditions), and the athlete is deciding on the fly what to do next. They might have a set of pre-programmed options to draw from (intervals, fixed time or distance, etc.) but at the end of each one, they pause and decide what to do next. In this case, does it make sense to capture each "workout" as a separate session (in the same activity file)? Garmin's triathlon example uses this approach, but the rationale for separate sessions is clearer there.

Maybe the standard should just be silent on all of this, but there are clearly choices to be made in how different scenarios are encoded, and it might be nice if we had some consistency across vendors.

[JaapvanEkris]

But let's talk about cases where there isn't a full plan in advance (or the plan is altered by weather or water conditions), and the athlete is deciding on the fly what to do next. They might have a set of pre-programmed options to draw from (intervals, fixed time or distance, etc.) but at the end of each one, they pause and decide what to do next. In this case, does it make sense to capture each "workout" as a separate session (in the same activity file)? Garmin's triathlon example uses this approach, but the rationale for separate sessions is clearer there.

As indoor rowers, weather often isn't a factor. But people do deviate from plans. What we do is inject rest splits to isolate the unplanned paused bit, and continue with the plan after the restart. Intervals will force a session finish on the erg, so we'll make them comply :).

The intervals are linked to the workoutplan (id's match), and splits contain an id as reference to the workoutstep/interval. So afterwards we can see if pauses are planned as splits do have a machted pause interval (planned step) or not (unplanned pause). For us, the big benefit is that summing up the active splits will always result in moving time.

Maybe the standard should just be silent on all of this, but there are clearly choices to be made in how different scenarios are encoded, and it might be nice if we had some consistency across vendors.

Agreed, that makes interpretation a lot easier as well.