PM5 averages: how “deep” is the data

[StevenWayne]

I have a question regarding PM5 and ErgData averages. How far back does the software “look” when using data to calculate averages?

Example: If a total workout average pace is 2:00 min/500m, did the software look back at the entire workout to get this average?

Why do I ask? I notice that rowing with stronger than average pace, even at the final minute of a workout, will lower the average min/500m time. This is understandable if one is rowing, say, 10 minutes and there’s 10 minutes worth of data to average...fast rowing could affect the average. But if one is rowing for 60 minutes, with a huge data set, then fast rowing for the final minute should barely affect the average. With a half marathon, it would be nearly impossible to move the average with a finishing sprint of even several minutes. But in my experience, sprint finishes do affect the average even on longer rows, and seemingly by the same as it would with a short workout. This has me inclined to think the software “reads” back only a certain amount of data to calculate the averages.

Is that true, or is my pretzel logic half-baked? Thanks

[Citroen]

It's done on the split boundaries. It's not an average, it's an instantaneous reading at the split.

[Carl Watts]

I don't know what your using but I use the "predicted finish" so its like you said, the longer the row and the closer you are to the finish, even a sprint will not change the numbers much, this is what you would expect. To many people overthinking it I feel.

[StevenWayne]

Thanks, I will have to watch the predicted finish, Carl. That's not something I even looked at, but will now. I'm looking at overall average pace (xxx min/500m). Predicted finish, okay, I see it here on one screen of the PM5.

Thank you, Citroen. Ah, an instantaneous reading at the split, that's why I can "move the needle" for my particular split. I see. And then the overall average at the end of the workout must be an average of all the split boundaries, so hard to "budge" that number.

I wonder if I can "move the needle" if I do a 30 minute row with a single 30 minute split (probably can't move it), or a 30 minute row with 30 one minute splits (almost instantaneous readouts). Fun, I may try it.

[Ombrax]

Maybe I don't understand the question, but average is average, so to calculate that all you need it the total time and total distance, and you can calculate the average for the entire piece. It doesn't matter if you row at a pace of 00:30 / 500m for part of it, and 50:00 / 500m for another part. It all comes out in the end, so the erg doesn't need to know that to calculate your average. Now for individual subsets of an entire effort, then yes, the averages for those parts will obviously be affected.

[Citroen]

The average is naïve. Sum the splits and divide by the number of splits (even if you get a short split). Nothing more sophisticated than that.

[nick rockliff]

The average is naïve. Sum the splits and divide by the number of splits (even if you get a short split). Nothing more sophisticated than that.

But if you set a say 60 min session and row as a single split it must take the data from the start to the end of the 60 mins?

[StevenWayne]

But if you set a say 60 min session and row as a single split it must take the data from the start to the end of the 60 mins?
[/quote]

Exactly, Nick. You understand the gist of the question.

[Citroen]

The average is naïve. Sum the splits and divide by the number of splits (even if you get a short split). Nothing more sophisticated than that.

But if you set a say 60 min session and row as a single split it must take the data from the start to the end of the 60 mins?

Nope. it takes the very last reading at the end of the split.
There's one split so that reading becomes the simple average.

It really is that bad.

[Carl Watts]

Have a play with ErgData if you want more "Data". For me personally the PM5 had everything I needed except for a stroke counter and ErgData finally came out and solved that problem and I was able to retire my soggy sweat soaked cardboard shoebox full of electronics to count the seat every time it was at the end of the drive. ErgData also has the most information for your C2 online Logbook.

[nick rockliff]

The average is naïve. Sum the splits and divide by the number of splits (even if you get a short split). Nothing more sophisticated than that.

But if you set a say 60 min session and row as a single split it must take the data from the start to the end of the 60 mins?

Nope. it takes the very last reading at the end of the split.
There's one split so that reading becomes the simple average.

It really is that bad.

But the PM shows two split avarages, one for the session and one for the split. The session average changes constantly throughout the session not at the end of each split.

[Ombrax]

But if you set a say 60 min session and row as a single split it must take the data from the start to the end of the 60 mins?

If you want average speed or pace it doesn't need "all the data," only the total distance and time (since it's just one piece).

If you want average HR that's a separate question, because unlike distance, individual heartbeats don't "accumulate." (Although that's certainly one way - and possibly the simplest way - avg HR could be calculated over your 60 min example.)

[Citroen]

The averaging for everything is done in the same naïve way.

Grab an instantaneous reading at the end of a split. Sum the readings and divide by the number of splits. That's the same for rate, calories, HR, everything.

That's how it's worked since the PM2. Yes it is a crap design. It's not changed despite the PMs getting ever more RAM, ever more flash ROM and ever faster processors.

A rolling average would be a better idea.

[Ombrax]

The averaging for everything is done in the same naïve way.

Grab an instantaneous reading at the end of a split. Sum the readings and divide by the number of splits. That's the same for rate, calories, HR, everything.

That's how it's worked since the PM2. Yes it is a crap design. It's not changed despite the PMs getting ever more RAM, ever more flash ROM and ever faster processors.

In that case, how does the PM project the final time (or distance, depending on what you're doing) when you set it to display that?
It must have some sort of running calculation (and a current instantaneous rate) in order to do that.

[Carl Watts]

The projected finish looks at the total time or distance to that point in your row and the pace of the last stroke that if you did that exact pace until the end thats your final time or distance. Pretty logical.

I use it all the time in my rows to hit a predetermined finish time or distance. It allows you to start fast and finish slow because the hard work is already done. Its fun to try and hit the exact finish time down to the last 0.1sec. Hit and miss of course as it only shows your finish time to the nearest second but you can get your average pace for the row to bang on as you hit the finish line and you will come in +/-0.2 sec every time.