Weird stroke rate in log ?

[HornetMaX]

Not hugely important but a bit weird: see this session. How can each split have a stroke rate of 19 and the overall have a stroke rate of 18 ?!

Overall stroke count is 1763 that with the overall time (1:32:14.6 i.e. 92.2433 minutes) gives an average stroke rate of 19.1 ...

The session was logged with ErgZone (in case it matters).

Code: Select all

Time 		Meters 		Pace 	Watts 	Cal/Hr 	S/M 	HR
1:32:14.6 	21,097m 	2:11.1 	155 	833 	18 	154
8:39.3 		2,000m 		2:09.8 	160 	850 	19 	145
8:42.0 		2,000m 		2:10.5 	157 	841 	19 	150
8:40.9 		2,000m 		2:10.2 	158 	845 	19 	155
8:43.6 		2,000m 		2:10.9 	156 	837 	19 	155
8:43.0 		2,000m 		2:10.7 	157 	838 	19 	157
8:47.9 		2,000m 		2:11.9 	152 	824 	19 	154
8:47.8 		2,000m 		2:11.9 	152 	824 	19 	156
8:47.4 		2,000m 		2:11.8 	153 	825 	19 	156
8:47.3 		2,000m 		2:11.8 	153 	825 	19 	158
8:46.8 		2,000m 		2:11.7 	153 	827 	19 	161
4:48.7 		1,097m 		2:11.5 	154 	828 	19 	158

[Sakly]

Saw this a few times on my own rows and also looking at others. No idea why this happens, only c2 can know. As it is not the most important metric, it is not of interest for me.
I also observed that stroke count is not matching what ergdata reports at the end. This was true for very long rows - stroke count above 2k.

[MPx]

Surprisingly often happens to me on my 8k SS ergs @ r20 reporting 1k splits. As a numbers nerd I count the strokes 9>0 every 3 secs as a I go, so know I am spot on. This always gets me consistent r20 splits all through as it should but about 1 in 5 will be reported as r19 overall. No idea why. I've had even dafter numbers on times where I'm trying for OCD screens. eg can miss my target fractionally minus on more than one split but end up fractionally over on total or vice versa. I'm assuming its all part of the conspiracy to keep me from seeing the perfect screens that so many others manage.

[Citroen]

This is a quirk of the PM3 (which followed on to the PM4 & PM5). They round everything down, even when rounding up would make more sense and even if a split is short.

There's nothing you can do about it. The maths done by the PM3 is the same as that which is hard-coded in the PM2. The idea is that the results between PM2 & PM3 (PM4 & PM5) are consistent. It's not the design decision I'd make, I'd have improved the maths so that it worked normally as soon as you had a "soft coded" PM with replaceable firmware.

[JaapvanE]

This is a quirk of the PM3 (which followed on to the PM4 & PM5). They round everything down, even when rounding up would make more sense and even if a split is short.

This is a very interesting observation, which might explain some behaviour seen by me and other testers when comparing OpenRowingMonitor with a PM5. Are there any references of this available?

[Citroen]

It's seen through observation. If you look at any of the numbers they are all rounded down. Even when that is the least sensible option.

[HornetMaX]

This is a quirk of the PM3 (which followed on to the PM4 & PM5). They round everything down, even when rounding up would make more sense and even if a split is short.

Hmm I don't see how that could justify what I see.
If you round down SR at every split and you round down the overall SR, it's not possible to have all the splits at SR 19 and the overall at SR 18.

Or I don't understand exactly how/where they do the rounding (e.g. something that would be very weird, like round down split time to seconds for the SR computation of each split, do the same with the real total time).

[Citroen]

Or I don't understand exactly how/where they do the rounding (e.g. something that would be very weird, like round down split time to seconds for the SR computation of each split, do the same with the real total time).

That's likely to be the pattern. However it's done it's weird and doesn't follow regular maths.

[jamesg]

The C2 PM has two rate digits available, and 18 and a bit appears correctly as 18 complete strokes. It can't count or calculate the work done in the 19th stroke if it's not yet finished in that specific minute.

