# Why would a bike computer calculate distance accurately but average speed inaccurately?

My otherwise reliable non-GPS bike computer calculates an extremely inaccurate average speed for my morning commutes. After my ride this morning, I read the following values from the display (units are in miles and miles per hour):

• trip dist: 1.70
• trip time: 00:06:29
• avg speed: 16.47
• max speed: 23.86

However, the actual average speed is: 1.7 / (6 / 60 + 29 / 3600) = 15.73. The reported value is off by almost 5%. This bothers me because I like to set goals to improve my average speed (for my traffic-light-enforced "interval training"), but the inaccuracy is higher than the 0.5 mph increments I reach for.

I would have assumed that a bike computer would compute average speed simply by dividing "trip dist" by "trip time"? What is it computing, and why is it different than the true average?

(slightly related: Why aren't average speeds computed over distance?)

• Does your computer stop counting at stops? ie: is 'trip time' the total time and your 'ride time' is located somewhere else? There's a difference between average speed and average moving speed. Aug 6, 2013 at 23:45
• It does stop accumulating time at stops, but it also stops updating the average speed at stops. So as far as I can tell, the "trip time" and "avg speed" are supposed to be moving time and average moving speed. Aug 7, 2013 at 0:00
• I say, if it wants to tell me I'm doing faster than I really am, I'm not going to argue with it. Aug 7, 2013 at 0:11
• what kind of computer is it? GPS, GPS + sensor or just the good old computer? Maybe that can help finding the source of the difference. I think GPS + sensor is the most accurate one, it can calibrate the wheel size. GPS only might be susceptible to loss of signal, like going inside a tunnel. That always gives a jump on my average speed because it thought I stopped at the start of a tunnel and got at the end at the speed of light. Aug 7, 2013 at 2:54
• @CareyGregory but if it were due to that, it would push the average speed to lower than you'd expect, not higher. Aug 7, 2013 at 8:29

Okay, this actually requires some knowledge of how these little computers work internally. Bicycle computers need to be extremely low-power, so the easiest way to do this is to make them very simple. Normal computers are able to use non-integer numbers. An integer is 1,2,3,4, etc., non-integer means for instance 1/2, 0.5762 or pi. Computers use so-called floating point numbers to represent non-integer numbers.

However, floating point numbers are very hard to use for these small computers compared to integers. So, they don't! They only use integers to do all necessary calculations, and with very little exceptions they are all limited to 8-bit integers. An 8-bit integer can store a value of 0-255. So, any calculation will (a) not be more precise than a whole number (e.g.: dividing 8 by 5 will yield 1 instead of 1.6 because you cannot represent numbers behind the decimal point) and (b) cannot exceed beyond the range of 0-255.

It's even worse: most bicycle computers can't even do math. Well, they can usually add and multiply, but they cannot divide or subtract. They are really super bare bones stuff, because they have to survive for a couple years on the juice in a single coin cell.

So, how does this affect the calculation of distance, speed and eventually average speed? Well, a bike computer has only 2 inputs: a very precise timer (usually outputting between 1024 and 32768 pulses per second) and a pulse input from a magnet on your wheel. It also knows how long the circumference of your wheel is. So, in order to calculate your current speed it does the following:

• wait for a pulse from your wheel
• start a timer
• when the next wheel pulse arrives, stop the timer
• divide your wheel circumference by the time and use a lookup table to convert this into something human-readable.

So, let's say the timer runs at 1024Hz and your bike wheel turns at about 5 rotations per second (36km/h or 22mph). This would mean that you would count floor(1024/5)=204 timer ticks per wheel rotation. In the little processor is a lookup table that relates those 204 ticks to your specific wheel size (which you programmed in) and then finds what speed needs to be displayed on your screen. It doesn't actually calculate it, because it's very hard for that processor to do such things. Besides, this table only needs to be a couple wheel sizes by a few tens or maybe 100 different time values. For instance a 5x100 table, pretty small in computer terms.

Distance is very easy to calculate: just multiply wheel circumference by the number of rotations. Then use another lookup table to relate this to something displayable. This too only requires a small lookup table.

However, average speed is not something that can be put into a reasonable-size lookup table. There are just too many possible trip distance and trip time values that can occur. So these computers have to cheat somehow: either they need to use the very limited math capabilities they have, or they need to round some things down or look for the nearest average value. This is exactly what your bike computer is doing.

There are more advanced bicycle computers, especially nowadays. With older designs, you could really see this lookup table-nature of operation: it could display for instance 22.3 km/h and 22.5, but not 22.4. Why? It was not in the lookup table. No matter how hard you would try to ride exactly at 22.4 km/h, it would never actually display this value. Also, older designs would only allow you to enter the inch-size of your tires, not the actual precise circumference in mm.

Nowadays, there are actually bike computers that can handle more 'complex' mathematical operations and use better number representations (either 16-bit integers or floating point numbers) to get to a better estimate of your speed and averages.

• This answer does a fantastic job of explaining the limitations of processing in a bike computer. But I think there might be just a bit more to the average thing because the bike computer shows average speeds changing in 0.1 mph increments but the error is much higher than this. Is there maybe some way that it's using a lookup table to find the average speed in discrete time intervals and then it has some way of "cheating" to combine these? Aug 7, 2013 at 14:37
• Of course, there are a gazillion permutations of these calculation tricks that may happen to calculate averages. I wrote this answer to convey how these computers 'cheat', but the specific cheat for this calculation is not set in stone or anything. Aug 7, 2013 at 14:58
• I'm not sure I like your assumption about using a lookup table for division. Doing the simple division necessary to calculate average speed to 3 digits is well within the capabilities of a simple microprocessor. It's more likely that either there was some sloppy programming in this case or some sort of "running average" approach is being used. Aug 7, 2013 at 16:26
• I should clarify further (and feel free to edit this in in some meaningful way): I am just trying to convey the types of 'cheating' these processors do to get to absolute lowest power. Lookup tables are much, much more power efficient than an ALU. Especially on the earlier designs, these things didn't even have any way to calculate anything, they just had counters and lookup tables - implemented in a ridiculously small amount of transistors. I am not claiming that this is exactly how all bike computers work now, but just trying to get people into the mindset of these devices. Aug 7, 2013 at 16:29
• @user26129 You said it can't do subtraction. I'm not even sure that bigger cpus had hardware subtraction because you can subtract by adding the number's two's complement. Also, even high end risc cpus didn't (don't?) have divide operation. I don't see see how you can see "lookup table-nature of operation". If floating point was emulated (with 8-bit integer), it'd still show the behavior as you describe and that's the nature of floating point. Even in larger cpu it'd behave like that, just less noticeably. Aug 8, 2013 at 4:37

