Why use FIR filters, anyway? Now that we've introduced good IIR (infinite impulse response) filters into PSoC Creator's Filter tool, I've spent a lot of time telling people the ways in which IIR filters can be a superior choice. They often require significantly fewer processing cycles to deliver comparable filtering. There are tradeoffs between FIR and IIR forms, of course. But here's the reason that drove the choice for a recent project: FIR filters have a finite impulse response!
Now this might appear to be just a banal restatement of the acronym for the filter type – of course FIR filters have a Finite Impulse Response, duh. But there are times when this finiteness is just what you need.
A filter with an impulse response that's strictly finite in length has a limited amount of 'memory'. Changes in the input signal that occurred at a time earlier than (“now” minus the duration of the impulse response) cannot possibly contribute to the latest output sample. If the input stabilizes to a constant value, the output will become exactly constant after a period equal to the duration of the impulse response. In other words, the settling time is finite, and known exactly.
In contrast, the output of an IIR filter is, in principle at least, affected by conditions in the input signal arbitrarily far back in the past. The output can also continue to change for an indefinitely long period of time after the input has stabilized. In a standard quantized digital version it's actually quite difficult to say for certain when the output will stop varying. In fact, sometimes it never does completely settle down, but fusses around for ever in a pattern called a limit cycle. One of those tradeoffs to examine one day. But back to the topic at hand.
Recently, colleagues requested a filter implementation for strongly suppressing the effect of both 50Hz and 60Hz AC line (plus their 2nd harmonics) pickup on some tiny sensor signals. We also needed to be able to strictly bound the settling time of the filter. For me, this settled (whoops, sorry about that) the IIR/FIR choice firmly in the FIR camp. Either form is possible on the Digital Filter Block hardware on the PSoC3 and PSoC5 devices I'm working with these days.
To fit the required number of filter channels concurrently into the hardware, I knew that these filters would need to be quite 'small', and that I couldn't waste implementation resources through the use of an inefficient design methodology. I needed to make every filter coefficient count towards my response goal! The actual method will be revealed in part 2, and to make sense of it, we first need to contemplate the meaning of FIR filters and how we represent them.
How is an FIR filter defined?
An FIR filter is completely defined by an ordered set of values that multiply (or 'weight') progressively more delayed versions of the input signal. Delaying samples of a signal is easy, of course. Just store the values in a memory somewhere, and read them out later. It doesn't have to be a digital memory; an early form of FIR filter called a transversal filter didn't digitize the signal at all, it just stored the voltage directly on a small capacitor, which was looked at later. The charge-coupled devices that today are mostly found in image sensors were once used to create sampled analogue voltage memories strung together into delay lines – so the early FIR filters were in fact analogue! But I digress.
All these weighted, delayed versions of the input signal are summed together, and this gives the desired output signal. If the input signal to this process is an impulse that has a non-zero value at only one sample time, the resulting output from the filter – its impulse response – has an identical form to the sequence of coefficients. Figure 1 shows an example set of filter coefficients (a 15-tap FIR designed by the PSoC Creator tool), together with the gain and the impulse responses.
Figure 1: An example 15-tap FIR filter
– coefficients, frequency and impulse responses.
Of course, many methods are available to calculate coefficients that deliver some desired filtering behaviour. Now, filter design is rather like cooking. You can get something partly or completely prepared by someone else and just pop it in the microwave, job done. Or you can put a little more effort in and make something up from more basic ingredients, using more fundamental tools. You do get more appreciation for food if you have some feeling for the processes employed to deliver the sensations that you crave. And so it is for electronic design, especially for filters.
Regular readers will recognize a repeating theme of mine here – roll up your sleeves and get 'under the hood' occasionally. Sometimes you'll create something unusual that's just not available on the shelves of your local store. Other times, the main value is that you'll learn how to 'call BS' (I think that's the correct American vernacular) on someone who's trying to pull some wool over your eyes (or your signals).
The good news is that you don't need to be a filter expert or a math nerd to make progress here. For example, as a chef (to push that cooking metaphor), you can exploit the Maillard reaction to make tasty dishes, without needing to understand its chemistry. And you can play around with some algebra to create cool filters even if you're not entirely comfortable with what it really means (yet <g>). And that's just what we're going to do right now!