Pro-Form Wave 500

[KjellVerb]

Here I will briefly document the process of the ORM-ification of my indoor rower. I will provide some background into my decision-making and modifications so I hope this can serve as general inspiration for others wanting to go through this process on a previously undocumented rower.

Experience level and motivation:
I've only been rowing for 4 sessions in two weeks, never done it before that. I need a lower-impact cardio training to supplement my running because I have overloaded my ankles and knees over the last months.
Just adding this for context of why I may use incorrect rowing terminology and why I can't just compare my power levels to previous effort levels or such.

My rower:
I bought one secondhand for €100 to dip my toes in the water before diving in and buying a Concept2 (which go for at least 5x more on the secondhand marked here). It's a Pro-Form Wave 500. Having nothing to compare against, I find it a good beginner machine. It feels quite high in resistance from the lowest level (based on visual comparison of videos), the endpoint of the bar is maybe slighly too close for my long arms and there is no connectivity. Other than that no complaints!

Motivation for using ORM

• I want to use my Coros sports watch to record more metrics of my session than just the built-in stroke- and heart rate.
• The machine's stats seem way off: 14min/500m during a rather high intensity row.

[KjellVerb]

Internals

After opening up the machine, these are my findings:

In terms of mechanics, there is a pulley that is connected via a belt and freewheel sprocket to a flywheel. The flywheel has a mechanical brake inside of it that is controlled by a motor.

It uses a rather unconventional sensor setup as far as I can tell:

• a reed contact under the seat
• four magnets on the drive pulley which pass by two reed contacts. I assume to detect the direction of the drive pulley by checking which one triggers first.

There is nothing on the flywheel that I can tap into so I will have to create my own sensor setup.

Modifications
In order to uniformly space the magnets I 3D printed a shell to slide over the flywheel. It has a slit at one point so that I could maneuver it in place without removing the flywheel. I then taped it in place just for some added security.
I chose 8 magnets because I thought more magnets would give more resolution. I can always remove some to step back to 2 or 4 if this makes the intervals too small.

I chose to use a hall-effect sensor, because it provides perfectly clean edges (and I had one laying around anyway).
A couple of modifications to the module were done:

• Added a 100nF capacitor between VCC and GND to filter supply noise for stable operation.
• Removed the on-board LED and series resistor because it would pull the high level of the sense pin too high for a RPi input when supplying 5V to the module
• Added a resistive divider to provide a 3.3V(-ish) signal to the RPi. I chose a 3.3k pull-up (between sense and VCC) and a 1.8k pull-down (between sense and GND). The sum of the values is not too high so that the rising edges are sufficiently fast.

I 3D printed a bracket to mount the sensor in the right spot to pick up the magnets and now I have a working sensor setup for ORM without any permanent modifications to the rower.

[KjellVerb]

Initial ORM setup
I used Raspberry Pi Imager to flash my SD card, following the guide. This way I ended up with the latest Raspberry Pi OS Lite. I did not know that the laberning fork does not support bookworm so that caused some issues with the install script, specifically because it uses a python version >3.10 that causes npm to error out somewhere. First I took a detour installing the correct python version and forcing npm to use it, but eventually I found the JaapvanEkris fork and with that install script everything went smoothly.

The next issue was that my ORM was not discoverable via bluetooth. I quickly discovered that the bluetooth service was not running and also not set to run at boot. sudo systemctl bluetooth start solved that and sudo systemctl enable bluetooth made sure it would be started after every boot.

Then I started adapting the ORM config.js

• set gpioTriggeredFlank: 'Down', the sensor has an Open Drain configuration so the falling edge is faster and cleaner than the rising edge.
• numOfImpulsesPerRevolution: 8 because that's how many magnets I put on the flywheel
• createRawDataFiles: true because I want to see whether my sensor provides clean measurements.

I logged 10 strokes and collected the raw data (2024-10-25_18-32-01_raw.xlsx). Looks like there is a bit of noise but overall this signal is very clean and seems perfectly usable.

Further investigation will follow for correct settings. As I have no reference to calibrate against and I'm not super eager to take out the whole flywheel assembly for measuring the inertia, I don't know yet how I will tackle this.

[KjellVerb]

Feel free to tag me in any electronics hardware related questions!

[Gordon-Shumway2]

