

Thread Tools  Display Modes 
Ads 
#132




GPS Units = Show road steepness?
On 21/3/19 3:37 am, wrote:
On Tuesday, March 19, 2019 at 1:58:13 PM UTC7, 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 lowpass filter possible: y_i = y_{i1} + k (x_i  y_{i1}) 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(i1) + k.x(i)  k.y(i1) y(i) = y(i1)  k.y(i1) + 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?  JS 
#133




GPS Units = Show road steepness?
James writes:
On 21/3/19 3:37 am, wrote: On Tuesday, March 19, 2019 at 1:58:13 PM UTC7, 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 lowpass filter possible: y_i = y_{i1} + k (x_i  y_{i1}) 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(i1) + k.x(i)  k.y(i1) y(i) = y(i1)  k.y(i1) + 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.  
#134




GPS Units = Show road steepness?
Radey Shouman wrote:
James writes: On 21/3/19 3:37 am, wrote: On Tuesday, March 19, 2019 at 1:58:13 PM UTC7, 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 lowpass filter possible: y_i = y_{i1} + k (x_i  y_{i1}) 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(i1) + k.x(i)  k.y(i1) y(i) = y(i1)  k.y(i1) + 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. 
#135




GPS Units = Show road steepness?
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 UTC7, 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 lowpass filter possible: y_i = y_{i1} + k (x_i  y_{i1}) 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(i1) + k.x(i)  k.y(i1) y(i) = y(i1)  k.y(i1) + 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 4bit 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. 
#136




GPS Units = Show road steepness?
On 21/3/19 11:53 am, Radey Shouman wrote:
James writes: On 21/3/19 3:37 am, wrote: On Tuesday, March 19, 2019 at 1:58:13 PM UTC7, 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 lowpass filter possible: y_i = y_{i1} + k (x_i  y_{i1}) 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(i1) + k.x(i)  k.y(i1) y(i) = y(i1)  k.y(i1) + 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. There can be a good reason for doing something like that. If x(i) 1/k, for example, and k is 1/16, then k.x(i) = 0, without decimal or fixed points. The solution is to leave the output k times greater, and only divide the output y(i) by k when you need it. I think this is what Tom was meaning.  JS 
#137




GPS Units = Show road steepness?
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 UTC7, 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 lowpass filter possible: y_i = y_{i1} + k (x_i  y_{i1}) 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(i1) + k.x(i)  k.y(i1) y(i) = y(i1)  k.y(i1) + 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 4bit 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 
#138




GPS Units = Show road steepness?
AMuzi writes:
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 UTC7, 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 lowpass filter possible: y_i = y_{i1} + k (x_i  y_{i1}) 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(i1) + k.x(i)  k.y(i1) y(i) = y(i1)  k.y(i1) + 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 4bit 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. That's likely true. That last step is just one more thing that has to be coded, has to fit in the available program and memory space, has to run in the available time ... Naturally the user expects it all to just work. Maybe it's a good thing metric time never took off. 
#139




GPS Units = Show road steepness?
2012 cm? Are you sure?

#140




GPS Units = Show road steepness?

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 