Integrating WaterRower S4 monitor

[RobinDevogele]

I wanted more precise monitoring than what the S4 monitor itself provides. I first tried PiRowFlo, which reads the pre-computed values the S4 outputs over serial — but those values update slowly and are smoothed quite heavily, which becomes a real problem with games like EXR that need responsive data.

While digging into the S4's USB serial protocol, I noticed it also exposes raw pulse counts (the flywheel's has 40 ticks), not just the pre-computed metrics. Poking around further, I came across this project, and started wondering whether I could feed the S4's raw serial output into ORM's engine instead.

Approach 1 — naive per-pulse reconstruction
The S4 only reports an aggregate pulse count per fixed 25ms window (e.g. P05 = 5 ticks passes in the last 25ms), not individual pulse timestamps. First attempt: for each line, divide the 25ms window evenly by the pulse count and call the engine once per pulse with that uniform dt. This produced a very noisy, "staircase" signal (visible in the raw dt recordings vs. the reference examples) with sharp discontinuities at line boundaries, which caused significant stroke over-counting (~1.5-2x too many strokes detected) — the engine's drive/recovery detection was reacting to quantization artifacts, not real acceleration.

Approach 2 — smoothing, but with a performance regression
To fix the staircase artifact, added a buffer that accumulated N lines before flushing a smoothed batch. This fixed the counting issue but introduced two problems: (1) discontinuities at batch boundaries (fixed by switching to a proper sliding window with weighted smoothing across neighbouring points instead of tumbling batches), and (2) CPU load spiking to 100-176% on a rPi 3B, because each individual physical pulse still triggered its own handleRotationImpulse call — at ~250 calls/sec during active rowing, the per-call overhead was probably too expensive.

Final approach — sliding window smoothing + impulse grouping
Combined a continuous sliding window (weighted average across neighbouring line-readings, no batch discontinuities) with grouping N=5 real physical impulses into a single engine call, while dividing numOfImpulsesPerRevolution by the same factor (40 → 8) to keep the reported rotation physically correct. This cut CPU load roughly 5x (down to ~35% steady-state) while keeping the smoothed signal quality that fixed the over-counting. End result: stroke counts now match real strokes, drive/recovery timing looks physically realistic, and CPU load is stable.

Here the plotted dT, it looks very clean to me:

I played around a LOT with the config,I don't know if my values are correct, but it seems to be working.

'use strict'
export default {
loglevel: {
default: 'info',
RowingEngine: 'debug'
},
createRawDataFiles: true,
rowerSettings: {
numOfImpulsesPerRevolution: 8,
minimumStrokeQuality: 0.85,
dragFactor: 5000,
autoAdjustDragFactor: true,
flankLength: 10,
minimumTimeBetweenImpulses: 0.001,
maximumTimeBetweenImpulses: 0.05,
flywheelInertia: 0.073,
naturalDeceleration: -0.015,
minimumDriveTime: 0.65,
minimumRecoveryTime: 0.8
}
}

Is my approach seems reasonable ? Should I change something ?

[JaapvanEkris]

I think it looks pretty good. Playing with the flywheel inertia allows you to change the pace, so if you feel it is too slow, that is the place to change that.

Is there a reason to keep the S4 in the loop? There are quite some people who simply replaced the S4 completely with ORM.

[RobinDevogele]

The main idea is to keep the installation as clean as possible.
Also, it would be great and much easier alternative for other people that don’t want to mess around with GPIO and so on.

« Just » install ORM on a Pi, plug the usb connection and that’s it.

I was actually thinking about doing via GPIO, then during a sleepless night I wondered « but if the s4 is already giving that info, why no just use it ! » 😄

Plus side, you keep the monitor working, my wife prefers the simple dumb monitor for instance

[JaapvanEkris]

The main idea is to keep the installation as clean as possible. Also, it would be great and much easier alternative for other people that don’t want to mess around with GPIO and so on.

« Just » install ORM on a Pi, plug the usb connection and that’s it.

