What does a cyclocomputer actually measure for calculating the speed of the bike? Is it the time for one revolution $T$ or is it the number of revolutions $n$ per given time $t_0$?

If the radius of the wheel is $R$ then you get the speed of the bike $v$ by

$v = 2 \pi R /T$

in the first case and by

$v = 2\pi R n/t_0$ in the second.

It might seem to be a tiny difference, but I am really interested in this detail. Hope someone could clarify this and give some references.

  • 2
    They use some algorithm to "smooth" out minor variations. The precise algorithm is irrelevant -- the results will be the same. Commented Apr 15, 2012 at 15:02
  • @DanielRHicks So what method is used? Do you have more details?
    – Julia
    Commented Apr 15, 2012 at 15:04
  • I would guess it varies from brand to brand. I think they time several revolutions and compute speed/distance from that. I suspect at least some vary the number of revs timed based on speed, so that they can update once a second or so, regardless of speed. Commented Apr 15, 2012 at 18:09
  • 2
    @heltonbiker I am teaching physics in high school. There are nice exercises in school books which consider cyclocomputers as real world examples in the context of rotating bodies, discussing frequency and speed... However sometimes it is assumed that a bike-computer measures in fact the time for one revolution and sometimes that it measures the number of revolutions in a given time interval. So I want get some background knowledge about how it really works (and not only how it could work in theory). Nevertheless your answer is helpful!
    – Julia
    Commented Apr 16, 2012 at 15:32
  • 4
    The main problem of bike computers is: what they display as current speed is in fact the average speed of a short recent time interval, and never the actual instantaneous speed. When you are accelerating, the speed displayed is always smaller than it should, and when you are braking, it is the opposite, because there is a delay. The only way to avoid it would be to provide ways to continually measure smaller angular displacements of the wheel instead of whole turn increments only. Commented Apr 16, 2012 at 16:34

4 Answers 4


The answer is "both, depending." The majority of current bicycle cyclometers use a reed switch and timer, and measure the time between successive triggerings of the switch as a magnet passes by. An advantage of this method is its simplicity and low cost, though if the magnet is ill-positioned or if the rotational speed of the wheel is too high, the reed switch can get fooled since it takes a while for the reed switch to reset itself.

A less common approach (used by the old Avocet line of speedometers, including the venerable and venerated Avocet 50) used an induction coil and magnet ring with 20 small magnets attached around the hub. The induction coil could rapidly count the change in current. You can see the details of this approach in the Avocet patent application for the 50, but its designer discussed some of the idiosyncrasies of that approach in this Usenet post from 1994.

Although these two different methods can be used to collect the data needed to calculate speed, the exact algorithms used may differ from device to device. One can see this in the way that cadence is often calculated. Almost all bike computers that have a cadence sensor use a reed switch, since the rotational speed of the cranks is low enough for reed switches to reset. However, different manufacturers use different averaging periods, time-outs, delays, and triggering events before displaying the result. Speed calculations work similarly, and one can occasionally see the evidence of these choices by examining speed and cadence data from bicycle computers that store these values and allow them to be downloaded after the ride. Here, for example, is a graphic that shows the speed recording from three different devices that were mounted on the same bicycle for the same ride (a PowerTap, a Polar S710, and a SRM Pro -- these are power meters but here we focus only on the recorded speed). Each device was set with the same wheel circumference but the histograms show that each stores and reports slightly different speeds.

speed recorded by three devices on same ride

  • Simple, and actually answers the question as formulated by the OP. +1 Commented Apr 17, 2012 at 4:01

Think of a cyclocomputer as a hardwired combination of a calculator, a quartz-clock, and a dedicated CPU working with a buffer.


Each time the magnet closes the reed-switch, a request is sent to the clock to capture a time-stamp, a time-stamped event is sent to a buffer, and the wheel circumference is added to the current distance and to the odometer.

Each time the CPU updates the current speed, it takes the first and last timestamped events from the buffer, calculates the distance (wheel circumference multiplied by number-of-events-minus-one) and divides by the calculated elapsed time (last timestamp minus first timestamp in the buffer), displaying the speed and clearing the buffer.

