Building my own PM

[Daniele_Redivo]

Hello,
I recently bought a used model B for 100 euro. I had to change the chain and I added aftermarket flexfoot. The thing came without PM display, so I am building my onw. So far I succeeded in measuring the wheel speed (in Hertz), acceleration, max force per stroke, stroke per min and other stuff. What I am still missing is the conversion between Hertz and minutes/500m.
Does anybody know how many wheel revolutions are needed to cover 500m on model B?

[Nomath]

There is no simple proportionality between flywheel revolutions and distance. The distance also depends on the drag factor setting and on the inertia of the flywheel.
The formulas you should use are :
- power [W] : P = C * ω³ + ω * J * dω/dt ; C is the drag coefficient, in [kg m²] ; J is the moment of inertia flywheel, in [kg m²]
- distance D [m] = time [s] * (P/2.8)^(1/3)
- angular velocity ω = frequency/(2π) ; frequency in Hz

You can determine the drag coefficient by measuring the drop in angular velocity (or frequency) of the flywheel when there is no power input ; a convenient observation period is about 3 sec after the drive. It follows from the above formula that : d(1/ω) = C/J
I believe the moment of inertia of the model B is the same as for the models C/D/E : 0.100 [kg m²], but others on this forum may have better knowledge.

See viewtopic.php?f=7&t=194719

[JaapvanE]

The thing came without PM display, so I am building my onw. So far I succeeded in measuring the wheel speed (in Hertz), acceleration, max force per stroke, stroke per min and other stuff. What I am still missing is the conversion between Hertz and minutes/500m.

There is an Open Source alternative for the PM5: Open Rowing Monitor. We validated it against a PM5 on 3 RowErg's in over 3000K of rowing and our deviation is structurally within 0.05% of the PM5 results. It also provides all functionality of the PM including Bluetooth and ANT+ support, except complex workouts (still a work in progress). We haven't got the exact settings for the Model B yet, although most variables are known (i.e. 3 magnets and an Inertia of 0.1001 as I remember correctly).

But, when you use a Raspberry Pi, 7 inch touchscreen and an ABS case, you probably end up above $180 with current prices, which is the cost of a new PM5 that should work on a Model B. See https://www.concept2.com/service/indoor ... /retrofits

Disclaimer: I am one of the developersof Open Rowing Monitor, so I'm a bit biased.

[Nomath]

You can determine the drag coefficient by measuring the drop in angular velocity (or frequency) of the flywheel when there is no power input ; a convenient observation period is about 3 sec after the drive. It follows from the above formula that : d(1/ω) = C/J

Sorry for a mistake that I can no longer edit. The correct formula is : d(1/ω)/dt = C/J

[JaapvanE]

Sorry for a mistake that I can no longer edit. The correct formula is : d(1/ω)/dt = C/J

