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
Prev Previous Post   Next Post Next
  #25  
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.


--
 




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 07:21 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.