skyjumper:
I have to admit, I don't fully understand what's going on in post #24. The A/D conversion is a 10 bit conversion. Are you just deciding that the fractional part of that should be 8 of those 10 bits?

No. The full 10 bits are used as-is.

Imagine you want to add 1/2 to 1/2. Using integer operations the result is not at all what we want: zero.

Let's take a simple 16 bit integer...

bbbb bbbb bbbb bbbb

...pretend there is a decimal point in the middle...

bbbb bbbb . bbbb bbbb

...also pretend that each bit to the right of the decimal is a fraction of a successive power of two...

bbbb bbbb . 1234 5678

"1" is the 1/2 place
"2" is the 1/4 place
"3" is the 1/8 place
"4" is the 1/16 place
etcetera

...and pretend each bit to the left of the decimal is just a normal integer...

iiii iiii . 1234 5678

The value 9.00 would be stored as...

0000 1001 . 0000 0000

...or 0x0900. The value 0.50 (1/2) would be stored as...

0000 0000 . 1000 0000

...or 0x0080. Adding 1/2 to 1/2 is just like adding normal integers (remember, the decimal isn't really there; we're just pretending it is)...

0000 0000 . 1000 0000

## 0000 0000 . 1000 0000

0000 0001 . 0000 0000

...or 0x0080 + 0x0080 = 0x0100.

There is an implied / imaginary divided-by-256 always present in our value. So 0x0080 + 0x0080 = 0x0100 can also be viewed as 128 (/256) + 128 (/256) = 256 (/256).

That's essentially what I'm doing in my fixed-point EWMA code. I pretend there is a decimal point to the left of the right-most eight bits (just like the example above). In order to convert from a "normal" integer (like the value returned from analogRead) I have to shift the value left by eight bits so the decimal points are aligned. That's the purpose of multiplying by 256; to shift the whole number into the whole number position.

Does that help?

From looking at your revision to the model spreadsheet, I noticed that making that change degrades how accurately the output of the filter reflects the input (when gain/alpha is set to 1).

I should have mentioned, the alpha for OUT 5 is permanently set at 0.25. No attempt is made to use the value in cell B3.

Just to make certain I understand: You're saying that OUT 1 and OUT 5 are a bit different even though they both have an alpha of 0.25. Correct?

I assume this reflects the reduced precision?

Yes. Excel uses IEEE 64-bit floats which give 11 to 12 total digits (10 to 11 decimals in this case). My code always has 2.4 decimals {log(256)}. The two values will frequently be a bit different but should never diverge for any extended period and should never be more than 0.005 different.

Whether or not this is acceptable of course depends on the application and the range of data.

Exactly. Two more things to consider...

It may not be worth using the fixed-point version because of conversions. In your case, you have the motor speed with two decimals. In order to use the fixed-point version you have to multiply the motor speed by 100 and round to an integer. If you display the smoothed value, you will have to convert the fixed-point value to text. After all that, the floating-point version may actually be more efficient.

The fixed-point version works well when alpha is predetermined and unlikely to change. In your case, you will probably want to experiment with different alpha values which makes the fixed-point version annoying and difficult to use.