Will the correct average HR please stand up?

[Sakly]

In a steady state with varying pace the HR at the end of different splits could end up with higher or lower values, but for a steady state the HR during the piece has no big value at all, so don't bother.

I don't get why you say so. I've done 1H and HMs at steady state for a while, each week.
If the PM5 gives me the real HR average, I can say things like:

• I held the same avg pace and my real avg HR was lower: I've progressed
• I went a bit faster and my real avg HR was a bit higher: maybe I'm on the same level as before.

The current fake avg essentially takes 10 samples (let's imagine the session had 10 splits) and averages them.
This can be thrown off in many ways: I may be drinking at the end of the split, or my mind went a bit astray and I was going too fast/slow at the end of the split. When I burp, my HR goes 5 beats down. Sometimes I change my breathing and this affects HR.
We have all the numbers for a real average, why taking the risk ?

If Polar/Garmin/"whoever has an HR app logging your HR" tells you "Here's your avg heart rate, computed slicing your workout in 5 and averaging the HR at these 5 points" everybody would be laughing hard at this.

Variation shouldn't be high at all, if you do your steady right, you will see a slight HR drift, if any at all.

Steady may not mean slow/zone 2. I may be doing an HM steady at my PB pace + 1-2 seconds. The drift would be more than slight.

As I said, the overall average is a bit weird, but good enough for a steady state, as you can assume your HR will not vary a lot. If you assume it will, you could split the piece in up to 50 'slices', which would give you a very near average compared to the real average, even if your HR varies a lot.

My last HM at 2:03 (not really slow) had 7 splits, variation from 134 to 141 mainly, a spike at the end to 144. Average given by logbook fake average 137 - average by ergdata app 137.
The HM before that at 1:56.3 (not really slow, +~4 to PB pace) had again 7 splits, variation from 153 to 159, fake logbook average of 156, ergdata app average 156. Both HMs had no variation in pace, so HR responded accordingly with only very slight drift and low variation. That is what I think of a steady state behaviour and it will give very near results, even with low amount of splits.

If you know that you have a high HR drift, slicing into more splits is helpful to get nearer results to real average. That's not the case for me personally, but may be different for others.

For the pace it's a different thing, this is a metric the sport is about and nothing for your personal information. So you want the specific metres (which is equivalent to average pace) you have covered to be able to compare to others.

Yeah, the thing about pace was just a provocation
But the same could be said about power: would you like the real avg power or the power at the end of the interval ?
If you "do intervals right", the power at end of interval is more or less like the average in the interval ...

Power is only another calculation of meters or pace or cals. All are "equal", meaning the same. Again, this is the metric the sport is about, no question - you want the average in a log, which represents the whole work done in the piece/split.

During the split/piece I like to see both in real time, as I can track my race plan precisely.

There's no real good reason to not have the real average HR (per interval/split and overall).
And if the "max HR in the split/interval/session" is useful too, let's have this too. Maybe even the min.

For steadies I think I covered above, why there is no real reason for an average of splits at all (variation should be low anyway; only overall average compared to average pace is of interest for improvement, IF you stay even paced in your steady; HR drift has no big influence, but if so, you can split in smaller pieces).
For intervals the end HR has more meaning, as you can see that you can perform the same pace in the interval with a lower end HR or the same end HR with a higher interval pace shows improvement. The average would be quite dependent from the rest between intervals, how your HR drops back.

A technical restriction also comes into play for the PM and logging. It can only be shown a single value for the split and the piece (at least if not the whole display and summary shown after the piece on the PM would be changed). Further the PM probably can only calculate so much data as it does. If you want to calculate running averages for all data and for each split, this would lead to more calculation resources on runtime, which is probably not available.

Anyway, all this could be done in post-processing of the per-split data, if you like to have this data.

[nick rockliff]

In a steady state with varying pace the HR at the end of different splits could end up with higher or lower values, but for a steady state the HR during the piece has no big value at all, so don't bother.

I don't get why you say so. I've done 1H and HMs at steady state for a while, each week.
If the PM5 gives me the real HR average, I can say things like:

• I held the same avg pace and my real avg HR was lower: I've progressed
• I went a bit faster and my real avg HR was a bit higher: maybe I'm on the same level as before.

The current fake avg essentially takes 10 samples (let's imagine the session had 10 splits) and averages them.
This can be thrown off in many ways: I may be drinking at the end of the split, or my mind went a bit astray and I was going too fast/slow at the end of the split. When I burp, my HR goes 5 beats down. Sometimes I change my breathing and this affects HR.
We have all the numbers for a real average, why taking the risk ?

If Polar/Garmin/"whoever has an HR app logging your HR" tells you "Here's your avg heart rate, computed slicing your workout in 5 and averaging the HR at these 5 points" everybody would be laughing hard at this.

Variation shouldn't be high at all, if you do your steady right, you will see a slight HR drift, if any at all.

Steady may not mean slow/zone 2. I may be doing an HM steady at my PB pace + 1-2 seconds. The drift would be more than slight.

As I said, the overall average is a bit weird, but good enough for a steady state, as you can assume your HR will not vary a lot. If you assume it will, you could split the piece in up to 50 'slices', which would give you a very near average compared to the real average, even if your HR varies a lot.

My last HM at 2:03 (not really slow) had 7 splits, variation from 134 to 141 mainly, a spike at the end to 144. Average given by logbook fake average 137 - average by ergdata app 137.
The HM before that at 1:56.3 (not really slow, +~4 to PB pace) had again 7 splits, variation from 153 to 159, fake logbook average of 156, ergdata app average 156. Both HMs had no variation in pace, so HR responded accordingly with only very slight drift and low variation. That is what I think of a steady state behaviour and it will give very near results, even with low amount of splits.

If you know that you have a high HR drift, slicing into more splits is helpful to get nearer results to real average. That's not the case for me personally, but may be different for others.

For the pace it's a different thing, this is a metric the sport is about and nothing for your personal information. So you want the specific metres (which is equivalent to average pace) you have covered to be able to compare to others.

Yeah, the thing about pace was just a provocation
But the same could be said about power: would you like the real avg power or the power at the end of the interval ?
If you "do intervals right", the power at end of interval is more or less like the average in the interval ...

Power is only another calculation of meters or pace or cals. All are "equal", meaning the same. Again, this is the metric the sport is about, no question - you want the average in a log, which represents the whole work done in the piece/split.

During the split/piece I like to see both in real time, as I can track my race plan precisely.

There's no real good reason to not have the real average HR (per interval/split and overall).
And if the "max HR in the split/interval/session" is useful too, let's have this too. Maybe even the min.

For steadies I think I covered above, why there is no real reason for an average of splits at all (variation should be low anyway; only overall average compared to average pace is of interest for improvement, IF you stay even paced in your steady; HR drift has no big influence, but if so, you can split in smaller pieces).
For intervals the end HR has more meaning, as you can see that you can perform the same pace in the interval with a lower end HR or the same end HR with a higher interval pace shows improvement. The average would be quite dependent from the rest between intervals, how your HR drops back.

A technical restriction also comes into play for the PM and logging. It can only be shown a single value for the split and the piece (at least if not the whole display and summary shown after the piece on the PM would be changed). Further the PM probably can only calculate so much data as it does. If you want to calculate running averages for all data and for each split, this would lead to more calculation resources on runtime, which is probably not available.

Anyway, all this could be done in post-processing of the per-split data, if you like to have this data.

In the last 20 years I've never looked at avg HR. The number that I concentrate on is the maximum HR at the end of the session.

[Sakly]

In the last 20 years I've never looked at avg HR. The number that I concentrate on is the maximum HR at the end of the session.

This is also fine, at the end it gives a very similar information about your progress (in a different number).
Average is better suited, if your pace varies, but that shouldn't be the intention, if you want to compare sessions.

[gvcormac]

Power is only another calculation of meters or pace or cals. All are "equal", meaning the same. Again, this is the metric the sport is about, no question - you want the average in a log, which represents the whole work done in the piece/split.

This brings up a question that I've had on my mind for a while, but not yet investigated: How is average power (watts) calculated? Do they just apply the power formula to the average pace (either overall or per split)? If so, this is wrong.

Some day, I will see if I can reverse engineer the answer from my per-stroke data. In the meantime, I bet somebody here knows ...

[HornetMaX]

For intervals the end HR has more meaning, as you can see that you can perform the same pace in the interval with a lower end HR or the same end HR with a higher interval pace shows improvement.

Even when you do an interval fly-and-die style ?
Maybe the max HR (instead of the end HR) would be better.

The average would be quite dependent from the rest between intervals, how your HR drops back.

And that's OK to me, as rest between intervals matter. If I do 3x1500 R3 and my avg HR is different from 3x1500 R7, that makes sense.

A technical restriction also comes into play for the PM and logging. It can only be shown a single value for the split and the piece (at least if not the whole display and summary shown after the piece on the PM would be changed).

Display could be changed to show one metric or the other (avg HR or end/max HR).
Or maybe display could even be left as is, and changes could be done only in the logbook (or in the data sent to logbook). It would be already be better.

Further the PM probably can only calculate so much data as it does. If you want to calculate running averages for all data and for each split, this would lead to more calculation resources on runtime, which is probably not available.

That would surprise me. It would mean the PM5 is currently running on the brink of 100% usage.

Anyway, all this could be done in post-processing of the per-split data, if you like to have this data.

Yeah but the logbook doesn't do it and doing it manually is too much work for such a simple thing: download stroke data, compute the real avg, put it in your own log of all your sessions ...

I'll just notice that:

1. The PM5 (and the logbook) is the only device I know of that does that weird fake avg HR thing. Other apps report a real avg HR (per interval and overall) and often also a per interval/overall max HR. The PM5 does neither of these, it does something else.
2. This seems to trigger periodic questions on this forum. Usually, that's a bad sign.
3. One shouldn't need to do anything special (like row at very constant pace or create 50 splits) to get a simple HR average.

To be honest, the PM5 & logbook never call the metric "Avg HR" (and the online manuals do explain how HR data is stored).
The problem is that this is unexpected and what is expected (real averages) is not there, so people gets confused.

[Sakly]

Power is only another calculation of meters or pace or cals. All are "equal", meaning the same. Again, this is the metric the sport is about, no question - you want the average in a log, which represents the whole work done in the piece/split.

This brings up a question that I've had on my mind for a while, but not yet investigated: How is average power (watts) calculated? Do they just apply the power formula to the average pace (either overall or per split)? If so, this is wrong.

Some day, I will see if I can reverse engineer the answer from my per-stroke data. In the meantime, I bet somebody here knows ...

Your assumption must obviously be wrong, as average pace/power/cals is a real-time metric, thus must be competed at any stroke.

[HornetMaX]

This brings up a question that I've had on my mind for a while, but not yet investigated: How is average power (watts) calculated? Do they just apply the power formula to the average pace (either overall or per split)? If so, this is wrong.

Power [W] = 2.8/((Pace [s]/500)^3)

In words: take your average pace per 500m and convert it to seconds (e.g. a 1:52.3 pace is 112.3 seconds), divide by 500 and cube the result.
Finally divide 2.8 by that number and you have your avg power in watts.

[HornetMaX]

Your assumption must obviously be wrong, as average pace/power/cals is a real-time metric, thus must be competed at any stroke.

The power is computed at every stroke (in the per stroke data).
But average power for an interval (or for the entire session) is computed from average pace with the formula above.
That's easier than doing a real average of all the per-stroke power (and likely even more accurate), because you only need the interval time and distance to compute the average pace and hence the average power.

[Sakly]

Your assumption must obviously be wrong, as average pace/power/cals is a real-time metric, thus must be competed at any stroke.

The power is computed at every stroke (in the per stroke data).
But average power for an interval (or for the entire session) is computed from average pace with the formula above.
That's easier than doing a real average of all the per-stroke power (and likely even more accurate), because you only need the interval time and distance to compute the average pace and hence the average power.

When a metric is calculated every stroke and a real time average is provided, the average must be computed every stroke as well. So I assume the PM5 takes the calculated value from the real-time average and not a calculated value from all previous data points, because it must store all of them in this case. Again, more resources needed, result not better.

[hikeplusrow]

Your assumption must obviously be wrong, as average pace/power/cals is a real-time metric, thus must be competed at any stroke.

The power is computed at every stroke (in the per stroke data).
But average power for an interval (or for the entire session) is computed from average pace with the formula above.
That's easier than doing a real average of all the per-stroke power (and likely even more accurate), because you only need the interval time and distance to compute the average pace and hence the average power.

I use power, and have noticed that, at the end of every programmed split, the average power reading resets itself and then climbs back up to the current average.

[Sakly]

For intervals the end HR has more meaning, as you can see that you can perform the same pace in the interval with a lower end HR or the same end HR with a higher interval pace shows improvement.

Even when you do an interval fly-and-die style ?
Maybe the max HR (instead of the end HR) would be better.

I never observed an interval where my HR at the end was lower than during the interval. If I break down during any of the intervals so much, that I need to paddle/limp home, that is a void piece for me and really not a base for comparison of improvements in this specific workout (probably except the last interval in the session).

The average would be quite dependent from the rest between intervals, how your HR drops back.

And that's OK to me, as rest between intervals matter. If I do 3x1500 R3 and my avg HR is different from 3x1500 R7, that makes sense.

Sure, but these sessions wouldn't be a base for comparison.
At interval sessions I typically use the pace metric as base for comparison, as it is very likely to reach max HR in every of the intervals (if not really short or mostly untrained and this not reaching full potential).

A technical restriction also comes into play for the PM and logging. It can only be shown a single value for the split and the piece (at least if not the whole display and summary shown after the piece on the PM would be changed).

Display could be changed to show one metric or the other (avg HR or end/max HR).
Or maybe display could even be left as is, and changes could be done only in the logbook (or in the data sent to logbook). It would be already be better.

Sure, anything can be changed. But you need to decide what you want to show as summary and probably you don't want to overwhelm with all different kind of data in a summary.
For the logbook I agree, there could be some table with more details and filter options or whatever one likes and is able to be computed from per stroke data.

Further the PM probably can only calculate so much data as it does. If you want to calculate running averages for all data and for each split, this would lead to more calculation resources on runtime, which is probably not available.

That would surprise me. It would mean the PM5 is currently running on the brink of 100% usage.

In no way it would be a surprise. In automotive it is very usual to run a CPU at +95% or higher load. This is the most cost effective, as you can use the smallest CPU, which can handle your needs.
Observations like losing BT connection during force curve display usage are indicators that CPU load IS high.

Anyway, all this could be done in post-processing of the per-split data, if you like to have this data.

Yeah but the logbook doesn't do it and doing it manually is too much work for such a simple thing: download stroke data, compute the real avg, put it in your own log of all your sessions ...

I'll just notice that:

1. The PM5 (and the logbook) is the only device I know of that does that weird fake avg HR thing. Other apps report a real avg HR (per interval and overall) and often also a per interval/overall max HR. The PM5 does neither of these, it does something else.
2. This seems to trigger periodic questions on this forum. Usually, that's a bad sign.
3. One shouldn't need to do anything special (like row at very constant pace or create 50 splits) to get a simple HR average.

To be honest, the PM5 & logbook never call the metric "Avg HR" (and the online manuals do explain how HR data is stored).
The problem is that this is unexpected and what is expected (real averages) is not there, so people gets confused.

Now you are comparing other APPs to a PM, which is running a much less powerful CPU and memory. My smartphone has 8 cores running at GHz clocks with several GB memory access. A PM does not...
Anyway, we won't get on the same page for this, we have a different view on it and that's fine.
Someone who is very interested in detailed data and metrics can do so, someone who only is interested in the real average HR can use the value from ergdata instead of logbook, as this is the correct one. Both need to use ergdata anyway to get the data.
If you only want to get average HR, you could also use any HR logging app in parallel, if you like.

[HornetMaX]

Your assumption must obviously be wrong, as average pace/power/cals is a real-time metric, thus must be competed at any stroke.

The power is computed at every stroke (in the per stroke data).
But average power for an interval (or for the entire session) is computed from average pace with the formula above.
That's easier than doing a real average of all the per-stroke power (and likely even more accurate), because you only need the interval time and distance to compute the average pace and hence the average power.

When a metric is calculated every stroke and a real time average is provided, the average must be computed every stroke as well. So I assume the PM5 takes the calculated value from the real-time average and not a calculated value from all previous data points, because it must store all of them in this case. Again, more resources needed, result not better.

I'm not sure what you mean here. The pM5 stores everything anyway in the per-stroke data, so it's not a matter of less resources needed.
In principle if you take the average of all the per stroke powers you get the same number as taking the power computer from overall distance and overall time. The latter is just easier to do (you don't need per-stroke data) and likely better (as in the former was you have rounding errors, effect of discretizing and sampling etc).

You can take one of your sessions, use the formula I gave and see you get the same number as the logbook.

[Sakly]

The power is computed at every stroke (in the per stroke data).
But average power for an interval (or for the entire session) is computed from average pace with the formula above.
That's easier than doing a real average of all the per-stroke power (and likely even more accurate), because you only need the interval time and distance to compute the average pace and hence the average power.

When a metric is calculated every stroke and a real time average is provided, the average must be computed every stroke as well. So I assume the PM5 takes the calculated value from the real-time average and not a calculated value from all previous data points, because it must store all of them in this case. Again, more resources needed, result not better.

I'm not sure what you mean here. The pM5 stores everything anyway in the per-stroke data, so it's not a matter of less resources needed.
In principle if you take the average of all the per stroke powers you get the same number as taking the power computer from overall distance and overall time. The latter is just easier to do (you don't need per-stroke data) and likely better (as in the former was you have rounding errors, effect of discretizing and sampling etc).

You can take one of your sessions, use the formula I gave and see you get the same number as the logbook.

No, it does not. You only get per-stroke data, if you use ergdata.
A running average will be computed in the most precise format the CPU can handle (not from the shown value of the PM display) , thus no computation errors like mentioned.

[HornetMaX]

Now you are comparing other APPs to a PM, which is running a much less powerful CPU and memory.

Not necessarily: as I said, if the logbook shows the real avg, that would avoid 99% of the issue.

If you only want to get average HR, you could also use any HR logging app in parallel, if you like.

The point is that it's not in the logbook, where at least some people seem to expect it to be.

[Sakly]

Now you are comparing other APPs to a PM, which is running a much less powerful CPU and memory.

Not necessarily: as I said, if the logbook shows the real avg, that would avoid 99% of the issue.

If you only want to get average HR, you could also use any HR logging app in parallel, if you like.

The point is that it's not in the logbook, where at least some people seem to expect it to be.

Yes, both right.
The logbook table is the mirror of the PM. As PM does not calculate HR average during the session, it "cannot" be part of it.
Sure, you could do a case decision and put HR data from ergdata in, if used, otherwise put PM data in that row. But if ergdata was used, this data point is there in the app and can be looked up.

As I wrote, we won't come to the same line and think different about it, which is ok