Simulation to generate Performance Monitor test data

[klamp169]

Simulation to generate Performance Monitor test data

I cooked up a very simple simulation of the concept2 type air-rower using Pathsim, very similar to what Nomath has done.

The purpose is to generate data to test performance monitors (PM) like ORM (but also my PM2 monitor) with well defined and repeatable simulated rowing strokes. (I would not be surprised if the ORM developers already use something similar.)

The model simply describes the dynamics of the flywheel under the influence of the chain force. Details like bungee cord force or rower acceleration to pick-up to the flywheel speed are all left out. The model simply solves the equation: $J\dot\omega=T_{in}-k\omega^2$, where $J$ represents flywheel inertia, $T_{in}$ is given by the input force and sprocket radius $r_s$ , $T_{in}=F_{drive}r_s$ ($F_{drive} = 0 [N]$ during recovery) and $k$ equals the drag factor. Input force curves can be specified as function of time or drive position.

In a post processing step, the flywheel angular position $\phi=\int\omega dt$ is translated into time values (by inverse interpolation) at which $\phi$ reaches the angle of the respective magnets. These time values are stored in a csv file, that can be used directly in ORM and my own rwnp. A similar approach is used to generate an audio file that can be played from regular soundcard output to drive the PM2 monitor (not suited for PM5, obviously!)

As an example, the last three (of 20) parabolic strokes (600 [N] peak, 1.3 [m] drive length, 20 [SPM], $J=0.1001 [kgm^2], k=120\cdot10^{-6} [kgm^2]$ and $r_s=1.415[cm]$) are shown in the figure. The power per stroke can be calculated beforehand to be 173.33 [W]. The steady state simulated stroke distance = 11.77[m] (with magic constant c = 2.8[kg/m]). I include the accompanying csv file with 6 pulses per revolution to play with concept2_3_sim_6p.csv.

If there is any interest in other simulation data (rectangular or triangular force curve, effect of irregular rowing, effect of magnet placement error, effect of (high) friction, linear (for magnetic rower) instead of quadratic damping term, etc.), let me know.

[JaapvanEkris]

That is cool!

I've been doing part of this by hand, but is doesn't scale well.

I have some requests here:

• Could you make this a little over 500 meters (allowing us to test algorithms settling in)
• Could you have another one with a little random noise?
• And one with magnet placement errors?
• And a magnetic rower

This indeed would allow us to experiment with our algorithms.

[JaapvanEkris]

The benefit of the less accurate approach is that it is much more robust against measurement noise.

I tend to neglect this complication. Sorry for that.

It is good you are asking questions. It is a trade-off between precission and robustness and its balance could change if our filtering gets better. Once we stop questioning the status quo, we stop improving.

HOWEVER, this was based on a pre-CEC-filter world. Moving there still is a goal.

You spent a long thread on CEC, but I still do not think I fully get it.

In essence, it is a modified Kalman filter.

The C2 RowErg has a sinoid pattern in its magnet configuration. I suspect they do some analog voodoo magic with frequency modulation, which in theory would provide a constant measurement of angular velocity. Or it is a production tolerance. But their magnet positioning isn't perfect and thus it adds noise to our data.

We know that during the recovery, the time between impulses over time should form a straight line (i.e. the recovery slope, 1/ω over time). This is how we determine the dragfactor. It is also a long line often containing hundreds of datapoints, making it robust against individual datapoint errors.

What we do with the CEC filter is measure the deviation between the raw value and the ideal value expected by the recovery slope. We feed that into a regression algorithm per magnet to find the structural error between raw and ideal value for that magnet. We then use that relation to clean up the new datapoints for that magnet.

It is an additional pre-filter helping the main algorithms. As experimenting with your data shows, the main algorithms are extremely robust against noise. But the CEC filter does help stabilize things.

It works well, we see less issues with noise, and thus a more stable set of metrics.

I will add a csv file with rectangular force curve, no noise, no placement error, 1.3 [m] drive length, 20 SPM, theoretical power: 260 [W], 60 strokes, >800 [m]. Force jumps up and down to 600 [N] in 10 [ms] (which is simulation time step) . I am curious to know what slew rate your CEC filter produces. My filter produces about 10 [N/ms]. c2sim_m0fxp0n0_6p.csv.zip

Interesting, but not sure how this relates to the CEC-filter. CEC learns during the recovery from the recovery slope.

To explain, we have two seperate streams of metrics calculation:

• Basic metrics, like time, distance, pace, power, strokerate, distance per stroke etc., which are always based on (a significant) angular distance travelled, a (significant) time period to do that and a dragfactor using robust math
• Advanced metrics like instantanuous handle force, instant handle speed and instant handle power which are based on angular velocity and angular acceleration using a quadratic Theil-Sen based Savitzky–Golay filter.

There are two streams with different filter mechanisms involved, so there is no reason that calculation of power via the basic metrics should match power via the advanced metrics. In a pure theoretical noisefree environment they should, but in reality it is tough.

PM5: logical choice. Making smooth force curve is easy, but it might become just a Gaussian bell curve blob.

That indeed is a concern. But my own force curves show enough issues to convince me there is enough detail there :)

Could this approach be related to the sometimes (too) long drive lengths? (BTW. rwnp estimates the drive length of the square wave force curve as 1.4[m]. This is obviously due to the fitering in combination with the unrealically steep force curve.)

