Using a Merach R28R1 Water Rowing Machine With OpenRowingMonitor

The Merach R28R1 water rower is priced very competitively - currently about £280 in the UK. It offers a good rowing position, and a good range of resistance values. Another big plus for the machine is it's ability to be easily folded up and stowed, something that is simply not possible with most rowing machines.

However the data generated by the rower is beyond useless. It only counts strokes, and assigns a fictitious energy input for each stroke it detects, so trying to use it for even rudimentary fitness workouts is hopeless.

Fortunately there is a github project called OpenRowingMonitor

which is designed to collect rowing data from a variety of different types of rowing machine and present them in a way where you can compare workouts and chart the progress of your fitness. Unfortunately fitting the Menarch R28R1 with OpenRowingMonitor (ORM) proved to be a bit more complex than most rowers ...

The Merach rower has a pull bar connected to a strap which goes over a couple of pulleys, and eventually applies a torque to the water impeller via a clutch. The clutch allows the power stroke to turn the impeller, and then disengages from the impeller to allow the pull bar to return.

As designed, the Merach picks up movement of the pull bar via a magnet on the upper pulley which generates pulses which are sent to the monitor.

On the power part of the stroke, the pulses measure the movement of the impeller, but on the recovery part of the stroke the clutch has disengaged from the impeller, and the pulses do not measure anything of consequence.

ORM requires accurate readings from the actual impeller or rotor of the machine during the power stroke when the impeller is accelerating, and during the recovery part of the stroke when the impeller is decelerating. If you're interested in why, see the docs section of the github project for details. Monitoring the pulley, though easy, was not going to be good enough.

After an examination of the rower I found that the impeller shaft was actually visible on the underside of the rower frame.

Now I had to devise a way to measure the speed of rotation of this shaft.

The plan was to put some kind of mark on the shaft, then detect the mark via some sort of optical sensor then pass that data to ORM,

The first problem is that there is not much space available under the machine. By ruler my estimate is that there is probably 15mm below the bottom plate and the floor. So the sensor and holder, and any wires have to be slimmer than that. The ORM raspberry pi itself will sit somewhere on the side of the machine so that will not be a problem.

I found some miniature sensors - the TCRT5000 - that contain an LED and a photo-diode in a single 5.8 x 8.5 x 10 mm (W x H x D) package. The TCRT5000 comes in two forms, the individual package, or in a module complete with support chips, and a potentiometer to adjust the sensor sensitivity. The module is ready to use, but will not fit easily into the available space. My solution was to buy a TCRT5000 module and a TCRT5000 sensor, cut the integrated sensor from the module, then re-attach the individual sensor to the module via long wires. The sensor will be held in a 3D printed 'sensor cap' and the module will be attached to the side of the pi support box.

The next problem I found was that with a rowing stroke length of 1.1m, I estimated that the impeller would only rotate 6 or 7 times ... so a single mark would only produce 6 or 7 timing marks per stroke. That did not seem to be enough for accurate measurements, and compared poorly to the 50 - 60 that an air rower would generate.

I could try to increase the number of marks on the shaft, but additional marks would have to be accurately placed and equally bright otherwise the timing would be erratic.

The sensor cap was designed to be a push fit over the boss on the underside of the rower. You could secure it with glue if you wished, but I found it was not necessary. Cutouts were made to hold the TCRT5000 sensor and it's wires. The sensor is glued in place with cyanoacrylate glue, but care should be taken to allow the glue fumes to dissipate ! I lost one set of components due to glue-fume-fogging on the sensor. I found that making sure the glue dried when the sensor was face upwards helped.

The top of the sensor LED's should only protrude 0.5 - 1 mm above the sensor cap. This is important as the distance from the top of the sensor LED's and the marker plate should be ~ 3 mm. If it is less than this the illuminator LED will be too bright, and the sensor LED may not be able to distinguish the marks.

