A Cycling & bikes forum. CycleBanter.com

Go Back   Home » CycleBanter.com forum » rec.bicycles » Techniques
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

GPS Units = Show road steepness?



 
 
Thread Tools Display Modes
  #61  
Old March 13th 19, 02:27 AM posted to rec.bicycles.tech
Radey Shouman
external usenet poster
 
Posts: 1,747
Default GPS Units = Show road steepness?

"Mark J." writes:

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 don't agree at all. I think that sampling a count of wheel revolutions
at regularly timed intervals is all you need for a reasonable speedometer.
I have done this, for pay, although not for a bike speedometer.

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.


The big difference between a DIY research project and a consumer item is
the pressure to save money. For a hobby you spend what you want, and
you only buy one at a time. For production you squeeze every penny, and
buy enough to get a good rate, or more likely, hire someone in China to
do it for you.

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 would be *amazed* if they did any division, except for setup. Even
today few microprocessors do hardware division. The ones I work with
give you one bit of quotient per cycle.

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).


I conflated them, because they are similar in the numerical problems
posed. There are of course differences. If the speedometer problem is
solved it's because our expectations are not very exacting, not because
the speed values are always right to display accuracy.


--
Ads
  #62  
Old March 13th 19, 02:30 AM posted to rec.bicycles.tech
Radey Shouman
external usenet poster
 
Posts: 1,747
Default GPS Units = Show road steepness?

"Mark J." writes:

On 3/12/2019 4:23 PM, Radey Shouman wrote:
"Mark J." writes:


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.


It's a filter with feedback of the output, meaning the transfer function
has one or more poles.
  #63  
Old March 13th 19, 03:06 AM posted to rec.bicycles.tech
Radey Shouman
external usenet poster
 
Posts: 1,747
Default GPS Units = Show road steepness?

Frank Krygowski writes:

On 3/12/2019 7:05 PM, Radey Shouman wrote:
Frank Krygowski writes:

On 3/12/2019 2:27 PM, Radey Shouman wrote:
Zen Cycle writes:

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.

Yes, but the perfect Platonic ideal is not necessary for anything
practical in cycling, not even for high budget racing. Current
cyclometers tell speed to within 0.1 mph with a lag of no more than
one second or so. They tell distance traveled with better
accuracy. Nothing more is needed, even for detecting fantasies.


Wait, where are those specifications documented? Are they, perhaps, a fantasy?


They're an estimation. Give your estimates if you disagree with mine.

Sheldon Brown and John Allen (couple name Shel-John?) reckon they're
good for half a percent, if properly calibrated of course.
https://www.sheldonbrown.com/cycleco...-accuracy.html

My guess is that the dominant error source will be calibration,
i.e. effective wheel circumference. Was the unit calibrated using a
rollout measurement, or just a number plucked from a chart? Was that
rollout done at the same tire pressure as when riding? Was the load on
the wheel the same as when riding?

Our cyclometer clocks seem to be accurate to roughly a minute a month
-
again, an estimation. So I doubt the timing circuit used to generate
speed results is off by even 1/10%.

Out west, I remember riding mile upon mile on freeway shoulders. My
cyclometer didn't precisely match the mile markers, but IIRC it was
off by less than 50 feet per mile - in my case, underestimating
distance. That 1% error could probably have been corrected by letting
a few psi out of my tire.


I agree that the real time clock (the thing that shows clock time, and
elapsed time) is good to a few seconds a month. I agree that the count
of revolutions is probably exact, so distance is as accurate as the
rollout measurement. These two things are ones that users care about.
Particularly with the time of day they'll notice inaccuracies.

I doubt that the instantaneous speed measurement is accurate to within
0.1 mph or 0.1 kph, unless speed is constant. If the display is updated
every second, which seems about right, then there can be a pure delay of
up to one second right there, and I suspect internal filtering adds several
more seconds of (frequency dependent) delay, which are almost always not
noticeable.

I don't have the frequency response of any bike speedometer, I guess you
could do something using video, but I'm not likely to try. It is not
something that a user is likely to notice, and very difficult to check.


--
  #64  
Old March 13th 19, 03:15 AM posted to rec.bicycles.tech
Frank Krygowski[_4_]
external usenet poster
 
Posts: 10,538
Default GPS Units = Show road steepness?

On 3/12/2019 8:15 PM, Mark J. wrote:
On 3/12/2019 10:05 AM, Frank Krygowski wrote:

