Schwinn Windrigger profile

[eriknz]

schwinn windrigger 251219.zip
I've attached a rowing machine profile and training data from a 10 minute session for my Schwinn Windrigger. I'm sure it's not perfect but it roughly matches what the original computer says and since I'm just using it to track my progress, I think it's good enough for me.
Hopefully it helps someone.

[JaapvanEkris]

Thanks! I'll add it to the existing profiles.

Jaap

[acoolsteve]

Hello, I also have a Schwinn Windrigger.
Unfortunately it has a broken screen and trying to fix/replace it lead me to this project.
Could some point me to the instructions to get this profile into ORM.
thanks

[eriknz]

windrigger_config_and_profile.zip
I've attached a new zip with my config and the windrigger profile. I've changed the gpio pin in the config.js in the zip to pin 17 which matches the original setup instructions (I use pin 26 because I'm using a gpio LCD screen).
The setup instructions are here: https://github.com/JaapvanEkris/openrowingmonitor/blob/main/docs/installation.md
I've made a post with basic setup instructions that might also be useful here: #148
In my case I was using a gpio lcd screen, but if you aren't, when you get to the bit in the instructions about editing config.js, just copy config.js and rowerProfiles.js from this zip into the samba share on the raspberry pi and ignore the rest of the instructions. reboot the pi and it should work and you should be able to access it from a web browser on the same wifi network at rowingmonitor.local (if that doesn't work, you might have to find its ip address and access it via that).
It's possible I've forgotten something, but hopefully this helps.

[acoolsteve]

Hello ErikNZ,

I managed to get it semi‑working by copying the values from the rowerProfiles.js file in your original post into my config.js. This got my time and distance showing numbers close to what I’m expecting, which is fantastic.

The issue I have now is that all the other data fields on http://rowingmonitor.local stay blank for about 60 seconds, and then they start displaying numbers that don’t look correct. Time and distance look great, though.

I'll look through the new files you uploaded and see if i can get things working better.

Thank you to everyone working on this project.
(I’m not a programmer/coder, so please bear with me as I learn.)

[acoolsteve]

So I've been having issues to the stroke detection stopping in the first few minutes of a session, and not being able to recover without resting the service.
ORM was still receiving rawdata but wasn't process it.

After days of making little progress on my own I asked Claude.ai for help and it determined I have excessive reed bounce / a dying sensor.

it's solutions are:

Option 1: Replace the Reed Switch (BEST)
-Your reed switch is failing to trigger at low speeds. This is common wear or a weak magnet.)

Option 2: Add a Second Magnet
-This gives the reed switch two chances per revolution to trigger, making it more reliable at slow speeds.)

Option 3: Increase Maximum Time Between Impulses
-This lets the algorithm tolerate the slow recovery:
maximumTimeBetweenImpulses: 2.0, // Up from 0.5

Option 4: Adjust Recovery Detection Settings
-Make the algorithm less strict about detecting recovery:
minimumRecoverySlope: 0, // Already at 0, good
autoAdjustRecoverySlope: false, // Turn off auto-adjustment
minimumStrokeQuality: 0.20, // Down from 0.33

Going with its suggestion of option 3 and 4 has giving 10mins of successful rowing with the stroke count working even when I was doing my best to upset it.

I've attached the config and profile that is currently working for my Schwinn Windrigger encase someone else is having similar trouble.
There is also rawdata and rowing data files for anyone with a good understanding of how things work to look at, and give advice as to where things are going wrong.

I'm using a Pi 4B to run ORM.

Edit I've just notice the config and default attached here is missing my rowerProfiles file
Edit fixed zip now contains correct "config.js/default.config.js/rowerProfiles.js"
logs_no_stopping.zip
Logs stopped.zip
Schwinn_WindRigger_rower_20260114.zip

[Abasz]

Reed bounce is almost number one in the FAQ I am creating. Have a look at this video:

https://www.youtube.com/watch?v=7LimjYS04FQ&t=278s

option 1

yes to a hall sensor

option 2

will not work, ORM needs to know up front how many impulses per revolution there are. So if you add one more magnet both needs reliable triggering

option 3

not sure how this helps

I have checked your impulses and its clean as a wistle:

logs_no_stopping file:

same for the other file:

This is very good. So there does not seem any issue with bounce, not even on slow speeds.

If you are having issues with stroke detection its not bounce. This is bounce:

and this:

I feel that your stroke detection should work fine if you find the correct settings.

[JaapvanEkris]

yeah,

maximumTimeBetweenImpulses has no direct impact on stroke detection. In essence, only on session start and session end (and on the ranges managed by the CEC filter, if turned on in 0.9.7).

