|
|
Thread Tools | Display Modes |
#51
|
|||
|
|||
GPS Units = Show road steepness?
On Tuesday, March 12, 2019 at 12:07:32 PM UTC-7, Frank Krygowski wrote:
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. -- - Frank Krygowski Where did you get those numbers Frank? Pulling them out of your ass again? Because of the time of a revolution of a wheel particularly in the speed regime of the people here (save maybe Jay) a half mile per hour is a wild approximation at more than 2 mph. Though I'm sure that you have a schematic and program printout of your speedo in order to prove me wrong. |
Ads |
#52
|
|||
|
|||
GPS Units = Show road steepness?
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. |
#53
|
|||
|
|||
GPS Units = Show road steepness?
On Tuesday, March 12, 2019 at 3:51:13 PM UTC-4, wrote:
Because of the time of a revolution of a wheel particularly in the speed regime of the people here (save maybe Jay) a half mile per hour is a wild approximation at more than 2 mph. I'm hoping you can translate that, Frank...... |
#54
|
|||
|
|||
GPS Units = Show road steepness?
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? |
#55
|
|||
|
|||
GPS Units = Show road steepness?
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. I would be amazed to find anything other than a general purpose microcontroller. The problem with higher clock rates is battery consumption, so there is an incentive to stay as slow as possible. 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. 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). 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. -- |
#56
|
|||
|
|||
GPS Units = Show road steepness?
"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 strongly suspect that jittering of the displayed speed is a much bigger problem than lag -- hardly anyone will actually notice a few seconds . 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? 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. -- |
#57
|
|||
|
|||
GPS Units = Show road steepness?
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. -- - Frank Krygowski |
#58
|
|||
|
|||
GPS Units = Show road steepness?
On Tue, 12 Mar 2019 19:05:40 -0400, 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? This discussion has become rather bizarre with hordes explaining how it might be done and no one explaining how it is actually done. How about explaining how the cow jumped over the moon as this has been a "known fact" far longer then bicycles have had a speedometer :-) Note: the poem seems to have been alluded to in Thomas Preston's 1569 play, A lamentable tragedy mixed ful of pleasant mirth, conteyning the life of Cambises King of Percia. -- Cheers, John B. |
#59
|
|||
|
|||
GPS Units = Show road steepness?
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. |
#60
|
|||
|
|||
GPS Units = Show road steepness?
On 3/12/2019 10:05 AM, Frank Krygowski wrote:
On 3/12/2019 12:46 PM, Mark J. wrote: Â*Â* 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. I agree. 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? Mark J. |
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 01: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 |