Tuning/calibrating ORM to a concept 2 model C/PM2

[norseghost]

After a few hassles (proper sensor placement, changing WiFi channel for the 2.4 GHz band, pulling the flywheel off at least twice to get into the guts) I’ve got ORM set up on my Model C rowerg. I think it might be slightly ahead of the PM2 though… how reliable is the meters rowed etc?

If/once confirmed that it is indeed ahead, how/what do I tune?

[JaapvanEkris]

After a few hassles (proper sensor placement, changing WiFi channel for the 2.4 GHz band, pulling the flywheel off at least twice to get into the guts) I’ve got ORM set up on my Model C rowerg. I think it might be slightly ahead of the PM2 though… how reliable is the meters rowed etc?

ORM is quite reliable. I've been testing it against a PM5 for over 5000K now, about 500 sessions, and it has shown to be reliable. We are hitting the point where I'm optimising the configuration for the RowErg (which has 6 magnets instead of the Model C's 3), and I'm trying to get from 0.3% deviation to 0.1% deviation. We are getting there, but it is a lot of small tweaks to make it happen.

In calibrating against a PM5 on a RowErg, I normally get within the 1 second accuracy (on a 21K, so that isn't much of a difference). HOWEVER, that is on a slightly different setup on an experimental branch (which is the "regression_completeness" branch) and I'm stil homing in on the settings involved.

If/once confirmed that it is indeed ahead, how/what do I tune?

It is quite a complex process, as it isn't just the tiny pace difference you're dealing with, it is also startup and closedown behaviour of both the monitors. In server.js, you'll find an object "intervalSettings", which ORM obeys. By setting a fixed time or distance on both ORM and the PM, I can exclude the messy ending of a session, as it will terminate the session abruptly as it crosses the finishline.

On any given setting, I do several different distances (in my case, 5K, 10K and 21K). Based on that, I can see how much time is deviating per distance. The trendline will tell you two things: the way the error becomes bigger/smaller over increasing distance (i.e. pace errors), and the offset (i.e. startup deviation).

Typically, a pace error you'll resolve with changing the flywheelInertia. When the time deviation is identical across all distances, the pace is good, but the startup behaviour causes the deviation. If ORM is too fast on longer distances, you need to reduce the flywheelinertia. Information from credible sources indicate that the true inertia is 0.1001 (it can be measured independently), where we currently use 0.10148, but in my experimental setup I'm moving to 0.1013. So there is some movement in that area.

Startup behaviour is governed by two parameters: maximumTimeBetweenImpulses which determines when the flywheel is really spinning, and dragFactor, which determines what dragfactor is used for the first stroke (as no dragfactor is experimentally determined yet). There are some indications that the current 0.0145 for maximumTimeBetweenImpulses is pretty decent, but dragfactor 110 might be too restricted (in experimental settings I often use 220). As I'm aiming to remove pace out of the equation first, I'm still puzzled by these two.

Please look to laberning#157 and laberning#151 as well, as several people made stome steps to some settings as well.

[norseghost]

Thanks! I’m off to do a test session so I can compare the measurements in a more specific exercise setting rather than just 5-20 strokes to confirm I’m getting data.

During one such test I noticed that ORM counted a couple strokes after I had put the handle down.

Is this related to the tail of data mess you describe? (doesn’t really matter if a 1400 stroke session has 2-4 phantom strokes I guess)

[norseghost]

Did 1400 meter trial run, and distance data was pretty consistent. If anything, the ORM lagged ever so slightly/counted slightly fewer meters - but then took longer to stop counting when I put the handle down, and ended up pretty much in the same spot. Otherwise, impressively consistent with the PM2 for strokes/min and so on.

Is there anything to be done about the ~5 phantom strokes at the end? Not a huge deal if I row 2K+ consistently, but could skew data quite a bit for say 500m intervals.

current rower settings:

  // Concept2, Model B and C
    Concept2_Model_B_and_C: {
    numOfImpulsesPerRevolution: 3,
    sprocketRadius: 1.4,
    maximumStrokeTimeBeforePause: 6.0,
    dragFactor: 110,
    autoAdjustDragFactor: true,
    minimumDragQuality: 0.95,
    dragFactorSmoothing: 3,
    minimumTimeBetweenImpulses: 0.010,
    maximumTimeBetweenImpulses: 0.040,
    flankLength: 6,
    smoothing: 1,
    minimumStrokeQuality: 0.36,
    minumumForceBeforeStroke: 11,
    minumumRecoverySlope: 0.00070,
    autoAdjustRecoverySlope: true,
    autoAdjustRecoverySlopeMargin: 0.01,
    minimumDriveTime: 0.40,
    minimumRecoveryTime: 0.90,
    flywheelInertia: 0.10148,
    magicConstant: 2.8
  },

Also, I get a LOT of these entries in the logs as session ends(?) maybe:

*** WARNING: currentDt of 0.14016099999992093 sec is above maximumTimeBetweenImpulses (0.04 sec)

Is this expected?

Thank you for all your help holding my hand here!

[JaapvanEkris]

Did 1400 meter trial run, and distance data was pretty consistent. If anything, the ORM lagged ever so slightly/counted slightly fewer meters - but then took longer to stop counting when I put the handle down, and ended up pretty much in the same spot. Otherwise, impressively consistent with the PM2 for strokes/min and so on.

Is there anything to be done about the ~5 phantom strokes at the end? Not a huge deal if I row 2K+ consistently, but could skew data quite a bit for say 500m intervals.

It shouldn't do that. In essence, it should land in 'waitingfordrive' statepretty quickly, and as the trend is decelerating, it should stay there. A bit puzzled about that one to be honest. You might have a look at https://github.com/JaapvanEkris/openrowingmonitor/blob/main/docs/rower_settings.md#critical-parameters-you-must-change-or-review-for-stroke-detection

Also, I get a LOT of these entries in the logs as session ends(?) maybe:

*** WARNING: currentDt of 0.14016099999992093 sec is above maximumTimeBetweenImpulses (0.04 sec)

Is this expected?

It is expected, a Concept2 can spin up to two minutes unpowered. In essence, we wait for at least 6 seconds (i.e. maximumStrokeTimeBeforePause) after the last drive and the maximumTimeBetweenImpulses should be structurally exceeded.

Thank you for all your help holding my hand here!

Absolutely no problem!

[norseghost]

So. Taking a look at the data/logs, there are clear anomalies when I set down the the handle where the data clearly reflect phantom strokes (rowingdata.csv excerpted lines at the bottom, full file linked)

In particular, I am noticing the ludicrously high SPM hike, which go from a reasonably consistent 29-32 to 35-38 as I lay my erg handle down. This would be consistent with stroke detection having a slight hiccup.

So. What do I tune? minimumDriveTime and minimumRecoveryTime maybe? I se a lot of these kinds of entries in the logs while rowing - that is, not at all the consistent logs that the guide for tuning rower data, but pretty much every stroke i get the 'suggests no power' line.

2024-07-31.log

Jul 31 07:50:16 rowingmonitor npm[859]: Time: 360.1180 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.5966 sec) to exceed minimumRecoveryTime (0.9 sec)
Jul 31 07:50:16 rowingmonitor npm[859]: Time: 360.1569 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.6356 sec) to exceed minimumRecoveryTime (0.9 sec)
Jul 31 07:50:16 rowingmonitor npm[859]: Time: 360.1763 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.6549 sec) to exceed minimumRecoveryTime (0.9 sec)
Jul 31 07:50:16 rowingmonitor npm[859]: Time: 360.2747 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.7533 sec) to exceed minimumRecoveryTime (0.9 sec)
Jul 31 07:50:16 rowingmonitor npm[859]: Time: 360.2944 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.7731 sec) to exceed minimumRecoveryTime (0.9 sec)
Jul 31 07:50:16 rowingmonitor npm[859]: Time: 360.3541 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.8327 sec) to exceed minimumRecoveryTime (0.9 sec)
Jul 31 07:50:16 rowingmonitor npm[859]: *** DRIVE phase started at time: 360.5359 sec
Jul 31 07:50:16 rowingmonitor npm[859]: *** Calculated drag factor: 119.3162, not used because reliability was too low. no. samples: 53, fit:
[2024-07-31.log](https://github.com/user-attachments/files/16479365/2024-07-31.log)
 0.9325
Jul 31 07:50:16 rowingmonitor npm[859]: stroke: 191, dist: 1405.4m, speed: 3.77m/s, pace: 2:12/500m, power: 150W, cal: 90.4kcal, SPM: 31.5, drive dur: 0.96s, rec. dur: 0.94s, stroke dur: 1.91s
Jul 31 07:50:16 rowingmonitor npm[859]: Time: 360.6803 sec: Delta Time trend is upwards, suggests no power, but waiting for drive phase length (0.1444 sec) to exceed minimumDriveTime (0.4 sec)
Jul 31 07:50:16 rowingmonitor npm[859]: Time: 360.7428 sec: Delta Time trend is upwards, suggests no power, but waiting for drive phase length (0.2069 sec) to exceed minimumDriveTime (0.4 sec)
Jul 31 07:50:17 rowingmonitor npm[859]: Time: 360.8060 sec: Delta Time trend is upwards, suggests no power, but waiting for drive phase length (0.2701 sec) to exceed minimumDriveTime (0.4 sec)
Jul 31 07:50:17 rowingmonitor npm[859]: Time: 360.8694 sec: Delta Time trend is upwards, suggests no power, but waiting for drive phase length (0.3335 sec) to exceed minimumDriveTime (0.4 sec)
Jul 31 07:50:17 rowingmonitor npm[859]: *** RECOVERY phase started at time: 361.7411 sec
Jul 31 07:50:18 rowingmonitor npm[859]: Time: 362.1260 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.3849 sec) to exceed minimumRecoveryTime (0.9 sec)
Jul 31 07:50:18 rowingmonitor npm[859]: Time: 362.1854 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.4444 sec) to exceed minimumRecoveryTime (0.9 sec)
Jul 31 07:50:18 rowingmonitor npm[859]: Time: 362.2453 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.5042 sec) to exceed minimumRecoveryTime (0.9 sec)
Jul 31 07:50:18 rowingmonitor npm[859]: Time: 362.2856 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.5445 sec) to exceed minimumRecoveryTime (0.9 sec)
Jul 31 07:50:18 rowingmonitor npm[859]: Time: 362.3056 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.5645 sec) to exceed minimumRecoveryTime (0.9 sec)
Jul 31 07:50:18 rowingmonitor npm[859]: Time: 362.3463 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.6053 sec) to exceed minimumRecoveryTime (0.9 sec)
Jul 31 07:50:19 rowingmonitor npm[859]: *** DRIVE phase started at time: 362.7831 sec
Jul 31 07:50:19 rowingmonitor npm[859]: *** Calculated drag factor: 118.8318, not used because reliability was too low. no. samples: 52, fit: 0.9493
Jul 31 07:50:19 rowingmonitor npm[859]: stroke: 192, dist: 1413.6m, speed: 3.74m/s, pace: 2:13/500m, power: 146W, cal: 90.8kcal, SPM: 28.7, drive dur: 1.03s, rec. dur: 0.98s, stroke dur: 2.09s
Jul 31 07:50:19 rowingmonitor npm[859]: *** RECOVERY phase started at time: 363.6173 sec
Jul 31 07:50:19 rowingmonitor npm[859]: Time: 363.6905 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.0731 sec) to exceed minimumRecoveryTime (0.9 sec)
Jul 31 07:50:20 rowingmonitor npm[859]: Time: 363.9909 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.3736 sec) to exceed minimumRecoveryTime (0.9 sec)
Jul 31 07:50:20 rowingmonitor npm[859]: Time: 364.0488 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.4314 sec) to exceed minimumRecoveryTime (0.9 sec)
Jul 31 07:50:20 rowingmonitor npm[859]: Time: 364.1068 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.4895 sec) to exceed minimumRecoveryTime (0.9 sec)
Jul 31 07:50:20 rowingmonitor npm[859]: Time: 364.1653 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.5480 sec) to exceed minimumRecoveryTime (0.9 sec)
Jul 31 07:50:20 rowingmonitor npm[859]: Time: 364.2837 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.6663 sec) to exceed minimumRecoveryTime (0.9 sec)
Jul 31 07:50:20 rowingmonitor npm[859]: Time: 364.3435 sec: Delta Time trend is downwards, suggesting power, but waiting for recovery phase length (0.7262 sec) to exceed minimumRecoveryTime (0.9 sec)