I suspect it is a side effect of the filtering we do on the force curve. It tends to flatten peaks (as it tends to favour gradual change). So peak force is less high. As torque is used for stroke state transitions, it also tends to lengthen the drive as force fades out a bit slower. So the overall curve is squashed a bit.

[klamp169]

For a magnetic rower: I assume the flywheel dynamics can be modeled with: $J_m\dot\omega=T_{in}-k_m\omega-T_{bm}$. Due to lack of data, I assume that the effective inertia $J_m$ equals $0.1001[kgm^2]$ and $T_{bm}=0[Nm]$. I kept everything else the same as for the first simulation we discussed. For $k_m$ I found that a value of $0.015 [kgm^2/s]$ gives reasonable results. I used the parabolic force curve, exactly as before, which should lead again to 173.33 [W] in steady state. see csv file c2sim_m1fxp0n0_6p.csv.zip (no noise, no placement error). rwnp found 175[W]. I did not make any modifications to rwnp, which is of course 'ridiculous', since for instance $\omega = c/(t-t0)$ during recovery does not hold anymore. Coast down follows exponential decay now, not 1/t as for the air-rower (and water rower??). I hope it works for you. Let me know. Of course, I'm open for any suggestion (like magnetic rower parameters) to improve.

[klamp169]

What we do with the CEC filter is measure the deviation between the raw value and the ideal value expected by the recovery slope. We feed that into a regression algorithm per magnet to find the structural error between raw and ideal value for that magnet. We then use that relation to clean up the new datapoints for that magnet.

Clarifying and inspirational. Thanks.

Interesting, but not sure how this relates to the CEC-filter. CEC learns during the recovery from the recovery slope.

I was just curious to what extent ORM 'flattens' the rectangle. I tried it myself in ORM and the resulting force curve looks very similar to what rwnp produces. But I am not 100% sure I use the proper ORM-settings.

To explain, we have two seperate streams of metrics calculation:

• Basic metrics, like time, distance, pace, power, strokerate, distance per stroke etc., which are always based on (a significant) angular distance travelled, a (significant) time period to do that and a dragfactor using robust math
• Advanced metrics like instantanuous handle force, instant handle speed and instant handle power which are based on angular velocity and angular acceleration using a quadratic Theil-Sen based Savitzky–Golay filter.

There are two streams with different filter mechanisms involved, so there is no reason that calculation of power via the basic metrics should match power via the advanced metrics. In a pure theoretical noisefree environment they should, but in reality it is tough.

Now I do understand your worries on internal consistency.

PM5: logical choice. Making smooth force curve is easy, but it might become just a Gaussian bell curve blob.

That indeed is a concern. But my own force curves show enough issues to convince me there is enough detail there :)

Same here!

[JaapvanEkris]

This one is > 691 meter and includes some magnet placement error : [-0.01, 0.1, 0.2, -0.2, -0.1, 0.01][deg] concept2_3_sim_6p.csv.zip. Note that the magnet placement error sums to zero. It is of the order of magnitude I see with my concept2 with optical encoder lines.

Could you create a clean one with variation across the strokes. For example alternating strokes with 500N peak and 700N peak. I want to see how the mathematics handles this.

[klamp169]

Here you go:
c2sim_m0fxp0n0_6p.csv.zip

Parabolic force curve, no magnet placement error, no noise, drive length $l_{drive} = 1.3 [m]$, drag factor = 120, 500/700[N] alternating, starting with 500[N], 20 [SPM], $T_b=0[Nm]$.
This should result in alternating stroke power of 144.44 [W] for the 500[N] stroke and 202.22 [W] for the 700[N] stroke, based on $P_{stroke}=\frac{SPM}{60}\left(\frac{2}{3}F_{max}l_{drive}\right)$ (Holds for parabolic curves only.)
Interestingly (and somewhat annoyingly), since monitors generally leave out the dynamic part of the power, these values will not show up. At 700[N] strokes, the power shown on my PM2 monitor is 161[W] and at 500 [N] strokes the power is 181 [W]. I am very sure you are quite familiar with this phenomenon.
When I run this data through ORM, I see very little power variation between the alternating strokes: 168[W] to 170[W] in steady state.

Let me know if this data is ok for you.

You may also like a simulation with single power strokes every N strokes (say, N=15).

[klamp169]

So, that's what I did:

A power-stroke every 15 strokes.
c2sim_m0fxp0n0_6p.csv.zip
(Apologees for same file name as previous one.)
I have been experimenting with it a bit already and it leads to interesting results:

The curve labels must be interpreted as follows:

• P_dyn is output from rwnp and represents the power calculation including the dynamic term $J\dot\omega\omega$
• P_PM2 is the transcribed power values from the PM2 monitor
• Power (watts) originates from ORM CSV file.
• P_rwnp represents output from rwnp and is defined as $P_{rwnp} = \frac{1}{T}\int\frac{k}{J}\omega^3dt$ integrated over entire stroke.

The power-stroke occurs at stroke number 30.

Some observations:

1. Effect of power-stroke on PM2 output can be seen upto 3-4 strokes later.
2. Peak power value on PM2 occurs at the stroke directly after the power-stroke (annoying, IMHO).
3. Steady state power values are quite close, ORM is slightly lower than other values, as seen before.
4. P_rwnp is in good agreement with P_PM2 and also with the theoretically derived values, given above.
5. The power-stroke power for ORM is considerably higher than for PM2 (or P_rwnp), but the power value for the stroke after the power-stroke is considerably lower.

