Ettus B205mini on Mac OS Part 2: Matched Filter Basics

In a previous project write-up, I created a simple loop back flowgraph for the Ettus B205mini USRP that took audio from my computer‘s microphone, applied FM modulation before sending it to the B205mini to transmit out to it’s own receiver port to apply the corresponding demodulation. Towards the end of that post, I made a note that the received audio had some distortion accompanied by some substantial sidelobes on the spectrum analyzer plot that were most likely due to my use of a low pass filter (LPF) on the transmitted data versus the proper use of a matched filter.

So revisited that flowgraph to see what the results of replacing the LPF on the baseband data would look like on both the transmit and receive sides of the radio chain. This is based on the GNU Radio installation I outlined in my previous project post here, and the B205mini setup I outlined in another project post here.

What is a Matched Filter?

A matched filter in digital signal processing (DSP) and software defined radio (SDR) is a special case of low pass filter designed to filter out noise/interference while aligning the signals within the passband such that they all sum to zero. Constraining signals within a filter like this is also known as "pulse shaping".

The main focus of a matched filter is to take each digital symbol or "pulse" and align them such that every pulse within the symbol period, T, sums up to equal zero. This ultimately guards against issues such as inter-symbol-interference (ISI).

Because the function of matched filters is to align symbols within the symbol period, it is important that it happens on both the transmit and receive side of the radio system. Arguably, it has the most impact on the transmit side since it would be extremely difficult for the receiver to realign the pulses/symbols if they were never aligned to begin with.

For a deeper look into the math behind a matched filter relative to their function, see PySDR's great write-up about Pulse Shaping here.

One of the common implementations of a matched filter is the root raised cosine (RRC) filter since it can zero sum the pulses within its passband while low pass filtering the spectrum.

The two key parameters of an RRC filter is the symbol rate (which dictates the symbol period, T) and how quickly the filter transitions from the passband to the stopband in the time domain (aka the roll off factor).

These two parameters translate to the GNU Radio Root Raised Cosine Filter block as the Symbol Rate and Alpha parameters respectively:

The Num Taps parameter is the number of taps in the underlying FIR filter used to implement the RRC in software. While more taps is usually better, there is a maximum before it bogs dow the CPU/memory of the host computer. For my Intel core i9 MacBook Pro with 64GB RAM, I found that 4000 taps was the maximum amount I could use before it bogged everything down.

GNU Radio Flowgraph

Like I mentioned at the beginning of this post, I wanted to directly compare the performance of the radio core with LPFs versus RRCs.

So I added the RRC blocks in line with the LPF blocks and enabled one or the other.

The first test is the original set up with LPFs on both the transmit and receive sides of the SDR:

The second with RRCs on both the transmit and receive sides of the SDR:

And finally with an RRC on the transmit side and an LPF on the receive side:

It's also worth noting that in since I'm using the WBFM Transmit block and Audio Source block, the symbol rate that is set in the RRC block is the audio rate coming out of the WBFM Transmit block.

And since the quadrature rate in the WBFM Transmit block has to be an integer multiple of the audio rate, I had to play around with interpolation/decimation factors a bit. The audio rate coming out of the Audio Source is 48kHz, so interpolating the audio rate to anything above that causes ISI out of the RRC.

My desired quadrate rate is 512kHz and my overall sample rate is 1.024MHz (to make the underlying firmware in the Zynq FPGA nice, they are powers of 2), so I used an interpolation factor of 2 and a decimation factor of 3 to get an audio rate of 32kHz which is the symbol rate that the RRC is then set to for both the transmit and receive side.

Results on Received Data

In the case of LPFs on both the transmit and receive chain the signal is clearly filtered down to the spectrum of interest, but the transmitted spectrum also has some sidelobes that made it through the filter. This manifests in some extra static and distortion in the received audio signal since there is ISI and the roll off of the LPF isn't as sharp as it is with the RRC.

Disabling the LPF and enabling the RRC on the transmit side while leaving the LPF on receive side shows the side lobes are eliminated on the transmit side as expected so the received signal is greatly improved, but there is still a large amount of static and a bit of distortion in the received signal.

Finally, enabling RRCs on both the transmit and receive results in the cleanest audio coming back through the receiver. Compared to the received spectrum (bottom) in the previous run with the LPF, the sharper roll off of the RRC is shown with the narrowed spectrum:

And that's the magic of matched filtering in SDRs!