Advantages

• Low implementation footprint: requires less coefficients and memory than FIR filters in order to satisfy a similar set of specifications, i.e., cut-off frequency and stopband attenuation.
• Low latency: suitable for real-time control and very high-speed RF applications by virtue of the low coefficient footprint.
• May be used for mimicking the characteristics of analog filters using s-z plane mapping transforms.

Disadvantages

• Non-linear phase characteristics.
• Requires more scaling and numeric overflow analysis when implemented in fixed point.
• Less numerically stable than their FIR (finite impulse response) counterparts, due to the feedback paths.

Definition

An IIR filter is categorised by its theoretically infinite impulse response,

Practically speaking, it is not possible to compute the output of an IIR using this equation. Therefore, the equation may be re-written in terms of a finite number of poles \(p\) and zeros \(q\), as defined by the linear constant coefficient difference equation given by:

where, \(a(k)\) and \(b(k)\) are the filter’s denominator and numerator polynomial coefficients, who’s roots are equal to the filter’s poles and zeros respectively. Thus, a relationship between the difference equation and the z-transform (transfer function) may therefore be defined by using the z-transform delay property such that,

As seen, the transfer function is a frequency domain representation of the filter. Notice also that the poles act on the output data, and the zeros on the input data. Since the poles act on the output data, and affect stability, it is essential that their radii remain inside the unit circle (i.e. <1) for BIBO (bounded input, bounded output) stability. The radii of the zeros are less critical, as they do not affect filter stability. This is the primary reason why all-zero FIR (finite impulse response) filters are always stable.

A discussion of IIR filter structures for both fixed point and floating point can be found here.

Classical IIR design methods

A discussion of the most commonly used or classical IIR design methods (Butterworth, Chebyshev and Elliptic) will now follow. For anybody looking for more general examples, please visit the ASN blog for the many articles on the subject.

ASN Filter Designer’s graphical designer supports the design of the following four IIR classical design methods:

• Butterworth
• Chebyshev Type I
• Chebyshev Type II
• Elliptic

 

 

The algorithm used for the computation first designs an analog filter (via an analog design prototype) with the desired filter specifications specified by the graphical design markers – i.e. pass/stopband ripple and cut-off frequencies. The resulting analog filter is then transformed via the Bilinear z-transform into its discrete equivalent for realisation.

Biquad implementations are advocated for numerical stability.

The Bessel prototype is not supported, as the Bilinear transform warps the linear phase characteristics. However, a Bessel filter design method is available in ASN FilterScript.

As discussed below, each method has its pros and cons, but in general the Elliptic method should be considered as the first choice as it meets the design specifications with the lowest order of any of the methods. However, this desirable property comes at the expense of ripple in both the passband and stopband, and very non-linear passband phase characteristics. Therefore, the Elliptic filter should only be used in applications where memory is limited and passband phase linearity is less important.

The Butterworth and Chebyshev Type II methods have flat passbands (no ripple), making them a good choice for DC and low frequency measurement applications, such as bridge sensors (e.g. loadcells). However, this desirable property comes at the expense of wider transition bands, resulting in low passband to stopband transition (slow roll-off). The Chebyshev Type I and Elliptic methods roll-off faster but have passband ripple and very non-linear passband phase characteristics.

Comparison of classical design methods

The frequency response charts shown below, show the differences between the various design prototype methods for a 5th order lowpass filter with the same specifications. As seen, the Butterworth response is the slowest to roll-off and the Elliptic the fastest.

Elliptic

Elliptic filters offer steeper roll-off characteristics than Butterworth or Chebyshev filters, but are equiripple in both the passband and the stopband. In general, Elliptic filters meet the design specifications with the lowest order of any of the methods discussed herein.

Filter characteristics

• Fastest roll-off of all supported prototypes
• Equiripple in both the passband and stopband
• Lowest order filter of all supported prototypes
• Non-linear passband phase characteristics
• Good choice for real-time control and high-throughput (RF applications) applications

Butterworth

Butterworth filters have a magnitude response that is maximally flat  in the passband and monotonic overall, making them a good choice for DC and low frequency measurement applications, such as loadcells. However, this highly desirable ‘smoothness’ comes at the price of decreased roll-off steepness. As a consequence, the Butterworth method has the slowest roll-off characteristics of all the methods discussed herein.

Filter characteristics