the profile used is this one:

  Schwinn_Windrigger: {
    numOfImpulsesPerRevolution: 1,
    sprocketRadius: 1.57,

    minimumTimeBetweenImpulses: 0.03,
    maximumTimeBetweenImpulses: 0.3,

    flankLength: 3,

    // STROKE DETECTION SETTINGS
    minimumForceBeforeStroke: 20,
    minimumRecoverySlope: 0,
    minimumStrokeQuality: 0.33,
    autoAdjustRecoverySlope: true,

    autoAdjustRecoverySlopeMargin: 0.05,

    // Error reducing settings for the rowing phase detection (in seconds)
    minimumDriveTime: 0.300, // minimum time of the drive phase
    minimumRecoveryTime: 0.900, // minimum time of the recovery phase

    dragFactor: 260,

    autoAdjustDragFactor: true,

    dragFactorSmoothing: 1,

    minimumDragQuality: 0.83,

//    flywheelInertia: 0.0667, (calculated based on measurements and CAD model but 0.08 seems to work better.)
    flywheelInertia: 0.08,

    maximumStrokeTimeBeforePause: 6.0,

    magicConstant: 3.3
  }

Stroke detection issues often come from minimumStrokeQuality and minimumForceBeforeStroke.

The change of magicConstant is unexpected: in rowing we typically use 2.8 and any deviation is actually problematic as apps like EXR actually check if power and reported speed match.

[eriknz]

I'm not sure what the problem might be. In the "2026-01-14_04-54-07_raw.txt" file you can see a longer recovery phase at around 49 seconds and again at 94 seconds (with good strokes in between), but the maxTimeBetweenImpulses wasn't exceeded. In the "2026-01-14_04-54-07_rowingData.txt" file, after 48 seconds it has what looks like two rows of junk data with drive times of 21 seconds and drive lengths of 32m before continuing with a few more reasonable strokes before you stopped.
I have no idea what could cause it though. I wouldn't trust Claude.ai in this case, I think the sensor is fine judging by the raw data.
2026-01-14_04-54-07.zip

[acoolsteve]

Thanks everyone for looking into this. 😊

the issue i have is seen in 2026-01-14_04-54-07, where the first 30 strokes are shown in rowingdata then stops, and there are 45-ish in the raw data.
this is also visible when watching the output over http, all data stops at 31, excluding distance that will continue to be shown.
once ORM rowingdata stops no matter how long I continue to row ORM will not recover to show anything other then distance climbing.

changing to
maximumTimeBetweenImpulses: 2.0, // Up from 0.5
autoAdjustRecoverySlope: false, // Turn off auto-adjustment
minimumStrokeQuality: 0.20, // Down from 0.33

gave me 10 minutes of rowing data over http without problems.
in the 2026-01-14_07-00-00 rowingdata after line 230 it shows "NaN | Infinity | NaN | NaN" in my other logs, when these appear the calculations just stop, and never recover.

The original monitor for my rower has a cracked screen so I'm completely blind as to how the ORM data would compare to what Schwinn would show.

[JaapvanEkris]

I used this on your raw data (please provide the clean raw files, as Excel messes it up), and I can get it working with the following config:

  Schwinn_Windrigger: {
    numOfImpulsesPerRevolution: 1,
    sprocketRadius: 1.57,
    minimumTimeBetweenImpulses: 0.03,
    maximumTimeBetweenImpulses: 0.3,
    flankLength: 3,
    systematicErrorAgressiveness: 0,
    systematicErrorNumberOfDatapoints: 240,
    // STROKE DETECTION SETTINGS
    minimumForceBeforeStroke: 18,
    minimumRecoverySlope: 0,
    minimumStrokeQuality: 0.20,
    autoAdjustRecoverySlope: true,
    autoAdjustRecoverySlopeMargin: 0.05,
    // Error reducing settings for the rowing phase detection (in seconds)
    minimumDriveTime: 0.300, // minimum time of the drive phase
    minimumRecoveryTime: 0.900, // minimum time of the recovery phase
    dragFactor: 100,
    autoAdjustDragFactor: true,
    dragFactorSmoothing: 3,
    minimumDragQuality: 0.85,
//    flywheelInertia: 0.0667, (calculated based on measurements and CAD model but 0.08 seems to work better.)
    flywheelInertia: 0.08,
    maximumStrokeTimeBeforePause: 6.0,
    magicConstant: 2.8
  }

The original monitor for my rower has a cracked screen so I'm completely blind as to how the ORM data would compare to what Schwinn would show.

The Schwinn delivers BS data anyway, so no need to comare. If you compare to anything, compare to a Concept2 with a PM5 (row on both machines, compare the pace/distance for the same feel).

[acoolsteve]