All this has some effect on the power readout of the various monitors, obviously, but little to no effect on the more important (?) distance rowed.

I hope some aspects may have some value to you. It helped me to understand the various monitor outputs and to pinpoint some significant differences.

[klamp169]

The obvious next step is to compare PM2, ORM and rwnp on the basis of simulated data, with a focus on distance rowed. The major advantage of using a simulation is that we know the distance rowed from the simulation itself to a very high degree of accuracy. We know the drag factor, also for the very first stroke and drag does not exhibit stroke to stroke variation, as seen experimentally. We can also avoid placement error and measurement noise.

I created a simulation starting from standstill ($\omega=0 [rpm]$). A complicating factor is that with a handle-distance based parabolic force curve ($F_{max} = 600[N]$, stroke length$ = 1.3 [m], $ drag = $120\cdot10^{-6} [kgm^2]$) such a simulation does not start. (The parabola has zero value at stroke start and the flywheel remains stationary.) Therefore, I introduced a rectangular first stroke with the same energy content as the parabolic strokes ($F_{max} = 400[N]$, $P_{stroke}=173.33[W]$ at $20 [SPM]$). In real life, the first stroke usually also shows a more rectangular behavior compared with the following strokes.

From the simulation I generated .csv files for ORM (6 pulses per rev), rwnp (12 pulses per rev) and a .wav file for the PM2 monitor (3 pulses per rev).

The distance-results from the simulation, ORM and rwnp are the same within one meter (after 1800 [s]: simulation: 7055.2[m], ORM: 7054.6 [m] and rwnp: 7055.3 [m]).

The PM2, however, produced a distance of 7094 [m], which is about 40 [m] more than ORM, rwnp and the simulation. The steady state mean speed shown by PM2 is 0.55 [%] higher than that shown from ORM, rwnp and the simulation.

It is interesting to note that PM2 shows 171 [W] for steady state stroke power. So, for the PM2 a slightly lower stroke-power leads to a slightly larger distance, compared with ORM, simulation and rwnp. The drag factor shown on the PM2 equals 120, which corresponds to the value given as input to the simulation.

Up to now, the only explanation I could find for the small but significant deviations is round-off errors within the PM2. I am quite convinced that the other data sources are very accurate.

Curious to learn your point of view on this.

It would be of great interest to carry out a similar study with the PM5.

(For completeness: I assumed the flywheel inertia to be $0.1001 [kgm^2]$ and the sprocket radius equal to $1.415 [cm]$ for ORM, rwnp and simulation)

[JaapvanEkris]

The obvious next step is to compare PM2, ORM and rwnp on the basis of simulated data, with a focus on distance rowed. The major advantage of using a simulation is that we know the distance rowed from the simulation itself to a very high degree of accuracy. We know the drag factor, also for the very first stroke and drag does not exhibit stroke to stroke variation, as seen experimentally. We can also avoid placement error and measurement noise.

That is consistent with my approach as well.

I created a simulation starting from standstill ( ω = 0 [ r p m ] ). A complicating factor is that with a handle-distance based parabolic force curve ( F m a x = 600 [ N ] , stroke length$ = 1.3 [m], $ drag = 120 ⋅ 10 − 6 [ k g m 2 ] ) such a simulation does not start. (The parabola has zero value at stroke start and the flywheel remains stationary.) Therefore, I introduced a rectangular first stroke with the same energy content as the parabolic strokes ( F m a x = 400 [ N ] , P s t r o k e = 173.33 [ W ] at 20 [ S P M ] ). In real life, the first stroke usually also shows a more rectangular behavior compared with the following strokes.

That is actually surprising. I would assume that ORM would start regardless.

From the simulation I generated .csv files for ORM (6 pulses per rev), rwnp (12 pulses per rev) and a .wav file for the PM2 monitor (3 pulses per rev).

The distance-results from the simulation, ORM and rwnp are the same within one meter (after 1800 [s]: simulation: 7055.2[m], ORM: 7054.6 [m] and rwnp: 7055.3 [m]).

The PM2, however, produced a distance of 7094 [m], which is about 40 [m] more than ORM, rwnp and the simulation. The steady state mean speed shown by PM2 is 0.55 [%] higher than that shown from ORM, rwnp and the simulation.

This is extremely interestng. I see the same effect on a PM5, but I always assumed it was caused by the measurement approach used by the PM5, and its significant magnet feeding the PM5 (changing flywheel inertia and adding a magnetic drag) that was managed away somehow. Seeing this issue with the PM2 puts this in another light.

I experienced the same issue, and I am trying to optimize the settings for ORM. I had several approaches to investigate this with the PM5. I compared the distance over time for both recordings. It is a difficult approach, and never got me really satisfying results (as in: where did the difference originiate). I now use an approach where I plot each session'a difference (y axis) between ORM and the PM5 per distance (x axis). I typically use 12 to 18 sessions per analysis. This shows me several things:

• the error grows as the distance increases. The regression line clearly indicates this. So this suggests to me that the pace used by ORM is slightly behind the PM5
• I do see a significant bandwith per distance. On a 5K, i see errors between 0.3 and 0.7 seconds (bandwith 0.4 seconds), on a 10K, this increased to 0.9 to 1.7 seconds (bandwith 0.8 seconds). On a 21K, the bandwith increases to 1.4 seconds. So variations are quite large, and I'm not sure if ORM is the one varying.

