|
|
Thread Tools | Display Modes |
#25
|
|||
|
|||
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 | |
|
|
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 |