0
$\begingroup$

I am evaluating gnuradio with Ettus USRP X310 and 2xUBX-160 daugterboards, connected via GBit ethernet to a new Lenovo laptop running Win10 and gnuradio 3.7.13.5.

I am testing it with the most basic setup: connecting "RX/TX" back-to-back to "RX2" via straight SMA cable (Remark: I know this is risky and I am careful not to exceed the allowed input power). This simple gnuradio diagram sends out a 10kHz tone at baseband; sample rate is set to 1MS/s and RF carrier 1GHz:

GNU Radio Setup

This somewhat works but whenever I change something in the TX path (e.g. the baseband frequency or BB attenuation) it takes way too long for the plots to update: I measured more than 8s(!) from the time I press enter to the moment the plots update. This does not seem to be the case for the RX side (e.g., when I change the RX gain, the plots update relatively quickly).

I also just tested it with QT and WX: It only occurs with QT; with WX the plots update relatively quickly.

Since WX is "deprecated" I would prefer to use QT.

What could be the cause of this? Is there any basic example (that does TX and RX at the same time) I could start with to have a "correct" baseline?

$\endgroup$
  • $\begingroup$ I'm not familiar with gnuradio, but familiar with Qt programming, and GUI lag is a common problem on some systems and OSs if multithreading or repaint events are not implemented properly. Maybe it's best to ask the developers, or browse through their git issues? $\endgroup$ – juod Oct 22 at 4:47
  • 1
    $\begingroup$ @juod GNU Radio head maintainer here. We have had severe performance issues with the drawing backend in WX in the past, and that's why we've deprecated it a long time ago (we can't maintain it and it has severe problems). We don't even remotely see performance issues at the rates OP is using here. The graphical sinks are asynchronously coupled to the sample flow through the usual Qt signal/slot mechanism and the drawing is done by the GUI / QtApp main thread. My prime suspect is the overly long DC blocker, and possibly gr-wxgui's lack made it "look" smooth where it really was stuttering. $\endgroup$ – Marcus Müller Nov 17 at 12:02
  • $\begingroup$ or maybe the qt gui sink was overloaded by the displaying of computational overload/overflow markers caused by the (overly long) DC blocker, and OP didn't notice the warnings/errors on the console coming from the UHD source block that told them that nope, your PC isn't fast enough at getting the samples from the hardware. These aren't displayed in the WX GUI toolkit by default, and that might be the cause for the perceived difference in performance. $\endgroup$ – Marcus Müller Nov 17 at 12:03
  • 1
    $\begingroup$ Anyway, general programming, not a signal processing question. $\endgroup$ – Marcus Müller Nov 17 at 12:04
  • $\begingroup$ I have to add that I saw this issue manwhile with WX too (despite not as frequent). I do not use the DC blocker any more. Interstingly the UHD input and display seems to work perfectly; only if values are changed on the TX side a lag of up to 10s may appear. Where would be the best place to discuss this question? (also, meanwhile using PCIe, so no speed issues) $\endgroup$ – divB Nov 18 at 3:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.