It is interesting to note that PM2 shows 171 [W] for steady state stroke power. So, for the PM2 a slightly lower stroke-power leads to a slightly larger distance, compared with ORM, simulation and rwnp. The drag factor shown on the PM2 equals 120, which corresponds to the value given as input to the simulation.

It is weird indeed. So, lower power, but more pace? Makes me wonder if they actually obey the power = 2.8 * linear velocity?

Up to now, the only explanation I could find for the small but significant deviations is round-off errors within the PM2. I am quite convinced that the other data sources are very accurate.

A key thing to consider is that potentially ORM, rwnp and the generator contain the same phyics model, and that assumtions might be wrong here. But rounding has crossed my mind as well.

[klamp169]

That is actually surprising. I would assume that ORM would start regardless.

ORM starts just fine. It is the simulation itself that does not start. It is due to a simulation artefact that I circumvented with the rectangular first stroke.

• the error grows as the distance increases. The regression line clearly indicates this. So this suggests to me that the pace used by ORM is slightly behind the PM5

In agreement with my findings: This corresponds to my comment on steady state mean speed (defined as total accumulated distance divided by total accumulated time).

• I do see a significant bandwith per distance. On a 5K, i see errors between 0.3 and 0.7 seconds (bandwith 0.4 seconds), on a 10K, this increased to 0.9 to 1.7 seconds (bandwith 0.8 seconds). On a 21K, the bandwith increases to 1.4 seconds. So variations are quite large, and I'm not sure if ORM is the one varying.

40 meters corresponds to roughly 10 seconds, which is quite large compared with the differences that define winning or losing a race. On a half marathon it would accumulate to roughly 30 seconds! Way larger than the bandwidth you mention.

It is weird indeed. So, lower power, but more pace? Makes me wonder if they actually obey the power = 2.8 * linear velocity?

I think they do obey this law (although you seem to have missed the cube on linear velocity), but lose some accuracy along the way. I could try to "repair" the problem (171 vs 173 [W]) by lowering inertia in rwnp by a factor of 0.985, but this leads also to a lowering of the estimated drag factor to 118.2e-6 [kgm^2]. So this simply shifts the problem.

rwnp can also calculate stroke power based on the stroke-average speed value: 169 [W]. This corresponds well with the ORM value (169 [W]), but is too low to correspond with PM2 [171[W]).

A key thing to consider is that potentially ORM, rwnp and the generator contain the same phyics model, and that assumtions might be wrong here. But rounding has crossed my mind as well.

...Physics model wrong...: Agree, but highly unlikely, IMHO. (I think of rounding and integer arithmatic in the first micro-controller, consequences of which had to be carried over to later PM-models for consistency. But I am not knowledgeable enough on these aspects to make a firm statement.)

[JaapvanEkris]

• I do see a significant bandwith per distance. On a 5K, i see errors between 0.3 and 0.7 seconds (bandwith 0.4 seconds), on a 10K, this increased to 0.9 to 1.7 seconds (bandwith 0.8 seconds). On a 21K, the bandwith increases to 1.4 seconds. So variations are quite large, and I'm not sure if ORM is the one varying.

40 meters corresponds to roughly 10 seconds, which is quite large compared with the differences that define winning or losing a race. On a half marathon it would accumulate to roughly 30 seconds! Way larger than the bandwidth you mention.

On a vanilla configuration, the deviation could be this big. I'm in a process of slowly increasing the flywheel inertia to get to similar steady state mean speed. I now use a flywheel inertia of 0.10157 to get this close. The thing is that the dragfactor scales linearly with the flywheel inertia, and that essentially $\overline{u}$ = $({k \over C})^{1/3}$ * $\overline{\omega}$ dampens that effect considerably as you take the cube root out of it.

The reason why I mention the bandwidth is that given steady state rowing for a 10K (or any other distance), I see that the difference between a PM5 and ORM actually varies across different sessions. It might be to handling uneven rowing differently and I am not as steady as I'd hope, but it might be interesting to see how the models react to a faster and or slower steady stroke. It would be quite telling if the difference between the PM2 and the models would vary based on steady state mean speed.

It is weird indeed. So, lower power, but more pace? Makes me wonder if they actually obey the power = 2.8 * linear velocity?

I think they do obey this law (although you seem to have missed the cube on linear velocity), but lose some accuracy along the way. I could try to "repair" the problem (171 vs 173 [W]) by lowering inertia in rwnp by a factor of 0.985, but this leads also to a lowering of the estimated drag factor to 118.2e-6 [kgm^2]. So this simply shifts the problem.

Yeah, but your steady state mean speed tells you to increase the flywheel inertia to get the same result in terms of distance. That is the weird thing here.

That is what I've been doing for the last years. I moved from an inertia of 0,1001 to 0,10157 to get the distance identical across the two monitors, given the same signal.

rwnp can also calculate stroke power based on the stroke-average speed value: 169 [W]. This corresponds well with the ORM value (169 [W]), but is too low to correspond with PM2 [171[W]).

But if you increase the flywheel inertia to match steady state mean speed, they might line up.

A key thing to consider is that potentially ORM, rwnp and the generator contain the same phyics model, and that assumtions might be wrong here. But rounding has crossed my mind as well.

