ErgData workout syncs to Garmin + Strava with wrong rest rate

[nradov]

There seems to be a defect in the ErgData Android app in that it records the wrong stroke rate during rest steps in structured workouts. Is this a known problem? Yesterday I did the workout of the day on the app with it connected to my PM5.
https://log.concept2.com/profile/1272303/log/92988284

The activity synced correctly to Strava and Garmin Connect. But the stroke rate shown in those platforms is completely wrong for the rest steps. It shows a constant rate during those steps which is much higher than my actual rate (I was going quite slow during the rests).

Here is the Garmin Connect activity. Screenshot is attached.
https://connect.garmin.com/modern/activity/17296126197

And here is the Strava activity.
https://www.strava.com/activities/12666245292

[Tsnor]

If you want to see correct rest data (stroke, HR, etc) download the CSV data from your C2 log entry.

You're correct. It's Broken. Look for the FIT file discussion. FWIW intervals are still broken (last I looked) when the data comes from the PM5 to a garmin watch to garmin connect. It's not just C2 log to Garmin bridge.

Also, your Garmin entry shows another persistent problem with Garmin's graphing of splits. https://connect.garmin.com/modern/activity/17296126197

The Graph of Pace has HIGH bars for dead stop. It should have LOW bars for dead stop times. High bars in the pace graph mean FAST not SLOW, except for dead stop which is highest of all.

The split for dead stop is a very high number which would go to bottom of graph of splits (time to go 500m is huge at dead stop). Instead Garmin plots a zero split (guess an artifact of dividing by zero distance travelled at dead stop) which is at the tippy top of the split range.

[JaapvanE]

The Graph of Pace has HIGH bars for dead stop. It should have LOW bars for dead stop times. High bars in the pace graph mean FAST not SLOW, except for dead stop which is highest of all.

The split for dead stop is a very high number which would go to bottom of graph of splits (time to go 500m is huge at dead stop). Instead Garmin plots a zero split (guess an artifact of dividing by zero distance travelled at dead stop) which is at the tippy top of the split range.

Yeah, it is a sloppy implementation by C2. I implemented the same interfaces, and we explicitly set all parameters to zero (or infinity for pace) when a pause is detected/forced. When you don't, you get this mess.

[Tsnor]

The Graph of Pace has HIGH bars for dead stop. It should have LOW bars for dead stop times. High bars in the pace graph mean FAST not SLOW, except for dead stop which is highest of all.

The split for dead stop is a very high number which would go to bottom of graph of splits (time to go 500m is huge at dead stop). Instead Garmin plots a zero split (guess an artifact of dividing by zero distance travelled at dead stop) which is at the tippy top of the split range.

Yeah, it is a sloppy implementation by C2. I implemented the same interfaces, and we explicitly set all parameters to zero (or infinity for pace) when a pause is detected/forced. When you don't, you get this mess.

Agree C2 should fix the intervals problem for C2 ergs. Someone at C2 should discover how intervals work for cyclists and then mirror that support. The ANT+ FE-C spec is hidden, so no idea what is in the standard. For Bluetooth FTMS there is no notion of intervals. But cycling trainers like Wahoo Kickr have programmed intervals. It would be easy to see how those show up in .fit files.

Garmin needs to fix the graphing problem.... the same "dead stop graphed as fastest pace" shows up in OTW rowing where the only sensor is a garmin watch. It's much for irritating OTW because I track the entire workout including warmup, etc., but only really look at the graph when I want to focus on one fast piece in the workout. Fast pieces don't stand out because of the dead stop time before and after. (workaround: use speed in MPH vs pace in 500m splits. but I want to see 500m split times not mph).

[JaapvanE]

Someone at C2 should discover how intervals work for cyclists and then mirror that support.

They haven't tested it with a watch. It is one of the first things we tested and fixed in our implementation.

The ANT+ FE-C spec is hidden, so no idea what is in the standard.

When you go to the ANT website (thisisant.com), you can register and download the specs.

The thing is that this is common sense: ANT+ broadcasts the machine state every 400ms to anybody who listens. So an obvious question is: what should I broadcast when the machine has stopped? And checking behaviour end-to-end is a no-brainer, especially as C2 had to pass ANT+ certification to obtain the logo.

For Bluetooth FTMS there is no notion of intervals. But cycling trainers like Wahoo Kickr have programmed intervals. It would be easy to see how those show up in .fit files.

True, but the same basic logic applies (at least inside OpenRowingMonitor): if the machine has stopped, you report that state, including zero-ed speed, etc. That part isn't rocket science.

FIT-files are an open specification, and they do provide structured workouts. Its oredecessor, the tcx file, already did that as well.

