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

Question

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?)

Answer 1

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.

Answer 2

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.)

Answer 3

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.