Johnson JAR5100 profile for 0.9.7

[eglin73]

Hi,

I have just installed 0.9.7 fresh, having been using 0.9.6 for some time. 0.9.6 was working well fore me from a data metrics perspective, and 0.9.7 seems to be continuing in the same manner, except for the force curve.

I have attached two screen grabs showing what my force curve typically looked like in 0.9.6 vs what it looks like in 0.9.7

I have done checks on my data, by capturing it and my raw data visualization looks ok to me, as does the Goodness of Fit: 0.9937, and I think my data is good. No errors in the log that I can tell. So I'm a bit at a loss as to why this might

One thought was that I'm running a pi zero 2, and wondered whether it is no longer up for the task. I have tried changing the gpioPollingInterval to reduce the load (I was running with 5 previously, but values from 2-5 all produce the same issue with my force curve) but I've not got as far as trying to change the default NICE priorities as suggested in the application settings. That is not something I am confident in.

So my question I suppose is whether my data is actually ok or could still be causing the problem, or whether this could be a performance issue with my pi. Or am I completely on the wrong track.

Thanks
Ian

Config is as follows:

export default{
loglevel: {
default: 'debug',
RowingEngine:'debug'
},

  createRawDataFiles: true,        
  gpioMinimumPulseLength: 100,
  gpioPollingInterval: 2,
  gpioTriggeredFlank: 'Down',
  heartRateMode: 'BLE',
  userSettings: {
  weight: 81,
  sex: 'male',
  highlyTrained: true,
  strava: {
  allowUpload: true,
  autoUpload: false,
  clientId: "",
  clientSecret: "",
  refreshToken: "",

},
},

rowerSettings: {
  numOfImpulsesPerRevolution: 3,
  minimumTimeBetweenImpulses: 0.01,
  maximumTimeBetweenImpulses: 0.2,
  dragFactor: 550,
  flywheelInertia: 0.138,
  flanklength:9,
  magicConstant: 2.80,
  numOfPhasesForAveragingScreenData: 4,
  peripheralUpdateInterval: 500,
  autoAdjustDragFactor: true,
  autoAdjustRecoverySlope: true,

},
}