...Physics model wrong...: Agree, but highly unlikely, IMHO. (I think of rounding and integer arithmatic in the first micro-controller, consequences of which had to be carried over to later PM-models for consistency. But I am not knowledgeable enough on these aspects to make a firm statement.)

One thing is the parameterization. One major difference is that the division between drive and recovery is different on a C2. I SUSPECT they use 'flywheel decelerating' as definition of the recovery. ORM uses a more nuanced approach where the recovery is defined as having a deceleration consistent with the dragforce. This has some knock-on effects:

1. The drive is shorter, so it might offset an approach that depends on 'volume under the curve'
2. The recovery contains a trace of the drive at the start (the start of the drive is violent enough to not get included in this), artificially flattening the recovery slope. This makes this calculation vulnerable (unless artificially trimmed afterwards)

I agree rounding or measurement imprecision is a likely potential cause here. Perhaps truncating the currentDt's to a certain precision might have an effect.

To be honest, thinking back to our early days, ORM performed better with respect to the PM5. That was when we used the on/off library, which was much less precise. Might be that we weren't paying as much attention to accuracy as we are now (noise reduction and stroke detection was a huge challenge back then, so that was more of a focus), but it could also be that we had less isses due to a more matching accuracy.

[klamp169]

Overview of a series of simulations I just did. Stroke efficiency simply depends on the shape of the stroke. It is the surface area of the "unit shape" fitting in a 1 unit by 1 unit rectangle. Remarkably, the error in the distance is quite constant, but the error in power even changes sign!

[klamp169]

One thing is the parameterization. One major difference is that the division between drive and recovery is different on a C2. I SUSPECT they use 'flywheel decelerating' as definition of the recovery.

I tend to agree with this. It is supported by this Concept2 link, treating "drive length".

ORM uses a more nuanced approach where the recovery is defined as having a deceleration consistent with the dragforce. This has some knock-on effects:

1. The drive is shorter, so it might offset an approach that depends on 'volume under the curve'

Agree. This can be remedied to large extent by taking the 'volume' from stroke start to stroke end instead of from drive start to drive end.

2. The recovery contains a trace of the drive at the start (the start of the drive is violent enough to not get included in this), artificially flattening the recovery slope. This makes this calculation vulnerable (unless artificially trimmed afterwards)

Also agree. But I see the PM2 drag factor to always match with rwnp (and ORM) drag factor, except for the first few strokes..

[klamp169]

After some absence, I try to wrap up this discussion on "distance":

The following graph sums up my findings. more or less. The data represents the measured distance minus the distance inferred directly from the simulation (distance is counting pulses and multiplying with a constant (if drag factor is constant)). The line labeled Simulation is obviously exactly zero for all time values. The PM2 curve shows the linear deviation up to 35 [m] (~0.5%) at 1800 [s]. I attribute the "noise" on the data to "interference" between the update frequency of the LCD screen of the PM2 and my optical detection method (OCR on video frames every second). PM2 shows a drag factor of 220-221, 20 SPM and 167-168 [W] (should be 173 [W]) throughout.
The ORM data also shows a small but significant deviation in slope, which may be attributed to a slight under-estimation of the drag factor.
Initial offsets can be attributed to discarding the first few pulses. ORM uses maximumTimeBetweenImpulses for that purpose.

My conclusion: PM2 shows small but signicant deviations in both power and distance measurement values. The origin of these deviations remains largely unclear. These deviations hinder the development of other PM's (like ORM and rwnp), since they have to replicate this behaviour if they want to stay close the PM2 (and PM5?) data.

(Inertia: $0.1001 [kgm^2]$, drag factor: 220, 20 SPM, parabolic, 600 [N] max, 1.3 [m] drive length. Drag factor 120 leads to close to identical results)

[klamp169]

Don't know about sloppy. In theory they could all correct for this.

In theory yes, but it would make the evaluation software more complex and "muddy".

Current understanding is that everything besides the flywheel it is not measured, at all. Sprockets, chain, bungee, nothing. Also the biggest additional energy expenditure (30 to 50 watt) of moving up and down the slide also isn't measured.

There actually is some valid idea behind it. I had quite some good discussions with manufacturers and data consumers in the industry about this. With only measuring the flywheel you have an extremely well defined measurement scope. It is the result of the work done (i.e the effect you are capable of inducing of the flywheel). If you start including random bits that do spend energy but are not part of the usefull result, you end up muddying the waters as you start to measure part of the effort put in, but lose track of the well defined portion that is usefull. As a real boat also has similar unaccounted losses (although behaving totally different), it generally is considered a decent approach in the industry. C2 does guesstimate this effort as part the KCal count, but that is it. RP3 does account for the chain, but not for the rest, which always feels off. I think it is better to have a well defined measurement than a badly defined one that includes random bits and pieces.

Fully agree with this reasoning! Important reason I do not like the inertia as fitting parameter. (Apologees for sounding like the wise guy.) I like the C2 rower for its clean evaluation algorithm. brake torque follows $\omega^2$ law perfectly over a wide speed range (except at very low speed).

[JaapvanEkris]

Important reason I do not like the inertia as fitting parameter. (Apologees for sounding like the wise guy.)

