PM5 ANT+ FE-C for the RowErg

[kadigeN]

Hello,
Im using my PM5 and recording workouts with my Garmin Fenix 7x, it works quite good there is only one major issue. During intervall workouts (controlled by PM5) the rower will stop sending power data during the rest periods, causing the watch to hold on to the last received power value from the active intervall for the entire rest intervall, all other metrics are received correctly on the watch during rest period (stroke count and 500m timings). So i would kindly suggest to keep sending the power data during rest intervals, because they way it currently works will produce bad training load data on the garmin watch because it thinks im doing full effort during rest intervals.

[JaapvanE]

I would send this request to info@concept2.com

In my experience, they are quite responsive to these points of improvement.

[k50935]

Hi, is there any progress with the Problem? I'm running into the same issue. By now, instead of setting a Pause in the ErgZone (or ErgData) "Rest time" in the original interval, i set an extra interval with 5 sec time and no intensity and set the "Rest time" there. The Power and SPM goes to zero and the pause is recorded correct by the Fenix. But thats only a quick an dirty fix, an an solution from c2 in the firmware would be appropriate...

[Citroen]

Write your own email to rowing@concept2.com or info@concept2.com and ask them.

[randybb]

Yea, the same with the last beta for my PM5v3 (R212B008) - hope they will respond to my email soon as they are probably not tracking this forum.

[dokotela]

Hi,
Since the most recent update my PM5 cannot find my heart rate monitor. I've changed the battery on the HRM and it's made no difference. I'm certain it's a glitch with the update

[HornetMaX]

Hello,
Im using my PM5 and recording workouts with my Garmin Fenix 7x, it works quite good there is only one major issue. During intervall workouts (controlled by PM5) the rower will stop sending power data during the rest periods, causing the watch to hold on to the last received power value from the active intervall for the entire rest intervall, all other metrics are received correctly on the watch during rest period (stroke count and 500m timings). So i would kindly suggest to keep sending the power data during rest intervals, because they way it currently works will produce bad training load data on the garmin watch because it thinks im doing full effort during rest intervals.

Could be more a Garmin problem than a PM5 one: is the PM5 sending the last value (I doubt) or is the Garmin receiving no value at all and holding the last valid one ?

[nwbasson]

Hi,

I have the same issue as well with an Instinct 2x. Is this a C2/PM5 bug?

Thanks.

[HornetMaX]

I have the same issue as well with an Instinct 2x. Is this a C2/PM5 bug?

I2X here too.

Garmin may say it's a c2 problem, c2 may say it's a Garmin problem.

BTW, without logging the activity on the Garmin watch via ANT FE-C (i.e. simply enabling the forwarding from c2 logbook to Garmin Connect) there's the same problem: during a rest interval there's no data point for any of the shown measure (HR, pace, power, stroke rate). Garmin Connect visually draws a line between the last point of the previous interval and the first point of the next. But in fact there's no data point at all in between.

However, next to the activity stats there a "Intervals"" tab (on the website, I don't have it on the app) that shows each interval properly (duration, meters etc), including rest intervals (just like the PM5). So Garmin Connect is aware that that part of the activity was a rest interval
Note it still counts the rest intervals metrics(e.g. pace or power) into the global activity averages (unlike the PM5).

PM5 summary:

Code: Select all

Time 	Meters 	Pace 	Watts 	Cal/Hr 	S/M 	HR
1:20:00	19,097m	2:05.6 	176 	906 	25 	159
15:00.0	3,680m 	2:02.2 	191 	958 	26 	161
15:00.0	3,492m 	2:08.8 	164 	862 	24 	155
10:00.0	2,387m 	2:05.6 	176 	906 	26 	159
r: 4:00	16m 						
15:00.0	3,663m 	2:02.8 	189 	949 	26 	164
15:00.0	3,494m 	2:08.7 	164 	863 	25 	155
10:00.0	2,384m 	2:05.8 	176 	904 	27 	165

Garmin Connect Intervals: you can see that only my 3rd interval had some rest time (4min) all the others have zero rest (but, surprisingly, non-zero meters ?!), which is correct.
My 6 real intervals were at pace (roughly) 2:03, 2:06 and 2:09, but the overall average is 2:12 because garmin includes the rest interval in the average (unlike the PM5).

