0

I have some problem to get two Rx channels running on the ettus USRP B210 in gnuradio. With only one input channel it works fine and i see my signal, but when i add a second channel I only see noise. My receiving signal is at 404MHz with a bandwidth of 2kHz.

The only things I changed from the single antenna to the double antenna version is:

  • Mb0: Subdev Spec A:A A:B
  • Num Channels 2

Gnuradio-companion flow graph 2 Rx

Gnuradio-companion flow graph 1 Rx

ludw
  • 113
  • 8
  • I think we might have a bug in QT Gui's frequency sink that makes FFT sizes > 8192 impossible. Also, how are you going to display a curve that's 32,000 pixels wide? – Marcus Müller Mar 20 '20 at 10:47
  • I changed the FFT size to 4096 and the problem still exists and the problem still exists when I change from the QT frequency sink to the WX GUI FFT sink. So I think it's more a problem in the UHD block. And I have no problem to display the entire FFT with 32768 bins on the screen, it shows the desired bandwidth. – ludw Mar 20 '20 at 11:02
  • ludw, it really doesn't. See my answer. – Marcus Müller Mar 20 '20 at 11:06

1 Answers1

0

You're misinterpreting what the "Bandwidth" setting of the QT Gui frequency sink does:

It's just determining the labeling on the x-axis. As per Nyquist, the displayed bandwidth is always -f_sample/2 to +f_sample/2.

You should add a 1/200-band low-pass FIR filter that also decimates by a factor of 100. That reduces your input sampling rate from 2.4 MHz (why did you pick that one, by the way?) to 24 kHz. Then, you can connect a frequency sink (bandwidth = USRP sampling rate / decimation = 2.4 MHz / 100 = 24 kHz) to that.

Marcus Müller
  • 34,677
  • 4
  • 53
  • 94
  • Thank you for your help. I now understand better what the QT GUI frequency sink does. It was not the QT Block that caused the problem. I had a problem with the LO of the SDR when I tuned that frequency on both channels. It worked fine on only one but caused problem with two Rx channels. I still don't understand exactly why that causes some problem but I know now where to look deeper. I will answer my question when i know exactly what caused the problem. The 2.4Mhz are chosen because in the "real" code I decimate it with 50 and get so the audio band of 48kHz. – ludw Mar 20 '20 at 11:38
  • Ah, perfect :-) – Marcus Müller Mar 20 '20 at 11:51