In your particular event, the time and number of strokes in the last incomplete minute was evidently lower than 19, enough to drop the overall average: 1763/93 = 18.956....

[HornetMaX]

The C2 PM has two rate digits available, and 18 and a bit appears correctly as 18 complete strokes. It can't count or calculate the work done in the 19th stroke if it's not yet finished in that specific minute.

In your particular event, the time and number of strokes in the last incomplete minute was evidently lower than 19, enough to drop the overall average: 1763/93 = 18.956....

You mean that to compute stroke rate, the PM5 ceils or rounds the time up to the minute (i.e. 1min29sec -> 2min or 1min respectively), then divides by the number of strokes and then floors the result to an integer (i.e. 18.99 -> 18) ? And that for both intervals, splits and overall session ?

Wow, that looks intentionally evil, as in "I'm doing my best to provide you a number that on occasions will be off in the most incomprehensible way".

So, for splits/intervals of less than 1min (pretty uncommon, yes) the computed stroke rate is total garbage ?

If this is kept only for backward compatibility reasons, I'd say that that's a very bad call (even if I agree the problem is marginal).

[JaapvanE]

You mean that to compute stroke rate, the PM5 ceils or rounds the time up to the minute (i.e. 1min29sec -> 2min or 1min respectively), then divides by the number of strokes and then floors the result to an integer (i.e. 18.99 -> 18) ? And that for both intervals, splits and overall session ?

Wow, that looks intentionally evil, as in "I'm doing my best to provide you a number that on occasions will be off in the most incomprehensible way".

So, for splits/intervals of less than 1min (pretty uncommon, yes) the computed stroke rate is total garbage ?

This is not how you calculate SPM during a row (it might be overall, but NOT what is on the display). What the PM5 does is calculate the time per stroke (which you need anyway for many other calculations like power and speed/pace), and do a 60 / time_per_stroke. The PM5 calculates this once per stroke, at the end of the recovery if I'm not mistaken.

If this is kept only for backward compatibility reasons, I'd say that that's a very bad call (even if I agree the problem is marginal).

Well, SPM is quite an important factor, as its underlying data element time_per_stroke underpins quite some calculations, and for OTW training many aim at a very specific SPM.

[HornetMaX]

You mean that to compute stroke rate, the PM5 ceils or rounds the time up to the minute (i.e. 1min29sec -> 2min or 1min respectively), then divides by the number of strokes and then floors the result to an integer (i.e. 18.99 -> 18) ? And that for both intervals, splits and overall session ?

Wow, that looks intentionally evil, as in "I'm doing my best to provide you a number that on occasions will be off in the most incomprehensible way".

So, for splits/intervals of less than 1min (pretty uncommon, yes) the computed stroke rate is total garbage ?

This is not how you calculate SPM during a row (it might be overall, but NOT what is on the display). What the PM5 does is calculate the time per stroke (which you need anyway for many other calculations like power and speed/pace), and do a 60 / time_per_stroke. The PM5 calculates this once per stroke, at the end of the recovery if I'm not mistaken.

Yeah but that's for the instantaneous stroke rate. For the split/interval/session "global" (average) stroke rate, something way more fishy seems to be done.

[JaapvanE]

Yeah but that's for the instantaneous stroke rate. For the split/interval/session "global" (average) stroke rate, something way more fishy seems to be done.

Wouldn't the sane approach be to average the stroke rates across all strokes in a split/interval/session?

The alternative approach would introduce all kind of weird problems, like rounding errors. As some here already suggested: you can't "simply count" the number of strokes in an interval.

Lets do some simple example. A 250 meter interval at a perfect 2:00 pace (thus an exact 60 seconds session) and a perfect distance per stroke of 10.0 meters, you'd do 25 strokes per minute. But when your stroke end is just after the minute mark (could be a millisecond due to startup noise), it would be counted as 24 strokes per minute? From the "you did a 60 seconds session with 24 completed full strokes" perspective, it might be true, but the person rowed a 25 SPM session (hence the DPS of 10 meters).

This approach would introduce all kinds of rounding issues with shorter splits or sessions. All it takes is a 99% completed stroke at the end of an interval to mess up a lot of metrics.