Besides the persistently stored variables (current distance, maximum speed, etc.), the computer works with three temporary variables: LAST_TIME, TEMP_TIME and TEMP_DISTANCE, all of them set to zero. The present_time() function, related to the clock, is abstracted here as a resource readily available upon request.

Each time the reed-switch closes contact, the computer performs the following operations:

if LAST_TIME is zero:
    LAST_TIME = present_time()
    TEMP_TIME = TEMP_TIME + (present_time() - LAST_TIME)
    LAST_TIME = present_time()

Each time the computer refreshes the screen, it performs the following operations:


Finally, each time the auto-stop function is activated (when the bike is stopped):


All these operations are not only trivial computationally speaking, but also almost realtime because thy are hardware-implemented in the integrated circuit.

It is worth considering two things:

  1. If the computer is working with auto-start / auto-stop function, if the wheel takes too long to complete a turn, the speed refresh function enters in pause mode;
  2. Most probably, these variables have a fixed-point/integer nature, that is, they have a maximum value. For the TEMP_TIME, which probably works on microssecond resolution, this might lead to variable overflow if too much time is elapsed between speed refreshes. That implies a minimum speed in order to work properly, depending on the memory size and number type of these variables in the integrated circuit.

Also, it is necessary that it counts the time between revolutions, not the number of revolutions during a fixed time interval, because time is a continuous (floating point) measure, and number of wheel turns is a discrete (integer) measure. If the second option would use, the speed would always be "rounded" to the nearest possible integer value, giving incorrect results except for very high speeds.

  • Well, technically time in the RTC is an integer, but it's an integer that increments very frequently, so it's as close to continuous as one could hope to get. Commented Apr 15, 2012 at 20:17
  • @DanielRHicks You're correct. What I meant is that TIME is a continuous magnitude by nature, while number of laps (measured by a switch) is not, it only increases by full-turn increments. Since time is measured in micro-seconds or less by quartz devices, it has enough resolution to be equivalent to a floating-point number, as you said - at least considering the application of measuring bicycle speeds. Commented Apr 15, 2012 at 20:26
  • This sounds reasonable. It is the opposite (in terms of this question) of what I understand to be true. Where do you get your info? (FTR, I'm interested, not looking to start an argument or whatever. Just want to know if I'm wrong, and how to be certain.)
    – zenbike
    Commented Apr 16, 2012 at 3:05
  • @zenbike Actually, this explanation is more of a guess than an actual knowledge, but I know a bit of programming, engineering and electronics, and that would be the "necessary" way to make it: since the wheel count cannot be measured continually (only when the reed-switch closes), it makes necessary that you count the time of each wheel turn, and not the number of turns in a fixed time interval, specially considering that bike wheels spin at relatively low RPM. Commented Apr 16, 2012 at 3:14
  • Quick experiment: Rotate your wheel one full revolution, so that your cyclometer sensors switch is activated 2x. Do you get a readout for speed, even momentarily? Mine does not. It requires the activation of the switch 10-12 times before the speed can be calculated. My understanding is that that is because it needs a reading for 2-3 times the length of the refresh period before the initial calculation can be processed. How does that play in? BTW, this could turn in to a long conversation. Are you willing to email me directly? If so, I'll send you an email.
    – zenbike
    Commented Apr 16, 2012 at 3:21

A cyclometer measures the number of revolutions, and multiplies it by the outside circumference of the wheel and tire, (or a close approximation of it, depending on how it was set up by the user) to get the distance ridden for a given period of time.

Applying the conversion formula to KMH or MPH is all that's left.


  1. Measure the circumference of the wheel in millimeters, ideally using rollout method described here. Convert the millimetric measurement of the wheel to inches by dividing by 25.4. (25.4mm = 1 inch) Divide by 12 to get circumference in feet.

  2. Calculate wheel revolutions per mile by dividing 5,280 by the tire circumference in feet.

  3. Calculate the speed per minute by dividing the wheel speed by the tire revolutions per mile. For example, if the wheel speed is 300 rpm, the example tire is moving at 0.446 miles per minute.

  4. Multiply the miles per minute speed times 60 to convert the speed to miles per hour (mph).

  5. Multiply by 1.609344 to get speed in KPH.


  • Wheel Circumference = 2105mm
  • 2105 / 25.4 = 82.8740157 inches circ.
  • 82.8740157 inches circ. / 12 = 6.90616798 feet circ.
  • 5280 / 6.90616798 feet circ. = 764.533967 wheel revolutions to travel one mile
  • 350 RPM / 764.533967 = .45779523 miles per minute
  • .45779523 miles per minute x 60 = 27.4677135 Miles Per Hour
  • 27.4677135 Miles Per Hour x 1.609344 = 44.205 Kilometers per hour