Good evening.
I've got here two sessions of 5mins constant rowing and then 3-5 mins of random stokes, fast, slow, short, long, strong, weak all trying to get the issue where ORM stops counting strokes.
what i noticed tonight is when aggressively doing max effort pulls there is on occasion slipping in the belt.
it happened in both tests, and i had to really pull hard to get it too happen.
I'll be looking into that issue over the weekend.

Attached are the csv,fit,log, and config files of the two tests.
Claude made 4 changes to the rower profile I was working with

Problem: OpenRowingMonitor stroke detection fails mid-session and never recovers. Distance continues accumulating (proving impulses are still being received), but no new strokes are detected.
Root Cause: Reed switch failure at low flywheel velocities during recovery phase. Raw data shows normal inter-impulse timing (50-80ms) during active rowing, then catastrophic degradation (400ms → 1100ms+ gaps) when the flywheel decelerates. The stroke detection FSM gets stuck in drive phase because it never sees a clean recovery transition - the reed switch fails to trigger when the magnet passes slowly.
Evidence: All three sessions show identical failure pattern - stroke detection hangs with massive recovery times (20-40+ seconds), then the session becomes unrecoverable. The raw impulse data clearly shows the reed switch stops reliably triggering as RPM drops.
Solution Applied: Config changes to make recovery detection more tolerant:

maximumTimeBetweenImpulses: 2.0 (was 0.5) - allows longer gaps
minimumStrokeQuality: 0.20 (was 0.33) - less strict validation
autoAdjustRecoverySlope: false - prevents adaptive algorithm drift
minimumRecoveryTime: 0.800 (was 0.600) - more forgiving phase timing

Hardware Recommendation: If config fix insufficient, either add second magnet (double impulses per revolution = 2x reliability) or replace failing reed switch. The hardware is clearly marginal at low speeds.

 Schwinn_Windrigger: {
    numOfImpulsesPerRevolution: 1,
    sprocketRadius: 1.57,

    minimumTimeBetweenImpulses: 0.02,
    maximumTimeBetweenImpulses: 2.0,
    smoothing: 1,

    flankLength: 5,

    minimumForceBeforeStroke: 10,
    minimumRecoverySlope: 0,
    minimumStrokeQuality: 0.20,
    autoAdjustRecoverySlope: false,

    autoAdjustRecoverySlopeMargin: 0.05,

    // Error reducing settings for the rowing phase detection (in seconds)
    minimumDriveTime: 0.200, // minimum time of the drive phase
    minimumRecoveryTime: 0.800, // minimum time of the recovery phase
    dragFactor: 260,

      autoAdjustDragFactor: true,
    dragFactorSmoothing: 5,
    minimumDragQuality: 0.83,

    // flywheelInertia: 0.0667, (calculated based on measurements and CAD model but 0.08 seems to work better.)
    flywheelInertia: 0.08,

    // The time before a stroke is considered paused
    maximumStrokeTimeBeforePause: 14.0,

     magicConstant: 3.3
  }

could not get it to error in the first test.

and then my 2nd test with rowerprofile from JaapvanEkris, posted in this thread

  Schwinn_Windrigger: {
    numOfImpulsesPerRevolution: 1,
    sprocketRadius: 1.57,

    minimumTimeBetweenImpulses: 0.03,
    maximumTimeBetweenImpulses: 0.3,

    flankLength: 3,

    // STROKE DETECTION SETTINGS
    minimumForceBeforeStroke: 20,
    minimumRecoverySlope: 0,
    minimumStrokeQuality: 0.33,
    autoAdjustRecoverySlope: true,

    autoAdjustRecoverySlopeMargin: 0.05,

    // Error reducing settings for the rowing phase detection (in seconds)
    minimumDriveTime: 0.300, // minimum time of the drive phase
    minimumRecoveryTime: 0.900, // minimum time of the recovery phase

    dragFactor: 260,

    autoAdjustDragFactor: true,

    dragFactorSmoothing: 1,

    minimumDragQuality: 0.83,

//    flywheelInertia: 0.0667, (calculated based on measurements and CAD model but 0.08 seems to work better.)
    flywheelInertia: 0.08,

    maximumStrokeTimeBeforePause: 6.0,

    magicConstant: 3.3
  }

in the 2nd test the error happens here:

