StrokeState change for the catch

Post questions and issues with Concept2 PM3 SDK
Post Reply
Posts: 10
Joined: March 8th, 2018, 4:05 pm

StrokeState change for the catch

Post by FooTheBar » September 12th, 2019, 3:26 am


I'm using the Py3Row-Interface (over USB) to get data from a PM5 and the data looks good. I wanted to use the strokeState-Data to measure the ratio between driver and recovery, however while I row, the strokeState switches only between 2 and 4.
4 is around 'arms away' (handle starts to move forwards), however the transition to 2 is triggered as soon as the handle moves across my feet during the drive (so at least 40cm away from the catch) position. My update frequency is around 50Hz so it get multiple monitor-readings between the beginning of the drive and the switch to strokestate 2.

From the docu:

  • 0. Waiting for wheel to reach min. speed
    1. Waiting for wheel to accelerate
    2. Driving
    3. Dwelling after drive
    4. Recovery
Note: Catch would be the transition from recovery to driving. End-of-stroke would be the transition from driving to dwelling after drive
Do you get similar values? Or is 2/Driving really at the direction-reversal of the chain? (Where I think the drive begins...)

Half Marathon Poster
Posts: 2867
Joined: March 18th, 2006, 3:44 am
Location: Trentino Italy

Re: StrokeState change for the catch

Post by jamesg » September 12th, 2019, 3:53 am

The sensor magnets are on the flywheel, so the system sees acceleration only when the flywheel starts to accelerate. This can happen anywhere, depending on technique.

On C machines there are 3 magnets, so the impulse rate is about 50Hz, given the gearing, and one impulse is 3cm chain travel.
08-1940, 183cm, 87kg. Last seen MHR 162, in 2k (2020-05-16) 8.47.5@24

Allan Olesen
5k Poster
Posts: 543
Joined: April 27th, 2018, 6:40 am

Re: StrokeState change for the catch

Post by Allan Olesen » September 12th, 2019, 12:12 pm

I have noticed the same as you, when I messed around with USB communication. I agree with James here. During a normal stroke sequence in the middle of a rowing session, the PM only has enough input to know two events:
  • when the wheel starts accelerating
  • when the wheel stops accelerating
Everything, which happens during the recovery, can't be divided into sub steps with this information.

Apart from that, the drive ratio is really a red herring. If you concentrate on keeping your stroke rate on target and your pace or power on target, the drive ratio will follow automatically. It has to, because you need a fast drive to keep your power or pace on target, and you need a slow recovery to keep your stroke rate on target. This more or less forces you into a single solution for drive ratio, with only a little wiggle room for different drive length and/or different distribution of stroke force through the drive.

(Of course, if you change the drag factor, the drive ratio will change. But again, there will only be little wiggle room for different drive ratios at that drag factor.)

Post Reply