There Was a previou version pretty much burnt to the ground and restarted - you may find some dangling references to it - sorry!
Hardware: Fitting 60-pulse/rotation sensor; worst (best!) case PEAK sample rate with safety margin ~ 1 kHz in a hard drive - maybe 500-700Hz realy. Gives WaterRower's heavy flywheel but high samples/rotation sample rate equal or better to Concept2 with much faster flywheel but fewer samples/rotation. Firmware: Using MCPWN to capture pulses with 80MHz / 12.5 nanosecond accuracy (pulse is time-stamped in hardware) then high priority ISR transfers this to ring-buffer. So when main physics process reads it there is latency question on how fast we process it but NO issue with time stamping the sample. Latency should be a few milliseconds but even major BLE-brownout won't affect time-stamping Smoothing/Determing angular velocity & acceleration Need to reduce processor load. Sample frequency varies but pulse represent constant delta-theta rotation. With fixed interval can use Savitsky-Golay smoothing turning regression into pre-computed sum-product. Current choice is 11-sample window (+/-5 either side of current sample) adding 5-sample lag in calculation which is acceptable for short pulse-length. This leaves smoothed data in angular rotation domain, not time-domain, so chain-rule convert into time-based speed/acceleration (2nd Savitsky-Golay coefficient is smoothed point-acceleration too). Experimentally, processing time per sample is ~40 microseconds on single 160Mhz core; 1kHz sample rate = ~ 4% processoing power
RowBot: Take a 25-year old Series II(C) UK WaterRower and add an updated sensor package and bluetooth comms module
A cherry wood classic WaterRower is a thing of beauty, and well made, which is why it has lasted me 25-years and will probably still be going strong when I am gone. It has had some TLC - refurbed water tank, new return-stroke bungee, new rails - which is fair enough
But the old Series 3 monitor was pretty basic - it basically just detects a moving average stroke rate and estimates all the other UI data from that. Not really up to scratch 2 1/2 decades on. And has died on me. (Apparently some small electrolytic capacitiors on the board tend to fail, so that it a likely cause, but nursing it back to life would still leave me with the old monitor)
The Series 4 monitor - standard nowadays - has a high-resolution encoder disk on the main shaft, which gives much more information - but is a significant retro-fit for an old machine (requiring a new top deck as well as the sensors, a new monitor and - if you want it any why wouldn't you - a bluetooth module) which along with return-to-factory for fitting would cost ~ £350. Surely a tinkering engineer can do better. I've given my self a £50 budget
Anyway, welcome to my emotional support Git
Plan for this project is to add high resolution encode/sensor linked to a bluetooth black box that handles sensor reading, rowing physics and BLE Bluetooth transmission of rowing metrics to a phone/tablet monitor, hopefully using one of the standard rowing apps
There are some brilliant projects on GitHub which are huge help (OpenRowingMonitor especially) which as ever huge thanks are due for sharing (see credits section)
I am building this on a Firebeetle 2 ESP32-C6 because it us a low power consumption chip that none-the-less has some good on-board signal processing hardware letting me shift some of the time-critical functions away from the main core. I've made good progress on the firmware, but sorting out the new optical encoder sensor is taking some time, so we are stilling running on some fairly basic simulated data injected into the GPIO. Hopefully the physics will still work well when we have real data
The firmware is being written with the help of ClaudeCode; this project would not exist without it. I haven't done any C/C++ programming for ~30 years and never for a microcontroller with the awesome power of a £5 chip today.
Anyway I hope you find it useful or interesting
What you will find here is:
- /docs: my notes on the project, somewhat coherent, orgaanised by topics, tracking my thinking/rough design
- /lib: core physics engine
- /spec: software design, decision etc (record + 'SDD' interface with ClaudeCode)
- /src: firmware infrastructure - BLE, GPIO, MCPWM etc
- /tools: a few Pyton utilities for testing etc from the laptop side of things
Where we are:
- Precise system dimensions: bought OEM sensor disc; sensor location will be based on that in place
- Physical sensor: found OEM opto-encoder on Ebay, for far less than the custom laser-cut was going to cost, so bought that
- Sensor electronics: Dependent on opto-encoder, so updating desing; cutting out inline signal improvement; ESP32-C6 does it better
- Microcontroller: Firebeetle 2 ESP32-C6 IoT Dev running on desktop
- Software: IDE set up, signal read, physics engine done; working on BLE
- Housing: not started
- Phone mount: simple 1/4"-20 UNC threaded nut insert on chassis (the standard camera/phone holder mount)
- Immitate the offical retro-fit - a high(er)-resolution encoder wheel attached to the main shaft + optical interuption sensor reading it
- Linked to new micro-controller on the rower, turning sensor data in real-time paddle speed/accelation, and running rowing physics model
- Algorithmic estimation of speed, energy etc along with distance, splits etc
- Generate power curve from detailed data (really hoping for live 'ECG'-style output)
- Bluetooth link using fitness industry standard GATT profiles to link with 3rd party/open source rowing apps on phones/tablets
- Battery power for wireless use
- Mount for mobile phone monitor
- Preferably just a black box, but what needed for on/off or more that FTMS can't handle?
- Microcontrollers are amazingly cheap; the single most expensive parts could be (1) the battery and (2) the encoder wheel, or other random parts
- Set an initial budget goal of < £50
Key steps would seem to be:
-
Investigation of the existing rower:
- Removal of top deck to access rower existing sensor, attachment point for new hardware; also removal of existing Series 3 Monitor (requires top deck removal)
- Checking state of existing sensor (believe to be a reed switch) tripped by a magnet on a secondary small pulley). I am rather assumnig it will need to be removed but if not it might make a good cross-check on a new sensor
- Precise measurement of the existing paddle spindel and mapping the vertical and horizontal space available for a new sensor (as I understand it, WaterRowers of this era used American manufacture parts in Imperial measures and the main shaft is likely 1" diameter, while current European WaterRowers have gone metric and likely to be 25mm)
-
Design of new sensor
- What kind of sensor and encoder disk to use (opto-interuptions, reflective, magnetic...)
- Size of disc and mounting on shaft, and hardware fitting (for example the official update has a routed channel in the underside of the top deck for sensor wires)
- Sensor power/voltage requirements and matching to microcontroller (and connection)
-
Hardware design of new microcontroller
- Choice of microcontroller hardware
- Power for microcontroller (and recharging)
- On-board interface/display (if any)
-
Firmware for new microcontroller:
- Software requirements - especially processor/RAM/IO feeding back into hardware selection
- Programming language and development stack
- Software components: sensor IO, rower data conversion, bluetooth interface
- Compatibility with 3rd party rowing apps
-
Housing and phone/monitor holder
- Re-purposing redundant tablet and permanent display/interface
- Phone/monitor simple attachment point for standard phone/camera tripod holder
- Houseing for electronics mounted on rower chasis
V.H. 10/7/26