On Tuesday, March 12, 2019 at 2:27:28 PM UTC-4, Radey Shouman wrote:
Zen Cycle writes:

On Tuesday, March 12, 2019 at 10:30:52 AM UTC-4, Radey Shouman wrote:
Zen Cycle writes:


Interesting how you characterize it as 'noise'.

For the speedometer the main source of noise is quantization error,
resulting from reducing a continuous wheel position to an integer number
of revolutions.

But that has to do with the digital filtering. I was under the
impression that the ASICS most bike computer companies use calculate
speed by the number of timing pulses between the wheel revolutions. As

As far as I can tell, none of us actually *know* how a bike computer
works internally, we're all guessing, based on personal experience.

I'm pretty sure no bike computer manufacturer is thinking so far outside the box that that most of us with a reasonable amount of electronic engineering experience can't make reasonably accurate assumptions. The biggest issue with companies like cateye, polar, garmin, etc. is cost. There's simply no reason for them to invest some sort of proprietary speed calculation algorithm with error correction when a simple counter and ALU provides more than enough accuracy.

So, Sure, if your sampling period is sufficiently close to the number of data points, but this is what made Nyquist famous - for greater accuracy and fewer quantization errors, increase the number of samples.

However, bicycle computer speed calculations aren't DSPs, even on a fundamental level. This is still pretty simple math. The number of rising edges represents an elapsed time between number of reed switch 'clicks'. Then it's simply distance (wheel circumference) over time. The only significant error inherent in the architecture would be the point at which the switch contact is measured within the waveform of one period*. Obviously the click occurring immediately after an edge is counted would be the same number as the click occurring just before the next rising edge, so the key is to get as many rising edges as possible, i.e a higher timer rate. The faster the count between reed switch 'clicks', the more accurate the speed can be. A 1KHz timer is probably an order of magnitude more accurate than necessary for a bicycle, but these days even a 1MHz clock rate is pretty cheap in a mass produced ASIC.

If you're talking about a GPS based speedometer, errors are introduced in the form of data errors (bit errors). The micro in a GPS based unit is more than accurate enough to handle the low data rate of the GPS signal. I know the GPS system transmits FEC data, but I don't know if the particular receivers in a cycling GPS computer use that code or not, though I think some smart phones do. I use my phone for strava, and occasionally I still get a straight line across the map for a significant period of time, when I was following winding country road.



you mentioned in the other thread, even a 100hz timing pulse is going
to give accurate results well beyond the typical 3 digit display of a
bike computer. This is a simple math function rather than an a/d
conversion, so I don't think quatization error applies here. Speed
calculation could be considered a strict d/a, where the speed display
is an analog number, yet derived purely as a digital process. There
really isn't any 'noise' in speed calculations, except that even at a
constant speed there would be some variation in the number of timing
edges in between the wheel magnet triggers

If you look at the real wheel position versus time at constant speed, it
is a line. The measured position, based on a signal from a reed switch,
is a staircase. If you subtract the real position line from the
staircase measured position line you get a sawtooth wave. The term of
art for the difference between the measured and the actual signal is
"noise". Quantization error is noise, noise is a property of a signal,
not a calculation.

That's a fun calculus exercise, and I know it's a legitimate concern for applications that require stable and high accuracy, but we're talking about bicycles here. Sure, keep track of quantization errors and add correction algorithms for the space shuttle, it just isn't necessary for bicycles. To invest in that kind of software development for a bike computer simply isn't cost effective, they'll never get the NRE return. For us, a simple counter with an ALU is more than enough. I'd be legitimately shocked if bike computer companies were applying error correction factors to counting the number of edges on a timing pulse between revolutions, there simply is no need for that level of accuracy.



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.

Here I can see the quantization error being an issue, since most bike
computers use a barometric pressure transducer to detect
altitude. Averaging is pretty critical here, and there is the issue of
the transducer a/d then being processed back d/a for the display. As I
mentioned above, short/steep gradients are more likely to be smoothed
over intentionally to get rid of the quantization noise associated
with attempting to oversample the transducer.

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.

Sure, but I think that's way beyond the application requirements of a
bicycle computer. There's no reason to over complicate the issue for
us. If this was a military application, or something like flight
computers in a passenger aircraft, the more accurate _and_ fast the
better.


On the issue of 'many ways to do it right' - My company builds
products for oil and gas processing. Some of our products use use dual
microprocessors in an n-version programming architecture. The outputs
of both UPs have to give the same result, or the system shuts down -
this is a failsafe application, not a life support system which would
require redundant (fault tolerant) systems to keep people alive.

Standards (and prices) for your companies products are much higher than
for bike computers, obviously.

Only stated as point of reference. By the same token, we also have a monitoring device that reads a sensor status for testing outside of the system. It's a simple off-the-shelf arduino driven device with an integrated display.. We have a junior software engineer that wrote the code using open source ware. It's cheap, and does exactly what our customers want. We could have designed an entirely proprietary architecture, it would have taken months longer, and doubled the cost of the product. This is much closer to what Cateye and VDO are up to, I suspect.


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

I think technology has progressed well beyond the point where that's
an issue even in a cycling computer application.

Sorry, that's nonsense. That differentiating amplifies (high frequency)
noise is a mathematical fact that technology cannot change.

My point was that such considerations are outside the realm of what is necessary for bicycles. DSP isn't necessary for bicycle computers.


Remember, this whole conversation started because because a guy
claimed his speed increased on flat ground without a tailwind or
pedaling - the idea that he had the display set to average speed is
much more plausible.

Oddly enough, whatever his display showed had to be some approximation
of "average speed", preferably over some short interval. The Platonic
ideal of the magnitude of the derivative of position is just not
directly available to any of us mortals. And that ideal is what the
laws of physics deal with.

--

*Certainly the accuracy of the clock in the system can be considered to be an inherent error, but considering the phase jitter of even a cheap timing crystals is on the order of 10e-7 these days, the measuring accuracy of user inputting the wheel circumference is several orders of magnitude more significant.