0
$\begingroup$

I'd like to implement a FHSS receiver in GNU Radio, using a USRP B210. The total bandwidth of the signal is about 30 MHz, with each message having a bandwidth of about 200kHz. When I attempt to sample the signal to account for the full 30MHz bandwidth, I receive Overflow notifications. I've considered sampling the signal at a significantly lower rate and induce aliasing so as to receive the messages within the lower bandwidth, but so far I've been unsuccessful in bypassing the anti-aliasing filter. My understanding is that, while the analog antialising filter on the USRP can be set to larger than the bandwidth required for my sampling rate, the digital filter is determined by the sampling rate and cannot be changed.

My questions are:

  1. Can the digital anti-aliasing filter be bypassed or changed in any way?
  2. Can the USRP source be programmed to give me samples at a decimated rate, so that I can sample at the higher rate and the load on my system will result from the lower sample rate?

Thank you

Improve this question
$\endgroup$

1 Answer 1

Reset to default
0
$\begingroup$

My understanding is that, while the analog antialising filter on the USRP can be set to larger than the bandwidth required for my sampling rate, the digital filter is determined by the sampling rate and cannot be changed.

no. None of the USRPs allow that: all USRPs / RF daughterboards (that you can still use) don't have adjustable frontend filters, as the ADC runs at the relatively high "master clock rate", and the "user" sampling rate is a fraction of that.

The ones who do have very flexible MCR (B2xx, for example) have their frontend filters built into the frontend chip, and offer no viable way of making that break Nyquist.

Anyway, not the real problem, because your > 30 MHz bandwidth exists within the digital part of your USRP. All you need to do is convince the digital part, not the analog part!

the digital filter is determined by the sampling rate and cannot be changed.

In stock USRP FPGA images that's the case, but as these are open source, so you can modify them to your delight.

For example, in RFNoC-supporting (X??0 devices, N3xx,…), devices you could just write a very simple subsampling NoC-block and use that.

But honestly, fix your GNU Radio receiver! 30 MHz bandwidth is not that much, and your average PC should be able to withstand that coming in via USB3 or 10 Gigabit Ethernet. Especially when all it does is drop N-1 in N samples, for N = 3·10⁷/2·10⁵=150 samples:

Flowgraph

runs perfectly well with a B200mini, and uses 43% of a single one of my CPU cores (I can literally run it pinned to a single CPU core on my fourth-generation core i7). Matter of fact, if I benchmark Null Source->Keep 1 in N->Probe Rate, I get 3.8 MS/s at the output - 570 MS/s consumption of data coming from the Null source. Which honestly could be better, but it's done with only nearly 2 CPU cores, so, either your PC is very slow, or something is wrong with your connection to your USRP, or the signal processing chain afterwards is overly CPU-hungry.

Improve this answer
$\endgroup$
4
  • $\begingroup$ Thanks for the answer! I'm running GNU Radio through a VM, and from what I've read that may be the reason for the Overflow issues. In any case, I'll look into everything you suggested. $\endgroup$
    – George Willis
    Dec 21, 2021 at 14:28
  • $\begingroup$ well, what kind of USRP are you using, and how are you "connecting" it to the VM? People with paravirtualized 10 Gig network cards report basically no performance loss; if on the other hand, you hand-caress network packets through a NAT daemon in the virtualizer, then that's bad. Generally, I found GNU Radio to be rather portable today, so not sure for an early development effort you need to use VMs (I agree, these are awesome once you start deploying your signal processing to server racks). $\endgroup$
    – Marcus Müller
    Dec 21, 2021 at 14:42
  • $\begingroup$ I'm using a USRP B210, connected by USB 3. $\endgroup$
    – George Willis
    Dec 21, 2021 at 14:49
  • $\begingroup$ hm, some virtualizers aren't great at passing through USB3. That's possibly where the problem lies – try to test whether if you install UHD on the host, not inside the VM, it works well enough. More discussion about making UHD work is probably best off at the usrp-users mailing list, though. $\endgroup$
    – Marcus Müller
    Dec 21, 2021 at 18:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.