In this example "350" is a variable which the cyclometer counts using a magnetic sensor. Most cyclometers refresh the calculation between once per second and once per 5 seconds.

Good mathematical explanation here.

  • Thanks. So it measures the number of revolutions per second (or per 5 seconds depending on the model) and not the time needed for one revolution? The problem is not how to calculate the speed out of the rpm or to convert units (by the way I am from germany where only metric units are used).
    – Julia
    Commented Apr 15, 2012 at 14:43
  • And I live in Dubai, where only metric units are used. Most cyclometers offer both options and use this calculation method. Your question was whether the cyclometer measures wheel revolutions in a given time, or time for one revolution. The answer is the former, but you must calculate the latter from the former to get per hour speed. Is there a better way to make that clear?
    – zenbike
    Commented Apr 15, 2012 at 14:45
  • Yes that's the question. Do you have a reference for that? For me both methods seems to be reasonable, you could take a fixed time say 2 seconds and count the number of revolutions (that's what is actually used as you said) or you could measure the time for one revolution. Do you know why the latter is not used? Again the problem is really not how to calculate things once you have the measurements (that's one reason I included the formulas in my question, to show that this is not the problem...)
    – Julia
    Commented Apr 15, 2012 at 14:56
  • "What does a cyclocomputer actually measure for calculating the speed of the bike?" is the question I was trying to answer. With possibly excess explanation... No references, but this is what is done. I know that because I have been managing a bicycle service shop for 10 years, and that rollout method is what is necessary to get accurate measurement of speed. You could go the other way, but I know that this is what is used.
    – zenbike
    Commented Apr 15, 2012 at 15:08
  • As for why, I think only because you would need to refresh each second if you measure time per revolution. Measuring number of revolutions allows for a reasonably accurate readout, with lower processing power, and less battery power use, because you only need to refresh once per 5-10 seconds. And it is only recently that bike computers have really turned into computers of any real power...
    – zenbike
    Commented Apr 15, 2012 at 15:10

I've designed embedded systems to measure speed several times.(Not a bike computer, but the same thing for locomotives.) Your question is easy to answer-

"Is it the time for one revolution $T$ or is it the number of revolutions $n$ per given time $t_0$"

You have two variables, time and number of revolutions. A computer can measure time very accurately. A computer can not measure revolutions anywhere near as accurately. (There just aren't very many of them as they occur slowly so you would have fractional revolutions in every fixed period of time to deal with.) So based on what can be more accurately measured, you want to measure the amount of time it takes to make one revolution. You can easily measure time to the microsecond, from the moment your sensor sees a revolution start until the next time that same sensor fires.

Also note bike computers are extremely low power devices. You expect to put a coin battery in one and have it run for years. The faster the software routines run, the more power they draw. So you have one fast routine, counting time. The second routine only runs when it sees a signal from the wheel sensor. It grabs the current timer value and saves it. A slower running background routine takes these time intervals, and uses the circumference to calculate a speed.

The calculated speeds get stored in a rolling buffer, where you run a low pass digital filter on these speeds to smooth them out. (For example add the current speed to the previous speed, divide by 2, and that's the displayed speed. In practice, you use a more complicated filter using more points.)

The wheel sensors must be able to run faster than you would suspect. My bike computers have always been able to measure speeds over 40 mph. I assume they can go up to at least 60mph. That means with a 700x25 tire, the wheel sensor can make 12 - 13 revolutions per second at 60mph. I also haven't priced it in a while, but reed sensors have to be way more expensive than hall effect sensor. Reed sensors use expensive metals (silver, or bismuth, or ???), can be unreliable, don't like fast switching, and generate electronic noise.

So the answer to your question is, you want to measure the amount of time each revolution takes, not the number of revolutions in a fixed period of time.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.