I'll note in passing that the original Avocet cyclometers use a tiny
(2"?) ring of 20 magnets to generate a wave signal using a coil
pickup. It's quite a bit different from the clicks of a reed switch.

IIRC, Jobst was in on that design. I doubt it's coincidence that he
also had done a lot of toying around with ancient Sturmey-Archer
dynohubs, which also use a 20 magnet ring, although a much larger one.

I've heard a rumor that the Avocet can get its signal directly from
the S-A magnets. But despite owning both, I haven't tried it.


I'll just note that I always thought those Avocets were using a
Hall-effect sensor rather than a coil.Â* I can't remember if I /knew/
that (perhaps from a Jobst post) or just guessed it.Â* Not sure if that
makes any difference, I suspect in either case the design was still just
counting magnets rather than sensing how fast they move past via ?the
shape of the current spike?


Here's a post
https://groups.google.com/d/msg/rec....k/tojDfIFAG0MJ
where Jobst mentions the Sturmey-Archer Dynohub powering the pickup.
Note his phrasing about "the pickup will have enough induced current."
I'm pretty sure that means it's just a coil, not a Hall effect switch.

--
- Frank Krygowski
  #65  
Old March 13th 19, 11:26 AM posted to rec.bicycles.tech
Mike A Schwab
external usenet poster
 
Posts: 443
Default GPS Units = Show road steepness?

Here is a great article by Sheldon Brown showing how bicycle cyclometers work. When bladed spokes came out, some units would register twice the distance at slow speed up to 6 mph 10 kph, so it can give you an idea of how fast it can register the magnetic field closing and opening a reed switch in the pickup.

https://www.sheldonbrown.com/cyclecomputer-magnet.html


Here is a bicycle handlebar bubble inclineometer if you are still interested.
https://www.amazon.com/Sun-Company-C.../dp/B06XCMXRVP
  #66  
Old March 13th 19, 04:13 PM posted to rec.bicycles.tech
SMS
external usenet poster
 
Posts: 9,477
Default GPS Units = Show road steepness?

On 3/11/2019 3:07 PM, AMuzi wrote:

snip

Just wait for eBikes with 'autonomous navigation' a.k.a. 'killer robots'.


Already he https://www.youtube.com/watch?v=LSZPNwZex9s.

  #67  
Old March 13th 19, 04:52 PM posted to rec.bicycles.tech
Radey Shouman
external usenet poster
 
Posts: 1,747
Default GPS Units = Show road steepness?

Mike A Schwab writes:

Here is a great article by Sheldon Brown showing how bicycle
cyclometers work. When bladed spokes came out, some units would
register twice the distance at slow speed up to 6 mph 10 kph, so it
can give you an idea of how fast it can register the magnetic field
closing and opening a reed switch in the pickup.

https://www.sheldonbrown.com/cyclecomputer-magnet.html


That does seem to show that, at least at slow speeds, on a high-end
computer, every reed switch pulse is used to compute a new speed. It's
not clear whether the computer fails to register a double pulse at
higher speeds, or that the internal algorithm changes. Either one is
possible.

Here is a bicycle handlebar bubble inclineometer if you are still interested.
https://www.amazon.com/Sun-Company-C.../dp/B06XCMXRVP


--
  #68  
Old March 13th 19, 10:20 PM posted to rec.bicycles.tech
Zen Cycle
external usenet poster
 
Posts: 194
Default GPS Units = Show road steepness?

On Tuesday, March 12, 2019 at 7:14:59 PM UTC-4, Radey Shouman wrote:
Zen Cycle writes:

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.


I wonder what kind of ASIC you think is used for a bike computer.


One that can be used for cycling computer functions. The design concept is simple - write some code in VHDL that does what you want, then have a die constructed to perform the function. In large volumes, this drives manufacturing costs down because you don't have to have a programming step in the manufacturing process. It also keep the device smaller and can use less power.. I don't know if any manufacturers actually do this, but I can see it as a business model.


I
would be amazed to find anything other than a general purpose
microcontroller.


This is probably true if the plan isn't to sell more than a few thousand units a month.

The problem with higher clock rates is battery
consumption, so there is an incentive to stay as slow as possible.


Considering I've gone for a couple of years in my Polar 720 without changing the battery, clock rate probably isn't as much of an issue as you're thinking. The big power pig in any portable device is a display backlight.



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.


I don't get it, but maybe I'm confounding the various skeptics. On the
one hand they say that specialized algorithms are not likely, yet reject
the most straightforward, standard approach: Sample position in
revolutions at several times the display rate, difference, run through
an IIR filter.


I don't believe that to be the case. I think the most straightforward and accurate approach is to count clock pulses in between wheel revolution triggers. From there it's simple math, no digital filtering needed.

They say the application is simple and the requirements
modest, yet refuse to believe in the possibility of a few seconds lag
(on top of up to 1 sec delay for display).


The simple count method I listed would easily be able to update current speed with a one-second display refresh rate.


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.


A typical frequency tolerance for an RTC crystal today is +/- 20 ppm.


Frequency tolerance and phase jitter aren't the same thing, but even so, 20ppm is 2*10e-5. So a typical ~32KHz xtal is accurate to less than .001 Hz. More than accurate enough for a bike computer.

  #69  
Old March 13th 19, 10:25 PM posted to rec.bicycles.tech
Radey Shouman
external usenet poster
 
Posts: 1,747
Default GPS Units = Show road steepness?

Radey Shouman writes:

Mike A Schwab writes:

Here is a great article by Sheldon Brown showing how bicycle
cyclometers work. When bladed spokes came out, some units would
register twice the distance at slow speed up to 6 mph 10 kph, so it
can give you an idea of how fast it can register the magnetic field
closing and opening a reed switch in the pickup.

https://www.sheldonbrown.com/cyclecomputer-magnet.html


That does seem to show that, at least at slow speeds, on a high-end
computer, every reed switch pulse is used to compute a new speed. It's
not clear whether the computer fails to register a double pulse at
higher speeds, or that the internal algorithm changes. Either one is
possible.


Oops, posted in haste, and less than half right.

The identified cause was a double pulse on the reed switch signal, the
symptom was, at lower speeds, "a speed readout varying erratically
between 7 and 12 MPH", which was roughly twice the true speed.

The computer worked as expected at higher speeds. The most likely
explanation for that is that analog signal conditioning circuitry
filtered out the double pulses when closer together. A conceivable but
less likely explanation is that software either deliberately or by
accident de-bounced the signal.

Since it worked consistently at high speed, I'm guessing that the
de-bouncing happened sometimes at low speed and sometimes not. If this
wasn't true then I don't have a good explanation.

1) Obviously speed was not computed by the dividing rollout distance by
elapsed time between pulses. In that case the speed reading would
alternate between almost right and very high. Linear filtering would
result in a speed that was much too high. Using the most recent value
would result in a speed that was usually almost right.

