Rowing phase detection

[KjellVerb]

Hi,

After my first full session with ORM, I got some unexpected results so I decided to dive into the data logs, where I saw unexpectedly long drive phases:

10/30/2024, 9:58:32 PM | npm[923] | stroke:  409, dist: 4016.7m, speed: 3.54m/s, pace: 2:21/500m, power: 124W, cal:  233.0kcal, SPM: 22.7, drive dur: 1.35s, rec. dur: 1.27s, stroke dur:  2.64s
10/30/2024, 9:58:33 PM | npm[923] | *** RECOVERY phase started at time: 1114.1413 sec
10/30/2024, 9:58:35 PM | npm[923] | *** DRIVE phase started at time: 1115.6762 sec
10/30/2024, 9:58:35 PM | npm[923] | *** Calculated drag factor: 279.3795, no. samples: 122, Goodness of Fit: 0.9885
10/30/2024, 9:58:35 PM | npm[923] | *** Calculated recovery slope: 0.005217, Goodness of Fit: 0.9885
10/30/2024, 9:58:35 PM | npm[923] | stroke:  410, dist: 4026.5m, speed: 3.53m/s, pace: 2:21/500m, power: 123W, cal:  233.6kcal, SPM: 22.6, drive dur: 1.34s, rec. dur: 1.31s, stroke dur:  2.66s
10/30/2024, 9:58:36 PM | npm[923] | *** RECOVERY phase started at time: 1117.0236 sec
10/30/2024, 9:58:38 PM | npm[923] | *** DRIVE phase started at time: 1118.5359 sec
10/30/2024, 9:58:38 PM | npm[923] | *** Calculated drag factor: 280.3024, no. samples: 120, Goodness of Fit: 0.9888
10/30/2024, 9:58:38 PM | npm[923] | *** Calculated recovery slope: 0.005234, Goodness of Fit: 0.9888

This prompted me to look around in the .csv's (Raw and RowingData). After some graphing around, I discovered that the auto-calculated drag factor drifts a lot and the driveTime variation is closely linked to that. This could also be the other way around of course because the dragfactor calculation has less of a recovery phase duration to work with if the drive phase is incorrectly detected too long.
I checked and autoAdjustRecoverySlope is set to false so I don't think the culprit is there.

Does anyone have an idea of what to check next?

[Abasz]

Di you have the raw data file? I like to graph those in excel to see if they are consistent as well as it is possible to replay a session which helps tweaking the settings without needing to row in real time

It is possible that you need stricter goodness of fit for the drag factor calculation.

[Abasz]

Magnetic break force is Indeed linear. Which means on slower rotation speeds the applied drag factor is higher than on higher speed.

Thus also means that when you do a stronger pull your recovery slope will shallower, while slower stroke steeper. This is why autoadjust does not work and DF moves around. As if there is too much moving around it is not able to detect (you simply never reach the set minimum recovery slope value

I experienced the same issue with old flywheels where there is a lot of bearing and mechanical drag

[JaapvanEkris]

The acc/dec approach works well indeed for stroke detection. My machine has a magnetic brake so the drag force should be quite linear to angular velocity. My raw data (see post below) also looks really clean to me so I'm not sure where the algorithm would go wrong. Even on a row without autoAdjustRecoverySlope (simulated on the same data) there is quite a big variation in dragfactor which seems to inversely impact the calculated power as well.

The issue is that most machines are air/waterbracked, where the dragforce is a function of the angular velocity. On a magnetic rower, it is a constant force. So you need a different formula to make df stable, but as the df * velocity underpins many formulea, you essentially end up rewriting the entire engine.

Using a longer averaging for dragfactor, or a fixed value for df typically leads to satisfactory results.

[KjellVerb]

So in a way this should be quite easy to calculate from the raw data but magnetic rowers would require a separate physics model where the dragForce is autocalculated instead of the dragFactor?

[JaapvanEkris]

So in a way this should be quite easy to calculate from the raw data but magnetic rowers would require a separate physics model where the dragForce is autocalculated instead of the dragFactor?

I wouldn't say easy, it is just different than we do, and AFAIK, nobody did this before. Removing the factor df * angular_velocity for each formula sounds easy, until the formula you are trying to adapt contains just one of the two elements, and not the other.

[KjellVerb]

Guess I'll just accept the inaccuracies (as they are consistent between sessions) and save up for a 2ndhand C2

[KjellVerb]

Correctly disabling autoAdjustRecoverySlope solved the issue, see here the before and after of the original RowingData and the re-simulated RowingData