On 3/12/2019 4:23 PM, Radey Shouman wrote:
"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'll admit that I don't know what an IIR filter is, nor did I spend much
time just now at the relevant Wikipedia page; I'm a mathematician, not
an EE, but I did intern with some EEs as an undergrad.

I think what ?Zen? is getting at is more about information theory than
circuit design: When you have finite/discrete data, there's only so
much information it can carry, and there's no free lunch. You can
improve accuracy by gathering more data (longer sampling period) at the
price of having less frequent updates, or you can update more frequently
and have larger ?discretization? error (here I'm thinking of the error
inherent in rounding a measurement to an integer or some other discrete
scale.)

You can have a higher sampling rate (more data is /almost/ always better
for accuracy), and we seem to be agreeing that effectively that's what
modern digital speedometers do, i.e. a higher clock rate and using
division to find speed. (If you have 256 clock pulses in a timing
interval, that's essentially 8-bit data, giving much more resolution
than, say, 8 pulses giving 3-bit data.)

As I said at the earlier, counting wheel revolutions just doesn't cut
it; /timing/ wheel revolutions, I ?think we agree? does. Beyond that,
what ?you? ?Zen? said about not needing to overthink/design this sure
seems true to me.

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

Probably true.

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?

Note I said /attempts/. I was designing with fairly simple CMOS chips
(counters, display drivers) and (God help us) an LED digital display.
Think I bought an LCD numeric display for a planned upgrade that never
happened. The speedometer goal turned into just an odometer and never
really worked well anyway, despite help from one of the EEs (who was
probably shaking his head when I wasn't watching). It was a good
learning experience, though.

Within a year or two, Cateye got into the business and it was clear that
their stuff (with a presumed ALU doing division) was over my head (or
outside the amount of money I'd risk on a DIY).

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.



Finally, somebody should note that we're awfully close to conflating two
related problems in this thread, measuring speed and measuring gradient.
The nature of the input data is quite different in these two problems.
As ?somebody? noted, the speedometer problem is solved to much greater
accuracy than almost anybody cares, and unsurprisingly for the quality
of input data we can get. The gradient problem's current bike-computer
solution is far courser, probably mostly because few folks care /that/
much, but mostly because the data is far noisier (here I mean
measurement errors) and costlier (in power and/or availability).

Mark J.