|
|
Thread Tools | Display Modes |
#141
|
|||
|
|||
GPS Units = Show road steepness?
On Thursday, March 21, 2019 at 4:51:40 PM UTC+1, Radey Shouman wrote:
writes: 2012 cm? Are you sure? Context, from Mr. Muzi: Popular bike computers use input in cm (rollout for a road bike is about 2012cm)and offer choice of either unit for display. That seems to indicate number manipulation is metric until final display if miles are selected. Looks like I am using 2143 cm for 622x28 tires. (2143/pi - 622)/2 = 30 cm seems about right. Perhaps (2012/pi - 559)/2 = 41 cm makes sense for mountain bikes? 2012 cm is 20.12 m. That is a big wheel ;-). Roll out of a 23 mm race tire is 2096 mm |
Ads |
#142
|
|||
|
|||
GPS Units = Show road steepness?
|
#144
|
|||
|
|||
GPS Units = Show road steepness?
On Wednesday, March 20, 2019 at 5:53:52 PM UTC-7, Radey Shouman wrote:
James writes: On 21/3/19 3:37 am, wrote: On Tuesday, March 19, 2019 at 1:58:13 PM UTC-7, James wrote: On 20/3/19 4:20 am, Radey Shouman wrote: writes: [ ... ] averages in particular. And I think that it was Radey talking about using IIR which would require a high end FPGA wouldn't it? I'm buying a new, wireless VDO for $50. An IIR can be very simple to implement. The "leaky integrator" or "exponential filter" is probably the simplest digital low-pass filter possible: y_i = y_{i-1} + k (x_i - y_{i-1}) In C: y += k*(x - y); If you're not too fussed about the actual cutoff frequency the multiplication can be done as a shift. The precision used for the state, y, does need to be higher than that of the input. If you need precise control over the frequency response then more work in design and more expense in implementation is needed, but not always. y(i) = y(i-1) + k.x(i) - k.y(i-1) y(i) = y(i-1) - k.y(i-1) + k.x(i) k is usually a fraction, 0 k 1. To avoid floating point arithmetic and division, if you make it a binary fraction (1/2, 1/4, 1/8, 1/16, etc), you can implement the filter with bit shifts, and addition and subtraction only. -- JS Don't you think that it would all be a great deal easier to handle by multiplying it enough to make them whole numbers and then displaying them as if they had been fractional? Can you illustrate your point with an example? Sounds like fixed point arithmetic to me. Suppose you want to represent signed numbers with 16 bits, 8 of them fractional. 1.0 is represented as 256. 0.5 is represented as 128. If you multiply two 8.8 numbers together, you get a 16.16 number, shift right by 8, check for overflow, and you have another 8.8 number. -- Remember that multiplying and dividing in binary doesn't really exist and is a pain in the butt. So there are all sorts of shortcuts to make adding and subtracting operate using less time. Of course MPU's do this all in hardware. Although I haven't looked into it in a very long time I remember MPU's as being really hardware intense. |
#145
|
|||
|
|||
GPS Units = Show road steepness?
On Wednesday, March 20, 2019 at 6:28:17 PM UTC-7, Radey Shouman wrote:
Ralph Barone writes: Radey Shouman wrote: James writes: On 21/3/19 3:37 am, wrote: On Tuesday, March 19, 2019 at 1:58:13 PM UTC-7, James wrote: On 20/3/19 4:20 am, Radey Shouman wrote: writes: [ ... ] averages in particular. And I think that it was Radey talking about using IIR which would require a high end FPGA wouldn't it? I'm buying a new, wireless VDO for $50. An IIR can be very simple to implement. The "leaky integrator" or "exponential filter" is probably the simplest digital low-pass filter possible: y_i = y_{i-1} + k (x_i - y_{i-1}) In C: y += k*(x - y); If you're not too fussed about the actual cutoff frequency the multiplication can be done as a shift. The precision used for the state, y, does need to be higher than that of the input. If you need precise control over the frequency response then more work in design and more expense in implementation is needed, but not always. y(i) = y(i-1) + k.x(i) - k.y(i-1) y(i) = y(i-1) - k.y(i-1) + k.x(i) k is usually a fraction, 0 k 1. To avoid floating point arithmetic and division, if you make it a binary fraction (1/2, 1/4, 1/8, 1/16, etc), you can implement the filter with bit shifts, and addition and subtraction only. -- JS Don't you think that it would all be a great deal easier to handle by multiplying it enough to make them whole numbers and then displaying them as if they had been fractional? Can you illustrate your point with an example? Sounds like fixed point arithmetic to me. Suppose you want to represent signed numbers with 16 bits, 8 of them fractional. 1.0 is represented as 256. 0.5 is represented as 128. If you multiply two 8.8 numbers together, you get a 16.16 number, shift right by 8, check for overflow, and you have another 8.8 number. Or just use hundredths of a km as your internal unit and do integer math, then put the decimal point in the "wrong" place. Judicious choice of units can sometimes save you some expensive math. True, if they're using a 4-bit micro it's likely they're using decimal arithmetic. The fly in the ointment is that if you want to sell in the US you need to support miles. this is why I doubt that most speedos use a 4 bit uPU. If your entire display is mileage and speed that's fine but for other things like average speed or overall mileage which can run as high as 1,000,000 miles on some processors - well I did outline the low power clock speeds problem. |
#146
|
|||
|
|||
GPS Units = Show road steepness?
On Thursday, March 21, 2019 at 6:15:52 AM UTC-7, AMuzi wrote:
On 3/20/2019 8:28 PM, Radey Shouman wrote: Ralph Barone writes: Radey Shouman wrote: James writes: On 21/3/19 3:37 am, wrote: On Tuesday, March 19, 2019 at 1:58:13 PM UTC-7, James wrote: On 20/3/19 4:20 am, Radey Shouman wrote: writes: [ ... ] averages in particular. And I think that it was Radey talking about using IIR which would require a high end FPGA wouldn't it? I'm buying a new, wireless VDO for $50. An IIR can be very simple to implement. The "leaky integrator" or "exponential filter" is probably the simplest digital low-pass filter possible: y_i = y_{i-1} + k (x_i - y_{i-1}) In C: y += k*(x - y); If you're not too fussed about the actual cutoff frequency the multiplication can be done as a shift. The precision used for the state, y, does need to be higher than that of the input. If you need precise control over the frequency response then more work in design and more expense in implementation is needed, but not always. y(i) = y(i-1) + k.x(i) - k.y(i-1) y(i) = y(i-1) - k.y(i-1) + k.x(i) k is usually a fraction, 0 k 1. To avoid floating point arithmetic and division, if you make it a binary fraction (1/2, 1/4, 1/8, 1/16, etc), you can implement the filter with bit shifts, and addition and subtraction only. -- JS Don't you think that it would all be a great deal easier to handle by multiplying it enough to make them whole numbers and then displaying them as if they had been fractional? Can you illustrate your point with an example? Sounds like fixed point arithmetic to me. Suppose you want to represent signed numbers with 16 bits, 8 of them fractional. 1.0 is represented as 256. 0.5 is represented as 128. If you multiply two 8.8 numbers together, you get a 16.16 number, shift right by 8, check for overflow, and you have another 8.8 number. Or just use hundredths of a km as your internal unit and do integer math, then put the decimal point in the "wrong" place. Judicious choice of units can sometimes save you some expensive math. True, if they're using a 4-bit micro it's likely they're using decimal arithmetic. The fly in the ointment is that if you want to sell in the US you need to support miles. Popular bike computers use input in cm (rollout for a road bike is about 2012cm)and offer choice of either unit for display. That seems to indicate number manipulation is metric until final display if miles are selected. -- Andrew Muzi www.yellowjersey.org/ Open every day since 1 April, 1971 I agree completely. Metric is so much easier to manipulate. Too bad here in the US we retain statute measurements. |
#147
|
|||
|
|||
GPS Units = Show road steepness?
writes:
On Wednesday, March 20, 2019 at 5:53:52 PM UTC-7, Radey Shouman wrote: James writes: On 21/3/19 3:37 am, wrote: On Tuesday, March 19, 2019 at 1:58:13 PM UTC-7, James wrote: On 20/3/19 4:20 am, Radey Shouman wrote: writes: [ ... ] averages in particular. And I think that it was Radey talking about using IIR which would require a high end FPGA wouldn't it? I'm buying a new, wireless VDO for $50. An IIR can be very simple to implement. The "leaky integrator" or "exponential filter" is probably the simplest digital low-pass filter possible: y_i = y_{i-1} + k (x_i - y_{i-1}) In C: y += k*(x - y); If you're not too fussed about the actual cutoff frequency the multiplication can be done as a shift. The precision used for the state, y, does need to be higher than that of the input. If you need precise control over the frequency response then more work in design and more expense in implementation is needed, but not always. y(i) = y(i-1) + k.x(i) - k.y(i-1) y(i) = y(i-1) - k.y(i-1) + k.x(i) k is usually a fraction, 0 k 1. To avoid floating point arithmetic and division, if you make it a binary fraction (1/2, 1/4, 1/8, 1/16, etc), you can implement the filter with bit shifts, and addition and subtraction only. -- JS Don't you think that it would all be a great deal easier to handle by multiplying it enough to make them whole numbers and then displaying them as if they had been fractional? Can you illustrate your point with an example? Sounds like fixed point arithmetic to me. Suppose you want to represent signed numbers with 16 bits, 8 of them fractional. 1.0 is represented as 256. 0.5 is represented as 128. If you multiply two 8.8 numbers together, you get a 16.16 number, shift right by 8, check for overflow, and you have another 8.8 number. -- Remember that multiplying and dividing in binary doesn't really exist and is a pain in the butt. So there are all sorts of shortcuts to make adding and subtracting operate using less time. Multiplying and dividing in binary makes perfect sense. Students and masochists do it on paper. Of course MPU's do this all in hardware. Although I haven't looked into it in a very long time I remember MPU's as being really hardware intense. -- |
#148
|
|||
|
|||
GPS Units = Show road steepness?
writes:
On Wednesday, March 20, 2019 at 6:28:17 PM UTC-7, Radey Shouman wrote: Ralph Barone writes: Radey Shouman wrote: James writes: On 21/3/19 3:37 am, wrote: On Tuesday, March 19, 2019 at 1:58:13 PM UTC-7, James wrote: On 20/3/19 4:20 am, Radey Shouman wrote: writes: [ ... ] averages in particular. And I think that it was Radey talking about using IIR which would require a high end FPGA wouldn't it? I'm buying a new, wireless VDO for $50. An IIR can be very simple to implement. The "leaky integrator" or "exponential filter" is probably the simplest digital low-pass filter possible: y_i = y_{i-1} + k (x_i - y_{i-1}) In C: y += k*(x - y); If you're not too fussed about the actual cutoff frequency the multiplication can be done as a shift. The precision used for the state, y, does need to be higher than that of the input. If you need precise control over the frequency response then more work in design and more expense in implementation is needed, but not always. y(i) = y(i-1) + k.x(i) - k.y(i-1) y(i) = y(i-1) - k.y(i-1) + k.x(i) k is usually a fraction, 0 k 1. To avoid floating point arithmetic and division, if you make it a binary fraction (1/2, 1/4, 1/8, 1/16, etc), you can implement the filter with bit shifts, and addition and subtraction only. -- JS Don't you think that it would all be a great deal easier to handle by multiplying it enough to make them whole numbers and then displaying them as if they had been fractional? Can you illustrate your point with an example? Sounds like fixed point arithmetic to me. Suppose you want to represent signed numbers with 16 bits, 8 of them fractional. 1.0 is represented as 256. 0.5 is represented as 128. If you multiply two 8.8 numbers together, you get a 16.16 number, shift right by 8, check for overflow, and you have another 8.8 number. Or just use hundredths of a km as your internal unit and do integer math, then put the decimal point in the "wrong" place. Judicious choice of units can sometimes save you some expensive math. True, if they're using a 4-bit micro it's likely they're using decimal arithmetic. The fly in the ointment is that if you want to sell in the US you need to support miles. this is why I doubt that most speedos use a 4 bit uPU. If your entire display is mileage and speed that's fine but for other things like average speed or overall mileage which can run as high as 1,000,000 miles on some processors - well I did outline the low power clock speeds problem. As I recall that was for a relatively ancient Cateye computer. Later ones with more features might very well use more capable processors, but their manuals no longer say anything about the internal bits. I was surprised to see the one that Frank dug up. |
#149
|
|||
|
|||
GPS Units = Show road steepness?
On Friday, March 22, 2019 at 4:58:23 PM UTC-4, wrote:
On Thursday, March 21, 2019 at 6:15:52 AM UTC-7, AMuzi wrote: On 3/20/2019 8:28 PM, Radey Shouman wrote: Ralph Barone writes: Radey Shouman wrote: James writes: On 21/3/19 3:37 am, wrote: On Tuesday, March 19, 2019 at 1:58:13 PM UTC-7, James wrote: On 20/3/19 4:20 am, Radey Shouman wrote: writes: [ ... ] averages in particular. And I think that it was Radey talking about using IIR which would require a high end FPGA wouldn't it? I'm buying a new, wireless VDO for $50. An IIR can be very simple to implement. The "leaky integrator" or "exponential filter" is probably the simplest digital low-pass filter possible: y_i = y_{i-1} + k (x_i - y_{i-1}) In C: y += k*(x - y); If you're not too fussed about the actual cutoff frequency the multiplication can be done as a shift. The precision used for the state, y, does need to be higher than that of the input. If you need precise control over the frequency response then more work in design and more expense in implementation is needed, but not always. y(i) = y(i-1) + k.x(i) - k.y(i-1) y(i) = y(i-1) - k.y(i-1) + k.x(i) k is usually a fraction, 0 k 1. To avoid floating point arithmetic and division, if you make it a binary fraction (1/2, 1/4, 1/8, 1/16, etc), you can implement the filter with bit shifts, and addition and subtraction only. -- JS Don't you think that it would all be a great deal easier to handle by multiplying it enough to make them whole numbers and then displaying them as if they had been fractional? Can you illustrate your point with an example? Sounds like fixed point arithmetic to me. Suppose you want to represent signed numbers with 16 bits, 8 of them fractional. 1.0 is represented as 256. 0.5 is represented as 128. If you multiply two 8.8 numbers together, you get a 16.16 number, shift right by 8, check for overflow, and you have another 8.8 number. Or just use hundredths of a km as your internal unit and do integer math, then put the decimal point in the "wrong" place. Judicious choice of units can sometimes save you some expensive math. True, if they're using a 4-bit micro it's likely they're using decimal arithmetic. The fly in the ointment is that if you want to sell in the US you need to support miles. Popular bike computers use input in cm (rollout for a road bike is about 2012cm)and offer choice of either unit for display. That seems to indicate number manipulation is metric until final display if miles are selected. -- Andrew Muzi www.yellowjersey.org/ Open every day since 1 April, 1971 I agree completely. Metric is so much easier to manipulate. Too bad here in the US we retain statute measurements. Here in Canada it used to be simple to figure out how much longer a car trip would be. That's because the speed limits were 60mph on the major highways. For every minute you traveled you went one mile. Now that it's metric it's 100kph. In some instances I prefer the old measurements. Cheers |
#150
|
|||
|
|||
GPS Units = Show road steepness?
Sir Ridesalot writes:
On Friday, March 22, 2019 at 4:58:23 PM UTC-4, wrote: On Thursday, March 21, 2019 at 6:15:52 AM UTC-7, AMuzi wrote: On 3/20/2019 8:28 PM, Radey Shouman wrote: Ralph Barone writes: Radey Shouman wrote: James writes: On 21/3/19 3:37 am, wrote: On Tuesday, March 19, 2019 at 1:58:13 PM UTC-7, James wrote: On 20/3/19 4:20 am, Radey Shouman wrote: writes: [ ... ] averages in particular. And I think that it was Radey talking about using IIR which would require a high end FPGA wouldn't it? I'm buying a new, wireless VDO for $50. An IIR can be very simple to implement. The "leaky integrator" or "exponential filter" is probably the simplest digital low-pass filter possible: y_i = y_{i-1} + k (x_i - y_{i-1}) In C: y += k*(x - y); If you're not too fussed about the actual cutoff frequency the multiplication can be done as a shift. The precision used for the state, y, does need to be higher than that of the input. If you need precise control over the frequency response then more work in design and more expense in implementation is needed, but not always. y(i) = y(i-1) + k.x(i) - k.y(i-1) y(i) = y(i-1) - k.y(i-1) + k.x(i) k is usually a fraction, 0 k 1. To avoid floating point arithmetic and division, if you make it a binary fraction (1/2, 1/4, 1/8, 1/16, etc), you can implement the filter with bit shifts, and addition and subtraction only. -- JS Don't you think that it would all be a great deal easier to handle by multiplying it enough to make them whole numbers and then displaying them as if they had been fractional? Can you illustrate your point with an example? Sounds like fixed point arithmetic to me. Suppose you want to represent signed numbers with 16 bits, 8 of them fractional. 1.0 is represented as 256. 0.5 is represented as 128. If you multiply two 8.8 numbers together, you get a 16.16 number, shift right by 8, check for overflow, and you have another 8.8 number. Or just use hundredths of a km as your internal unit and do integer math, then put the decimal point in the "wrong" place. Judicious choice of units can sometimes save you some expensive math. True, if they're using a 4-bit micro it's likely they're using decimal arithmetic. The fly in the ointment is that if you want to sell in the US you need to support miles. Popular bike computers use input in cm (rollout for a road bike is about 2012cm)and offer choice of either unit for display. That seems to indicate number manipulation is metric until final display if miles are selected. -- Andrew Muzi www.yellowjersey.org/ Open every day since 1 April, 1971 I agree completely. Metric is so much easier to manipulate. Too bad here in the US we retain statute measurements. Here in Canada it used to be simple to figure out how much longer a car trip would be. That's because the speed limits were 60mph on the major highways. For every minute you traveled you went one mile. Now that it's metric it's 100kph. In some instances I prefer the old measurements. But officer, I had to do 120 kph to make the arithmetic work out! Nice hat, by the way. |
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 |