Technically, from the monitor's perspective, there is no distinction between a pause and a full stop. You detect a stopped flywheel and that is the trigger to have metrics shared reflect that. As soon as someone starts rowing again, it apperantly was a pause.

Garmin needs to fix the graphing problem....

In this specific case, it isn't Garmin's place to fix. OpenRowingMonitor's implementation shows that Garmin's implementation works correctly when you feed it the right data. C2 is broadcasting the wrong data, but Garmin must assume these metrics are right: you can't second-guess the data that is handed to you, as you have no idea what is happening there.

One can blame some things on Garmin, but they are subtle. Both OpenRowingMonitor and the PM5 diligently report the FE state (i.e. the state of the rowing machine). It would not make sense when we report "Ready" or even "Finished" to assume that the machine is moving and metrics should be recorded. Some logic might be expected here on the watch side, and auto-start and auto-stop/pause should kick in (which it doesn't). But, the PM5's approach of reporting a pace via ANT+ when the monitor considers the machine stopped is idiotic, so that shouldn't happen in the first place.

[Tsnor]

Garmin needs to fix the graphing problem....

In this specific case, it isn't Garmin's place to fix. OpenRowingMonitor's implementation shows that Garmin's implementation works correctly when you feed it the right data. ...

I buried the key information for why Garmin has to fix the graphing problem. It was hidden in a wall of words. The split graphing problem is not just for ergs.

The Graphing problem shows up for OTW rowing. No Erg. No C2.

On the water the data flow is: Garmin Watch --> Garmin Connect --> Garmin Server --> Bad Graph Display (stopped time displayed as fastest pace).

The data provided by C2 to Garmin for just row erg'ing produces the CORRECT speed graph. It's only when you display the same data as a split time graph that the glitch where "dead stop is fastest" appears. Pretty sure this is Garmin's to fix. Agree that the intervals disaster is something concept2 needs to get done. Intervals are key to training, and C2 sending bad intervals data to training aggregators undermines the open data strategy C2 worked to foster.

Aside: I really want the +1 function to praise posts. Your insight from OpenRowingMonitor is hugely helpful. Has been for years. Thank you.

[Tsnor]

.. But, the PM5's approach of reporting a pace via ANT+ when the monitor considers the machine stopped is idiotic, so that shouldn't happen in the first place.

Grin, I like to work my rest strokes on intervals. On a 30 seconds on, 90 off piece: the 90 seconds off time will be around my long/slow pace. I like seeing HR and pace during the rest intervals. (HR recovers on 30/90s, HR never drops on 40/20s). I like that C2 counts the rest meters towards that free t-shirt. For training, if Garmin ever steps up to using rowing data in their FirstBeat analytics I'd like them to use input from rest data too.

Do we need the "reporting a pace via ANT+ when the monitor considers the machine stopped" to get that ? I assume the "stopped" is the rest interval. (If rest strokes are reported via ANT+ then analytics processing must know the difference between rest and work for intervals.)

[JaapvanE]

Grin, I like to work my rest strokes on intervals. On a 30 seconds on, 90 off piece: the 90 seconds off time will be around my long/slow pace. I like seeing HR and pace during the rest intervals. (HR recovers on 30/90s, HR never drops on 40/20s). I like that C2 counts the rest meters towards that free t-shirt.

In OpenRowingMonitor we consider a programmed pause a forced stop, and we'll ignore the flywheel during that period (as it takes 2 minutes to spin down). Our approach is that if people want a low intensity interval, they should program it as such. This approach is identical to EXR, intervals.icu and TrainingPeaks. As all major players in workouts take this approach, we simply copied it (makes integration a lot easier further down the road).

According to the specs, the PM5 accounts for resting meters. I think it leads to sloppy accounting as the flywheel needs to spin down. At true rest intervals it will mess up totals. For example, my FM on ORM is exact the distance, but the PM5 overshoots with 50 meters (messing with the official recognition there).

For training, if Garmin ever steps up to using rowing data in their FirstBeat analytics I'd like them to use input from rest data too.

As said, a low intensity interval being programmed is the way all major parties do it, not a pause. But any improvement to rowing analysis is welcome in my book.

Do we need the "reporting a pace via ANT+ when the monitor considers the machine stopped" to get that ? I assume the "stopped" is the rest interval. (If rest strokes are reported via ANT+ then analytics processing must know the difference between rest and work for intervals.)

That is actually up to the monitor to report it, as it is the only one actually detecting flywheel speed. I can imagine C2 deviating from the rest of the industry and considering work done during a rest still work. Could be, but when a drive hasn't been seen for 6 seconds it will stop regardless, and pace/spm/etc. still have to be set to zero. And that doesn't happen here either.