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.
