Portable software defined transceiver: Roofing filter

Jason has been working on a portable software defined transceiver design for the past year. Every day this week he’ll discuss a different part of the hardware in a series of guest posts. You can chat with the designer in the forum.  Today’s post is about the roofing filter.

The term roofing filter is used to refer to the filter in a receiver that determines the bandwidth it is capable of receiving. Since this is a general purpose software defined transceiver, it is desirable to support a variety of bandwidths. Ideally, there would be separate roofing filters for each bandwidth that was to be supported. This would enable superior dynamic range for the narrower bandwidths than would be possible if only the widest supported bandwidth was used. However, this design is a compromise between performance and simplicity, so I have elected to create only a single roofing filter with a bandwidth that starts to roll off at 10KHz.

Lots more below.

In a superheterodyne receiver, the roofing filter takes the form of a bandpass filter — usually implemented with a ceramic or crystal filter at some standard frequency like 455KHz or 10.7MHz. In a DC receiver, things are a bit simpler. The roofing filter is implemented with a simple low-pass filter since the it has a zero-IF. But because this is a software defined receiver, special attention needs to be paid to the type of low pass filter.

Filters (low-pass or otherwise) affect not only the amplitude, but also the phase of the signals that go through them. Consider for a moment that you are decoding a signal encoded with FSK (frequency shift keying). There are two (or more) different frequencies present in the signal you wish to decode. If your filter delays all frequencies within the passband equally (leading to a linear phase response) then the mark and space frequencies within your FSK signal will be delayed the same amount and therefore there will be no overlapping of energy between them. On the other hand, of the filter delays different frequencies within the passband by different amounts, then there will be energy overlapping between the mark and space frequencies, and this will degrade your ability to decode a signal in the presence of noise. Typical filter types like the Butterworth or Chebychev designs do not have linear phase responses and are therefore best avoided in general purpose software defined radios. There is another type of filter, called the Bessel filter, which does have a linear phase response within the passband and that is what I have chosen to use for this design.

There is also an important interaction between this low pass filter and the sampling rate used to digitize the signal. The filter must prevent any signal energy from above the Nyquist frequency from reaching the analog to digital converters. Otherwise aliasing will result, which will again compromise the performance of the receiver. The end result of this is that if you use a low-order low-pass filter, you will need a sampling rate which is many times higher than your desired passband to avoid aliasing. For this design, I am willing to oversample the signal by a factor of two, so my lowpass filter needs to offer a great deal of attenuation above 20KHz in order to prevent aliasing. An 8th order lowpass Bessel filter meets the requirements I set out above, offering 40dB of attenuation at 20KHz, rapidly increasing above that frequency while maintaining a linear phase response within the passband.

Here is the schematic of the low pass filter. There are two identical filters in the design, one for the in-phase (real) channel, and the other for the quadrature (imaginary) channel. I have attached a PDF copy of the schematic for those who wish to examine it more closely.

Note:

Yes, I have built and tested the filter. It worked as advertised, but not as drawn! Earlier when you mentioned I was missing feedback, I checked my notes and didn’t know what you meant. However, I just looked at the schematic I drew in Altium Designer, and I see that when I drew the first 2nd order stage, I left out the connection between the inverting input and the output of the op amp! That mistake was duplicated on the remaining 7 stages in the schematic when I pasted it!

Anyway, thank you very much for catching that mistake and I’m sorry I didn’t think to check the posted schematic rather than my notes earlier. Since this mistake is particularly grievous, I have edited my earlier posting to correct the error.

Via the forum.

Join the Conversation

5 Comments

  1. You may be interested in learning how to correctly write SI symbols: http://en.wikipedia.org/wiki/International_System_of_Units#Writing_unit_symbols_and_the_values_of_quantities

    Mainly because KHz ≠ kHz (KHz would be kelvin · hertz as only SI prefices above k and unit names derived from the name of a person are start with a capital letter), but also because “10.7 MHz”, not “10.7MHz”. Correcting the last one is maybe nitpicking, however, if you are writing scientific documents, the missing space really starts to irritate you when you read an article like this.

    Marvin

  2. I don’t want to pick on you – I really don’t.

    I suspect that you haven’t actually tested the low-pass filter that you describe above. When you do test it, you will most likely find that it doesn’t work.

    What is missing is the feedback from the output of each op-amp back to the (-) input. Without that feedback, the op-amp can never stabilize at its DC bias point, and will instead go to one rail or the other.

    The value of the feedback resistor affects the filter cutoff frequency, thus, I can’t suggest a value.

    Actually, a 2nd look suggests that you are probably running the op-amps at unity gain. In that case, your drawing is missing the lines from the outputs of the op-amps back to the (-) input.

    Hope this helps.

    dwayne

    1. I noticed the lack of feedback right away. These op-amp configurations look like Sallen-Key filters without feedback. I don’t see how they can work as shown in the schematic.

  3. Thank you DwayneR and Rsdio for noticing the missing feedback in the filters. I have in fact built and tested the filters, but I made a transcription error when I drew the schematics in the schematic capture software from my notes. I have corrected the schematic in my blog entry to reflect this.

    Regarding the SI conventions on using symbols — I wasn’t aware of this, but now that I am, I will update my writing practices to follow them.

Leave a comment

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.