Concept2 Model C/PM3

[nathan-stewart]

I have a concept2 Model C which I believe is an older style magnetic pickup. The pulses are pretty weak and I would expect to need some processing. Has anyone converted one for OpenRowingMonitor? I have a working PM3 but was looking at this project as I had some ideas I'd like to see (particularly interested in video overlay).

[nathan-stewart]

For anyone else trying to get a variable reluctance type sensor into a Raspberry Pi this looks interesting. I believe I'll need to leave the pullup to 5v off and use the pi internal pullup to 3.3v.

https://oshpark.com/profiles/nslogan MAX9924 Breakout v1.0

This chip does some clever zero crossing detection with dynamic thresholding and seems to have emerged as the current de facto "turn VR pulses into logic pulses" standard.

[laberning]

Sounds like an interesting approach. I am curious what your experiments will show 😄

[nathan-stewart]

By "interesting approach" do you have something simpler in mind? It's hard to see how high the voltages can be because can't read the scope while I'm on the rower, but I'm pretty sure I can bust 3.3v wide open.

[laberning]

For a variable reluctance sensor your approach sounds like a good plan. If that MAX9924 works as described, then this should work.

I don't know the intern of the Concept2 Model C, but if you can access the sensor physically, then you could also try to add a Hall Sensor. The magnet that is currently triggering the VR sensor should also be able to trigger a hall sensor, so it might be enough to just attach the sensor somewhere next to the existing one. You could attach a hall sensor directly to the raspberry (i.e. see here: https://circuitdigest.com/microcontroller-projects/interfacing-hall-sensor-with-raspberry-pi).

[nathan-stewart]

Hmm one advantage of another sensor I suppose is calibration, since I have a working PM3.

[nathan-stewart]

Ok, I have a data cable now, and it occurs to me that I can just suck data out of the PM3 and merge it with my HR from Ant+. Any tips on going about that?

[JaapvanEkris]

My exoerience is that it is quite a complex process: AFAIK, ANT+ delivers a broadcast every second and matching workout data with HR data is surprisingly difficult. The tools that do this for tcx files tend to put the recorded HR data between the strokes, making analysis quite hard. RowsAndAll.com has a paid feature that is called Sensor Fusion (see https://analytics.rowsandall.com/2018/04/09/rowsandall-com-use-examples-part-i-concept2-ergometer/) which claims that can do it.

[nathan-stewart]

If ANT+ is every second then I suppose I need to build a tempo map and then interpolate the strokes to the HR tempo map. But I'm also still trying to see if I can feed ANT+ data into the PM3 Polar receiver, but I'm still looking for interface specs for that.

[nathan-stewart]

From the c2forums discussion:
https://www.c2forum.com/viewtopic.php?f=10&t=202673&p=543656#p543656

nates wrote: ↑
Another idea I might try is seeing what's involved in feeding PM3 data into ORM. I'd have to bypass a lot of the physics engine it seems and just poll the monitor. 

JaapvanE:
I thought about it a bit better, and looked at PyRow for you. Easiest approach is to isolate the changes to ORM so you can upgrade later on when we add new functionality like better BT support for the EXR rowing game and similar apps. Unfortunately, the PyRow interface isn't interrupt driven, so you need to poll/sample the PM3. There are several steps you need to take to make this happen:

First, change the GpioTimerService.js to create a currentDt ever x milliseconds (for inspiration, you can look at RowingStatistics.js, where we use setInterval(emitMetrics, screenUpdateInterval) to update the screen). On a Raspberry Pi 4, we can handle impulses every 5ms without issue, but the question is if python, the USB port and the PM3 can handle this. The value of CurrentDt isn't important, it just needs to send it every x ms.
Second, you need to modify the handleRotationImpulse function of RowingEngine.js to call PyRow and extract all data (this is the function that handles the created currentDt). As you want a .tcx to go to Garmin, you need at least the time, distance, speed and spm. To make ORM work, it needs to see stroke and drive phases, which are reported back to the mother process through workoutHandler.handleStrokeEnd and workoutHandler.handleRecoveryEnd (please note that handleStrokeEnd will become handleDriveEnd in a future update!). These HAVE to be reported with the associated metrics to make broadcasts and .tcx creation possible. When I look at strokelog.py, they loop until the PM3 indicated the session has ended and they watch for strokestate == 2 (which is the drive?). So when the strokestate changes from a 1 to a 2 you need to broadcast a workoutHandler.handleRecoveryEnd and when it changes from a 2 to a 1, you need to broadcast a workoutHandler.handleStrokeEnd. When you don't see a change in the strokestate, you could broadcast a workoutHandler.updateKeyMetrics. In RowingEngine.js, the time and distance are absolute (time is in seconds), so you can extract the data from PyRow and copy it to the appropriate fields. Pace you have to transform to speed (in M/s) and strokenumber you have to count yourself. Power isn't provided (?) but you can deduce it from the pace. All other fields are allowed to be 0 if unknown.
Last, you need to configure numOfPhasesForAveragingScreenData to 1 (see the config settings), to prevent any smoothing to be applied to your PM3 data (as that already smoothens data).

Please send the resulting code to OpenRowingMonitor, it might be a solution for other people as well.

[nathan-stewart]

Still think this is a good idea, but my personal project level is high at the moment, and I have a PM5 otw. An alternative idea I came up with ia using Py4j to have the PyRow polling loop call into ORM's update functions when it sees data.

[JaapvanEkris]

I hope you like the PM5. I must say I'm a bit dissapointed by the level of data they register for further analysis. But that probably is my data-driven mindset talking....