• Smooth monotonic response (no ripple)
• Slowest roll-off for equivalent order
• Highest order of all supported prototypes
• More linear passband phase response than all other methods
• Good choice for DC measurement and audio applications

Chebyshev Type I

Chebyshev Type I filters are equiripple in the passband and monotonic in the stopband. As such, Type I filters roll off faster than Chebyshev Type II and Butterworth filters, but at the expense of greater passband ripple.

Filter characteristics

• Passband ripple
• Maximally flat stopband
• Faster roll-off than Butterworth and Chebyshev Type II
• Good compromise between Elliptic and Butterworth

Chebyshev Type II

Chebyshev Type II filters are monotonic in the passband and equiripple in the stopband making them a good choice for bridge sensor applications. Although filters designed using the Type II method are slower to roll-off than those designed with the Chebyshev Type I method, the roll-off is faster than those designed with the Butterworth method.

Filter characteristics

• Maximally flat passband
• Faster roll-off than Butterworth
• Slower roll-off than Chebyshev Type I
• Good choice for DC measurement applications

Download demo now

Licencing information

The post Classical IIR filter design: a practical guide appeared first on ASN Home.

I recently attended a seminar on advanced instrumentation, where algorithms were heavily featured. The project pitches heavily emphasised implementation rather than analysis and design, which started an interesting discussion, and led me to think about providing some hints that we’ve successfully used over the years:

1. What do we want to achieve? This is perhaps obvious, but I’ve seen that many people do over look this step and jump into Matlab or C in order to try something out. I would urge some caution here, and suggest that you think very carefully about what you’re about to undertake before writing a single line of code. Don’t be afraid to ask your colleagues/network for advice, as their suggestions may save you months of development time. Also consider using established techniques such as, MoSCoW.

2. The specifications: After establishing the ‘big picture’, split up the specifications into ‘must haves’ and ‘nice to haves’. This may take some time to work out, but undertaking this step saves a considerable amount of time in the development process, and keeps the client in the loop. The specifications don’t need to be 100% complete at this stage (they’re always minor details to be worked out), but make sure that you’re clear about what you’re about undertake, and don’t be afraid to do some analysis or short experiments if required.

3. Algorithm design: Sketch out the algorithm’s building blocks (Visio is a good tool), and for each idea produce a short list of bullets (pros and cons) and computational complexity. This will allow you easily review each concept with your peers.

4. Test data: arrange for some test vectors data (from clients or design some of your own synthetic signals), and sketch out a simple test plan of test vectors that you aim to use in order to validate your concept.

5. Development: Depending on your programming ability, you may decide to implement in C/C++, but Matlab/Octave are very good starting points, as the dynamic data types, vector math and toolboxes give you maximum flexibility. Use the testplan and vectors that you’ve designed in step 4. However, in the case of how to best design your algorithm for streaming applications, I would say that many aspects of the algorithm can be tested with an offline (data file) approach. For a majority of our radar and audio work, we always begin with data file comprised of 10-30seconds worth of data in order to prove that the algorithm functions as expected. Subsequent implementation steps can be used to make the algorithm streaming, but bear in mind that this may take a considerable amount of time!

6. Avoid a quick fix! Depending on the complexity of your algorithm, there will be certain testvectors that degrade the performance of your algorithm or even cause it to completely fail. Allocate sometime to investigate this behaviour, but remember to prioritise the importance, and don’t spend months looking for a minor bug. Try and avoid looking for a quick fix or a patch, as they generally re-appear in the future and kick you up the backside.

7. Implementation: after verifying that your concept is correct, you can finally consider target implementation. This step couples back to the previous steps, as the algorithm complexity will have direct influence on the implementation platform and development time. Some good questions to ask yourself: Is the target platform embedded? In which case, do I need an FPGA, DSP or microcontroller? Will it be fixed point or floating point? Perhaps it will be PC based, in which case is it for Windows, Linux or Mac or for a tablet? What tools do you need in order to develop and test the algorithm?

8. Validation: Verify that your implemented algorithm works with your test vectors and that look for any difficult cases that you can find – remembering point 6.

9. Documentation: In all of the aforementioned steps, documentation is essential. Make sure that you document your results, and provide a paper trail such that a colleague can continue with your work if you get hit by a bus.

The post Some points to bear in mind when designing and implementing algorithms appeared first on ASN Home.