# Typical filter orders

I am on my first DSP project where I want to implement lowpass/highpass filters for ECG application. I have started from MATLAB to give me orders and coefficients for my desired specs. I prefer to go with FIR filters but as you know they require much higher orders than IIR filters. Since this is my first project I have no clue what ballpark should I have in mind for a filter order that runs in a DSP.(Analog Devices BlackFin)

So I decided to frame this question as a general call for advice, that what filter orders are DSP engineers comfortable with choosing for implementation. Is 100's of order very high for a DSP? Do they go with less than order of 10? 50?

I understand this is very much dependent on filter specs and my application. But I still want to know if there is a range to have in mind.

I hope I have been able to convey my question.

my experience in audio is that for IIR filters, there is usually a cascaded Second-order Section (SOS) for every little feature (a bump or an edge in the frequency response deliberately placed there by the user). often just a single second-order IIR is used for many little jobs where some frequency is given a little boost or cut. we call those IIR filters a Parametric Equalizer.

however, for a fixed and sharp feature (like a brickwall of some sort), then the order of the IIR filter will be related to the sharpeness of that feature. for a brickwall, there is a 6 dB per octave of steepness in the wall for every integer order of the filter.

for FIR, Fat's answer is good. the order of the filter is 1 less than the number of taps of the FIR. the minimum order again is related to the sharpness of some particular feature in the frequency response. there are a couple of heuristic formula for initial guessing at what order you will need. i will try to express them in a way to compare apples-to-apples.

using a Kaiser-windowed FIR design the filter order (one less than the number of taps) is about:

$$N \ge \frac{(A-7.95)F_\text{s}}{14.357 \cdot \Delta f}$$

where $A$ is the amount of attenuation in dB of the brickwall, $\Delta f$ is the frequency width of the transition between the nominally un-attenuated and attenuated portions of the frequency response, and $F_\text{s}$ is the sample rate.

using Parks-McClellan will reduce $N$ a bit:

$$N \ge \frac{(\tfrac12 A + \frac{4.343}{r_\text{p}} - 29.7)F_\text{s}}{14.602 \cdot \Delta f}$$

where the new symbol $r_\text{p}$ is the passband ripple in dB.

this appears to be twice as good as i was expecting. so i am not sure i did this right, but i was being very careful with the equations from O&S about the P-McC alg.

• corrected the order vs length typo in my answer.. thnx! – Fat32 Aug 4 '17 at 0:49
• i changed my symbol notation to match yours, @Fat32. – robert bristow-johnson Aug 4 '17 at 2:24

The application itself determines the required quality of filters in terms filter specs, and requireed processing throughput in terms sample rate $$F_s$$, samples per second.

High quality filters will tend to have tight specs, and that will require high orders for a given type of filter. Different types of filters, however, can meet similar specs at different orders.

The order of the filter, and the given data (sample) rate $$F_s$$, in return, determines the processing power requirements. For example, an FIR filter of order $$N$$ will perform $$N+1$$ MACs (multiply accumulate) per typical output sample for long input sequences; and if the data sample rate is $$F_s$$ samples per second, this means the filter will perform $$(N+1) \times F_s$$ MACs per second.

Given a CPU with a clock frequency of $$M$$ Hz, and MAC efficiency of $$L$$ MACs per hertz, then your processor should provide $$M \times L > (N+1) \times F_s$$, excluding any overheads due indexing, looping, or memory operations.

This is for a typical FIR implementation on single core, single thread system. There are a variety of architectures to implement FIR / IIR filters based on multirate techniques, or parallelizations based on SIMD techniques, which can affect the processing power.

Finally, as a figure of very rough merit, for audio applications at $$44.1$$ kHz, an FIR filter of order less than $$20$$ will have mostly weak properties. Orders between $$20$$ and $$90$$ will have (increasingly) mild qualities, and orders larger than 128 can have good to high quality characthersitics, where high quality refers to more control on the filter frequency response's spectral shape. Be warned that thousands of taps might be necessary to realize a sharp transition, narrow band, FIR filter.

In late response to comments below, it's possible to implement an FIR filter convolution drastically more efficient by using FFT based frequency-domain multiplication technique. My answer concerns time-domain implementation at this point.

• One should note that for FIR filters, once you get beyond a particular order, it becomes more efficient (from a total arithmetic operations perspective) to use frequency-domain fast-convolution techniques to implement the filter. The breakeven point is going to be dependent on the characteristics of your platform, but it is often in the 50-100 range. There are some applications where thousands of taps are used routinely; I've seen some cases where hundreds of thousands of taps were employed when a filter with exceedingly sharp transition was desired. – Jason R Aug 4 '17 at 1:33
• there are room reverb effects algs that emulate actually spaces, like the nave of a cathedral. 44.1 kHz $F_s$ and an 6-second reverb time. comes out to be about a quarter million taps. they definitely use fast-convolution. – robert bristow-johnson Aug 4 '17 at 2:20
• @rbj wouldn't that mean they acquire at least one whole impulse response worth of samples to pad, fft them? That would imply the system is not working online. – Marcus Müller Aug 4 '17 at 6:53
• Yes, there is a tradeoff between delay and efficiency. For a given number of taps, the larger your block size, the fewer arithmetic operations you need per output sample. However, the latency of the processing increases because you have to wait for the larger block of samples to buffer up before you can do anything (so it might be deemed less responsive). There are often other reasons that drive you to smaller blocks; the processing can often be more efficient on smaller datasets due to characteristics of your hardware (cache size, for example). – Jason R Aug 4 '17 at 12:58
• Extremely long filters can still have low latency using partitioned convolution with shorter partitions at the beginning of the impulse response, see How do real-time convolution plugins process audio so quickly – Olli Niemitalo Aug 5 '17 at 6:16