# How does transition width of a low-pass filter affect a message which is well within the pass-band?

I'm taking a communication systems course and we use GNURadio in the lab. In an exam, we had a simple question where we were asked to demodulate a Dual Side Band (with carrier) AM signal in GNURadio. Carrier frequency was known to be precisely 500KHz and message was audio (known to be < 15KHz). The incoming signal has sampling rate of 1.92MHz.

EDIT: i.e incoming signal is given to be of the form $(1 + k_am(t))cos(2{\pi}{f_c}t)$ with $|k_am(t)| < 1$

To do that, I took the absolute value of the incoming signal, and used a Low pass Filter with cutoff frequency 17KHz and transition width 100Hz to obtain the audio clip. I was listening to the audio sampled at 48KHz (with proper decimation of 40 set in the Low Pass filter block). However the received audio clip was very jittery. I could listen and identify the song, but there were periodic higher frequency spiky noises.

The TA observed this, changed the transition width of the LPF from 100Hz to 1KHz and it was completely fine now - I could hear it neat and clear! I argued that I only tried to make the filter better by making it more ideal - brick-wall type, and also, this transition is happening where I don't have my message (transition occurs at 17KHz and my message < 15KHz). He replies that I pay a price when I make a filter transit faster, and added I would understand that when I do the digital communications course.

Could someone kindly explain to me, what price I pay (in digital domain) when I decrease the transition width of the Low Pass filter? Thanks in advance.

• What type of filter was that? FIR, IIR, Equiripple etc.? – Fat32 Sep 23 '17 at 22:19
• Thanks for the response @Fat32. It was the ready-made "Low pass filter" block which is apparently an FIR filter (ref: www.ece.uvic.ca/~elec350/grc_doc/ar01s12s01.html) – QMrules Sep 25 '17 at 4:08
• was the length of the filter fixed during the design? – Fat32 Sep 25 '17 at 7:55
• @Fat32 I wasn't sure of that while changing the transition width. In fact the answers helped me understand that decreasing the transition width directly increases the filter length, so I think my filter length wasn't fixed by the ready made LPF block in GNURadio. – QMrules Sep 28 '17 at 18:51

For an FIR filter there are 3 main components that determine the filter length for equiripple designs:

1. Passband ripple
2. Stopband attenuation level
3. Transition width (Width from the edge of the passband to the edge of the stopband)

For other filter designs the filter order may be related to flatness of the passband and the rate of fall-off in the stopband (and initial stopband attenuation). The transition width is often expressed as a fraction of the original sampling frequency.

In your case the original fraction is $\frac{100}{1.92\times10^6}\approx 52.1\times10^{-6}$ which is very small and is going to require a very long filter. Depending on the algorithm used to design the filter, the algorithm may run into numerical difficulties. As an example, designing a 2000 tap FIR equiripple filter using Matlab's Remez type routines is often problematic.

Increasing the transition width by a factor of 10 will roughly reduce the filter length by a factor 10 as well. This is just a rough approximation and results will vary based on the design routine and the filter specs being used.

If you really need such a small transition width, it is better to perform you decimation in steps, e.g, break it down to decimate by 10 and then by 4. In the first decimate by 10 you can use a wider transition width. The transition width in the last filter will be the same as the original requirement, but because of the reduced sampling rate the filter length will be much smaller. Crochiere and Rabiner's "Multirate Signal Processing" goes into more details.

• Thanks for the helpful response. I've understood it as follows: Smaller transition width (for a given cutoff frequency) implies a greater roll-off slope and hence higher order in the familiar analog sense, and analogously also in the digital domain. And since order of filter in digital domain is related to the number of taps (= length) of filter, it'll take more processing for a higher order filter. Hence the jitter in my sound. Also, thanks for the workaround. It makes sense to me and I'll try that. – QMrules Sep 28 '17 at 18:42
• Pretty much. I can't really say what would cause the jitter - you'd have to look at the time series and/or the frequency domain and see exactly what the code is doing. Note - order and filter length are really only related for FIR filters. For IIR you can have one pole that is close to the unit circle and it will have a long impulse response. – David Sep 29 '17 at 1:13

A filter with cutoff frequency 17kHz and transition width of only 100Hz will inevitably result in a filter of very high order.

This means filters with poles very near the unit circle.

This means several things: intermediate values in the filter implementation can get very large amplitudes, and produce clipping, overflow, and distoriton. Also, The actual implementation (due to limited numerical precision) may result in the poles shifted outside the unit circle, and thus produce an unstable filter.

As a rule of thumb, filter orders of 10 (for an IIR filter) is too much.

• Thanks for the analogy with poles in the complex plane, it helps. :) – QMrules Sep 28 '17 at 18:48