Most likely your magnets are not polarity-aligned (see (#87)). Hall sensors can be biased towards one pole regarding detection of polarity. When approaching the N side of a N-S magnet they will trigger slightly earlier than when approaching the S side (and vice versa). This is different from reed switches which will trigger regardless of the magnet's polarity.

Make sure that all your magnets face either N or S when approaching the sensor. You can detect polarity with your fingers: use another magnet and slowly approach each of your eight magnets from the direction that the sensor would approach them. You will feel either a pulling or pushing motion. Align magnets so that all magnets create the same motion.

[JaapvanEkris]

Feel free to tag me in any electronics hardware related questions!

Welcome to the group! Are you using https://github.com/JaapvanEkris/openrowingmonitor ? The version in that branch about 3 years ahead of the current main here, and has shown to be more robust against the noise you experience.

[KjellVerb]

I am indeed, but only by chance because that one works in bookworm while this branch doesn't. I was a bit confused by the two branches and didn't know where to post.

[KjellVerb]

Most likely your magnets are not polarity-aligned (see (#87)). Hall sensors can be biased towards one pole regarding detection of polarity.

I have an OH44E sensor which is unipolar so I made sure to check the magnet polarities. This type would not even trigger on a magnet with the wrong pole up.
I guess it's due to some wobble or something else outside of my control. The filtering seems to work well and the metrics are all stable so I'm not that worried.

[KjellVerb]

Calibrating flywheel inertia

After multiple guesses, I arrived to the conclusion that the inertia should be around 0.03 to 0.05 for realistic rowing data. As stated before I have no rowing experience nor access to a concept2, so fine tuning the inertia value by rowing metrics is not a viable option. Unfortunately that means disassembling the flywheel.

First I took out the entire flywheel and brake assembly and tried the method described in #113, without success. After an all-nighter I decided to give up, reassemble the machine and go to bed at (3:30).
The next day I decided that I wouldn't give up after all. I would go all or nothing and eventually I found a new method. This required even further disassembly of the flywheel unit. I also discovered that it brakes magnetically after all, and the motorized drag setting mechanism changes the distance between the magnets and the inner rim of the flywheel.

I weighed the flywheel and measured the dimensions as accurately as possible (this time without the brake assemby it was below 5kg so my kitchen scales handled it). Then I took those measurements and drew the flywheel in Fusion360. I set the material to cast iron (lucky guess) and initially the mass was only off by 18g. I tuned the model a little until the mass matched (by removing some material in the model where the bearings are on the flywheel, because I assumed the bearings would be less dense than the rest of the wheel). Then in the properties window it states that the Izz is equal to 4.206e7 g*mm² or 0.04206 kg*m².

Now I will take some time to reassemble the machine and give it a try!

[KjellVerb]

The exact material does not matter at all as long as every part of your drawing is made of only one material of uniform density. If you can then tweak the density to match the weight, the inertia will calculate to the same value even if you selected water as a material or whatever.
What was the inertia that F360 ended up with and how does it compare to your experience with the machine?

[Abasz]

The C2 flywheel inertia (model C/D) has an inertia of 0.1001

Yes, but this is a copy, probably reverse engineered based on measurements. It does not go through the same rigorous quality checks as C2 rowergs, so I expect that the inertia of the flywheel in it will not match the C2.

The exact material does not matter at all as long as every part of your drawing is made of only one material of uniform density. If you can then tweak the density to match the weight, the inertia will calculate to the same value even if you selected water as a material or whatever.

I was expecting this. Yes, I have different components for the different materials in F360.

What was the inertia that F360 ended up with and how does it compare to your experience with the machine?

So I was testing 0.07806. The new proposed value is 0.07848.

My calibration method is that I do a 200m-2000m-200m pyramid and a (5x100m+500m)x2 + 1000m on both machines with max effort (with a few days apart for sufficient recovery). I record the splits with my watch and check the split's avg power in Garmin Connect for both. For example these are the Sprints + 500 results on the two machines with 0.07806 inertial on the generic (original). The third column is wit the new inertia value.

Dist	generic (original)	C2	generic (new, 0.07848)
100m	265	363	310
100m	261	334	311
100m	270	328	326
100m	259	320	297
100m	269	330	325
500m	261	296	271
100m	281	317	323
100m	278	355	323
100m	290	332	332
100m	268	tainted data	304
100m	245	tainted data	292
500m	232	295	246
1000m	192	228	197

On the sprints it looks good (but those are only like 11-12 strokes, so its plausible that there is a potential difference on the two machines, if for instance my start is not with a mostly stationary flywheel), on longer distances my rower seems to be still a bit behind with the new inertia. But the shape of the blades is difficult to get right (though I used a picture of it to copy) and there could be scale precision, my caliper etc. So there is still room for error.

Not to mention that such comparison excersize may not be fully comparable (for instance my shock cord is a little stronger than on the C2, and bearings for the pulley are smoother on the C2 as well, which means less resistance that cannot be measured, not to mention that my avg HR for the last 500 and 1000 on my generic rower was 10-15bpm less than on the C2 which indicates less effort...). Also rerunning the splits with the new inertia in simulation mode may not line up properly with the splits recorded by the watch (I need to match those manually based on the stroke avg power).

Any way, purely looking at the split avg power, I would need 0.085 to have the first set to mostly align (i.e. first 5x00m and the first 500m). But to have the same power for the second half I would need 0.09. which would over shoot the first.

These are quite significantly bigger inertia values than the one I modelled. I double checked the measurements and the weight with two scales (unfortunately only kitchen weigh...) and they seem to check out I only slightly changed the model and now its at 0.07848.

[KjellVerb]

Nice to see that the F360 method seems to yield a result that could be correct or close to it.
I think looking at your HR that the lower powers on your machine are probably plausible.

For me personally I don't mind being off of my real physical effort by a couple percent, in the foreseeable future I will only ever train on my own machine so as long as the ORM results are consistent then I can track my progress. If ever I upgrade to a C2, it might be nice or disappointing to find out how much over- or underestimation there was :-)

Obviously at the same time it is a fun side-hobby to try and optimize the parameters for the best accuracy possible!

[JaapvanEkris]

The C2 flywheel inertia (model C/D) has an inertia of 0.1001

Yes, but this is a copy, probably reverse engineered based on measurements. It does not go through the same rigorous quality checks as C2 rowergs, so I expect that the inertia of the flywheel in it will not match the C2.

It won't. Inertia is also based on placement of heavy parts (see Dave Vernooy's approach, see https://dvernooy.github.io/projects/ergware/). So using a different material ring will change the whole inertia as well.

Not to mention that such comparison excersize may not be fully comparable (for instance my shock cord is a little stronger than on the C2, and bearings for the pulley are smoother on the C2 as well, which means less resistance that cannot be measured, not to mention that my avg HR for the last 500 and 1000 on my generic rower was 10-15bpm less than on the C2 which indicates less effort...). Also rerunning the splits with the new inertia in simulation mode may not line up properly with the splits recorded by the watch (I need to match those manually based on the stroke avg power).

I have some issues as well on an original C2, although significantly smaller. I am currently calibrating at DF145 to DF150. My Flywheel Inertia seems to be around 0,1012. Some practical observations:

• I try to stabilize the absolute error across multiple distances. So I take the absolute deviation across a 5K, 10K and 21K, and see how it behaves across several of these sessions. Currently, directly compared to a C2 getting identical data, I am within 0,5 sec on all distances. Issue seems to be that it is a significant constant across all distances. I currently am running tests of ignoring the first drive, which reduces the absolute error, but it isn't perfect yet.
• I see that the error isn't consistent across various dragfactors. It seems to be bigger on lower dragfactors.

I have double checked the dragfactor calculation, and I even created an alternative version of it to see if it deviates much, but it seems to be something C2 might be struggling with, and not us. But I have to run official tests to make sure (I want to record the dragfactor consistency and its average GoodnessOfFit).

These are quite significantly bigger inertia values than the one I modelled. I double checked the measurements and the weight with two scales (unfortunately only kitchen weigh...) and they seem to check out I only slightly changed the model and now its at 0.07848.

Have you tried Dave Vernooij's other approach: swinging the flywheel?

[Abasz]

I have some issues as well on an original C2, although significantly smaller. I am currently calibrating at DF145 to DF150. My Flywheel Inertia seems to be around 0,1012. Some practical observations:

Actually if you believe that ORM more accurate and robust than the approach of C2, I would not expect match. In the past you have concluded that C2 ends the drive a bit early because it is not detecting the force but rather the flywheel acceleration (or the lack of it). This means that some small amount of drive gets into the recovery and hence the drag factor. If so, this means that the drag factor will be underestimated and essentially not accurate.

The same applies when for the catch where it is possible that some drive gets into the recovery reducing the slope, and the DF that distorts the metrics.

Have you tried Dave Vernooij's other approach: swinging the flywheel?

I understand the swinging but I think there is just too much room for error. I think fusion model and calculation should yield a much more precise number.

[Abasz]

@KjellVerb Quick question on the hall sensor: in unipolar sensors if you use the other pole of the magnet at the back it will switch. So basically you can do either north or south but you need orient the sensor to the magnets.

My question is does this impact switching speed or switching accuracy? I know that generally one should use the "front" (with the text).

[KjellVerb]

Good question, I did not test it but theoretically there should be no difference if all other parameters (magnet strength, mounting distance,...) are identical.
I used the side that would give me the best/easiest mounting method and flipped the magnets to the correct orientation for that side of the sensor, without further consideration.