"Mark J." writes:

On 3/12/2019 7:30 AM, Radey Shouman wrote:
For the speedometer the main source of noise is quantization error,
resulting from reducing a continuous wheel position to an integer number
of revolutions.

I'm pretty sure that counting revolutions is /not/ particularly
relevant to modern electronic bike speedometers. For Odometer,
probably much more relevant.

For speed calculations, I'm strongly convinced that time between
counts is used, with some division, as already noted earlier in this
thread. After all, one rev. per second of a ~700c wheel comes to about
4.8 mph / 7.7 kph.

Assuming you want the speedometer to update even once every two
seconds, (I'm being generous here!) say in two seconds you get a count
of 5 revolutions. That really means 5 to 5.99 or so revolutions
occured in the two seconds, so a speed of 12 to 14.8 mph - not very
impressive resolution. Faster updates lower the resolution.

Sample a position count a several times the display update rate,
difference, use a low pass IIR filter. Works fine. A lot of the input
differences are going to be zero, that's not a problem. Apply the same
algorithm, taking the same time, every time. Predictable timing is a
wonderful thing.

I strongly suspect that jittering of the displayed speed is a much
bigger problem than lag -- hardly anyone will actually notice a few
seconds .

Averaging over multiple updates will improve resolution if speed is
close to constant, but then you lose the ability to detect brief
spikes (probably not a problem for a bike computer) and also get a
bigger lag between speed changes and their reflection on the readout.

I believe you're still right that quantization error is an issue, but
with the resolution of the device's /clock/ as it times the gap
between reed switch activations.

Note this is all based on deduction of observed digital speedometer
data and some fairly serious attempts at designing a DIY digital
speedo back in the 70's, but not inside mfr information.

I don't have any inside info either, nor any reason to believe they're
all the same, this stuff isn't published. What kind of hardware did you
use in the 70's? And how have you collected digital speedometer data?

I remember one design in a ?Popular mechanics? article that had one
magnetize spokes and count them; 36 spokes per revolution versus one
magnet really helped resolution. [One spoke per second (out of 36
spokes) is 0.133 mph, or equivalently, one spoke per 0.133 seconds is
1 mph, so count the spokes in 0.133 seconds and it's your speed in
mph.]
Quick updates and a simple design, but not up to our current standards
for resolution, we'd likely count for 1.064 seconds and "divide" by
8. This was right around the time that quality stainless
(nonmagnetizable) spokes came into wide use, though, trashing that
idea.

Cateye's original digital speedometer had you mount a ring at your
hub with four magnets, perhaps to help the resolution problem; I owned
one, and suspect they were already dividing by time interval, though.

For the 2-d field of altitudes obtained from a map I
suspect that the quantization of position, ie, the limited number of
data points, perhaps at irregular places, is the main source of noise.

I agree. Gradient is in practice a very different calculation than
speed, even though both are effectively numeric differentiation.

How to turn topographical survey data into something that looks like a
continuous function is a whole field of study -- there are many ways to
go wrong, and no one perfect way to do it right.

In either case, errors that would be fairly small in altitude or
distance become larger when differentiated to estimate speed or
gradient.

Yes, as ?you or others? noted above, numeric differentiation is known
to magnify measurement/data errors.

Mark J.


--