Concept 2 model C with optical flywheel angular speed detection.

[klamp169]

Introduction

Just for inspiration to others, I report here my experience with ORM connected to my old Concept2 model C fitted with a PM2 performance monitor.

Optical detection

Instead of using the 3 induction voltage spikes per revolution of the flywheel, I used an optical encoderdisk and an infrared sensor (see pictures below, also proposed here: #61). The encoder lines were printed on a sheet of paper with a laserprinter. The paper was cut out and glued onto the flywheel surface. For the placement of the sensor I drilled a few small holes in the housing of the flywheel, allowing the phototransistor to detect the reflected IR-light from the encoder disk inside the housing.

Rower flywheel with encoder glued on top of it. Phototransistor assembly mounted on flywheel housing.

Signal routing

Digital signal routing.

The sensor module outputs a digital signal, which is connected to an ESP32 microcontroller, running an interrupt routine (see figure). The ESP32 only sends the timestamp values via bluetooth to a laptop running my own Python "PM2-replacement"" program "rwnp" (comparable in functionality with "ORM"). The interrupt routine also outputs a pulse on another pin after "dividing" the incoming pulses by 1, 2, 3, 4, 6, or 12, resulting in 12, 6, 4, 3, 2 or 1 pulses per flywheel revolution, respectively. This pulse train is used as input into the Raspberry Pi 3 Model B+, running ORM. Since I could not get ORM to work with 12 pulses per rev, I chose 6 pulses per rev. This produced values close to PM2 and rwnp readings using the following rower profile:

  Concept2_RowErg_: {
    numOfImpulsesPerRevolution: 6,
    sprocketRadius: 1.415,
    maximumStrokeTimeBeforePause: 6.0,
    dragFactor: 68,
    autoAdjustDragFactor: true,
    minimumDragQuality: 0.60,
    dragFactorSmoothing: 1,
    minimumTimeBetweenImpulses: 0.005,
    maximumTimeBetweenImpulses: 0.02,
    flankLength: 6,
    smoothing: 1,
    minimumStrokeQuality: 0.34,
    minimumForceBeforeStroke: 11,
    minimumRecoverySlope: 0.00070,
    autoAdjustRecoverySlope: true,
    autoAdjustRecoverySlopeMargin: 0.01,
    minimumDriveTime: 0.40,
    minimumRecoveryTime: 0.50,
    flywheelInertia: 0.1001,
    magicConstant: 2.8
  }

Conclusion

Generating high quality/ low noise digital pulses is imperative for the proper functioning of the detection software (PM2, ORM, rwnp). Making use of optical techniques is an interesting, cheap and reliable route to accomplish this and may be preferable over magnetic techniques.

[JaapvanEkris]

Introduction

Just for inspiration to others, I report here my experience with ORM connected to my old Concept2 model C fitted with a PM2 performance monitor.

A very cool approach, especially as it is less dependent on magnets, which might disturb the balance and inertia of the flywheel.

The sensor module outputs a digital signal, which is connected to an ESP32 microcontroller, running an interrupt routine (see figure). The ESP32 only sends the timestamp values via bluetooth to a laptop running my own Python "PM2-replacement"" program "rwnp" (comparable in functionality with "ORM"). The interrupt routine also outputs a pulse on another pin after "dividing" the incoming pulses by 1, 2, 3, 4, 6, or 12, resulting in 12, 6, 4, 3, 2 or 1 pulses per flywheel revolution, respectively. This pulse train is used as input into the Raspberry Pi 3 Model B+, running ORM. Since I could not get ORM to work with 12 pulses per rev, I chose 6 pulses per rev.

In the early days of ORM, we actually experimented with a similar setup: an ESP for highly accurate signal detection, and the RPi for the further processing. Instead of your analog signal, we used a HTTP-socket over WiFi (I must add I am still convinced a serial port would have been more reliable): the ESP injected the raw measurements directly into the engine. Currently, this is still possible by replacing the gpio-polling thread and replacing it by a recieving socket.

When looking at 12 pulses per rotation, the flankLength should ideally be 24, which creates a significant CPU load. So it might overload the RPi3. 12 pulses should be quite doable if the structural signal error is tiny, as the standard RowErg uses that FlankLength, and the pattern might be extremely precise. The upcoming version 0.9.7 might help here as well as it has a new filter that removes structural signal errors.

Generating high quality/ low noise digital pulses is imperative for the proper functioning of the detection software (PM2, ORM, rwnp). Making use of optical techniques is an interesting, cheap and reliable route to accomplish this and may be preferable over magnetic techniques.

Overall, I agree. Practical thing is that reed switches are simple to implement, despite being noisy.

[Abasz]

About reed switches: Generally, I do not think "ease of use" offsets "trouble in operation". Only for low pulse count systems reed switches might work reliably.

I disagree with this slightly (yes a hall is better of course). I used reed that was rated to 500hz and apart from the bounce (which needed filtering) it worked absolutely well given a sufficiently sized magnet with 3 impulses per rotation. It has the added benefit that it is passive so battery operation is as simple as it gets.

after "dividing" the incoming pulses by 1, 2, 3, 4, 6, or 12, resulting in 12, 6, 4, 3, 2 or 1 pulses per flywheel revolution, respectively.

I dont fully understand how you interface ORM. Or you are saying you take the modulus? ORM normally expects delta time so I am a bit confused. Or is it like you can "down sample" the impulses as needed by "skipping" and only signal an impulse to ORM after 2 or 3 or 4 etc ?

timestamp values via bluetooth

And there are no packet loss ever? Actually when I was developing ESPRM originally I have thought about this, so I dont have to port the full ORM engine to C++. Then I decided after some research that packet loss is too big of a potential issue at high speeds (though BLE through put should be plenty), and I settled with serial for a little while (before realising that this combined setup is difficult to take with me to the boat house to be used on kayak ergs :D)

I simply take the time of the 13th pulse minus the time of the 1st pulse (14th minus 2nd , etc.) to calculate the flywheel angular speed. [...] This circumvents the sse-problem, gives very low noise, is very straightforward and the resolution of the erg-handle position is still maintained.

But wouldnt this method kind of reduce the responsiveness? While this is very simple I think the cyclic error filter (or phase correction in your case) does not have this trade off (though we can argue that it has other potential issues especially when a signal skips or bounce occurs).

[klamp169]

Hey Abasz, thanks for your comments!

On pulse detection technique: my main point is: use the technique that leads to best quality data and that is relatively easy to implement. I did considere using a Hall sensor on the model C, but then I would not be able to increase the number of pulses per rev. The printed encoder disk makes this very straightforward. I was not aware of the relatively high frequency capabilities of reed switches, which widens their applicability. Bouncing can be a nuisance, still.

On ORM interfacing: I do the "skipping" technique you mention. I am amazed with the speed and reliability of the Bluetooth connection. (Took me some time to find out how this works; I am not a software engineer). I have never witnessed packet loss, up to now. 4 bytes every 3 msec or slower is very doable, of course. I use standard BT and rfcomm for this.

On reducing responsiveness: Yes, but it is still plenty, due to the high rotational speed of the flywheel. This is also the reason why the phase correction technique does not give a more responsive result.

On signal skips and bounce: See my first response called "On pulse detection technique". I simply never have skips or bounce, even at high speed or downto flywheel standstill. My Python program "rwnp" has the advantage that it does not have to cope with all the different rowers and detection techniques that ORM has to deal with 😅.

Cheers!

[Abasz]

I use standard BT and rfcomm for this.

Yes that could be relevant indeed. I was only thinking BLE :)

simply never have skips or bounce,

I quite like the idea of IR with the encoder, though I never thought that a setup of these analog IR sensors with the comparator chip would be able to achieve the needed frequency and switching accuracy. It is very good that we have this proof of concept now as they are very simple, and less prone to magnet placement errors (no need for 3d printed or somehow standardised brackets), they work well with 3.3v and only a normal printer is needed.

[klamp169]

datasheet of TCRT5000. Cutoff frequency is 30 to 50 kHz. Encoder lines come at ~240 Hz (12 lines, 1200 rpm).

[klamp169]

Magnet placement errors may also be related to small variations in magnet strength and magnet pole direction. Encoder lne placement errors may also be related to variations in "blackening strength" of the lines. Even "perfect" placement does not guarantee a "perfect" signal. We have to live with it to a certain extent.