New (March 2024?) PM5 with USB-C no USB-A or USB-B

[JaapvanE]

that's what C2 gives with PM5. Distance per stroke you need to calculate from the per stroke data to get graph.

With ANT+ it is actually reported by the PM5. The C2 route is inaccurate as all numbers are rounded, leading to weird behaviour.

[Carl Watts]

I have an Android tablet on the WattBike Atom X, its looking at the loadcell an the crank position and throwing out a PES score, or Pedal Efficiency Score, which is bit like power curve on the Erg but way better, it would be like having a score of your Drive and comparing that to that of a top elite rower in real time instead of just a pretty useless graph on the PM5. You could then work on your technique to improve the score with the feedback provided stroke by stroke.

But a pedal maxes out at 120 RPM, plenty of time to broadcast it, even via old protocols like ANT+. And a pedal is a pretty stable and simple rotational motion. But when you look into the underlying specs and put to the test (currently I'm working on a commercial project to design the perfect cycling simulator, so I am paid to do that), these powermeters are horribly slow and inaccurate.

Incorrect I can do 160rpm and it still works fine, by the way the crank has an encoder with 48 positions per rpm. This is slow in comparison to modern micro speeds.

Worst case Concept 2 can use the same micro in the PM5 and just build it into the tach pickup along with a Li-Ion battery and charger with a USB C port for battery charging if needed and some diagnostics. Simply Bluetooth the data to the tablet the same as its already happening to ErgData on Your Phone, its easy and everyone else is already doing it and have been for years. The micro in the PM5 is now tiny, they have put the Flash memory in the micro and there is no longer external flash, the micro is tiny because it no longer needs all the address and data ports.

Concept 2 must already be working on it, its a total no brainer

[JaapvanE]

Incorrect I can do 160rpm and it still works fine, by the way the crank has an encoder with 48 positions per rpm. This is slow in comparison to modern micro speeds.

You clearly have no clue what the bottleneck is. The microprocessor isn't the bottleneck. The protocol setting of the iPhone is, as it only accepts one datapage per 20ms.

Worst case Concept 2 can use the same micro in the PM5 and just build it into the tach pickup along with a Li-Ion battery and charger with a USB C port for battery charging if needed and some diagnostics. Simply Bluetooth the data to the tablet the same as its already happening to ErgData on Your Phone, its easy and everyone else is already doing it and have been for years. The micro in the PM5 is now tiny, they have put the Flash memory in the micro and there is no longer external flash, the micro is tiny because it no longer needs all the address and data ports.

As said earlier, displaying the force curve is the limiting factor here. With ESPRowingMonitor we moved to this exact setup, and it isn't optimal when compared to a PM5.

[stevegaspars]

Big question, will it still support USB-C sticks and wired upgrades?

Probably need to use an USB-C to USB-A OTG cable for a USB2 stick. I'd be surprised if this doesn't still work. I believe USB-C flash drives are a whole new beast, hence the incompatibility.

So i was surprised. I got confirmation from C2 that no USB sticks will work for updating firmware on a PM5v6.

[Tsnor]

that's what C2 gives with PM5. Distance per stroke you need to calculate from the per stroke data to get graph.

With ANT+ it is actually reported by the PM5. The C2 route is inaccurate as all numbers are rounded, leading to weird behaviour.

Neat. But I'm not understanding, and am kind of interested.

Distance per stroke is (for me on long/slow) about 10-11 meters. If I use the starting distance in the per stroke data and subtract the prior starting distance I get a pretty consistent per stroke metric for "distance per stroke". I don't know where rounding would come in other than that C2 rounds distance to a 1/10 of a meter... ?

stroke/time/distance/pace/watts/cal/stroke/HR
161 460.3 1692.1 130.2 159 845 22 121
162 463.1 1702.7 131.2 155 833 22 122

1702.7 minus 1692.1 = distance per stroke of 10.6 meters ????

What would this distance look like reported by PM5 to C2 ? Why would it be more accurate? I don't read fit files, but took an export of this session from Garmin. I'll paste it below, it doesn't correspond to the stroke above. Is is cutting a new type-6 record based on time and not stroke start? If so why would the distance/stroke be more accurate? Is the example below is the distance about 4 meters between data points ? Other than average how would you get actual stroke length ?

TYPE=6 NAME=record NUMBER=20
--- timestamp=1097620177=2024-10-11T22:29:37Z
--- distance=758200=7582.00 m
--- accumulated_power=290547=290547 watts
--- enhanced_speed=3602=12.967 km/h
--- power=131=131 watts
--- xxx87=1080=1080
--- xxx108=3903=3903
--- heart_rate=129=129 bpm
--- cadence=20=20 rpm
--- resistance=0=0
--- temperature=25=25 deg.C
--- fractional_cadence=0=0.00 rpm
--- xxx135=2=2
--- xxx136=129=129
--- xxx143=31=31
--- xxx144=129=129
==
= TYPE=3 NUMBER=233
--- xxx2=0=0,0,0,80
==
= TYPE=6 NAME=record NUMBER=20
--- timestamp=1097620178=2024-10-11T22:29:38Z
--- distance=758600=7586.00 m
--- accumulated_power=290678=290678 watts
--- enhanced_speed=3602=12.967 km/h
--- power=131=131 watts
--- xxx87=1080=1080
--- xxx108=3903=3903
--- heart_rate=129=129 bpm
--- cadence=20=20 rpm
--- resistance=0=0
--- temperature=25=25 deg.C
--- fractional_cadence=0=0.00 rpm
--- xxx135=2=2
--- xxx136=129=129
--- xxx143=31=31
--- xxx144=129=129
==
= TYPE=3 NUMBER=233
--- xxx2=31=31,153,4,0

[JaapvanE]

Neat. But I'm not understanding, and am kind of interested.

Distance per stroke is (for me on long/slow) about 10-11 meters. If I use the starting distance in the per stroke data and subtract the prior starting distance I get a pretty consistent per stroke metric for "distance per stroke". I don't know where rounding would come in other than that C2 rounds distance to a 1/10 of a meter... ?

The ANT+ specification is actually accurate in centimeters, so there is one more significant digit to start with. Up till a year ago C2 truncated it up to whole meters, until I filed a feature request, so some improvement has been made already, but it isn't ideal.

An issue arises (although perhaps small, but nonetheless...) that you are doing math with rounded numbers. Let's say in the perfect world you row exactly 10.05 meters per stroke. ANT+ will record it as such. But the PM5 will round it, so you get the following distances:

stroke 1, distance 10.1 meters --> Distance per stroke 10.1 meters
stroke 2, distance 20.1 meters --> Distance per stroke 10.0 meters
stroke 3, distance 30.2 meters --> Distance per stroke 10.1 meters
stroke 4, distance 40.2 meters --> Distance per stroke 10.0 meters

Not a big thing per se, but something to consider when doing post-processing on data.

[Tsnor]

Neat. But I'm not understanding, and am kind of interested.

Distance per stroke is (for me on long/slow) about 10-11 meters. If I use the starting distance in the per stroke data and subtract the prior starting distance I get a pretty consistent per stroke metric for "distance per stroke". I don't know where rounding would come in other than that C2 rounds distance to a 1/10 of a meter... ?

The ANT+ specification is actually accurate in centimeters, so there is one more significant digit to start with. Up till a year ago C2 truncated it up to whole meters, until I filed a feature request, so some improvement has been made already, but it isn't ideal.

An issue arises (although perhaps small, but nonetheless...) that you are doing math with rounded numbers. Let's say in the perfect world you row exactly 10.05 meters per stroke. ANT+ will record it as such. But the PM5 will round it, so you get the following distances:

stroke 1, distance 10.1 meters --> Distance per stroke 10.1 meters
stroke 2, distance 20.1 meters --> Distance per stroke 10.0 meters
stroke 3, distance 30.2 meters --> Distance per stroke 10.1 meters
stroke 4, distance 40.2 meters --> Distance per stroke 10.0 meters

Not a big thing per se, but something to consider when doing post-processing on data.

The C2 error seems structurally a smaller error than the fit file -- which maybe uses the cadence (spm) to get the distance per stroke because there isn't a marker for stroke start... ??? (Or how are they getting stroke start/end?)

(I'm used to working with experts outside my own field. This is usually the point where they sigh and start explaining to me the numbers I'm seeing are adjusted, and the model i'm using is simplified, and it doesn't really work that way...)

Let's say in the perfect world you row exactly 10.05 meters per stroke. ANT+ will record it as such.

I wasn't seeing anything like distance/stroke in the .fit file. (Thus my guess that this field was computed from distance and spm over a short time interval). Is the PM5 reporting that in ANT+ ?

FWIW eyeballing the .fit file the watts rowed seem to be steady +/- 1%. Given 20 spm and a record cut every second (so three seconds per stroke, three data points per stroke) some data points should be during the drive and some should be during recovery. Yet watts are constant. Must be some smoothing going on in the .fit file ....

[JaapvanE]

(I'm used to working with experts outside my own field. This is usually the point where they sigh and start explaining to me the numbers I'm seeing are adjusted, and the model i'm using is simplified, and it doesn't really work that way...)

Hahaha, I know the feeling

FWIW eyeballing the .fit file the watts rowed seem to be steady +/- 1%. Given 20 spm and a record cut every second (so three seconds per stroke, three data points per stroke) some data points should be during the drive and some should be during recovery. Yet watts are constant. Must be some smoothing going on in the .fit file ....

Nope, that is the internals of a rowing monitor doing its thing. Pace and power could be measured instantanuous, meaning a direct measurement as it is in the absolute now. Like you, C2 recognized that pace and power vary during the stroke (technically, instantanuous power drops to 0 in the recovery), which tends to freak users out. So, they use an average across the stroke, as that tends to be stable, making it a good training metrics. So, one can technically calculate pace only at the end of the drive and the end of the recovery (as you then have a complete stroke for sure), where the PM5 only seems to use the end of the drive. In the time between those points, pace internally is fixed.

The C2 error seems structurally a smaller error than the fit file -- which maybe uses the cadence (spm) to get the distance per stroke because there isn't a marker for stroke start... ??? (Or how are they getting stroke start/end?)

They don't. ANT+ is normally a purely time-driven protocol, so it sends messages every 400ms to 1sec. Page 17 of these messages contains the "distance per stroke", which is followed by page 22 which tells the total number of strokes, strokerate and power.

As it sees the same stroke number, it assumes the metrics all belong to that same stroke. So it will get most data two or three times. When it gets changed metrics belonging to a new strokenumber, it starts reconstructing the stroke data. With ORM we can create FIT-files with 1 message per stroke, but it freaks many apps out as they think data is missing.

I wasn't seeing anything like distance/stroke in the .fit file. (Thus my guess that this field was computed from distance and spm over a short time interval). Is the PM5 reporting that in ANT+ ?

It is, page 17 indicates it should be reported for a rower (in centimeters). If you look at https://runnermate.eu/garmin/concept2/r ... oaded.html, tou see it is only recorded for a small number of Garmins (model feature description was never their strong point).