<Off topic>
Although technically correct, it is also the least robust approach to dragfactor calculation. A much more robust approach is measuring the time between impulses and plot it against total time, and use Linear Regression to determine the slope of that line (see https://github.com/JaapvanEkris/openrow ... monitor.md for the underlying physics and nicer formula's).

then dragfactor k = slope * (FlywheelInertia * NumberOfMagnets) / (2 * pi)

When the Linear Regression algorithm is chosen well it is rock solid. A simple algorithm like OLS already has provided ORM with very good results, even on machines with 1 or 2 magnets per flywheel rotation. If needed a more robust Theil-Senn regressor might yield better results, but having around 100 datapoints should kill any outliers providing stroke detection is decent.
<End off topic>

[Nomath]

If you look carefully what d(1/ω)/dt means and how you measure it, you will see that boils down to a (linear) regression of the pulse intervals or rotation periods of the flywheel versus time.
Otherwise, look at the graphs in viewtopic.php?f=7&t=194719#p523634 . I believe you copied that.

[JaapvanE]

If you look carefully what d(1/ω)/dt means and how you measure it, you will see that boils down to a (linear) regression of the pulse intervals or rotation periods of the flywheel versus time.

Yes and no. It isn't that blindingly obvious to most. Anu Dudhia suggests using this formula for the entire recovery phase, which suggests a simple slope calculation based on a simple slope = delta y / delta x. However, as some flanks of the drive might be included, that approach isn't robust against that kind of noise. Dave Vernooy used a different approach by calculating the slope once per rotation and then average it across all measurements. A bit more robust, but still not stable enough. Only applying regression analysis will provide a sufficiently stable dragfactor.

Otherwise, look at the graphs in viewtopic.php?f=7&t=194719#p523634 . I believe you copied that.

Yes, still impressed by the results of that approach, as it can take quite a beating as well on non-C2 machines.

[Daniele_Redivo]

thanks for your answers, very interesting. I have to say one thing about my erg: it must be a model B produced on licence, not directly by Concept2. It just says "Rowning" on the bar below the seat, "Concept2" does not appear anywhere. Furthermore it came without any monitor nor magnets on the flywheel. So I added an inductive pickup, which detects the passing of the 8 blades on the flywheel. Inductive pickups does not require any magnet.
This is the current status of my project. I used ESP8266 as controller.

[JaapvanE]

thanks for your answers, very interesting. I have to say one thing about my erg: it must be a model B produced on licence, not directly by Concept2. It just says "Rowning" on the bar below the seat, "Concept2" does not appear anywhere. Furthermore it came without any monitor nor magnets on the flywheel. So I added an inductive pickup, which detects the passing of the 8 blades on the flywheel. Inductive pickups does not require any magnet.
This is the current status of my project. I used ESP8266 as controller.

Cool. An alternative might be to switch to our sister project that ports our Java-based code to the ESP32: https://github.com/Abasz/ESPRowingMonitor

Their lead developer is a great guy (he does a lot for the Java version of ORM as well), and they typically are only a couple of steps behind ORM in terms of functionality.

[Abasz]

Hi, thanks Jaap for the note.

On the ESPRowingMonitor: ESP8266 may not have the juice to run an 8 impulse Theil Sen regressor. It has only a max 160Mhz CPU.

Generally my experience is that 2 -2.5 turns of flanklength (the number of datapoints that are looked at on each rotation) is necessary for reliable results. That means calculations with approx 16-20 datapoints per rotation.

The ESP32 I used has 240Mzh (it is dual core, but the algorithm code uses only one thread) and currently the code takes approx. 10 milliseconds for a 16 datapoint calculation to complete with using double type precision (and 6.5 milliseconds if float precision is used). This it self is an issue as this is an eternity already with 240Mhz machine and you are not running anything else (no gui, no serial, no wifi, nothing)

But the bigger problem is that this is longer than the time between two consecutive impulses on an air rower with 8 impulses per rotation.

I am not saying that my code is super efficient and probbaly a few ms can be shaved off, but that will not help anyway

[Carl Watts]

Interesting conversation from a technical perspective.

Reminds me of how the 1984 arcade game Robotron ran on a 1Mhz Motorola 6809 micro with like 64k of RAM and yet the MAME emulator running on a 266Mhz Pentium II with like 512M of ram in 2000 was not fast enough and now got it running on a quad core.

The Concept 2 PM2 only uses a Phillips 8051 based micro, I think the crystal is 4.3Mhz, had to replace them a few times but never actually measured the frequency.

Don't really know the first thing about coding, always been a bit of a hardware guy but personally I wouldn't bother to make a PM. I did in a way remake ten of the PM2 monitors, a guy in the UK had the boards made and I just transferred a good micro and all the components over.

[JaapvanE]

Hi, thanks Jaap for the note.

Your welcome, and credit where credit is due

On the ESPRowingMonitor: ESP8266 may not have the juice to run an 8 impulse Theil Sen regressor. It has only a max 160Mhz CPU.

Generally my experience is that 2 -2.5 turns of flanklength (the number of datapoints that are looked at on each rotation) is necessary for reliable results. That means calculations with approx 16-20 datapoints per rotation.

In general I'd agree with you, as the two rotation is needed to weed out production variation in magnet placement (or seemingly deliberate design constructs like on the C2 RowErg). But when you can assume the placement is near-perfect, a lot less pulses are needed. When you are actually measuring the blades passing by, these could have near-perfect placement. And then 4 to 5 pulses for flanklength might be all you need.

Unfortunatly, I haven't encountered a machine with near-perfect placement yet, so it is uncharted territories how low you can take the flanklength for real and get good results.

The ESP32 I used has 240Mzh (it is dual core, but the algorithm code uses only one thread) and currently the code takes approx. 10 milliseconds for a 16 datapoint calculation to complete with using double type precision (and 6.5 milliseconds if float precision is used). This it self is an issue as this is an eternity already with 240Mhz machine and you are not running anything else (no gui, no serial, no wifi, nothing)

But the bigger problem is that this is longer than the time between two consecutive impulses on an air rower with 8 impulses per rotation.

I have to agree with you on that one, a RowErg with 6 pulses per rotation goes down to 0.006 sec per pulse. So with 8 blades, you'd go down to 0.004 sec between pulses. That is pretty fast.

The big CPU consumer is the regression algorithm used for determining angular velocity and acceleration. It behaves O(n^2) to O(n^3), so it is quite vulnerable to bigger flanklengths: doubling flanklength typically quadruples the CPU time it needs (or worse). The rest is childsplay compared to that, and scales linear. Played with it on the Pi to see if 24 datapoints would get ORM into trouble, but that was on a dedicated CPU at 1.8GHz.

So "fitting" it on a light CPU depends on the possibility to reduce the flanklength significantly, which really depends on the mechanical and magnetic spacing of the flywheel blades.

I am not saying that my code is super efficient and probbaly a few ms can be shaved off, but that will not help anyway

It is the Theil-Senn regressor that kills your performance, especially with bigger flanks. It is robust as hell, but at a hefty price in terms of CPU load. All other optimisations are just drops in an ocean.

[Slidewinder]

In the 2021 thread linked by Nomath, Carl Watts advises not to delve into the black box too far because "it's C2's intellectual property and trust me that's a brick wall."
Well, if he is referring to patent protection, my search of the patent records turns up just one, granted to Concept 2 in 1989. It is titled "Energy Absorbing Means with Self-Calibrating Monitor" (Patent #US4875674A). It has expired - which means that the described method is now in the public domain.

[JaapvanE]

In the 2021 thread linked by Nomath, Carl Watts advises not to delve into the black box too far because "it's C2's intellectual property and trust me that's a brick wall."

It is far from a brick wall, and nobody can legally stop anyone from interpreting signals and applying basic physics (as described by any physics textbook). That is also what Concept2's competitors are doing as well, albeit less accurate. Several Open Source projects led the way, although our approach to signal processing is more in line with current approaches to noise management.

We are not copying Concept2's code (as we have no clue how to do that and it would be a copyright infringement), we're simply building our own monitor, based on our (perhaps misguided) ideas, and making sure our results match the results of the golden standard in the industry.

[Slidewinder]

In the 2021 thread linked by Nomath, Carl Watts advises not to delve into the black box too far because "it's C2's intellectual property and trust me that's a brick wall."

It is far from a brick wall, and nobody can legally stop anyone from..etc."

We are in agreement. My comment was a refutation of Carl Watts' suggestion that your work and Nomath's could constitute patent infringement.