That is a pretty neat idea actually!

I was actually thinking about doing via GPIO, then during a sleepless night I wondered « but if the s4 is already giving that info, why no just use it ! » 😄

If you want to keep the machine in original state, it is an approach indeed. On my Concept2 I added an optocoupler which essentially provides a pass-through for the original signal (which is transported via a 2.5mm jack plug) and provides a 3.5mm jack for the Raspberry Pi. If it needs to be removed it is just three plugs, and we are back to original.

Plus side, you keep the monitor working, my wife prefers the simple dumb monitor for instance

My wife never got into rowing :( Tried it a couple of times, even set her up on EXR, but not enough dancing involved I'm afraid.

[RobinDevogele]

I changed flywheelInertia to 0.1
It is "closer" to what S4 monitor, but still a bit behind (~8-10% in distance, a bit less in watts), but I guess it's ok because it is a know fact that S4 is overestimating by that amount.

However, I notice that drive length is overestimated. For example it is stated 4m of drive length. A small pull on the cord would state 1m or so.

Any idea ?

Another thing, I had issues with bluetooth. When trying to connect to EXR, it was either not detecting it, or detecting it then when trying to connect, it was failing (then not detecting it anymore).
Restarting ORM was working.

But I don't know if it will be stable after that (like... if it works once, it will still work) or if I need to have some kind of easy restart procedure.

[JaapvanEkris]

Ok. Rowing machines normally only provide a single bluetooth connection. So the ORM connection gets tossed around between EXR and Kinomap. Kinomap has the tendency to skip the disconnect on the app closure, so ORM thinks it is still connected and won't advertise its availability.

[RobinDevogele]

I think it is a general bug with kinomap. I'm never able to connect, even without touching EXR.
And whenever I try to connect to Kinomap, bluetooth connection is out until I restart ORM.

One thing to notice, Kinomap is always showing the old device name of my raspberry pi. Pi' os has been completly wiped since then , but somehow it kepts the cache of device name <-> mac address I guess.
Maybe it's the reason it fails to connect and then never disconnecting ?

I don't know how to reset that cache. I tried to "forget" the device, reinstall the app, reboot iphone... still always detected with old name

nRF connect on the same iphone is showing the proper name

probably related: https://developer.apple.com/forums/thread/780235

[RobinDevogele]

FYI, I changed the bluetooth mac address and it is now working. So it is a bug on apple side due to caching of the name.
There seems to be no way to clear that cache.

It will be my permanent solution then.

EDIT: cmd to change mac adress; for future reference

hcitool cmd 0x3f 0x001 0x34 0x12 0xEF 0xBE 0xAD 0xDE

[Abasz]

Cant you actually remove the BLE connection from the bluetooth setting? on android this is generally possible.

[RobinDevogele]

Only paired bluetooth device are visible in bluetooth settings. It's not the case for BLE connections.

[RobinDevogele]

I don't know if I put this in another topic, or maybe it is related to my stuff only.

I did my first "real" session since configuring ORM.
It was working fine then I have been confused by some metrics, in particular when I decrease the cadence.
While all the strokes are still very well detected (I counted myself and checked the number of strokes detected), but some metrics are completly wrong or froozen:

• cadence (stroke / min) get stuck at a high value, which is strange because there is no overdetection
• watt are sometimes stuck at the high value for quite a long time. To get it back to a proper value, I need to completly stop rowing, so it get reset

I attach an extract of the session. You see that during the time interval of one minute, there are only 18 strokes, but:

• cadence is stuck at 26.9
• power is stuck at 154w
• speed is stuck at 3.81

Any idea what's happening ?
CPU overload ?

edit: my Pi is undervolted, so it probably causes throttling..
stuck_data.csv

[JaapvanEkris]

What does the syslog say. Typically ORM logs deviating behaviour pretty well. Perhaps set the loggng level to debug?
And please record a raw datafile. That allows me to replay your session on one of the test-installs I have here.