2) The speed could have been computed by multiplying the number of
pulses by the rollout distance and dividing by the combined elapsed
time.

3) The speed could equally well have been computed by dividing rollout
distance times number of pulses in a fixed time, by the fixed time, and
then filtering.

4) It's certainly possible that Shimano used some algorithm I'm not
familiar with.

Looking at the output would have given a clue: For (2) we would expect
the speed shown to be either about right or about double. For (3) we
would expect the speed to vary between about right and about double,
with values in between.

So what did "varying erratically" mean? I favor "taking many values
between", but "oscillating irregularly between approximately the same
two values" is not impossible.
  #70  
Old March 13th 19, 10:36 PM posted to rec.bicycles.tech
Radey Shouman
external usenet poster
 
Posts: 1,747
Default GPS Units = Show road steepness?

Zen Cycle writes:

On Tuesday, March 12, 2019 at 7:14:59 PM UTC-4, Radey Shouman wrote:
Zen Cycle writes:

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.


I wonder what kind of ASIC you think is used for a bike computer.


One that can be used for cycling computer functions. The design
concept is simple - write some code in VHDL that does what you want,
then have a die constructed to perform the function. In large volumes,
this drives manufacturing costs down because you don't have to have a
programming step in the manufacturing process. It also keep the device
smaller and can use less power. I don't know if any manufacturers
actually do this, but I can see it as a business model.


I know what an ASIC is, I just doubt they are used in bike computers.
I have been wrong before.

I
would be amazed to find anything other than a general purpose
microcontroller.


This is probably true if the plan isn't to sell more than a few
thousand units a month.

The problem with higher clock rates is battery
consumption, so there is an incentive to stay as slow as possible.


Considering I've gone for a couple of years in my Polar 720 without
changing the battery, clock rate probably isn't as much of an issue as
you're thinking. The big power pig in any portable device is a display
backlight.



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.


I don't get it, but maybe I'm confounding the various skeptics. On the
one hand they say that specialized algorithms are not likely, yet reject
the most straightforward, standard approach: Sample position in
revolutions at several times the display rate, difference, run through
an IIR filter.


I don't believe that to be the case. I think the most straightforward
and accurate approach is to count clock pulses in between wheel
revolution triggers. From there it's simple math, no digital filtering
needed.

They say the application is simple and the requirements
modest, yet refuse to believe in the possibility of a few seconds lag
(on top of up to 1 sec delay for display).


The simple count method I listed would easily be able to update
current speed with a one-second display refresh rate.


We'll just have to disagree, then. Have you written any embedded
software at all?

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.


A typical frequency tolerance for an RTC crystal today is +/- 20 ppm.


Frequency tolerance and phase jitter aren't the same thing, but even
so, 20ppm is 2*10e-5. So a typical ~32KHz xtal is accurate to less
than .001 Hz. More than accurate enough for a bike computer.


Nor did I say they were the same. Frequency tolerance is more
interesting. The thing about an RTC that is likely to make users
unhappy is having to adjust the clock time.
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Pothole gardener stars on Road Rage TV show Alycidon UK 0 February 10th 16 02:12 PM
Show off now faces arrest after road damage Alycidon UK 5 October 5th 15 11:00 PM
gps units recycled[_2_] General 1 July 26th 09 11:59 PM
FS: 2 Polar Power units Andre Marketplace 0 June 17th 05 12:13 AM
FS: 2 polar power units Andre Marketplace 0 June 11th 05 10:49 PM


All times are GMT +1. The time now is 10:19 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 CycleBanter.com.
The comments are property of their posters.