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
  #41  
Old March 12th 19, 03:33 PM posted to rec.bicycles.tech
Radey Shouman
external usenet poster
 
Posts: 1,747
Default GPS Units = Show road steepness?

Ralph Barone writes:

Radey Shouman wrote:
Zen Cycle writes:

On Sunday, March 10, 2019 at 6:35:02 PM UTC-4, Roger Merriman wrote:
Sir Ridesalot wrote:
Talking about GPS units on another thread reminded me of something else I
wondered if they do. Does a bicycle GPS unit show you the steepness of
roads? There's an area that I frequently ride where on road has short but
very steep hills, another road a mile or so east of it has much more
gradual hills whilst a third road to the west of the first one is a major
highway that can be ridden with a bicycle. What I'm wondering is this: if
someone unfamiliar with the area got there and used a GPS unit to show
those three roads, would the GPS unit show them the different gradients
of the roads? Or is that another function that they'd need to download or
otherwise install?

Cheers


Various mapping sites will show the gradient, and some GPS units will show
the gradient, in the same way that it can give improbable maximum speeds
they can also give improbable max gradients or sometimes on very short
ramps not notice it, there is a nasty little ramp nr my folks place, which
is the software flattens claiming 12% when it’s a fair cruel 25/30% even
more cruel this weekend with a 50mph headwind.

It's probably an averaging issue - taking enough samples before and
after the section so that it flattens the pitch.


It's the same basic issue as the speedometer kerfluffle. Numerical
differentiation amplifies noise.


I would think it was the opposite. Numerical integration suppresses spikes.


I would call that the converse. But turning altitude data, which is
what is actually measured, into a gradient is differentiation.

--
Ads
  #42  
Old March 12th 19, 03:39 PM posted to rec.bicycles.tech
Ralph Barone[_4_]
external usenet poster
 
Posts: 853
Default GPS Units = Show road steepness?

Radey Shouman wrote:
Zen Cycle writes:

On Monday, March 11, 2019 at 3:28:58 PM UTC-4, Radey Shouman wrote:
Zen Cycle writes:

On Sunday, March 10, 2019 at 6:35:02 PM UTC-4, Roger Merriman wrote:
Sir Ridesalot wrote:
Talking about GPS units on another thread reminded me of something else I
wondered if they do. Does a bicycle GPS unit show you the steepness of
roads? There's an area that I frequently ride where on road has short but
very steep hills, another road a mile or so east of it has much more
gradual hills whilst a third road to the west of the first one is a major
highway that can be ridden with a bicycle. What I'm wondering is this: if
someone unfamiliar with the area got there and used a GPS unit to show
those three roads, would the GPS unit show them the different gradients
of the roads? Or is that another function that they'd need to download or
otherwise install?

Cheers


Various mapping sites will show the gradient, and some GPS units will show
the gradient, in the same way that it can give improbable maximum speeds
they can also give improbable max gradients or sometimes on very short
ramps not notice it, there is a nasty little ramp nr my folks place, which
is the software flattens claiming 12% when it’s a fair cruel 25/30% even
more cruel this weekend with a 50mph headwind.

It's probably an averaging issue - taking enough samples before and
after the section so that it flattens the pitch.

It's the same basic issue as the speedometer kerfluffle. Numerical
differentiation amplifies noise.


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

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.


Ah... I see your point now.

  #43  
Old March 12th 19, 03:46 PM posted to rec.bicycles.tech
Rolf Mantel[_2_]
external usenet poster
 
Posts: 267
Default GPS Units = Show road steepness?

Am 12.03.2019 um 13:38 schrieb Zen Cycle:
On Monday, March 11, 2019 at 9:13:08 PM UTC-4, Ralph Barone wrote:
Radey Shouman wrote:
Zen Cycle writes:

On Sunday, March 10, 2019 at 6:35:02 PM UTC-4, Roger Merriman
wrote:


Various mapping sites will show the gradient, and some GPS
units will show the gradient, in the same way that it can
give improbable maximum speeds they can also give improbable
max gradients or sometimes on very short ramps not notice it,
there is a nasty little ramp nr my folks place, which is the
software flattens claiming 12% when it’s a fair cruel 25/30%
even more cruel this weekend with a 50mph headwind.

It's probably an averaging issue - taking enough samples before
and after the section so that it flattens the pitch.

It's the same basic issue as the speedometer kerfluffle.
Numerical differentiation amplifies noise.


I would think it was the opposite. Numerical integration suppresses
spikes.


That's why I made the comment about the definition of 'noise'. I
don't think differentiation is appropriate in this case, especially
since we're doing simple math (not even algebra, let alone
calculus).


I would not talk about Math, Algebra or Calculus in this context but
simple engineering, combined with 'finite difference' rather than
differentiation or 'finite sums' rather than integration.