No need for appologies on this, as you are correct in general and it is a very valid point you are making. Key issue is, as with most rowing machines, we are clueless what the true inertia of a flywheel is to begin with. Even for the RowErg, it is unknown. So is inertia then a fitting parameter, or are we experimentally determening the true inertia of the flywheel?

[klamp169]

IMHO, this is a misconception. We are not looking for the true, physical inertia, but the value that is incorporated in the PM software. (Again, please correct me if you think otherwise,) Up to now I/we cannot find a value that is 100% consistent with both drag factor and distance rowed, using the simple model for flywheel dynamics. So either the model is wrong/incomplete, or the PMx evaluation software has shortcomings (corroborated by stroke power measurement, which is even more off). By using a simulation (with very accurate value for "physical" inertia!) I was able to remove the uncertainty on the physical inertia value from the analysis.

BTW, I expect a sigma of something like 1-1.5% for the physical inertia in the field. Contrary to weight, accurate inertia measurent (better than 0.5%) is quite hard. I remember the exercise I did together with Abasz. I am curious to know how C2 (and RP3) accomplishes that.

[JaapvanEkris]

IMHO, this is a misconception. We are not looking for the true, physical inertia, but the value that is incorporated in the PM software. (Again, please correct me if you think otherwise,)

Agreed, as that is the only approach one can take. But even then it becomes fairly complex.

Let me explain my setup:

• I have around a 1000 raw recordings with the pigpio library in place, along with their outcome (time to complete a distance) on a PM5. Session lengths, dragfactors, all vary. There are some collections (DF125, DF135 and DF145 with a lot of sessions, but DF100 and DF180 are also included), and some standard distances (5K, 10K, 21K)
• I also have a lightly modified version of ORM (added a simulator on top of the sessionmanager to replay the raw files and record the results, modified flywheel.js and up a bit to offer a bit more telemetry like GoF). It can also modify the injected configuration, allowing large simulations to run essentially scanning an area for the best results.
  This is used for validating the engine itself. The 1000 simulations take about 24 hours to complete. It allows to see what happens if I modify the engine or configuration.

Having that, from a pure statistics perspective, it becomes a two parameter (maximumTimeBetweenImpulses for start time and inertia for elocity) solver with over a 1000 instances. There are some issues with this approach:

• a key issue is that when a session "shifts" due to a different start time (waiting for the first recovery, as we once discussed), a C2 can skip a slow start and gain a fast finish for the same defined 30 minute window. Depending on the agressiveness of the start, this has different effects on the time/distance discrepancy
• we retrospectively apply the recalculated dragfactor onto the recovery statistics. In my opinion it would be inaccurate not to, as we know with a very high certainty that the df was during that period. However, C2 might have made another decission given the limited CPU time they had
• several parameters (df smoothing) and approaches (clipping the recovery to the middle second) influence the dragfactor calculation while its results are "unpredictable" at best. I strongly suspect C2 uses DF smoothing of 1, as on higher DF's, there is a lot of stroke to stroke inconsistency in DF. But that would require detailed logging from a PM5 to confirm.

Up to now I/we cannot find a value that is 100% consistent with both drag factor and distance rowed, using the simple model for flywheel dynamics. So either the model is wrong/incomplete, or the PMx evaluation software has shortcomings (corroborated by stroke power measurement, which is even more off). By using a simulation (with very accurate value for "physical" inertia!) I was able to remove the uncertainty on the physical inertia value from the analysis.

I can't either. But I have decided that DF as a number has some value, but it is close enough to be usefull. Matching the distance (for a variety of DF's) is more crucial.

I am considering refining my approach. With 0.9.8 will come a database that essentially records all data on a stroke level. It would be almost trivial to hook it up to the simulator and record all data from a 1000 session simulation. Importing the same data from the C2 logbook (csv's) is a lot of work initially (downloading and mapping them to the right session), but allows for a direct comparison. Not just on outcome, but on progress in the session itself. Comparing the slope of distance over time between over a 1000 matching sessions could remove the uncertainty around delayed starts or weird progress. This is not a trivial comparison, as there are alignment issues and PM5 sometimes induced ghost strokes. But seeing where they match or are completely different is extremely interesting.

[klamp169]

Let me explain my setup:

• I have around a 1000 raw recordings with the pigpio library in place, along with their outcome (time to complete a distance) on a PM5. Session lengths, dragfactors, all vary. There are some collections (DF125, DF135 and DF145 with a lot of sessions, but DF100 and DF180 are also included), and some standard distances (5K, 10K, 21K)

Also physical inertia will vary, I think, from one rower to the other. I expect with sigma = 1-1.5 %.

• I also have a lightly modified version of ORM (added a simulator on top of the sessionmanager to replay the raw files and record the results, modified flywheel.js and up a bit to offer a bit more telemetry like GoF). It can also modify the injected configuration, allowing large simulations to run essentially scanning an area for the best results.
  This is used for validating the engine itself. The 1000 simulations take about 24 hours to complete. It allows to see what happens if I modify the engine or configuration.

Solid but slow iteration cycle!

Having that, from a pure statistics perspective, it becomes a two parameter (maximumTimeBetweenImpulses for start time and inertia for elocity) solver with over a 1000 instances. There are some issues with this approach:

• a key issue is that when a session "shifts" due to a different start time (waiting for the first recovery, as we once discussed), a C2 can skip a slow start and gain a fast finish for the same defined 30 minute window. Depending on the agressiveness of the start, this has different effects on the time/distance discrepancy

PM2 discards at least 1 second when feeding it with a simulated row. This corresponds roughly to 3 [m] rowing distance. The C2 detection technique (induction voltage in coil) is "flawed", since signal amplitude depends on flywheel speed. Losing pulses is therefore inevitable. The optical technique is more robust in that respect: every analog pulse has the same amplitude, before digitization (by comparator).

• we retrospectively apply the recalculated dragfactor onto the recovery statistics. In my opinion it would be inaccurate not to, as we know with a very high certainty that the df was during that period. However, C2 might have made another decission given the limited CPU time they had

I think you mean here that you use the drag factor determined during the very first recovery to calculate the distance rowed during the first drive (and recovery). C2/PM2 is not doing that, since it starts showing meters on the PM2 before the first drive finishes. (But perhaps I misunderstand your statement)

• several parameters (df smoothing) and approaches (clipping the recovery to the middle second) influence the dragfactor calculation while its results are "unpredictable" at best. I strongly suspect C2 uses DF smoothing of 1, as on higher DF's, there is a lot of stroke to stroke inconsistency in DF. But that would require detailed logging from a PM5 to confirm.

I think this inconsistency may be caused by flywheel vibrations during recovery. (The flywheel bearing suspension with rubber ring puzzles me somewhat. It may well lead to resonance-like behaviour (with low Q) and thereby to flywheel vibrations, often reported on the C2 forum)

Up to now I/we cannot find a value that is 100% consistent with both drag factor and distance rowed, using the simple model for flywheel dynamics. So either the model is wrong/incomplete, or the PMx evaluation software has shortcomings (corroborated by stroke power measurement, which is even more off). By using a simulation (with very accurate value for "physical" inertia!) I was able to remove the uncertainty on the physical inertia value from the analysis.

I can't either. But I have decided that DF as a number has some value, but it is close enough to be usefull. Matching the distance (for a variety of DF's) is more crucial.

