How Time_Moving and/or Distance is accumulated?

[José Luis García Pallero]

Hello:

I have in my Overview tiles the metrics Time_Moving, Distance and Average_Speed metrics. Apparently, for individual rides the average speed computed as Distance/Time_Moving is the same (at least to the first decimal place) to Average_Speed. 

But in Trend view the difference between Distance/Time_Moving and Average_Speed is greater and differs about 0.1 km/h or more. Some examples:

Time_Moving: 234:59:37

Distance: 7001.478 km

Average_Speed: 29.9 km/h

Distance/Time_Moving = 7001.478/(234+59/60+37/3600) = 29.794 ~ 29.8

Time_Moving: 34:41:20

Distance: 962.319 km

Average_Speed: 27.9 km/h

Distance/Time_Moving = 962.319/(34+41/60+20/3600) = 27.741 ~ 27.7

Time_Moving: 99:11:04

Distance: 3109.036 km

Average_Speed: 31.7 km/h

Distance/Time_Moving = 3109.036/(99+11/60+4/3600) = 31.346 ~ 31.3

So, how is Average_Speed computed and Time_Moving and Distance accumulated?

[Ale Martinez]

Time_Moving and Distance are total type metrics, so they accumulate by sum, Average_Speed should use Time_Moving as count, but it doesn’t, so it defaults to Duration which likely explain the difference on aggregation:  https://github.com/GoldenCheetah/GoldenCheetah/blob/62993743d9870fab8cca8048fc51913dec4bcf66/src/Metrics/BasicRideMetrics.cpp#L1049-L1057

[Ale Martinez]

I fixed this in master. 

[José Luis García Pallero]

Thanks!

El dom, 28 abr 2024 a las 20:51, Ale Martinez
(<amtri...@gmail.com>) escribió:

> --
> _______________________________________________
> Golden-Cheetah-Users mailing list
> golden-che...@googlegroups.com
> http://groups.google.com/group/golden-cheetah-users?hl=en
> ---
> You received this message because you are subscribed to the Google Groups "golden-cheetah-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golden-cheetah-u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/golden-cheetah-users/ce49fa1a-7756-4429-8836-0f90292fe939n%40googlegroups.com.



--
*****************************************
José Luis García Pallero
jgpa...@gmail.com
(o<
/ / \
V_/_
Use Debian GNU/Linux and enjoy!
*****************************************

[José Luis García Pallero]

Hi again:

Inspecting in detail my data, I think the problem is not due to the
use of Duration, as in my case Duration stores a much bigger value
(hours due to ride coffee breaks) than Time_Moving.

I think the source of the difference could be the auto pause function
of my Garmin. I have configured the auto pause not at 0 speed, but at
8 km/h, i.e., when I stop at a traffic light the heead unit pauses the
activity when the speed is less than 8 km/h. I don't know how this
feature is reflected in the FIT file (are the points with speed>0
stored?), but GoldenCheetah considers valid a point when (point->kph >
0.0). For example, in my today's ride the Time_Moving in GoldenCheetah
is 2:30:28, but in Garmin Connect is 2:29:57 (I stopped at four or
five traffic lights). Then, for long periods in Trends it is possible
that these small differences add up and produce the slightly
difference in Average_Speed. So, if for Average_Speed computation
Duration is not used nor accumulated Time_Moving, which time is
employed?

Best regards

El dom, 28 abr 2024 a las 20:58, José Luis García Pallero
(<jgpa...@gmail.com>) escribió:

[Ale Martinez]

El domingo, 28 de abril de 2024 a la(s) 4:15:32 p.m. UTC-3, José Luis García Pallero escribió:

Hi again:

Inspecting in detail my data, I think the problem is not due to the
use of Duration, as in my case Duration stores a much bigger value
(hours due to ride coffee breaks) than Time_Moving.

Difference is small because Duration is used, instead of Time_Moving, to weight the averages on aggregation.

 

I think the source of the difference could be the auto pause function
of my Garmin. I have configured the auto pause not at 0 speed, but at
8 km/h, i.e., when I stop at a traffic light the heead unit pauses the
activity when the speed is less than 8 km/h. I don't know how this
feature is reflected in the FIT file (are the points with speed>0
stored?)

Pauses will be present as gaps in recording, either manual or auto, but you could look at Raw Data for such files to find out...

 

, but GoldenCheetah considers valid a point when (point->kph >
0.0). For example, in my today's ride the Time_Moving in GoldenCheetah
is 2:30:28, but in Garmin Connect is 2:29:57 (I stopped at four or
five traffic lights). Then, for long periods in Trends it is possible
that these small differences add up and produce the slightly
difference in Average_Speed. So, if for Average_Speed computation
Duration is not used nor accumulated Time_Moving, which time is
employed?

You can look at the code linked in my previous response. Try the code with the fix and then lets talk again.