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.
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.
Think of a cyclocomputer as a hardwired combination of a calculator, a quartz-clock, and a dedicated CPU working with a buffer.
EDIT TO A MORE PLAUSIBLE ALGORITHM:
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:
TRIP_DISTANCE = TRIP_DISTANCE + WHEEL_CIRCUMFERENCE
if LAST_TIME is zero:
LAST_TIME = present_time()
else:
TEMP_TIME = TEMP_TIME + (present_time() - LAST_TIME)
LAST_TIME = present_time()
TEMP_DISTANCE = TEMP_DISTANCE + WHEEL_CIRCUMFERENCE
Each time the computer refreshes the screen, it performs the following operations:
CURRENT_SPEED = TEMP_DISTANCE / TEMP_TIME
TEMP_TIME = TEMP_DISTANCE = 0
AVERAGE_SPEED = TRIP_DISTANCE / TRIP_TIME
if CURRENT_SPEED > MAXIMUM_SPEED:
MAXIMUM_SPEED = CURRENT_SPEED
Finally, each time the auto-stop function is activated (when the bike is stopped):
LAST_TIME = 0
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:
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.
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.
Instructions:
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.
Calculate wheel revolutions per mile by dividing 5,280 by the tire circumference in feet.
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.
Multiply the miles per minute speed times 60 to convert the speed to miles per hour (mph).
Multiply by 1.609344 to get speed in KPH.
Example:
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.
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.
