As mentioned in the topic below, there are discrepancies between the power values shown on Garmin Connect and Intervals. Most likely, this is due to differences in the calculation methods. Garmin uses accumulated power (work) over time as the basis, whereas Intervals uses the instantaneous power value recorded for each second.Please see the topic below for more details.
I would like to be able to choose the preferred method, hence the request for an option to use accumulated power for calculations.
AFAIK , accumulated values basically tries to account for dropouts at the headunit level. Internally, the PM will keep a running total. And you’re also right that not all head units will have it.
I will have a look at this when we have finished the huge web app library upgrade we are busy with. It would be very nice to have Intervals.icu power numbers match Garmin’s as this generates a lot of questions. However it is also a big change and it is quite irritating that the second by second numbers Garmin writes to the file do not match the “accumulated power”.
seems like Accumulated Power is only useful for calc the Normalised Power and Averages. Which I believe should already be what is used when Garmin Writes it into the FIT File as SESSION messages?
Intervals.icu doesn’t do anything with accumulated power yet. However we have made the existing interpolation for missed power data more aggressive. Before it would interpolate across a gap of up to 8 seconds, now it will fill in a 30 second gap. This makes quite a big difference for activities with many such gaps.
No interpolation is done if the device was stopped during the gap.
I am not sure if this is an improvement; it could lead to errors as well. Why would you want to interpolate if the data is stored in a running record that is available?
In other words, why not solve the root cause of the discrepancies between the power values shown on Garmin Connect and Intervals?
If I could guess, I am pretty sure, that Garmin interpolates missing data too. And they call this „accumulated power“. How should the powermeter know, when a session starts or ends, to reset the accumulated power data?
Imho it would always be better to optimize the data connection, so that no data drops will occur.
A user sent me a file with less moving time than expected. His Garmin was acting up and freezing creating gaps in the data with accumulated power also not increasing. It is not likely that a 20s gap in a file is real if the device was not paused. This change will fix those kinds of errors and was easy to implement.
I will do additional work soon to check accumulated power if available and use that to decide what the average power should be for the interpolated section, if it looks sane (e.g. has gone up a decent amount compared to the time).
I can’t just use accumulated power for everything because then you can’t edit the power data to get rid of spikes and so on.
I am thinking in the direction of post-processing the data if accumulated power is available.
In the screenshot below (previously shared in the associated topic), you can see that when there is an error between power and accumulated power, the cadence data is also not transmitted and thus shows as zero.
My suggestion would be to smear out the error over the previous rows where cadence is zero, and replace the power values accordingly.
These corrected power values can then be handled the same way as the power values are now processed by intervals.icu.