Code: Select all

Int	Type	Lap	Time	CumTime	Dist	AvgPace
1	Other	1	15:00	15:00	3,680	2:02
	Rest	2	0	15:00	12	--
2	Other	3	15:00	30:00	3,492	2:09
	Rest	4	0	30:00	10	--
3	Other	5	10:00	40:00	2,387	2:06
	Rest	6	4:00	44:00	12	2:46:46
4	Other	7	15:00	59:00	3,663	2:03
	Rest	8	0	59:00	14	--
5	Other	9	15:00	1:14:00	3,494	2:09
	Rest	10	0	1:14:00	2,378	--
6	Other	11	10:00	1:24:00	2,384	2:06
Summary	--	--	1:24:00	1:24:00	19,113	2:12

[Tsnor]

FWIW C2 has a novel way of showing intervals in per-stroke data. It makes time stop (to show rest strokes) and then go backwards to show start of next interval. At a guess PM generates this, Garmin can't consume this, and C2 needs it for internal analysis to show the interval data. FE-C likely does not expect time to go backwards but you cant verify this because ANT+ hides their specs unlike the equivalent Bluetooth protocols which are here https://www.bluetooth.com/specification ... rvice-1-0/.

Look at the data for "30 seconds on 90 seconds rest" intervals below from downloaded C2 CSV data. First interval starts at stroke 1. Time increases until stroke 20. From strokes 20 to 47 time is frozen at 30 seconds, these are the rest strokes. Power is given, but time is not moving. Then time resets to 0 at stroke 48. If the PM5 is giving the same data over ANT+ FE-C it's no surprise Garmin is choking. (Aside, my Garmin 265 watch also shows same problem you were seeing with power held constant over rest strokes when recorded over ANT+ FE-C. I tried using just row to get better data to Garmin when I did intervals, but Garmin did not seem to use the data in its training calculations so I went back to normal intervals and ignored the Garmin graphs.)

Stroke-Number Time(seconds) Distance(meters) Pace(seconds) Watts Cal/Hr
1 0 3 124.3 182 927
2 1 8 124.3 182 927
3 2 13 102.4 326 1421
4 4 22 96.6 388 1636
5 6 32 92.4 444 1826
6 7 37 92.4 444 1826
7 9 47 91.4 458 1877
8 11 57 90.8 468 1909
9 12 68 89.8 483 1963
10 14 78 90.1 479 1946
11 16 89 91 464 1898
12 18 98 91 464 1898
13 20 108 92.2 447 1836
14 22 119 92 449 1846
15 23 128 92 449 1846
16 25 138 93 435 1797
17 27 148 92.5 442 1821
18 29 158 90.9 466 1903
19 30 168 92.7 439 1812
20 30 181 104.7 305 1349
21 30 191 134.8 143 791
22 30 200 152.1 99 642
23 30 208 160.5 85 591
24 30 220 158.7 88 601
25 30 228 154.6 95 625
26 30 237 153.9 96 630
27 30 250 151.3 101 647
28 30 259 151.1 101 649
29 30 268 150.1 103 656
30 30 281 151.9 100 643
31 30 290 150.8 102 651
32 30 301 150.5 103 653
33 30 310 150.5 103 653
34 30 322 156.4 91 614
35 30 331 156.4 91 614
36 30 343 156.6 91 613
37 30 352 156.6 91 613
38 30 364 155.7 93 619
39 30 372 155.7 93 619
40 30 384 155.3 93 621
41 30 395 166.7 76 560
42 30 406 165.1 78 567
43 30 418 162.8 81 579
44 30 426 161.7 83 584
45 30 439 156.7 91 613
46 30 445 126.4 173 896
47 30 458 113.9 237 1115
48 0 0 0
49 1 6 97.1 382 1615
50 3 16 99.4 356 1526
51 4 25 98.7 364 1552
52 6 35 95.4 403 1687
53 8 45 92.3 445 1831
54 10 54 92.5 442 1821
55 12 65 93.4 430 1778
56 14 75 93 435 1797
57 16 85 92.6 441 1817
58 16 95 93 435 1797
etc