[0.9.7 data visualisation.xlsx](https://github.com/user-attachments/files/27032514/0.9.7.data.visualisation.xlsx)

[JaapvanEkris]

Hi Ian,

I strongly suspect that our new CyclicErrorCorrection filter is kicking in while it shouldn't. The cyclic pattern suggests that. A way of finding out is by setting autoAdjustDragFactor to false to see if the problem goes away (that is a new filter).

Setting systematicErrorNumberOfDatapoints to a sufficiently large number might help as well, and could allow to reduce the flanklength you need

[eglin73]

Thanks for your reply Jaap; I have some errors now:

Configuration Error: systematicErrorNumberOfDatapoints is configured while preconditions for the CECFilter are not met
Apr 24 16:33:20 rowingmonitor npm[2034]: Configuration Error: rowerSettings.autoAdjustRecoverySlope can not be true when rowerSettings.autoAdjustDragFactor is false,

The second error I can see where to correct it, changing that in my config, but not sure about the first. Could you point me in the right direction please?

Thanks

[JaapvanEkris]

Yeah, setting autoAdjustDragFactor to false and systematicErrorNumberOfDatapoints above zero will do that.

My practical advice, do three tests:

• autoAdjustDragFactor to false and systematicErrorNumberOfDatapoints to 0 (should disable the cyclic error filter and make your problem go away)
• autoAdjustDragFactor to true and systematicErrorNumberOfDatapoints to 0 (should still keep issue away)
• autoAdjustDragFactor to trueand systematicErrorNumberOfDatapoints to about two full recoveries of datapoints (in my logs, ORM reports 220 datapoints for a recovery, so I use 500 datapoints for this).

If this all fails, please provide a raw recording, so I can look at ORM's behaviour.

[eglin73]

OK, I will give that I try thanks Jaap, just to confirm the systematicErrorNumberOfDatapoints goes in the rower settings section of the config, like this?

rowerSettings: {
numOfImpulsesPerRevolution: 3,
minimumTimeBetweenImpulses: 0.01,
maximumTimeBetweenImpulses: 0.2,
dragFactor: 550,
flywheelInertia: 0.138,
flanklength:9,
magicConstant: 2.80,
numOfPhasesForAveragingScreenData: 4,
systematicErrorNumberOfDatapoints: 0,
peripheralUpdateInterval: 500,
autoAdjustDragFactor: false,
autoAdjustRecoverySlope: false,

[JaapvanEkris]

yep, that is the place where it goes.

[eglin73]

Thanks Jaap,

It tried all three of those options, the issue remains the same with all three as far as I can tell.

I have attached the raw data for 12 strokes, hope that is enough. And also the output of the log and status files.

Thanks for looking at it

Ian

0.9.7_status_andlog.txt
2026-04-24_09-11-29_raw.csv.gz

[JaapvanEkris]

Thanks for looking at it

Will look at it Sunday or Monday. First I want to clear my dev machine from 0.9.8 and migrate back to 0.9.7, to make sure I have the exact same setup.

[eglin73]

Thanks Jaap, that's great.

…

On Sat, 25 Apr 2026, 01:16 Jaap van Ekris, ***@***.***> wrote: Thanks for looking at it Will look at it Sunday or Monday. First I want to clear my dev machine from 0.9.8 and migrate back to 0.9.7, to make sure I have the exact same setup. — Reply to this email directly, view it on GitHub <#244 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A67ZYIEIONQCCANQAERQXPL4XOAMZAVCNFSM6AAAAACYERJEG2VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNZQGMZTKNI> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/A67ZYIA6FTHCSTMTBWAGHNL4XOAMZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRXGAZTGNJVUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/A67ZYIB2VSIUE34YTM5STGT4XOAMZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRXGAZTGNJVUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: <JaapvanEkris/openrowingmonitor/repo-discussions/244/comments/16703355@ github.com>

[JaapvanEkris]

Found the cause, you didn't actually set a flankLength (typo in name...). You set it to 9, but due to the typo it was stuck at the default value of 3. Attached is a configuration that works with your data:

  rowerSettings: {
    numOfImpulsesPerRevolution: 3,
    minimumTimeBetweenImpulses: 0.01,
    maximumTimeBetweenImpulses: 0.2,
    dragFactor: 550,
    systematicErrorAgressiveness: 0.95,
    systematicErrorNumberOfDatapoints: 110,
    minimumStrokeQuality: 0.26,
    flywheelInertia: 0.138,
    flankLength: 4,
    magicConstant: 2.80,
    autoAdjustDragFactor: true,
    dragFactorSmoothing: 3,
    minimumDragQuality: 0.85,
    autoAdjustRecoverySlope: true,
    minimumDriveTime: 0.40,
    minimumRecoveryTime: 0.70,
  }

This configuration will still display some artifacts in the first two strokes. But after that, the new Cyclic Error Correction Filter will kick in, retaining the detail of the force curve while still making it smooth. And as a side-effect: your Goodness of Fit for the recovery goes to 0.9994.

Increasing the flankLength to 6 will make it smoother from the start, but you lose a lot of detail because of it. So my advice is to stay at 4, as it will provide the best feedback in EXR.

Could you record a raw file of about 500 meters (a little over it) and upload it here? This way I can add this to the known machines, and you and other people can just rely on us checking that a configuration still works (with engine changes we check all machine configurations, but we need samples to do that).

@Abasz : this is the first time I've actually seen the CECFilter actually work in action, it is quite cool to see :). We've seen the data improve on a lot of machines, but I've never seen it actually happening in real force curve, live, which is just cool! In the first stroke it is full of artifacts, in the second stroke you'll see the artifacts smooth out as the curve progresses (large artifacts in the begin, small in the end), in the third they are almost absent and in stroke 4 it is really smooth.

[Abasz]

Yes this was my experience, when I was playing around with kayak ergs data. Not so pronounced, I have not thought that it is capable of correcting such a big errors though.

[eglin73]

That is fantastic, thanks very much Jaap! I have updated by config to what you have suggest and done a row and it works really well.

Those additions to the GUI are also fantastic, thanks for the continued work in improving ORM.

Attached is the raw data as requested.

My rowing machine is a Johnson JAR 5100, which I had to add magnets to (I used the magnet sensor array off an electric bike speed control which I got from a local bike shop).

Thanks again.
Ian

2026-04-27_22-05-45_raw.csv.gz

[klamp169]

@JaapvanEkris, @Abasz : Interesting data set from Ian. Shows quite large placement error (I estimate up to a degree) (which your filter can handle very well!) but also a very large constant friction torque of about 0.35 [Nm] (close to two orders of magnitude larger than for my model C!). The flywheel exhibits lower rotational speeds (higher drag factor) compared to Concept2 and stops running within about 12 seconds after the last stroke!
I wonder what you think is the consequence of this very large friction term on the analysis within ORM.
(BTW, I could not find the sprocketRadius in the config, so I took 1.4 [cm]. This gave very reasonable results)

Cheerio!

[JaapvanEkris]

The flywheel exhibits lower rotational speeds (higher drag factor) compared to Concept2 and stops running within about 12 seconds after the last stroke! I wonder what you think is the consequence of this very large friction term on the analysis within ORM.

In essence, it is a static drag force. In practice my assumption is it will mostly be absorbed by the current drag calculation, as long as speeds are within the same range stroke-to-stroke.

What I do see is that as soon as the dragfactor is changed, for example on a RowErg, the ratio between static amd speed-dependent drag changes, and calibration tends to be off.

So, I'm working on a prototype that will calculate the static drag based on the air-drag residu. So you get a speed dependent dragfactor component (airbased machines) and a static component (magnetic machines). This should work better, especially on hybrid machines. It is a bit tricky, and the first attempts have proven to be way too unstable for practical use. So absolutely on my radar for 0.9.8, but also a very high probability of failure.

The big issue is that hybrid machines like the NordicTrack change both magnetic and air drag settings at the same time. So you need an in-situ calculation. And the Kalman filter should be modified, and the current recovery slope might need to understand the portion of air drag as well. As said, a complex puzzle which might be impossible to solve.

[eglin73]

Interesting that the data showed the high static drag force, anecdotally that is always what I've felt when comparing my machine to a Concept 2, but I never had any data to support that. In terms of the rowing experience, particularly at low stroke rates, again anecdotally, it feels like a more effort is required to overcome that rapid slowing of the flywheel and get it moving again on my machine vs the Concept 2. How ORM accounts for that (beyond the drag factor setting in the config, which is quite high in my setup) is beyond my understanding.

(Note my machine does not have an option to alter the airflow like a C2)

Just as an FYI, I've tried to calibrate my machine by doing set distance rows and workouts on both mine and a C2 and comparing the results (measured using EXR). Those rows ranged from 500m, 1000m, 2000m through to 30+min set worksouts. Obviously I'm the variable in those, but looking purely at the times and distance I think it is probably not wildly off. The short max effort rows were typically within 1-2% of each other which seemed good enough for me.

Not sure if that is of any value, but thought I'd share anyway in case it is.

Thanks again.

[klamp169]

Static drag (i.e. magnetic drag and/or mechanical friction) ....

IMHO magnetic drag produces a torque which is linearly proportional to speed. (Coulomb-type) mechanical friction is speed independent. The air drag in the Concept2 type rower is proportional to angular speed squared. So magnetic and mechanical friction behave differently with speed.

The amount of speed independent friction seen in Ians' data raises the suspicion that there might be a mechanical fault.

On a RowErg, we are hitting GoF of 0.9983, you were hitting 0.9937 (this is with the CECFilter off). So the overwhelming majority of the drag (well over 99.3%!) is accounted for by the dynamic drag.*

Please state your definition of GoF. I use R-squared and see values almost always exceeding 0.99999 (my modelC, using rwnp)

Footnote: @klamp169 : The CECFilter improves the GoF by removing structural noise. However, it might actually 'hide' the speed independence of a drag component, as the CECFilter corrections are speed dependent and it assumes the dragline contains the perfect value. This makes regression to the line a bit of a self-fulfilling prophecy as this is a self-reenforcing feedbackloop. This in fact is the key challenge in identifying the static drag in a in-situ measurement: how to prevent CECFilter in killing true signal while removing structural noise. Initial attempts by regression over α = A * ω + B, where A is the air based drag and B is the static drag proved to be too unstable. But there are other ways I'm currently exploring.

I understand your predicament. I think the speed independent friction should be negligible (at operating speeds) in any good quality rower. Magnetic, speed proportional 'friction' is a different matter. Let me know if I can be of assistance with more simulations.

[eglin73]

Yes, what Abasz has explained is what I was meaning. My machine is air resistance only, there is no magnetic component. When I row at lower stroke rates, it feels like the flywheel slows down and requires effort to get it up to speed again.

If I understand Jaap's comments then potentially the balance of inertia and drag is not optimum and I could fiddle around with the fan blades to reduce their drag effect, but risk not having enough resistance on the drive.

And Klamp169's comment suggests maybe the static mechanical resistance is not optimal and might be able to be improved.

At the end of the day I think for my purposes of 50 year old fitness rower that is probably not necessary, it is interesting to note though.

Thanks again

Ian

[JaapvanEkris]

We had the same feedback from athletes on Old Danube when we moved to the free spinning flywheel design that the whole machine felt more consistent at variable interval speeds.

That indeed is the key issue with a magnet or friction based approach. Air based resistance behaves so moluch more natural.

For instance you do a hard work interval and then stop fully for rest (without doing more strokes). Flywheel stops, dragfactor does not gets calculated because of the length of the recovery). When you restart for the next interval at the first 5-10 strokes (until the flywheel speeds up to the same speed at where the last drag was calculated) stroke detection would struggle so the minimum torque settings needed to be set to something that allows the incorrect drag factor (determined for higher speeds) at lower speeds (which meant that including drive in the recovery, that essentially screwed the power calculation because the drag factor was lower than in reality). For this actually I have a reset mechanism in ESPRM where if the drive length is absurdly long, I "reset" the dragfactor for the stroke detection (I keep it for the metrics so there are no zeros, but essentially those are off).

In ORM I considered resetting drag on a pause. But I haven't seen any reports of people running into issues. But in rowing dragfactor is often set to a single setting (unless for specific training). Some national teams even mandate a specific value.

Jaap, a few years ago I had posted a bug called dumper setting change bug or something similar (I was not able to find, may be it was in a discussion). I was saying that if you change the damper mid session (particularly reduce it massively e.g. from 5-6 to 1) stroke detection stops (I think your solution/answer was the introduction of the margin based was the drag slope adjustment or something similar). This is essentially the same problem with the constant friction that manifests in the feeling.

I remember. The key issue is that the torque and slope targets become unreachable due to the settings and a changed physical configuration. Torque should have become lower over last years because of better noise reduction, and slope has a dedicated margin which can be set quite loosely (as GoF will still prevent spontanuous changeover). It is a tricky scenario as nothing stops people from moving from DF69 to DF220 in an instant.

[JaapvanEkris]

Static drag (i.e. magnetic drag and/or mechanical friction) ....

IMHO magnetic drag produces a torque which is linearly proportional to speed. (Coulomb-type) mechanical friction is speed independent. The air drag in the Concept2 type rower is proportional to angular speed squared. So magnetic and mechanical friction behave differently with speed.

Youbare completely correct on this one.

Please state your definition of GoF. I use R-squared and see values almost always exceeding 0.99999 (my modelC, using rwnp)

We use r^2.

Could you provide a recording of a C2 Model C, for 500 meter steady state and the expected output? Current recording in the calibration set is a total mess.

I understand your predicament. I think the speed independent friction should be negligible (at operating speeds) in any good quality rower. Magnetic, speed proportional 'friction' is a different matter. Let me know if I can be of assistance with more simulations.

Thanks. First order of business is migrating to the new testplatform, and find a way to do an approximation of magnetic drag without the machine going banana's with real-life data.

[klamp169]

Could you provide a recording of a C2 Model C, for 500 meter steady state and the expected output? Current recording in the calibration set is a total mess.

I am not sure if I understand this request. Please note that I modified my modelC according to this. The three magnets with the inductive pick-up is only used for the PM2. Could you please rephrase your request?

If you want a raw csv file based on three pulses per revolution, I can produce that by reducing pulse count by a factor of 4. This is all explained in the previously cited link.