What bizarre averaging algorithm is my bike computer using?

Question

My bike computer can show me various figures such as distance travelled, time elapsed, max speed, average speed, current speed etc. I usually have it set to display the current and average speeds.

You can reset the distance and time (both together) at any point; the max and average speeds are calculated since the last reset. The distance is taken from the wheel sensor (you have to calibrate it initially to tell it the circumference of your wheel) and the time is from its own real-time clock.

Now, quite often while I am cycling along, I will be going at well above the displayed average speed and yet the average speed shown will go down. As a concrete example, this evening I was cycling home and my current speed was holding steady at 19.5 mph; my average was showing 12.6 mph and as I looked at it, it clicked downwards to 12.5.

What I'm trying to work out is what kind of bizarre averaging algorithm it is using that can give this effect. I can't believe it's doing any kind of fancy stuff other than total distance / total time. I guess it must be some sort of rounding / boundary condition but I can't work out what. Any suggestions?

[I asked this around the office at work but nobody had any ideas other than that I should stop worrying about these sorts of details! Hey, I have to think about something when I'm cycling, it's 9 miles each way...]

Answer 1

I'm going to guess that it has a history of a certain number of data points and displays the average over them. As time goes on the older points are pushed off.

If you were going faster at the point far enough back to be the end of the history pushing off a point will lower your average.

Answer 2

It's really a motivational technique.

Answer 3

It's timing between rotations of the wheel but it can easily miss a pass of the magnet over the sensor because of a bump in the road or noise.
So you measure a speed half the correct value for that one data point, it then does a running average so that bad point pollutes the speed for the next few revolutions.

Answer 4

The system needs to sample at some (probably constant) rate.

In order to compute a moving average it only stores at most N datapoints.

So in order to update the average it must drop one of its stored points to get a new average, and if the dropped point was faster than your current speed, the moving average would drop.

Answer 5

It's not a running average, it's supposed to be the average for the whole trip, right? At least that's what I always assumed mine was doing.

I've noticed that effect too. My theory is that both the clock and the distance counter it uses for the average have a fairly low resolution, so sometimes the clock counter ticks up while the distance counter stays steady, and you get the dip. For Example:

dist time   spd
8.5 40.1   12.72
8.5 40.2   12.69

If they are using an integer processor and fixed point, truncation would make the drop appear even larger