We have 2d-points with errors
(x1,e1), (x2,e2), ... (xn, en). Total distance is easily calculated as
xn-x1 with an error estimation of (1/2 |en - e1| ), i.e. the error on a
total distance is similar to the error of each individual sample: very
good results on a very simple algorithm. Sadly, total distance is not
so useful when you take a round trip.

Length of a track section is still an OK calculation where you get an
error estimation in the order of k * e when you split your total track
into k sections. As long as the size of each section is significantly
larger than the typical error, the final result "trip distance" (and
compared to this, 'average speed') is of sufficiently high quality.

"Current speed" calculations (what you call 'differentiation') is
extremely error prone:
(x2 - x1) / (t2 - t1) gives you an error in the order of
(e2+e1) / (t2-t1). You interpolate the current speed by a measuring
interval, and splitting the sampling interval by 2 doubles the expected
error.
Horizontally, we have an error of 2-3m, vertically maybe 5m. Sampling
once per second, at walking speed (2m/sec) we get a measured speed "0 -
4 m/sec" i.e. just noise, at cycling speed we get a realistic speed "8 -
12 m/sec" or "18-27 mph". Here, we can interpolate over longer time
ranges (e.g. a moving average for 5-10 sec) to get an acceptable value
for '(horizontal) current speed' but this loses all information
necessary for a realistic "max speed" like we're used from the bike
computer, supressing spikes.

Vertically we have the double challenge that
a) the vertical resolution of GPS is lower
b) our vertical speed is significantly lower (exception: parachuting)
and these two facts combine to GPS being completely useless for
'altitude gain' and 'vertical speed' in flat or rolling country.

Rolf

  #44  
Old March 12th 19, 04:16 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 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 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

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.


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.

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.
  #45  
Old March 12th 19, 04:17 PM posted to rec.bicycles.tech
Radey Shouman
external usenet poster
 
Posts: 1,747
Default GPS Units = Show road steepness?

Zen Cycle writes:

On Monday, March 11, 2019 at 9:13:08 PM UTC-4, Ralph Barone wrote:
Radey Shouman wrote:
Zen Cycle writes:

On Sunday, March 10, 2019 at 6:35:02 PM UTC-4, Roger Merriman wrote:
Sir Ridesalot wrote:
Talking about GPS units on another thread reminded me of something else I
wondered if they do. Does a bicycle GPS unit show you the steepness of
roads? There's an area that I frequently ride where on road has short but
very steep hills, another road a mile or so east of it has much more
gradual hills whilst a third road to the west of the first one is a major
highway that can be ridden with a bicycle. What I'm wondering is this: if
someone unfamiliar with the area got there and used a GPS unit to show
those three roads, would the GPS unit show them the different gradients
of the roads? Or is that another function that they'd need to download or
otherwise install?

Cheers


Various mapping sites will show the gradient, and some GPS units will show
the gradient, in the same way that it can give improbable maximum speeds
they can also give improbable max gradients or sometimes on very short
ramps not notice it, there is a nasty little ramp nr my folks place, which
is the software flattens claiming 12% when it’s a fair cruel 25/30% even
more cruel this weekend with a 50mph headwind.

It's probably an averaging issue - taking enough samples before and
after the section so that it flattens the pitch.

It's the same basic issue as the speedometer kerfluffle. Numerical
differentiation amplifies noise.


I would think it was the opposite. Numerical integration suppresses spikes.


That's why I made the comment about the definition of 'noise'. I don't
think differentiation is appropriate in this case, especially since
we're doing simple math (not even algebra, let alone calculus).


Speed and road gradient are both defined in terms of derivatives. These
are approximated using "simple math". It seems a lot simpler if you
haven't tried to do it -- produce meaningful results, automatically, on
schedule (meaing milliseconds or microseconds), all the time, from
whatever data your machine has.



--
  #46  
Old March 12th 19, 05:46 PM posted to rec.bicycles.tech
Mark J.
external usenet poster
 
Posts: 840
Default GPS Units = Show road steepness?

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.

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

  #47  
Old March 12th 19, 06:05 PM posted to rec.bicycles.tech
Frank Krygowski[_4_]
external usenet poster
 
Posts: 10,538
Default GPS Units = Show road steepness?

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.

--
- Frank Krygowski
  #48  
Old March 12th 19, 07:27 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 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.

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.

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.

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.

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.

--
  #49  
Old March 12th 19, 08:07 PM posted to rec.bicycles.tech
Frank Krygowski[_4_]
external usenet poster
 
Posts: 10,538
Default GPS Units = Show road steepness?

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
  #50  
Old March 12th 19, 08:34 PM posted to rec.bicycles.tech
[email protected]
external usenet poster
 
Posts: 1,261
Default GPS Units = Show road steepness?

On Tuesday, March 12, 2019 at 9:46:08 AM UTC-7, Mark J. wrote:
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.

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


How do you magnetize aluminum spokes?
 




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:34 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.