I just compared my last rowing session where my stroke rate slowly increased to compensate for drive strength (after a half marathon yeasterday, the muscles gave up on an additional 5K, but my mind didn't).

This is what OpenRowingMonitor and RowsAndAll produce (please note: ORM calculates SPM twice per stroke with a one decimal precision and averages that across the two calculations, RowsAndAll is told what the splits are afterwards and interpolates the metrics to fit the splits):

#-|SDist|-Split-|-SPace-|-Pwr-|SPM-|AvgHR|MaxHR|DPS-
00|00200|00:54.7|02:16.8|136.6|21.1|106.3|120.0|10.4
01|00300|01:19.2|02:11.9|152.0|21.2|130.0|133.0|10.7
02|00500|02:08.9|02:08.9|163.5|21.4|135.1|138.0|10.9
03|00500|02:07.5|02:07.5|168.6|21.5|140.8|146.0|11.0
04|00500|02:06.6|02:06.6|172.5|21.9|145.8|150.0|10.8
05|00500|02:05.0|02:05.0|179.2|22.1|152.1|155.0|10.9
06|00500|02:05.0|02:05.0|179.1|22.5|154.8|157.0|10.7
07|00500|02:02.6|02:02.6|189.5|22.9|159.5|163.0|10.7
08|00500|02:02.1|02:02.1|191.9|23.1|163.5|166.0|10.6
09|00500|02:01.0|02:01.0|198.1|23.7|167.6|169.0|10.5
10|00300|01:12.3|02:00.5|200.2|24.1|170.2|171.0|10.3
11|00200|00:48.2|02:00.5|199.6|24.4|169.5|171.0|10.2

This is the exact same row recorded with the PM5, ErgData and the Concept2 log:

2:13.6 500m 2:13.6 147 805 21 133
2:08.9 500m 2:08.9 163 862 21 138
2:07.5 500m 2:07.5 169 881 22 146
2:06.6 500m 2:06.6 172 893 22 150
2:05.0 500m 2:05.0 179 916 22 154
2:05.0 500m 2:05.0 179 916 23 155
2:02.7 500m 2:02.7 189 952 23 163
2:02.2 500m 2:02.2 192 960 23 166
2:00.9 500m 2:00.9 198 981 24 168
2:00.5 500m 2:00.5 200 988 24 169

Please note that the first PM5 split is divided across the 00 and 01 ORM split, as is the last PM5 split is divided across 10 and 11 ORM split. There are extremely subtle differences in pace as ORM tends to start 0.5 seconds before the PM5.

Looking at split 2, you see that the average of all ORM splits is 21.4, where C2 nicely rounds this to 21. At split 3, you see that the average of all ORM splits is 21.5, where C2 nicely rounds this to 22. Another interesting one is split 6: ORM has a 22.5 SPM, and C2 again nicely rounds to 23.

I must admit, when I look at the Steady State Half Marathon I see more deviations (see bold lines). First the data from ORM/RowsAndAll:

#-|SDist|-Split-|-SPace-|-Pwr-|SPM-|AvgHR|MaxHR|DPS-
00|00200|00:57.5|02:23.7|117.9|21.1|097.5|112.0|09.9
01|00300|01:22.4|02:17.3|135.3|21.6|118.7|122.0|10.1
02|00500|02:16.8|02:16.8|136.7|21.4|121.4|125.0|10.2
03|00500|02:14.6|02:14.6|143.5|21.1|130.7|133.0|10.6
04|00500|02:14.7|02:14.7|143.1|21.1|136.1|139.0|10.6
05|00500|02:12.8|02:12.8|149.3|21.3|141.4|145.0|10.6
06|00500|02:12.6|02:12.6|150.1|21.3|145.3|148.0|10.6
07|00500|02:11.8|02:11.8|153.0|21.6|146.3|149.0|10.6
08|00500|02:11.3|02:11.3|154.8|21.5|148.6|151.0|10.6
09|00500|02:11.0|02:11.0|155.3|21.6|150.6|153.0|10.6
10|00500|02:12.1|02:12.1|152.1|21.3|151.2|152.0|10.7
11|00500|02:12.4|02:12.4|150.9|21.5|152.5|154.0|10.6
12|00500|02:11.5|02:11.5|153.8|21.7|153.0|157.0|10.5
13|00500|02:11.5|02:11.5|154.2|21.9|154.9|157.0|10.4
14|00500|02:11.1|02:11.1|155.3|21.7|156.3|157.0|10.5
15|00500|02:11.0|02:11.0|155.8|21.7|157.6|159.0|10.5
16|00500|02:11.3|02:11.3|154.7|22.0|156.6|158.0|10.4
17|00500|02:11.4|02:11.4|154.1|22.0|157.0|159.0|10.4
18|00500|02:11.5|02:11.5|153.8|22.0|158.3|160.0|10.4
19|00500|02:11.3|02:11.3|154.4|22.0|158.7|161.0|10.4
20|00500|02:11.2|02:11.2|155.2|22.3|158.6|160.0|10.3
21|00500|02:12.1|02:12.1|152.0|22.4|157.5|161.0|10.1
22|00500|02:12.0|02:12.0|152.5|22.3|157.2|159.0|10.2
23|00500|02:12.5|02:12.5|150.7|22.7|157.2|160.0|10.0
24|00500|02:12.3|02:12.3|150.9|22.6|157.1|159.0|10.0
25|00500|02:12.5|02:12.5|150.4|22.4|158.0|160.0|10.1
26|00500|02:12.3|02:12.3|151.3|22.2|156.5|161.0|10.2
27|00500|02:11.5|02:11.5|153.8|22.0|158.5|161.0|10.4
28|00500|02:11.6|02:11.6|153.7|22.2|158.8|161.0|10.3
29|00500|02:12.6|02:12.6|150.3|22.3|158.3|160.0|10.1
30|00500|02:12.6|02:12.6|150.0|22.1|156.6|160.0|10.2
31|00500|02:13.1|02:13.1|148.5|22.4|157.0|159.0|10.1
32|00500|02:11.6|02:11.6|153.6|22.8|155.9|158.0|10.0
33|00500|02:11.6|02:11.6|153.5|22.9|157.7|159.0|09.9
34|00500|02:12.1|02:12.1|151.8|22.8|157.0|159.0|10.0
35|00500|02:12.6|02:12.6|150.1|22.6|157.5|159.0|10.0
36|00500|02:12.8|02:12.8|149.7|22.6|156.0|157.0|10.0
37|00500|02:11.6|02:11.6|153.9|22.4|158.0|159.0|10.2
38|00500|02:11.2|02:11.2|155.0|22.1|157.7|161.0|10.3
39|00500|02:10.9|02:10.9|155.9|22.2|159.3|161.0|10.3
40|00500|02:09.9|02:09.9|159.7|22.6|161.2|163.0|10.2
41|00500|02:10.2|02:10.2|158.6|22.5|159.9|163.0|10.2
42|00300|01:16.5|02:07.5|169.1|22.7|163.1|164.0|10.3
43|00297|01:14.0|02:04.6|180.5|23.8|164.1|165.0|10.1

Same data from the PM5:

2:19.5 500m 2:19.5 129 743 22 122
2:16.8 500m 2:16.8 137 770 21 125
2:14.6 500m 2:14.6 144 793 21 132
2:14.8 500m 2:14.8 143 791 21 137
2:12.8 500m 2:12.8 149 814 22 145
2:12.6 500m 2:12.6 150 816 21 147
2:11.8 500m 2:11.8 153 826 21 148
2:11.3 500m 2:11.3 155 832 21 149
2:11.2 500m 2:11.2 155 833 22 151
2:12.0 500m 2:12.0 152 823 21 152
2:12.4 500m 2:12.4 151 818 22 153
2:11.5 500m 2:11.5 154 829 21 154
2:11.4 500m 2:11.4 154 830 22 155
2:11.2 500m 2:11.2 155 833 22 156
2:11.0 500m 2:11.0 156 835 22 157
2:11.4 500m 2:11.4 154 830 22 157
2:11.4 500m 2:11.4 154 830 22 155
2:11.5 500m 2:11.5 154 829 22 156
2:11.4 500m 2:11.4 154 830 22 160
2:11.1 500m 2:11.1 155 834 22 160
2:12.1 500m 2:12.1 152 822 22 158
2:11.9 500m 2:11.9 153 824 22 157
2:12.4 500m 2:12.4 151 818 23 157
2:12.4 500m 2:12.4 151 818 23 158
2:12.5 500m 2:12.5 150 817 22 159
2:12.3 500m 2:12.3 151 820 22 157
2:11.5 500m 2:11.5 154 829 22 160
2:11.6 500m 2:11.6 154 828 22 160
2:12.5 500m 2:12.5 150 817 23 150
2:12.7 500m 2:12.7 150 815 22 159
2:13.2 500m 2:13.2 148 809 22 157
2:11.5 500m 2:11.5 154 829 23 157
2:11.6 500m 2:11.6 154 828 23 157
2:12.2 500m 2:12.2 151 821 23 158
2:12.7 500m 2:12.7 150 815 23 157
2:12.7 500m 2:12.7 150 815 23 156
2:11.6 500m 2:11.6 154 828 22 158
2:11.2 500m 2:11.2 155 833 22 158
2:10.9 500m 2:10.9 156 837 22 158
2:09.9 500m 2:09.9 160 849 23 163
2:10.2 500m 2:10.2 159 845 23 155
2:07.1 500m 2:07.1 170 886 23 164
0:23.5 97m 2:01.1 197 977 26 165

What I notice is that these deviations are in areas where the ORM data indicates that SPM did not vary much: the surrounding splits have a more or less same SPM.

I dug deeper (the joy of ORM and RowsAndAll data), and before 2000 meters there was no SPM above 12.5, at that time it "spiked" to 12.6 until 2050 meters, after which it went below 12.5 again until 2730 meters. At 14500 meters, the SPM is around 22.3, where it is actually around 22.1 until the end of the split where it "peaks" to sligthly above 22.5 at 15017 meters.

Could this be an issue we've seen before with heartrate, where the average HR isn't the average at all, but the last measured value?

[HornetMaX]

Yeah but that's for the instantaneous stroke rate. For the split/interval/session "global" (average) stroke rate, something way more fishy seems to be done.

Wouldn't the sane approach be to average the stroke rates across all strokes in a split/interval/session?

The alternative approach would introduce all kind of weird problems, like rounding errors. As some here already suggested: you can't "simply count" the number of strokes in an interval.

Well, as when counting strokes your max absolute error is +/- 1 (EDIT: only -1 in fact) stroke per interval, usual interval lengths (multiple minutes) wouldn't suffer too much.
But averaging stroke times is technically more precise (and can only show wrong stuff if you do something weird with your last partial stroke).
However, if then you round to the nearest integer you're likely to introduce more "error" by doing that than by computing the average wrongly ...

Could this be an issue we've seen before with heartrate, where the average HR isn't the average at all, but the last measured value?

That should be easy to check (even easier than the HR): row a single interval at say SR20, last few secs drop to SR15 and see what gets reported.
I can try this in my next warmup.

[HornetMaX]

Now that I think about it, maybe a way to be precise on short intervals: instead of averaging stroke rate across the interval (which essentially assumes that the last unfinished stroke is done at the stroke average of the interval) you should probably count strokes, then see what's the time between the last full stroke and the end of the interval and divide that by the time of the last full stroke to get the fraction of the last unfinished stroke (to be added to the stroke count). This way you're assuming that the last unfinished stroke was done at the same rate as the previous stroke instead of at the interval rate average.

You can even try to be very subtle:

• last full stroke had a time of 2s (SR30), and happened 1s before the end of the interval: in that case count 1s/2s = 0.5 extra strokes.
• last full stroke had a time of 2s (SR30), and happened 10s (ten !) before the end of the interval: in that case it wouldn't make sense to add 5 extra strokes of course, so maybe just add one (or none at all).

P.S.
I think recently I've see some crazy numbers on the PM5 for very short intervals (I think I was on 250m intervals). The SR was very off at interval start and it progressively went to the "right" value.