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

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.