[JaapvanE]

FWIW C2 has a novel way of showing intervals in per-stroke data. It makes time stop (to show rest strokes) and then go backwards to show start of next interval. At a guess PM generates this, Garmin can't consume this, and C2 needs it for internal analysis to show the interval data. FE-C likely does not expect time to go backwards but you cant verify this because ANT+ hides their specs unlike the equivalent Bluetooth protocols which are here https://www.bluetooth.com/specification ... rvice-1-0/.

Those are NOT the messages a PM5 sends. The PM5 uses its own protocol which doesn't resemble FTMS in any way. You can see the specs here:
https://www.concept2.co.uk/files/pdf/us ... nition.pdf

Look at the data for "30 seconds on 90 seconds rest" intervals below from downloaded C2 CSV data. First interval starts at stroke 1. Time increases until stroke 20. From strokes 20 to 47 time is frozen at 30 seconds, these are the rest strokes. Power is given, but time is not moving. Then time resets to 0 at stroke 48. If the PM5 is giving the same data over ANT+ FE-C it's no surprise Garmin is choking. (Aside, my Garmin 265 watch also shows same problem you were seeing with power held constant over rest strokes when recorded over ANT+ FE-C. I tried using just row to get better data to Garmin when I did intervals, but Garmin did not seem to use the data in its training calculations so I went back to normal intervals and ignored the Garmin graphs.)

It seems that that is a trick they use. They must send an ANT+ message every 400ms, and they keep increasing the stroke number every second (as their BLE interface sends a message every second?). I noticed they also wait for a drive before a new interval starts.

When I do intervals, I let EXR and my Garmin in on it, but don't tell the PM5.

[HornetMaX]

Those are NOT the messages a PM5 sends. The PM5 uses its own protocol which doesn't resemble FTMS in any way. You can see the specs here:
https://www.concept2.co.uk/files/pdf/us ... nition.pdf

Right, but the per-stroke data may be what C2 logbook forwards to Garmin Connect (as 3rd party activity, not when logging via ANT FE-C).

Anyway, I totally gave up on "logging on the Garmin watch" approach, I just let c2 logbook forward to Garmin Connect.
Some minor side effects aside (e.g. steps counted during RowErg and SkieErg session, bad HR recorder by Garmin optical sensor) everything else works very nicely. Even the estimation of the VO2max (from daily activities) seems to slowly converge to something that aligns to what table-based estimations on my PBs usually give (55-60 from my PBs, Garmin stuff started around 30 but has now crept up to 49 and growing).

[JaapvanE]

Those are NOT the messages a PM5 sends. The PM5 uses its own protocol which doesn't resemble FTMS in any way. You can see the specs here:
https://www.concept2.co.uk/files/pdf/us ... nition.pdf

Right, but the per-stroke data may be what C2 logbook forwards to Garmin Connect (as 3rd party activity, not when logging via ANT FE-C).

