GPIO impulses not detected unless GpioService is explicitly named in loglevel config (Pi 4, Bookworm Legacy, main branch)

[Johnedit]

Hi, John from RowAlong here. Lots of people have been in touch about ORM - so I've started looking at it. I'm having an issue with my development though.

Context: I'm building a non-invasive rowing monitor for a Concept2 RowErg using a Waveshare IR reflective sensor pointed at the flywheel's ventilation slot (detecting the 8 fan blades passing, rather than tapping the PM5's own 18V signal) — this is a proof of concept before extending the same approach to other rowing machines. This is my first Raspberry Pi project, so apologies if I've missed something obvious.

Environment:

Raspberry Pi 4 Model B
Raspberry Pi OS Lite (Legacy) 64-bit, Debian 12 Bookworm
ORM installed via official installer, main branch, version 0.9.7
Sensor: Waveshare IR Reflective Sensor (digital output via LM393 comparator), wired to GPIO 17 (VCC → pin 1, GND → pin 9, DOUT → pin 11)
rowerSettings based on rowerProfiles.Concept2_RowErg with numOfImpulsesPerRevolution: 8 and flywheelInertia: 0.1001 overridden

Summary:
GPIO impulses are not picked up by ORM's rowing engine unless GpioService is explicitly listed as a key in the loglevel config object — setting only default (to either 'debug' or 'trace') is not sufficient, even though the startup log line (Gpio-service: pin number 17, polling interval 5 us, triggered on Up flank, minimal pulse time 50 us) prints identically either way, and the service reports active (running) with no errors in both cases.
Steps to reproduce:

Confirm sensor wiring is correct and hardware-level detection works independently of ORM:

watch -n 0.2 pinctrl get 17
Confirmed: pin reliably toggles hi/lo when the sensor is triggered, in every test below.

With this config:

javascript loglevel: {
default: 'debug'
},
Restart the service, watch sudo journalctl -u openrowingmonitor -f, trigger the sensor repeatedly. No stroke or impulse activity is logged or reflected in the web dashboard, despite the pin toggling correctly at the hardware level.

Change to:

javascript loglevel: {
default: 'trace',
GpioService: 'trace'
},
Restart, repeat the test. Impulses are picked up correctly — stroke detection, pace, and stroke rate all populate as expected, and a session file is saved on stop.

Revert to step 2's config (removing the GpioService key). Restart, repeat test. Impulse detection stops working again — confirmed reproducible in both directions (worked → removed key → stopped working → re-added key → worked again), across multiple restarts.

Expected behaviour: GPIO impulse detection should function correctly regardless of the loglevel configuration, since logging verbosity shouldn't affect functional behaviour.
Actual behaviour: Impulse detection appears to depend on GpioService being explicitly present as a named key in loglevel, suggesting a possible initialisation path tied to per-module logger setup that isn't otherwise triggered.
Additional note: during this same session, the GpioTimerService.js process also crashed with Unhandled signal 11 during a service stop/restart cycle — noted in case it's related, though I couldn't reliably reproduce this specific crash on demand.

Happy to provide full raw session logs, or test any suggested fix. Config.js is below.

John

GNU nano 7.2 /opt/openrowingmonitor/config/config.js
'use strict'
/*
Open Rowing Monitor, https://github.com/JaapvanEkris/openrowingmonitor

You can modify this file to configure Open Rowing Monitor to your needs.
This file should be placed in the 'config' folder of Open Rowing Monitor.

All available configuration parameters are visible in config/config.default.js
To modify a parameter, copy it to this file and modify the value.

Changes to this file are persisted when you update to new versions.
*/
// eslint-disable-next-line no-unused-vars
import rowerProfiles from './rowerProfiles.js'

export default {
// example: change the default log level:
loglevel: {
default: 'trace'
GpioService: 'trace'
},

// The rower specific settings. Either choose a profile from config/rowerProfiles.j>
// https://github.com/JaapvanEkris/openrowingmonitor/blob/main/docs/Supported_Rower>
// the settings manually (see https://github.com/JaapvanEkris/openrowingmonitor/blo>
// on how to do this). If you find good settings for a new rowing device please sen>
// with a raw recording of at least 10 strokes) so we can add the device to the pro>

// EXAMPLE ROWER CONFIG : using a Concept 2 RowErg as is
// rowerSettings: rowerProfiles.Concept2_RowErg

rowerSettings: {
...rowerProfiles.Concept2_RowErg,
numOfImpulsesPerRevolution: 8,
flywheelInertia: 0.1001
},

// EXAMPLE ROWER CONFIG: set a rower profile, but overwrite some settings:
// rowerSettings: Object.assign(rowerProfiles.DKN_R320, {
// autoAdjustDragFactor: true
// })
}

[JaapvanEkris]

Hi, John from RowAlong here. Lots of people have been in touch about ORM - so I've started looking at it. I'm having an issue with my development though.

That's why we are here to help you.

Context: I'm building a non-invasive rowing monitor for a Concept2 RowErg using a Waveshare IR reflective sensor pointed at the flywheel's ventilation slot (detecting the 8 fan blades passing, rather than tapping the PM5's own 18V signal) — this is a proof of concept before extending the same approach to other rowing machines. This is my first Raspberry Pi project, so apologies if I've missed something obvious.

That is a neat idea! My own approach of an optopcoupler allowed me to revert s well, but yours is more universal. I like it. Neat little sensor too. We have some experience with optical sensors, so it is doable (see #249 and #182).

Environment:

Raspberry Pi 4 Model B Raspberry Pi OS Lite (Legacy) 64-bit, Debian 12 Bookworm ORM installed via official installer, main branch, version 0.9.7 Sensor:

Pretty standard, looks good.

Waveshare IR Reflective Sensor (digital output via LM393 comparator), wired to GPIO 17 (VCC → pin 1, GND → pin 9, DOUT → pin 11) rowerSettings based on rowerProfiles.Concept2_RowErg with numOfImpulsesPerRevolution: 8 and flywheelInertia: 0.1001 overridden

DOUT is a clean digital signal, so it might not need the pull-up resistor we normally set. So in /boot/firmware/config.txt you could see what happens if gpio=17=pu,ip is changed to gpio=17=ip or even gpio=17=pn,ip

Another likely cullprit is our bounce filter, which is inside gpio. Normally in your config, people use gpioMinimumPulseLength: 50,, but setting it to gpioMinimumPulseLength: 5, might help: the position of the sensor is quite crucial here. If you measure close to the edge of the flywheel, those blades are fast! That is why C2 measures close to the axis. We can handle it, but pulses will be short. Another approach is to invert the signal here by setting gpioTriggeredFlank: 'Up', to gpioTriggeredFlank: 'Down',. Some sensors behave better when using the other flank.

Summary: GPIO impulses are not picked up by ORM's rowing engine unless GpioService is explicitly listed as a key in the loglevel config object — setting only default (to either 'debug' or 'trace') is not sufficient, even though the startup log line (Gpio-service: pin number 17, polling interval 5 us, triggered on Up flank, minimal pulse time 50 us) prints identically either way, and the service reports active (running) with no errors in both cases. Steps to reproduce:

Confirm sensor wiring is correct and hardware-level detection works independently of ORM:

watch -n 0.2 pinctrl get 17 Confirmed: pin reliably toggles hi/lo when the sensor is triggered, in every test below.

With this config:

javascript loglevel: { default: 'debug' }, Restart the service, watch sudo journalctl -u openrowingmonitor -f, trigger the sensor repeatedly. No stroke or impulse activity is logged or reflected in the web dashboard, despite the pin toggling correctly at the hardware level.

Change to:

javascript loglevel: { default: 'trace', GpioService: 'trace' }, Restart, repeat the test. Impulses are picked up correctly — stroke detection, pace, and stroke rate all populate as expected, and a session file is saved on stop.

Revert to step 2's config (removing the GpioService key). Restart, repeat test. Impulse detection stops working again — confirmed reproducible in both directions (worked → removed key → stopped working → re-added key → worked again), across multiple restarts.

Expected behaviour: GPIO impulse detection should function correctly regardless of the loglevel configuration, since logging verbosity shouldn't affect functional behaviour. Actual behaviour: Impulse detection appears to depend on GpioService being explicitly present as a named key in loglevel, suggesting a possible initialisation path tied to per-module logger setup that isn't otherwise triggered. Additional note: during this same session, the GpioTimerService.js process also crashed with Unhandled signal 11 during a service stop/restart cycle — noted in case it's related, though I couldn't reliably reproduce this specific crash on demand.

Weird. Logging should not influence primary behaviour. But its requirements might push stuff over an edge somewhere.

Happy to provide full raw session logs, or test any suggested fix. Config.js is below.

We'll do that if the above doesn't work. I ssuspect a timing thing somewhere. These optical sensors are good and provide a "sharp" signal, where magnets are a bit more messy. Oddly, life becomes complicated when we don't get a messy signal.

rowerSettings: { ...rowerProfiles.Concept2_RowErg, numOfImpulsesPerRevolution: 8, flywheelInertia: 0.1001 },

A good start, also look at minimumTimeBetweenImpulses, as pulses will follow up faster on a 6 magnet signal than on a 8 blade signal. This has some effects on how OpenRowingMonitor behaves.

Please note: force curves will become roughly 125 datapoints. The upcomming FIT-standard for rowing will only accomodate 128 datapoints. So some clipping might occur there.

Regarding flywheel inertia: 0.1001 is a number floating around on the internet. I suspect for a model C. With model D C2 introduced the 12 pole magnet, adding weight to the flywheel, and actually tap into its power to power the PM5. So this suggest the inertia has changed since then. In what, we don't know. We do know that the current value gets us closer to PM5 bahaviour, and we are still getting closer. But we also see some unexplained behaviour from the PM5 (sometimes ORM and a theoretical model agree, and the PM2 which is fed the same signal fails that test somehow). The magnet signal is not perfect for us (might be a disgn choice for C2) and we are compensating for that, but in theory we lose some accuracy. Testing with the upcomming version on theoretical data suggests that this is below 0.1% (this is the same engine as 0.9.7 with very small bugs removed).

[JaapvanEkris]

@Johnedit did you make any progress on this?

[Johnedit]

Hi,I’ve paused this for a couple of weeks while I take a family vacation in Italy.   Will come right back to it when I’m back though.  John. Sent from my iPhoneOn 22 Jul 2026, at 12:25, Jaap van Ekris ***@***.***> wrote: @Johnedit did you make any progress on this? —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>