Low pass filtering in software

[gf]

You either have to have a gain less than 1 at your frequency of interest, or allow for overshoot.

It is also my subjective observation that all low pass filters that do not overshoot seem to have a frequency response that starts to roll off at DC, i.e. gain(f) < 1 for f > 0. Even a flat frequency response with a soft roll-off beyond the flat top (e.g. Butterworth) is not possible without overshoot in the step response.

[Nominal Animal]

It is also my subjective observation that all low pass filters that do not overshoot seem to have a frequency response that starts to roll off at DC, i.e. gain(f) < 1 for f > 0. Even a flat frequency response with a soft roll-off beyond the flat top (e.g. Butterworth) is not possible without overshoot in the step response.

Don't you mean \$\text{gain}(f_1) > \text{gain}(f_2)\$ for all frequencies \$0 \lt f_1 \lt f_2\$? At least, this is how I understand the no-overshoot requirement.  The actual maximum gain doesn't matter, only that it has to lower as frequency increases.

I do not have an expression for the minimum necessary drop in gain, though, because I do not know all the ways one can avoid the overshoot.  I've only shown one example of when it is more or less achieved.

When the pulse width and interval has a minimum, like in pulse density modulation limited to some middle duty range –– this is used to push the quantisation noise up in frequency, making filtering the PDM signal to an analog one much easier; for example, limiting to 16..240 in 8-bit PDM means you'll always have an edge within any sixteen consecutive cycles –– then I do believe the gain below that fundamental frequency \$f_0\$ can be flat without causing overshoot; i.e. \$f_0 \lt f_1 \lt f_2\$ in such specific circumstances, but generally \$f_0 = 0\$.

It's just a belief, though; I haven't verified it mathematically.  It could be that \$f_0 = 0\$ for the absolutely-no-overshoot case, because PDM patterns can always hold lower frequency content than the frequency corresponding to the minimum interval between signal edges –– that's what it's used for, after all.  I do not know if that is sufficient to cause overshoot (at least more than in statistically insignificant corner cases).

[gf]

Don't you mean gain(f1)>gain(f2) for all frequencies 0<f1<f2? At least, this is how I understand the no-overshoot requirement.

This is definitively not a requirement. The FIR in the attached image is all-positive, so its integral (step response) won't overshoot. Still the corresponding frequency response has "ripples", i.e. your condition is not met. [ Figure2 shows, of course, only a finite section of the infinte frequency axis. ]

[Nominal Animal]

Right, thanks.  Makes specifying it precisely quite hard; possibly something along the lines of "The maximum gain in any lower frequency band with at least one local gain maxima must be greater than the maximum gain in any higher frequency band with at least one local gain maxima, or overshoot will occur with digital inputs with fundamental frequency in the lower frequency band and harmonics in the higher frequency band."

[paulca]

Oddly asides...  I was looking into doing some rudimentary filtering in assembler yesterday.  Well, me not being the mathematician type, I called it "Rolling averages" or "Windowed means".

Take a value which you can read every time you are executed, then write it to a peripheral register to display and return.

Now that value is hard to read as it just jumps around all over the place. 32.4  29.2  24.5  38.2 ... to the human eye it's nearly meaningless updating every 0.5 seconds.

So what is the simpliest way to address this I wondered?

If I take the "running average", add the next value to it and divide the result by two, it's still an "average" right?  Don't be mean about "mean" now!

A quick thought experiment makes you think it's not though.

10, 20, 30 avg 20

However,

10, 20 avg 15
15, 30 avg 22.5

Yet looking more closely 22.5 is a valid value for a "window size" or "set" of 2.  (EDIT:  I know it's not now... now I do) The value "20" is for a window of 3.  Both are correct in there own way.

The thing is though.  (15+30) / 2.  The "15" is the output of the previous averaging.  Therefore this is not a finite response "averaging function" at all, it's a decay function.  A single datum pulse will result in an exponential decay response.

I'm sure there are correct mathematical terms, but it's just amazing how much of a can of worms TWO single ASM instructions can get you into.

Anyway.  For it's purpose, to smooth out a "jumping" datum so it makes sense to a human and will allow them to spot trends.... for that I need to spend some memory and some iteration and use a proper rolling window and average it.  Not with 2 values, but with a dozen maybe.

Other janks not becoming of someone who did any maths study....  If I don't display the value itself, but it's mid point between itself and it's previous, that will give me an intregal?  Where it will approach the real value faster if its changing quickly, but slower if its not.  But never reaching the actual value.  "If the sales man travels half the distance to the destination each day, how long does it take?" (EDIT:  It's the same thing as avg+current/2.)