Jan 15 20:37:30 rowingmonitor npm[1153]: stroke: 216, dist: 1777.9m, heartrate 145 BPM, pace: 2:59/500m, stroke dist: 8.3m, strokerate: 21.4 SPM, drive dur: 0.77s, rec. dur: 3.16s, stroke dur: 2.81s
Jan 15 20:39:22 rowingmonitor npm[1153]: *** RECOVERY phase started at time: 624.4134 sec
Jan 15 20:39:22 rowingmonitor npm[1153]: *** Stroke duration of 116.91173599999962 sec is considered unreliable, skipped update cycle statistics
Jan 15 20:39:28 rowingmonitor npm[1153]: *** WARNING: currentDt of 0.3083800000000565 sec is above maximumTimeBetweenImpulses (0.3 sec)
Jan 15 20:39:28 rowingmonitor npm[1153]: *** WARNING: currentDt of 0.3240499999999429 sec is above maximumTimeBetweenImpulses (0.3 sec)
Jan 15 20:39:28 rowingmonitor npm[1153]: *** PAUSED rowing at time: 629.9036 sec, rower hasn't moved in 118.1217 seconds and flywheel is dwelling
Jan 15 20:39:28 rowingmonitor npm[1153]: *** Calculated drag factor: 338.7565, no. samples: 29, Goodness of Fit: 0.9897
Jan 15 20:39:28 rowingmonitor npm[1153]: *** Calculated recovery slope: 0.026606, Goodness of Fit: 0.9897
Jan 15 20:39:28 rowingmonitor npm[1153]: *** PAUSE MOVING command recieved by RowingEngine at time: 629.9036 sec, distance: 2198.42 meters
Jan 15 20:39:28 rowingmonitor npm[1153]: stroke: 216, dist: 2197.7m, heartrate 142 BPM, pace: ∞/500m, stroke dist: NaNm, strokerate: NaN SPM, drive dur: NaNs, rec. dur: NaNs, stroke dur: NaNs
Jan15 20:39:28 rowingmonitor npm[1153]: Rowing stopped/paused at 20:39:28, at 629.61999 seconds,distance 2197.7m

there is 400-ish metres between when the error happened and me stopping.
after leaving it for a while, I started a session and ORM won't count strokes.
I have to send a restart the service to get it to work again.

I'd like to find out is why it's freezing and not recovering.
I can do more testing if anyone has a protocol they want me to follow that will help track down the issue.

I really appreciate the time you all have given me.

Claude.zip
JaapvanEkris.zip
rowing without restarting ORM engine.zip

[Abasz]

Claude

It is wrong. This is nothing to do with the reed. Your signal is very clean. I plotted all 3 raw data and there are no bounces. This purely a setting issue. It is clean on low speeds. No bounce even before like stopping. I am wondering if this real is a reed :)

settings

• For a one impulse machine I think flankLength: 5 is unnecessary. 3 should suffice especially since your raw data is clean.
• I dont know your machine but on air rowers dragFactor: 260 is rather high. The max on the C2 when you take off full the cover and the flywheel is exposed is around 280. I am not sure what resistance setting you are using but this is too much. On C2 general recommendation is 125-135.
• Minimum recovery time: 900 can be lowered I think (though this is not going to solve your issue its just simply high) you can use 800 (rule of thumb is twice the drive).
• If you want to be conservative and test you can increase the minimumForceBeforeStroke to 30 or 40 and then reduce it in increments. Basically this is the setting that controls at what power (force) the rower should consider recovery start. Increasing this will trigger recovery even when you are still pulling the handle

You know you can reply the sessions right? So you can tweak the setting by chaning one setting and than see how stroke detection improve. I suppose you can send Claude agent to do a feedback loop, but in my experience even opus was not able to tweak profiles well (they gave up too early) even when they had full access to the code to understand what each setting does what) :) : I am preparing a faq, that explains how to, its currently draft but here is the link, its issue number 16 that covers this specifically

[JaapvanEkris]

• For a one impulse machine I think flankLength: 5 is unnecessary. 3 should suffice especially since your raw data is clean.

Agreed. It seriously introduces the risk of choking the stroke detection. Stroke detection works on changes in the angular velocity. Too much flanklength will flatten that out.

• I dont know your machine but on air rowers dragFactor: 260 is rather high. The max on the C2 when you take off full the cover and the flywheel is exposed is around 280. I am not sure what resistance setting you are using but this is too much. On C2 general recommendation is 125-135.

And it really depends on the use of the profile. When drag is automatically recalculated, it shouldn't be set too high as it tends to block the initial stroke (as it is an ingredient in the forcebeforestroke calculation).

• Minimum recovery time: 900 can be lowered I think (though this is not going to solve your issue its just simply high) you can use 800 (rule of thumb is twice the drive).

Yeah, it is a safety net. I personally use 0.300 s for the drive, 0.600 s for recovery.

• If you want to be conservative and test you can increase the minimumForceBeforeStroke to 30 or 40 and then reduce it in increments. Basically this is the setting that controls at what power (force) the rower should consider recovery start. Increasing this will trigger recovery even when you are still pulling the handle

That, or set minimumStrokeQuality lower. Or do both. Replaying and seeing what works is sometimes required.

[JaapvanEkris]

This machine is now on the official supported list for release 0.9.7. You can replace the manualy configured profile with

  rowerSettings: rowerProfiles.Schwinn_Windrigger