IMHO, this should be the most reliable result.
Stroke rate is rounded by C2 to two decimals accuracy. So you end up with quite an inaccurate result in the output.
Here again, internal rounding might cause this.
This is actually really surprising. I must say with validating OpenRowingMonitor we structurally compare total time and distance against a PM5, and we can replicate their results quite closely on a complete session. We do see that total time seems to start around 0.5 sec later then we do.kingpeterking wrote: ↑June 8th, 2023, 6:45 amI don't think that drive + recovery is a reliable way to calculate this as over the whole piece there are lots of 'gaps' as the total drive time + total recover time does not equal the length of this piece. The other two numbers are close enough for what I need.
What I do see is the PM5 drive time is much more stable than OpenRowingMonitor's. As I'm hardly a rowing metronome, I suspect a running average there on the PM5. But using the data like you do, might push it beyond its intended use.
The start of the drive isn't observed by the PM5, nor is the end. They define a drive as an accelerating flywheel, which excludes drive sections where the excerted force is below the drag force. In practice, this is only an issue at the end of the drive, at the beginning of the drive the catch often is so explosive that you can't miss it.
Please also note that in essence a rower is a discrete reporting system: a model C reports a position every third rotation, you have no clue what happens in between. So even when you define a stroke differently (like we do in ORM: we define a drive as a situation where there is a force present countering the drag force), you don't get real zero force.
I don't know. The PM's are pretty ancient technology. I wouldn't exclude some old school lookup table somewhere that is causing repeated values.kingpeterking wrote: ↑June 8th, 2023, 6:45 am2. In every force curve (from 800+) strokes in this piece there are repeated values - 53,53 74,74 etc.. My hypothesis is that the PM algorithm is retrospectively smearing the Joules across the curve and converting to Ints and hence losing some precision.
Please look carefully how you apply the spline function. With OpenRowingMonitor we access the raw pulse data and use a running quadratic (Theil-Senn) regression on two flywheel rotations to determine angular velocity and acceleration. What I notice is that using a too agressive algorithm will destroy crucial elements in the force curve that are present in real life (like in my case, a weak back muscle).kingpeterking wrote: ↑June 8th, 2023, 6:45 amI have a long flight tomorrow, so will try to reconcile this - I will try to smooth the curve using a spline, add the missing left numbers, and then see if there is a consistent way to scale the curve so the area under it matches the characteristics data.