Why is GNU Radio dropping packets when I introduce a Frequency Xlating FIR filter?

I've got a GNU Radio flowgraph intended to take a signal from a USRP X310 at a 25MS/s sample rate and downsample it to 2.4576MS/s for demodulation as 9600 baud GMSK.

If I run the USRP straight into a FFT GUI sink, I get a nice, constantly moving graph, with the spike of the signal appearing every five seconds, as expected.

As soon as I introduce either the FIR filter or the automatic gain control, I start getting overflows (error message O) and dropped packets (error message D) in the output text. After two or three signalling periods, I'm getting maybe 20 dropped packets at a time and sometimes all the output charts freeze for several seconds at a time.

Please, can anyone explain this behaviour to me?

GNU Radio doesn't drop packets – it's probably the UHD source that does that.

There's only one reason for that happening: Due to the additional CPU workload your filter introduces, your computer becomes too slow to process the samples that come in at 25 MHz in real time – buffers fill up, and at some point, they're full, so the new samples coming from the USRP can't be put anywhere.

I don't know your filter specifications – but if they're anything like your grayed out low pass, that filter is massive.

To use the numbers I can guess from the screenshot:

• transition width $\Delta f=5\text{ kHz}$
• sampling rate $f_2=2457.6\text{ kHz}$
• attenuation $\delta_1=60\text{ dB}=10^{-6}$ (default in most GNU Radio filter design routines)
• passband ripple $\delta_1=1\text{ dB}=10^{0.1}$ (wild guess, might be to benevolent, this could be much better, and hence, computationally intense)

and put these into this formula for the number of taps (further notes):

\begin{align} N&\approx \frac 23 \log_{10} \left[\frac1{10 \delta_1\delta_2}\right]\,\frac{f_s}{\Delta f}\\ &= \frac23\log_{10}\left[\frac1{10\cdot10^{0.1}\cdot10^{-6}}\right]\,\frac{2457.6}{5}\\ &\approx \frac23\log_{10}\left[10^{4.9}\right]490\\ &\approx 800 \end{align}

So, you've got an 800 complex taps filter running at 2.4576 MHz on a complex data stream. That's nearly 8 billion floating point multiply-accumulate operations per second. Not a good situation! No wonder your computer is overtasked with that.

If you need only a few kHz of bandwidth on the output, shift (using the "Rotator" block) in frequency first, then resample to a much lower sampling rate.

A few issues with your flow graph:

• It's absolutely not clear what you'd need more than 2 MHz for if you're demodulating something with only 9600 bd – unless your modulation is an extreme spread spectrum modulation (and it's not, it's GMSK, which has a relatively compact spectrum).
• The parametrizations (bandwidth) of your graphical sinks make no sense at all – you might be misunderstanding things! The Nyquist bandwidth of a graphical sink is the sampling rate going into that sink – 25 MHz for the top Qt GUI Frequency sink, 2.4576 MHz for the lower two. So, please, clean that up! It doesn't have any effect on the signal you see, it's only used for labeling the frequency axis.
• There's no daughterboards for the X310 that have adjustable bandwidth – the 120 kHz setting in the USRP Source has no effect at all. If you just want 120 kHz of spectrum, by all means, use a sampling rate close to that. Now, 120 kHz is so extremely low that the USRP X310 can't decimate from its internal ADC rate to that, but if you really just want 120 kHz, well, use a sampling rate of maybe 1 MHz, not 25 MHz. The USRP will internally bandlimit the signal so that it fits into that 1 MHz without aliasing.

So, start with a much, much lower USRP sampling rate. The USRP internally filters in digital domain and decimates, too, so you get the oversampling SNR gain, no matter whether you resample in software or on the USRP. Only that the USRP has an FPGA dedicated to that job, and thus your CPU is free to process the much lower load that a lower rate sample stream means to your application.

• Thank you very much for such a considered reply. As you can see, this is a new experience for me. In fact, the suggested low pass tap function gives me 2961. I have dropped the initial sample rate down to just over 600kHz, but I think the graphical sinks are still very laggy. Could you suggest some reading on how to choose a transition bandwidth? – Walkingbeard Jul 25 '17 at 10:22
• @Walkingbeard Check your system's CPU usage. How much spare raw computational power do you have? How is the distribution of that across CPU cores? I'm not familiar with GNU Radio, but it's perfectly possible that your system is simply underpowered for what you are trying to do. DSP is very computationally intensive. – a CVn Aug 6 '17 at 13:31
• @MichaelKjörling exactly what I'm telling op. It starts with him using 25 MS/s just to get 2.something MS/s just to get a ca 10kHz wide signal. – Marcus Müller Aug 6 '17 at 13:49
• I realize that, and basically I concur. That's why I'm suggesting that OP check just how bogged down the system is. If it's happily churning along at 40% CPU utilization and no core above, say, 90%, but still acting like it's dropping data on the floor, that's a rather different situation than if it's pegged at 100% on every single core and acting like it's dropping data on the floor. – a CVn Aug 6 '17 at 18:58