rowingData.csv:

,index, Stroke Number, lapIdx,TimeStamp (sec), ElapsedTime (sec), HRCur (bpm),DistanceMeters, Cadence (stokes/min), Stroke500mPace (sec/500m), Power (watts), StrokeDistance (meters), DriveTime (ms), DriveLength (meters), StrokeRecoveryTime (ms),Speed, Horizontal (meters), Calories (kCal), DragFactor, PeakDriveForce (N), AverageDriveForce (N),Handle_Force_(N),Handle_Velocity_(m/s),Handle_Power_(W)
80,80,80,0,1722404670.81400,146.84152,NaN,593.4,38.3,107.76,280,7.22,547,1.04,990,4.64,593.4,38.2,118.2,904.2,439.0,"13.81,45.61,84.16,134.64,220.08,324.14,430.98,555.36,666.05,767.32,824.54,831.48,855.14,832.29,833.76,815.05,768.39,759.84,743.36,712.50,661.36,598.84,584.39,569.63,503.06,486.03,431.86,373.00,319.55,259.07,215.95,137.94,93.11,48.22","1.675,1.668,1.664,1.662,1.659,1.661,1.671,1.682,1.703,1.728,1.753,1.783,1.811,1.833,1.855,1.875,1.895,1.914,1.931,1.946,1.958,1.972,1.983,1.992,2.001,2.005,2.011,2.020,2.022,2.021,2.023,2.019,2.017,2.019,2.013","76.1,140.0,223.7,365.1,538.4,720.2,934.4,1134.1,1325.9,1445.8,1482.5,1549.0,1526.0,1546.2,1527.9,1455.9,1454.5,1435.6,1386.5,1295.2,1180.9,1158.7,1134.5,1006.6,974.5,868.5,753.5,646.1,523.6,436.9,278.5,187.8,97.3"
81,81,81,0,1722404672.62300,148.65066,NaN,601.5,37.4,109.24,268,7.33,547,1.04,989,4.58,601.5,38.7,117.7,864.2,439.0,"46.48,51.01,39.73,32.51,22.10,0.00,0.00,0.00,0.98,24.35,65.64,123.54,187.41,268.34,342.92,450.65,559.06,655.44,718.9
[2024-07-31_05-42-03_rowingData.csv](https://github.com/user-attachments/files/16479302/2024-07-31_05-42-03_rowingData.csv)
3,714.20,709.18,707.71,696.79,636.88,587.75,599.46,610.38,581.17,513.95,502.32,508.07,505.11,472.69,417.38,398.10,362.06,321.36,270.15,222.10,174.05,124.77,66.67,48.72,20.54","1.738,1.733,1.730,1.730,1.725,1.719,1.715,1.707,1.701,1.698,1.691,1.685,1.685,1.683,1.686,1.694,1.702,1.715,1.737,1.761,1.785,1.804,1.815,1.827,1.844,1.858,1.873,1.885,1.892,1.901,1.913,1.920,1.928,1.939,1.945,1.950,1.955,1.956,1.958,1.964,1.962,1.960,1.955,1.948,1.943,1.942,1.936","111.0,208.2,315.7,451.6,578.2,763.6,951.5,1124.1,1248.7,1257.9,1266.2,1276.7,1264.4,1163.9,1083.8,1114.1,1143.3,1095.5,972.6,955.1,971.8,969.7,911.4,809.1,774.3,706.1,628.4,528.4,435.0,341.9,244.8,130.7,95.2"
82,82,82,0,1722404674.38100,150.40895,NaN,609.3,35.9,110.72,258,7.55,588,1.08,1053,4.52,609.3,39.3,117.9,835.1,418.6,"63.64,153.51,270.79,387.72,501.96,607.62,658.42,683.74,677.55,691.44,668.71,619.00,575.39,527.41,499.32,469.53,468.95,484.67,475.52,474.94,436.34,405.57,347.80,330.79,303.92,265.72,220.53,144.19,115.75,53.82,24.04","1.647,1.643,1.643,1.643,1.639,1.634,1.627,1.618,1.617,1.631,1.647,1.671,1.692,1.710,1.729,1.752,1.772,1.796,1.814,1.825,1.835,1.845,1.853,1.866,1.879,1.886,1.896,1.906,1.913,1.918,1.924,1.923,1.928,1.932,1.931,1.927,1.923,1.915","103.6,248.5,438.0,632.2,826.6,1015.1,1114.2,1169.0,1171.5,1211.1,1185.2,1111.6,1043.8,962.4,916.4,866.3,869.0,904.4,893.4,895.9,827.4,773.0,665.2,634.4,584.6,511.0,425.1,278.5,223.5,103.7"
83,83,83,0,1722404676.20300,152.23036,NaN,615.8,33.6,113.38,240,7.69,588,1.08,1053,4.41,615.8,39.9,117.9,767.0,387.9,"20.52,47.02,62.05,48.85,26.06,17.97,13.39,13.93,10.52,0.00,0.94,0.00,1.36,8.37,2.46,10.49,8.85,21.63,29.85,23.98,18.32,17.48,18.29,9.39,6.19,14.23,23.81,27.07,30.18,32.14,34.12,30.17,26.53,25.35,21.03,16.59,20.48,32.49,48.95,52.36,50.05,50.16,36.51","1.613,1.612,1.614,1.612,1.607,1.603,1.597,1.592,1.591,1.585,1.581,1.578,1.572,1.569,1.567,1.563,1.559,1.555,1.549,1.545,1.543,1.541,1.538,1.535,1.529,1.523,1.521,1.518,1.514,1.511,1.506,1.501,1.499,1.496,1.492,1.489,1.483,1.477,1.474,1.470,1.468,1.467,1.464,1.461","72.0,76.8,73.4,73.5,53.4"
84,84,84,0,1722404677.58300,153.61061,NaN,620.0,34.9,129.30,164,7.00,588,1.07,1017,3.87,620.0,40.3,117.9,705.2,335.4,"16.34,23.89,15.41,17.13,23.03,22.73,16.47","1.300,1.297,1.294,1.290,1.287,1.286,1.282,1.279,1.275,1.270,1.266,1.264,1.262,1.262,1.260,1.255,1.250,1.246,1.243","0.0,0.0,0.0,0.0,0.0"
85,85,85,0,1722404680.00800,156.03517,NaN,626.1,34.1,157.63,90,5.46,689,1.07,1017,3.17,626.1,40.6,117.9,376.7,176.3,"16.41,14.07,17.62,24.52,34.17,36.23,28.37,20.57,22.43,14.83","1.131,1.127,1.126,1.122,1.119,1.117,1.114,1.111,1.108,1.104,1.101,1.099,1.095,1.093,1.092,1.090,1.086,1.083,1.079,1.075,1.074,1.073,1.071,1.070,1.066,1.062,1.060,1.057","22.0,23.9,15.7,3.4,0.0"
85,85,85,0,1722404685.97200,161.99993,NaN,637.2,0.0,Infinity,0,0.00,NaN,NaN,NaN,0.00,637.2,40.6,117.9,NaN,NaN,"","",""
85,85,85,0,1722404686.02000,162.04714,NaN,637.3,0.0,Infinity,0,0.00,689,0.97,1017,0.00,637.3,40.6,117.9,49.1,20.7,"13.40,11.60,17.31,16.52,14.58,14.43","0.900,0.896,0.894,0.893,0.890","4.9,0.0,0.0,0.0,0.0"
--- snip ---
210,210,210,0,1722404920.30100,396.32874,NaN,1548.8,31.8,129.66,161,7.34,811,1.28,1153,3.86,1548.8,99.6,118.3,561.9,217.7,"27.06,34.57,51.47,51.46,41.66,24.13,7.01,2.44,0.00,0.00,0.00,14.03,31.25,22.82,33.93,35.19,23.19,16.71","1.456,1.451,1.449,1.444,1.442,1.443,1.441,1.437,1.433,1.426,1.421,1.418,1.414,1.410,1.408,1.403,1.400,1.400,1.396,1.395,1.393,1.385","32.5,23.3,0.0,0.0,0.0"
211,211,211,0,1722404921.71600,397.74366,NaN,1552.7,33.8,142.16,123,5.70,659,1.04,1062,3.52,1552.7,100.0,118.3,561.9,217.7,"1.00,0.00,0.00,0.00,0.00","1.195,1.195,1.193,1.188,1.184,1.182,1.177,1.175,1.173,1.170,1.167,1.165,1.161,1.159,1.157,1.154","1.2,0.0,0.0,0.0,0.0"
212,212,212,0,1722404923.42800,399.45574,NaN,1556.9,37.7,169.04,73,4.71,600,0.91,1062,2.96,1556.9,100.2,118.3,272.8,112.1,"9.75,19.25,19.48,10.72,10.27","1.047,1.046,1.045,1.041,1.037,1.037,1.034,1.031,1.028,1.024,1.021,1.020,1.017,1.015,1.013,1.011","9.9,19.6,19.8,10.9,10.4"
213,213,213,0,1722404924.96100,400.98880,NaN,1560.2,37.3,195.84,47,3.94,456,0.56,1061,2.55,1560.2,100.4,118.3,37.6,19.5,"0.00,0.00,0.00,0.00,7.53","0.892,0.889,0.886,0.885,0.882","0.0,0.0,0.0,0.0,6.6"
213,213,213,0,1722404930.94700,406.97454,NaN,1570.3,0.0,Infinity,0,0.00,NaN,NaN,NaN,0.00,1570.3,100.4,118.3,NaN,NaN,"","",""

2024-07-31_05-42-03_rowingData.csv

[norseghost]

here is a graph of the raw sensor data

there are two pauses in the data, and a tail between each pause - is this where ORM gets confused maybe?

kinda weird my strokes / min goes up as time between impulses increases (if this is indeed the case)

[JaapvanEkris]

It looks a lot like signal bounce: https://github.com/JaapvanEkris/openrowingmonitor/blob/main/docs/rower_settings.md#fixing-switch-bounce

Perhaps look at the signal bounce settings.

[norseghost]

Will try that.

Edit: makes a lot of sense, now I’ve read the signal bounce setting. Could also adjust the ky-24 potmeter sensitivity down?

but changing a setting or two is a lot simpler 😅

Would setting initial dragfactor closer to measured/calculated dragfactor do much of anything?

[JaapvanEkris]

Will try that.

Edit: makes a lot of sense, now I’ve read the signal bounce setting. Could also adjust the ky-24 potmeter sensitivity down?

but changing a setting or two is a lot simpler 😅

See what works best. Using the debounce filter might hurt jour signal as well.

Would setting initial dragfactor closer to measured/calculated dragfactor do much of anything?

Not really. It is a default setting you need to calculate the distance when no dragfactor is calculated yet in the first stroke. I assume C2 uses either a an average value or an extreme value, but we are still filtering through a lot of simulations to get that info out. After the first recovery a dragfactor is known, and retrospectively applied to the recovery phase, and the initial DF is ignored completely.

[norseghost]

Opened up the rower again, fiddled for a while to reposition the magnet-detector, and got (seemingly) reliable stroke detection... after changing to 'down' flank. I got one extra stroke counted, maybe? as I put down the handle. I need to test with the PM2 to verify distances etc.

The log graph also looks a lot cleaner now.

less jitter at the end.

I am noticing I am rather consistently far below the maximumTimeBetweenImpulses: 0.032, -- hovering somewhere around 0.020-0.023.

would it be advisable to adjust this value to say 0.027?

Heck it, I'll do it and try tomorrow. Need the rowing form practice anyhow (I am not at alle experienced on the rower -- which my post-settings-change-test DOMS readily attest to.)

[norseghost]

Did it, no regrets so far. No extra strokes recorded after I put down the handle at least.

The meters did keep running up a little while after handle-put-down. Is this expected? The PM2 seems more aggressive in cutting off the counting if I recall (it has finally died the E011 death, so I can’t verify).

[JaapvanEkris]

The meters did keep running up a little while after handle-put-down. Is this expected? The PM2 seems more aggressive in cutting off the counting if I recall (it has finally died the E011 death, so I can’t verify).

The PM5 does. By setting the maximumTimeBetweenImpulses and maximumStrokeTimeBeforePause you can change it.

[norseghost]

Ok, thanks. I’ve considered reducing maximustroketimebeforepause somewhat — the default seems to have ample headroom for my current pace.

[JaapvanEkris]

Ok, thanks. I’ve considered reducing maximustroketimebeforepause somewhat — the default seems to have ample headroom for my current pace.

A practical tip: ORM will force a stop if maximumTimeBetweenImpulses is exceeded, it hasn't see a 'drive' for maximustroketimebeforepause seconds and the flywheel seems to have no power on it. A missed drive in a slow row can do this sometimes. The 6 seconds is chosen to let such a fault occur but be mitigated.

[MaDe78]

Hi I would like to jump into the discussion...
I have a Model C with PM2, unfortunately the PM2 no longer works. @norseghost: How did you connect ORM to your Model C? Did you use this board: https://oshwlab.com/jpbpcb/rower2 . Or is there another solution?
Many thanks for your feedback.
MaDe