I would suspect the average-speed calculation is performed with insufficient numeric accuracy, for all the reasons detailed in the other answer (essentially, making the battery last a long time)

For example, lets say the distance is stored in metres, and the time in seconds, e.g:

``````distance = int(1.7 * 1000) # in metres
time = int(6*60 + 29) # in seconds
``````

If I wanted to calculate the avg-speed without using floating-point calculations, my first attempt might be this:

``````(distance*10 // time*10 * 36) / (10*10*10) # result: 15.48
# The `36` is (60sec*60sec) * 1000m to convert to m/s to km/h, multiplied by 10
``````

..this would result in a value of 15.48 km/h. An embedded device would likely perform the calculation quite differently and have different limitations, but this shows the general issue

Compared this to the floating point equivalent:

``````float(distance) / float(time) * 3.6 # result: ~15.732
``````

(note: the above calculations were done in Python 3, `/` is float division, `//` is integer division.)

• but this goes into the wrong direction: 15.73 is the avg speed @amcnabb calculates from the the measured distance and time. 16.47 is the avg. speed that the computer calculates and which is bigger than the avg. calculated "by hand". In your example the integer calculation would make the situation even worse. Aug 8, 2013 at 17:52
• @BenediktBauer Oops, thanks for spotting my, err, numeric dyslexia.. but, the main point was to demonstrate how limitations in the calculation would introduce errors. Edited the question to clarify this a bit
– dbr
Aug 9, 2013 at 13:02

I think the clue lies in the short distance you ride as there are two uncertainty points in the way your computer works that have a large impact if the distances are short but more or less vanish for longer distances.

First lets see how a digital bike computer works: basically it does two things as it counts how often the little spoke magnet has passed its sensor, giving it (with knowledge of the wheel circumference) the travelled distance, and it measures the time between two magnet passages to get the speed. If the magnet has just passed the computer is just waiting for the next time to pass which means that the computer is deaf and blind during this time.

If you stop your bike now there's some awkward situation for your computer as it waits for the next impulse from the passing magnet which will never come as the wheel doesn't turn anymore. You can watch this moment on your computers trip timer as the seconds of the stop watch are still counting for about 3 to 5 seconds although you're already standing. This is the time where the computer waits for the the next impulse to come but doesn't get one.

Here it gets a bit speculative: I would guess that that your computer has basically two counters, one for the number of wheel rotations and one for the time needed for those rotations, while the trip time is running on a separate counter that is just for the time output but is not taken into calculations. The difference between the rotation time counter (RTC) and the stop watch counter (SWC) is that the RTC contains only the time where the computer can tell for sure that the wheel was turning, while the SWC also contains time where the computer was waiting if the wheel is still turning. As cycling computers are primarily constructed for longer rides (where you normally don't stop every five minutes) this discrepancy won't make a big effect there, but in your case with a very short measurement time it might make quite an effect.

If you calculate back from the average your computer has to the time it should have used, you get 6 min 12 sec which is a difference of 17 secs to your computer's trip time. You write something about "traffic light-enforced interval training", so I guess you have to stop at some of them. If you now assume that your trip time will count about 3 to 5 extra seconds at each stop, it will take only about 3 to 5 stops to get the time difference.