Not really. The ANT FE-C and FTMS definitions are totally different from the one that C2 uses. ANT+ and FTMS are stupid as hell, as they essentially originate from cycling and thus blindly assume that effort is continuous (which isn't true for rowing!). Both don't understand the concept of a drive starting an stroke, and just report pace, power, time and distance. They are totally time driven (ANT+ at 400ms intervals, FTMS at 1000ms intervals).

The C2 PM5 BLE protocol is much much more intelligent. It reports based on the event (start of the drive, start of the recovery), and reports much more metrics (much more than the C2 logbook records). Tools like painsled can show you wat really gets reported.

[HornetMaX]

Those are NOT the messages a PM5 sends. The PM5 uses its own protocol which doesn't resemble FTMS in any way. You can see the specs here:
https://www.concept2.co.uk/files/pdf/us ... nition.pdf

Right, but the per-stroke data may be what C2 logbook forwards to Garmin Connect (as 3rd party activity, not when logging via ANT FE-C).

Not really. The ANT FE-C and FTMS definitions are totally different from the one that C2 uses. ANT+ and FTMS are stupid as hell, as they essentially originate from cycling and thus blindly assume that effort is continuous (which isn't true for rowing!). Both don't understand the concept of a drive starting an stroke, and just report pace, power, time and distance. They are totally time driven (ANT+ at 400ms intervals, FTMS at 1000ms intervals).

The C2 PM5 BLE protocol is much much more intelligent. It reports based on the event (start of the drive, start of the recovery), and reports much more metrics (much more than the C2 logbook records). Tools like painsled can show you wat really gets reported.

I don't see why you say "Not really".

When C2 logbook forwards to Garmin Connect, they for sure do not use ANT+ or FTMS or the C2 BLE dedicated protocol.
The forwarding happens after the activity is completed ...

What I can say is that when c2 logbook forwards to Garmin Connect, Garmin Connect understands the intervals properly, even the rest intervals.
The graphs in Gramin Connect look weird because there's no data point at all during a rest interval, so Garmin Connect draws a a line between the last point of the previous interval and the first point of the next (non-rest) interval. They shouldn't do that, it's confusing.

In case of (let's say) a power graph, it looks wrong as it seems you have power even during the rest interval (during which I didn't do a single stroke), but it's only a visualization artifact: there's no data point at all during rest intervals.

That fact (no data point during rest intervals) is also visible in the .csv stroke data: there're lines only during real intervals, not during rest intervals. I'm not sure this is something new (as Tsnor seems to say): I was under the impression this was always the case in the .csv files (but I can be wrong).

Connecting the PM5 to the Garmin watch is a different story as in this case yes, ANT+, FTMS or C2 proprietary BLE protocol could be used.

[JaapvanE]

When C2 logbook forwards to Garmin Connect, they for sure do not use ANT+ or FTMS or the C2 BLE dedicated protocol.
The forwarding happens after the activity is completed ...

The thing is that the PM5 BLE interface dictates what ErgData knows, and thus what it can forward. ErgData gets a message on each drive-start, recovery-start, session-start, session-end, interval-end and after a second has passed without any message.

I don't know what they use to export it, but when I plan a rest interval, it shows up on Concept 2 website, so there they certainly know a rest interval is happening. So it happens from there down the line.

What I can say is that when c2 logbook forwards to Garmin Connect, Garmin Connect understands the intervals properly, even the rest intervals.
The graphs in Gramin Connect look weird because there's no data point at all during a rest interval, so Garmin Connect draws a a line between the last point of the previous interval and the first point of the next (non-rest) interval. They shouldn't do that, it's confusing.

In case of (let's say) a power graph, it looks wrong as it seems you have power even during the rest interval (during which I didn't do a single stroke), but it's only a visualization artifact: there's no data point at all during rest intervals.

When I select "Download original" in the Garmin website for a C2-upload, I get a FIT-file, which is a format that also available for download on the Concept 2 website. The upload specifications for Garmin indicate they prefer the FIT-file. So let's assume Concept 2 has to play by the same rules like everybody else and uploads workouts in FIT-format like the rest of us.

FIT-files must contain a timestamp for every message (i.e. datapoint containing a distance, velocity, etc.) it contains. When I download the fit-file from C2, I see a message for each recovery-end. So, there they are stroke based. But that is all there is.

When I download the Garmin file for the same workout from my watch, I see that they spit the excercise in laps, and in fact it contains the data about the intervals themselves. And at the interval end, it starts a new lap, and all things are marked. Those things are missing completely from C2's fit file. And by omitting that data, Garmin is forced to assume that the last message is still valid (please realize, a FIT-file in essence is just a ANT+ recording, so the same rules apply). That is why in OpenRowingMonitor we explicitly "zero" many metrics in specific circumstances and actually broadcast two messages when an interval ends: last known metrics, and a zero-ed set of metrics (aside from time and distance) to confirm that the machine has stopped.

That fact (no data point during rest intervals) is also visible in the .csv stroke data: there're lines only during real intervals, not during rest intervals. I'm not sure this is something new (as Tsnor seems to say): I was under the impression this was always the case in the .csv files (but I can be wrong).

That is because, as the name suggests, it only contains "Stroke data"