Norm Power is really high

Bug Reports
1

First of, really enjoying the website. A lot of very usefull features.

Yesterday I did a ride with an average wattage of 259w, strava had the average watts to 290. However the norm watt output for intervals.icu is 370.
I think this number is really high, I downloaded the data and did a 30 second moving average removing zeros and could not replicate it.

Is it a bug, or is there something to the norm power that I dont understand?
Link to ride on intervals.icu Intervals.icu
Link to strava ride 25.5 km Ride Activity on March 9, 2021 by Mads Schnoor N. on Strava

2

NP is a little more complicated than just a 30s rolling average. This article explains the Training Peaks calculation Formulas from ‘Training and Racing with a Power Meter’ | by Aart Goossens | Critical Powers | Medium

I pulled your file from Strava (hope you don’t mind) and came up with an NP value of 307W. I’ve no idea how Strava calculates Weighted avg Power (290W in this case) but its not just a simple average of the data.

3

Thanks for the response.
Don’t mind at all!
307 w sounds reasonable. But intervals.icu gives me 370 watts. Which I can’t figure out how is estimated?

4

I get 310 using the formula in the link you’ve provided. The difference I suspect has something to do with the increments. Nevertheless both estimates are a long way from the 370 provided by Intervals.icu

5

From Sauce for strava:

Screenshot_1
Screenshot_11618×600 148 KB

6

I’ve just checked a couple of my old files and they agree with interval.icu. I’m sure David will know what’s going on in this case.

7

Usually it is spot on with Garmin Connect when I’m riding outdoors as well. It might be something with this ride in particular.

9

Tx everyone for checking this data. The power trace has a number of drop-outs that have been automatically fixed by Intervals.icu when computing the ride stats. In this example the power goes 712w, 398w, 0w, 298w, 409w. That zero is replaced with 398w.

Screen Shot 2021-03-10 at 17.19.03

I suspect that is why the NP is much higher. Did you do much freewheeling?

I need to download your data to find out for sure. That takes a while so will do tonight.

10

Thanks for addressing this :slight_smile:

I did in fact do a lot of freewheeling. I raced on the indoor platform RGT. The dynamics are such that you easily get dropped of you are not cautious. So I tend to do short bursts of power and then freewheel a bit. That might set of the calculation. But my FTP is 370ish and it didn’t feel like a threshold effort.

11

I have figured this out. The ride data is missing 212 seconds scattered throughout. Intervals.icu interpolates these missing data points which is why the normalised power is higher. Intervals.icu is correct IMO. Its not correct to just calculate the 30s moving average for the NP calc over the points that are there. You need to work on a 1 point per second interpolated series.

In this example the data for 2283 is missing:

time watts
2280 1193
2281 1207
2282 618
2284 1210
2285 1497

Intervals.icu interpolates and fills it in:

2283 914
1 Like
12

Interesting.
I am not sure I agree with you on this one. I think the interpolation of missing depends on the reason why there are missings in the first place. Do you know that? I think in his case the normalized power is inflated, and the better solution would be to ignore the missings. I get why you wrote it like that in the first place, and it might not be possible to differentiate between different types of missing variables.

13

To elaborate a bit on this point. If the observations where missing at random, the np would be approximately the same as without the missings. But clearly something is going on, such that it is mainly the higher power numbers that is missing.

14

You have to fill in something for the missing data points. NP is calculated from a 30 second moving average, not a 30 point moving average. I think mostly those missing points are likely to be real power so interpolating is probably the best option. Its not like you weren’t putting the power down at any point in that end of race sprint :slight_smile:

Put it another way: If you just calculate NP over the points and not seconds you are leaving out 3 minutes and 32 seconds of power from a 38 minute race.

15

That’s a good point :slight_smile:

Does that mean that the average power is biased? Since it is calculated on the same date, the 3 minutes of data points must be missing in that calculation as well.

16

I was intrigued by this so went back to your TCX file I downloaded from Strava. Firstly, no idea if Strava has done anything to the file in the background before I get my hands on it so my conclusions are caveated by that.

  1. In the raw TCX file whole lines are missing for those timestamps, i.e. HR, cadence etc, not just power, so it appears for some reason those time points were just not recorded.

  2. I agree with David, to correctly calculate NP you need to fill in the blanks as these were not legitimate zero powers, rather they were missing data

  3. When I did this using simple linear interpolation I still came up with an NP of 312W, so lower than the 370W you’re seeing (without filling in the blanks you get 307W)

  4. Avg Power with filled in blanks is 258.3W as opposed to 257.5W with the raw data, so this doesn’t seems to affect that.

Hope this helps.

17

Not sure what you mean by biased? Intervals.icu calculates the total Joules of energy expended during the ride from the 1s interpolated power stream by just adding up all the points. The average power is J / secs.

The secs part is the “recording time” which is elapsed time with coffee stop pauses (more than 30s time gap) removed. If recording time is not available then elapsed time is used.

Hmm … I hope you have a bug and not me … :slight_smile: I get 310w with blanks ignored and 372w with simple linear interpolation. I checked his on a couple of Google sheets:

This one has the interpolated data as used by Intervals.icu:

18

I am embarrassed to admit that my moving average calculation had a bug that caused the values for the last 30s to be overestimated. Normally you wouldn’t notice but @Mads_Schnoor_Nielsen did a massive sprint at the end of that ride. Tx everyone and especially @John_Peters_endura.f for helping with this.

I will deploy the fix Sunday AM (GMT+2).

3 Likes