I wire-wrapped the flying wires onto the sensor, then carefully bent the wires to lie in the channels. It's a bit of a tight fit, but with needle pliers, and a small screwdriver the results were good. I finished the back of the sensor with a piece of gaffer tape ! Make careful note of the wire colours you use as the wires need to go to the equivalent locations on the module. The flying wires can be made into a twisted loom then attached to the module.

If you are struggling to get the sensor and the wires into the sensor cap please contact me and I can send you the Freecad design files for the sensor cap - you can then adjust the channels to your preference.

The marker plate provides a simple way to put a number of equal sized and spaced marks onto something which can be attached to the end of the impeller shaft.

Initially I experimented with printing a paper disc, but after trying plain, matte inkjet and glossy inkjet paper I could not get this to work at all.

So I eventually turned to 3D printing a thin disc, with indentations at the marker points. I painted the markers with white Tipex, then carefully painted the remaining parts of the disc with matt black enamel. Care needed to be taken to make the edges of the marks clear and distinct. The end result was just about OK (I'm the worlds worst painter ...).

I used 3 marks and I think I could have used 4 ... But my design for the sensor cap will not allow for more than 4 marks. The problem is that I mounted the optical sensor tangentially to the movement of the impeller shaft ... This makes the sensor detection zone quite large. I think that if I had mounted the sensor radially with respect to the movement of the impeller shaft the detection zone would be much smaller and I could have used more marks on the marker plate. Something to think about for V2.0 ...

Finally the marker plate is glued to the impeller shaft. I found that cyanoacrylate was not a good choice for this, and used some 3M 'VHB' tape that I glued to the disc, then carefully cut to size before pressing the disc onto the shaft. As the shaft sits in a recess, and the marker disc is a close fit inside the recess, the centre of the marker disc will align closely with the centre of the shaft.

ORM runs on a Pi - typically a model 3 or 4. I happened to have a 'spare' 4Gb model 4 so I re-used that one.

I designed a box that would hold the pi inside it's normal case on the rower frame, requiring two M4 hex nuts and bolts to secure it.

The box also contains a small hutch on the side which houses the TCRT5000 support module.

During the next few steps you will probably have to spend some time looking and fiddling with the underside of the rower.

When I did this I was acutely aware that if the upper track chose to unhinge I would probably loose my head ! I used bungee cords to make sure that the upper track would not crash down on me whilst I was working, and would suggest that you will need to do something similar.

I actually built a rig to test the optical sensor. I'm glad that I did as it taught me much about how the sensor works.

Basically the TCRT5000 consists of a 'illuminator' LED which provides infra-red light, and a photo-diode 'sensor' which conducts when it detects (enough) photons. The output level of the sensor is passed to a comparator which uses a reference signal from the module potentiometer and if the signal is strong enough, the comparator drives the digital output to ground.

Note that the comparator output is pulled up to the Vcc used to drive the module, so you MUST use 3V3 as Vcc to drive the module, otherwise you will 'fry' the GPIO pin on your Pi.

This sounds very good, but the problem I found was that because the marker plate and the sensor are placed very close together the illuminator LED can overwhelm the sensor, so that the sensor detects 'white' all of the time.

I'm quite lucky as I have an oscilloscope so I could actually see what the problem was, but I will try to explain what happens so you should be able to fix the problem with a multi meter (and a bit of luck).

If you refer to the 'scope trace above, the upper trace is from the analogue sensor signal on the module (pin A0), the lower trace is from the digital output pin (pin D0) whilst a motor drove the marker disc past the TCRT5000. This trace was made from a single marker spot on my test rig, so please ignore the timing and the duty cycle of the signal.

The upper trace shows a good signal with an excellent range. 'Black' is high voltage, in this case ~2.2V. 'White' is low voltage or about 0.4V.

If the LED is overwhelming the sensor, the analogue output would be a straight line at about 0.5V.

If you need to check this with a multi meter, set the meter to DC, Volts, and a scale that will read about 5V. You need to connect the meter between GND and the A0 pin on the module, then move the impeller slowly to see if the voltage fluctuates. If it does change, adjust the impeller to a position where the signal is highest and measure that. That should be the 'Black' voltage. It must be at least 2V for correct operation.

If you have a 'Black' level of more than 2V, check the 'White' level by gently moving the impeller until the signal drops. You need to have a 'White' level of less than 1V. If your voltages are within spec, you can skip to the next section.

If the voltage on pin A0 does not fluctuate, you will need to adjust the LED brightness. Note that adjusting the module potentiometer at this stage is pointless as there is no analogue signal for it to detect.

The easiest way to adjust the LED brightness is to add a ballast resistor to the LED supply. How large ? Well I tested my setup by putting a potentiometer in series with the LED and adjusting it to see what happened. I found that 75 Ω was about the sweet spot. So I wired in a 75 Ω 1/4 watt resistor in series with the LED supply, and then found that my 'Black' level was just over 2V. My guess is that if your sensor is carefully positioned in the sensor cap, and if you have used good contrasting paints on the marker disc, that 50 - 100 Ω should work.

Finally you should check to see that the digital output on pin D0 is also pulsing correctly. If you have a good signal range on pin A0, I think that the standard module potentiometer setting (about mid range) will be fine.

The first step is to assemble the sensor cap, the TCRT5000 sensor, the wiring loom and the sensor module.

Then glue the marker disc onto the end of the impeller shaft.

Then mark and drill the holes in the frame to mount the Pi box.

Then attach the module to the Pi box

Then attach the Pi box to the frame using M4 nuts and bolts

Then feed the sensor cap through the frame, and push the sensor cap onto the boss.

I secured my wires with gaffer tape (a job's not complete until the gaffer tape comes out ...)

Then drop the rower into it's normal orientation

I re-imaged a 32 Gb mircoSD card for the Pi, I used 64bit 'Bullseye' as my os, but I'd recommend you read the ORM install instructions before you start.

Once the base OS is in place, ORM has it's own install script which basically does everything else.

I made up a short lead with female break-out connectors at one end to attach to the Pi GPIO connector, and a 3 pin female Dupont connector at the other to attach to the sensor module. Note that we only need 3 pins, Vcc (3V3 remember !), GND, and a suitable input GPIO for pin D0. The module analogue signal pin A0 should only be used for testing.

Finally put the Pi into the Pi box, attach the lead to the sensor module, and apply power to the Pi ...

Once the Pi has been built with the software the next step is to try rowing !

I am not planning to describe all of the software setup for ORM ... the project docs/ files do a very good job of that. But I will describe what changes I made and why.

The configuration that I use for my rower looks like this ... this section is added to config/rowerProfiles.js.

The upper section contains parameters that are largely obvious ... The lower section is complete with comments that provide a little more background on the settings.

If you now row a few strokes and collect the raw csv data you can draw a simple plot of (delta t between impulses) and (impulse number). See the chart above.

The drive part of the stroke can be seen as the downward part of the curve. Downwards because the impeller is accelerating, and the time between impulses will be decreasing.

The recovery part of the stroke can be seen as the upwards part of the curve showing the impeller to be decelerating.

But what is causing the 'steps' in the data ?

I think this is due to my inaccuracy in painting my marker disc. The steps are suspiciously repeated in groups of three ...

Does it matter ? Well yes and no. No because the ORM software contains a sophisticated filtering technique which is referred to as the CyclicErrorCorrector which seems to clean up the data considerably.

Yes because I think the jitter in the data prevents me from running the autoAdjustRecoverySlope parameter. I think I would like to use this technique but switching it on results in a lot of warning messages in the log as ORM looks to determine the start and end of the drive and recovery portions of the stroke.

The flywheelInertia parameter is currently still somewhat of a guess. I have tried to calibrate it by measuring the peak force applied to the pull handle and comparing that to the peak force as reported by ORM, and they are in reasonable agreement, but this also depends on the other ORM parameters being correct.

It's also worth remembering that flywheelInertia is directly dependent on the water level in the rower. Change the water level to change the resistance, and you will change the flywheelInertia.

I would like to say a heartfelt 'Thank you' to the guys at OpenrowingMonitor. As well as actually writing and releasing the software they helped me enormously to come up with my solution.