I understand your priority. Still, I think this is somewhat "unsatisfactory".

I am considering refining my approach. With 0.9.8 will come a database that essentially records all data on a stroke level. It would be almost trivial to hook it up to the simulator and record all data from a 1000 session simulation. Importing the same data from the C2 logbook (csv's) is a lot of work initially (downloading and mapping them to the right session), but allows for a direct comparison. Not just on outcome, but on progress in the session itself. Comparing the slope of distance over time between over a 1000 matching sessions could remove the uncertainty around delayed starts or weird progress. This is not a trivial comparison, as there are alignment issues and PM5 sometimes induced ghost strokes. But seeing where they match or are completely different is extremely interesting.

I have never consciously witnessed ghost strokes on PM2.

Thanks for your description of your setup. I was not fully aware of the extent of your statistical analysis. I would immediately drown in the overwhelming amount of data of varying quality. For this to work, good bookkeeping is as important as it is tedious! Good luck with that.

[klamp169]

So, what if the simple model is incomplete? I have been playing around with an additional constant loss term: $j\dot\omega=-k\omega^2-T_b$ (as I have done before). The additional term $T_b$ is always present (otherwise the flywheel would never come to a full stop).
For my model C, $T_b=0.004 [Nm]$ and can be found easily by plotting $\dot\omega$ versus $\omega^2$. This constant drag torque corresponds with a flywheel stop time of about 200 [s]. But I learned from the concept2 forum that shorter stop times can be found, even as low as 15 [s] (all on concept2 rowers). One to 2 minutes seem to be quite common.
First simulations show that by introducing $T_b$ and increasing the physical inertia somewhat, the rowed distance goes down slightly and the drag factor can be seen on the PM2 to correspond with the drag factor given in the simulation. I still have to do some tweaking to get "optimal" results.

Although I do not like this approach very much, I am curious about your opinion on this.

I think that the variation in values for $T_b$ in the field may also have an impact on your statistical approach.

[klamp169]

Thanks! I hope you had a great holiday.

This graph shows $\dot\omega$ versus $\omega ^ 2$, zoomed in at the values representing low flywheel speed (< 400 [rpm]). I did not remove the bouncy issues. The slope gives k = 137.6 and the intersection with the y-axes gives $T_b = 0.004 [Nm]$, which is the same as my model C shows. The dashed red line represents the linear fit I made to all data, upto 1100 [rpm]. This data is indistinguishable from the model C data and therefore does not show any influence of the generator.

Other observations: The data shows quite a bit of random noise. I had to increase the savgol_filter window_length to 12 (twice N_encoder) to get stroke detection right.
Fascinatingly, the noise seems to almost disappear right before the last stroke (t=679.6[s]) and is also largely absent during the "tail". See bottom graph in figure below. Any idea what causes this behaviour?

[JaapvanEkris]

Thanks! I hope you had a great holiday.

Yeah, it was great. No ergs in sight (my wife made sure of that), but quite enjoyable in the mountains.

This graph shows ω ˙ versus ω 2 , zoomed in at the values representing low flywheel speed (< 400 [rpm]). I did not remove the bouncy issues. The slope gives k = 137.6 and the intersection with the y-axes gives T b = 0.004 [ N m ] , which is the same as my model C shows. The dashed red line represents the linear fit I made to all data, upto 1100 [rpm]. This data is indistinguishable from the model C data and therefore does not show any influence of the generator.

It is all mechanical friction then.

Other observations: The data shows quite a bit of random noise. I had to increase the savgol_filter window_length to 12 (twice N_encoder) to get stroke detection right.

This is identical to our normal setting of the windows size we use for our internal Savitzky-Golay filter to get things working for the RowErg. Even with the Kalman filter in front of it (which removes the systematic noise in the signal) somehow the RowErg seems to "need" this length regardless of pre-filtering.

Fascinatingly, the noise seems to almost disappear right before the last stroke (t=679.6[s]) and is also largely absent during the "tail". See bottom graph in figure below. Any idea what causes this behaviour?

According to the PM5, the 2.5K session lasted 11 minutes and 18.7 seconds. ORM clocked it out at 11:19.0. I typically make a final stroke after the finish to make sure that if I need to do a rerun of raw data with different settings (engine callibration) I don't run out of strokes too fast.

As it stops mid-recovery (!), i am inclined to think it isn't caused by the handle or any mechanical stuf. There are two likely candidates here:

• The PM5 causes this noise on the electrical signal and it just has stopped recording?
• ORM's calculations frustrate the detection of the datapoints (fighting for CPU time) and this is how it shows. If the finish is reached, a major part of the engine's calculations actually stop. If I'm not mistaken, the noise is only present during the recovery, and not in the drive. In the recovery, the second Theil-Senn regressor becomes active. Upon a session stop, that part of the engine gets stopped by Flywheel.js. The noisy tail just before 679.6 seconds would be the calculation of all totals for the session (including VO2Max calculation which uses regression techniques), etc..

I did another experiment: I rowed 5K without the PM5 plugged in, just ORM.
C2_RowErg_2026-08-11_1803_Rowing_5K_Drag_136_raw.zip
GoF jumped from 0.9996 to 1.0000 So it might indicate we lost some noise there. Extremely interested in what you think.

[klamp169]

This data has much less noise! Even a bit better than my Model C, which shows vibrations during recovery. Probably your flywheel has better balance. I could reduce the window_length to 6. Possibly, you can do the same. See figure below.

It should smoothen your force curves considerably.

The PM5 causes this noise on the electrical signal and it just has stopped recording?

IMHO: unlikely.

ORM's calculations frustrate the detection of the datapoints (fighting for CPU time) and this is how it shows. If the finish is reached, a major part of the engine's calculations actually stop. If I'm not mistaken, the noise is only present during the recovery, and not in the drive.

No, also during drive (See previous to last figure).

In the recovery, the second Theil-Senn regressor becomes active. Upon a session stop, that part of the engine gets stopped by Flywheel.js. The noisy tail just before 679.6 seconds would be the calculation of all totals for the session (including VO2Max calculation which uses regression techniques), etc..

So, you finish-up as soon as the distance target (2500 [m] or 5000 [m]) has been reached?

[klamp169]

I skipped the savgol filter altogether and rwnp ran just fine on your 5k data. I also found that magnet placement error is low: 0.66 [deg] max.

[JaapvanEkris]

The PM5 causes this noise on the electrical signal and it just has stopped recording?

IMHO: unlikely.

It isn't as unlikely as you think. The PM5 is in the circuit, parallel to the optocoupler. This itself already reduces the amplitude of the sinewave that passes. As the optocoupler's internal LED is triggered at a certain passing voltage (roughly 12V if i'm not mistaken), a reduction of amplitude can cause a shift in the positioning of that crossing. Deactivating that circuit could remove the parallel draw, and thus the disturbance.

ORM's calculations frustrate the detection of the datapoints (fighting for CPU time) and this is how it shows. If the finish is reached, a major part of the engine's calculations actually stop. If I'm not mistaken, the noise is only present during the recovery, and not in the drive.

No, also during drive (See previous to last figure).

Thanks, good catch.

So, you finish-up as soon as the distance target (2500 [m] or 5000 [m]) has been reached?

Yeah, that is the only way to be able to structurally compare time over a set distance between a PM5 and ORM.

[klamp169]

Steady state mean speed for PM2, ORM and rwnp

mean_speed.xlsx

The attached table gives an overview of the results I obtained with various simulation runs. (No placement error, no noise.) The purpose of these runs (1920 [s] duration) was to check the consistency of the various PM's with respect to distance rowed. I created a first order polyfit for steady state (therefore discarding the first 10 seconds) distance versus time. The resulting slope is the steady state speed of the "boat" and is shown in columns J thru L.

I varied the drag factor, Strokes per minute, Max Force, drive length, Drive Shape and friction torque Tb as can be seen in columns B thru G.

Main conclusion: PM2 consistently estimates the steady state speed about ~0.5 % higher than ORM (column M) and rwnp (column N). Only for the low force (200 [N]) test (sim# 34) this discrepancy is lower.

ORM estimates the steady state speed ~0.025 % lower than rwnp (column O), with remarkable consistency, except sim# 27.

The consistency (0.5 %) of the deviation of the PM2 steady state speed does not support the hypothesis that it may be caused by processor limitations / rounding errors. On the other hand: it does allow for a "correction factor" so as to match the distance reading of ORM and rwnp to the PM2.

Other observation: ORM estimates the drag factor slightly too low (example: DF 220 in the simulation (sim# 27) is estimated as 219.7 for every stroke by ORM).

I know, it's next level nitpicking. Yet, it may help to get ORM (and rwnp) even closer to the "C2 standard".

Cheerio!