On long rides with stops the HR curve drops far below the ride’s average HR, which
can’t happen for a real best-average curve.
Example: a 4.5 h (moving) mountain ride with a couple of hours of summit and coffee
stops, average HR 140. The “this ride” HR curve shows ~135 at 1 h and ~120 from
1h45 onwards. But if the whole 4.5 h averaged 140, every window of 2 h or longer
has to average at least ~137.
I pulled the streams and recomputed the curve. The head unit writes no samples
while auto-paused, so the file has timestamp gaps (the longest one ~25 min).
Filling those gaps with 0 bpm and computing over elapsed time reproduces the
chart exactly, including a small non-monotonic bump around 2 h:
duration gaps as 0 bpm moving time only
30 min ~150 ~157
1 h ~135 ~152
2 h ~123 ~148
3 h ~119 ~149
4 h ~114 ~144
So I’m fairly sure that’s the current implementation. For the power curve treating a
stop as 0 W is correct – you really did produce zero watts. For HR it isn’t: the
heart didn’t stop, the device just stopped recording. The result is that on any ride
with a stop, the curve is only meaningful out to the longest stop-free stretch, and
the 42d / 84d / season curves inherit the same low values at long durations.
Request: compute the HR curve over moving time (i.e. over the recorded samples,
skipping timestamp gaps), or at least drop gaps longer than the “show pauses”
threshold. The same argument applies to any other physiological stream that isn’t
“zero when stopped”, e.g. core temperature.
Turning auto-pause off isn’t a workaround: it would dilute avg HR, avg power, NP,
load and zone times with hours of standing around, and the curve would still be
wrong, just with resting HR in the gaps instead of zero.
@david - is this something you can imagine to implement, maybe as an optional setting