Unresponsive GUI behavior and system instability with USRP2 + WBX module

GNU Radio
1

Hi,
I noticed that the GNU radio’s GUI for a simple FM receiver can
become un-responsive. For example, when trying to run the WFM receiver
example, the Frequency Slider moves, but the frequency of the station
doesn’t change. There is a Failed message at the bottom left corner of
the GUI.

At times, when it launches, it works fine and doesn’t show the audio
buffer under-run messages, but if I stop and relaunch the same
application, I suddenly get a whole bunch of audio buffer under-runs.

Is GNU Radio stable enough? Or are these type of issues common in the
current release, and needs to be fixed?

For example, I notice that if some internal blocks or computations don’t
correctly align, like if I have a audio input rate of 32051, the system
doesn’t launch, but if I set the audio input rate to 32050, the WFM
receiver launches (refer to my earlier thread, where I still haven’t got
the rational resampler way of getting the FM receiver to work). See the
following thread for the example patch to reproduce this behavior
http://old.nabble.com/USRP2-%2B-WBX%3A-Unable-to-receive-FM-signals-td29176138.html

I’m assuming that the FM receiver example is simple enough. But if the
system gets bogged down like this with a simple application, what about
more complex applications like a WiFi transceiver, or HDTV
transmitter/receiver applications?

Is this a general behavior that everyone else sees, i.e. GNU Radio being
unstable and un-responsive at times?

I have 8 virtual CPU cores allocated to my Linux VMware image, and a
dedicated ethernet port connected to the USRP2. CPU utilization is still
restricted to 2 CPUs and the load is between 20 to 30 percent for when
running the FM receiver application. The host computer is a iMac
quad-core i7 processor at 2.8 GHz. I’ve allocated 2.5GB RAM to the linux
virtual machine.

I would like to know if the system instability and un-responsiveness is
something specific to my system configuration or if it is related to GNU
Radio or the USRP2 or the particular firmware that I’m using (txrx_wbx).

Elvis D.

2

Hi Elvis,

I do not have experience with USRP2 but maybe my experience with USRP1
applies.
When I got the WBX back in January, I noticed that it was tuning a bit
slow
compared to the other boards that I have. I think the technical term is
“PLL
lock time”. The TVRX can tune very fast, but the WBX is too slow to be
connected directly to a GUI slider. GUI events are asynchronous, i.e.
when
the value of the slider changes an event is sent through the system. If
the
pll lock time in the hardware is longer than the rate at which these
events
are arrive you will experience unresponsive behaviour.

You can check if this is what’s causing your problems using the
usrp2_fft.py
application where the frequency is entered manually in a text field
rather
than using a slider.

Other than that I can only say that SDR applications that prefer real
time
scheduling running in a multi tasking OS, running in a virtual machine
running in another multi tasking OS does not sound like a feasible
setup. I
don’t know how virtual machines work, but when I tried VirtualBox and
Parallels desktop on my iMac (the previous generation) I found that I
could
get better GNU Radio performance running linux on a 5 yr old computer
with a
1.2 GHz dual-core CPU.

Alex

PS: Obviuosly, your 8 CPU allocation is ignored by the VM since you only
have 4 physical cores (with 2 threads per core) and you also need to
leave
something to the host OS.

3

Hi Alex,

On Jul 16, 2010, at 2:02 PM, Alexandru C. wrote:

I do not have experience with USRP2 but maybe my experience with USRP1 applies.
When I got the WBX back in January, I noticed that it was tuning a bit slow compared to the other boards that I have. I think the technical term is “PLL lock time”. The TVRX can tune very fast, but the WBX is too slow to be connected directly to a GUI slider. GUI events are asynchronous, i.e. when the value of the slider changes an event is sent through the system. If the pll lock time in the hardware is longer than the rate at which these events are arrive you will experience unresponsive behaviour.

This is exactly the type of behavior that I am experiencing.

I think the rational resamper also works, but due to this (PLL?) sync
glitch, the reception is corrupted with audio under-runs.

Only once did I get the FM reception crystal clear, with the modified
rational resampler block inserted, and it sounded very good. After I
restarted the application, it went back to its corrupted state. I
haven’t been able to get it to work since then, tried around 10 times
successively, with no results.

Also, the WBX board gets really hot after a few minutes of operation.

You can check if this is what’s causing your problems using the usrp2_fft.py application where the frequency is entered manually in a text field rather than using a slider.

Other than that I can only say that SDR applications that prefer real time scheduling running in a multi tasking OS, running in a virtual machine running in another multi tasking OS does not sound like a feasible setup. I don’t know how virtual machines work, but when I tried VirtualBox and Parallels desktop on my iMac (the previous generation) I found that I could get better GNU Radio performance running linux on a 5 yr old computer with a 1.2 GHz dual-core CPU.

I’m trying to get the Mac OS X native build running, right now, so that
I can check it’s native performance. I just discovered that there is a
GNU Radio next branch, with support for the UHD driver, so I’m going to
try and compile that.

I think I have to download and compile the UHD driver sources from
Ettus, which I’ve already done, and then build the GNU Radio next
branch, which has support for gr-uhd.

This way I can check native performance.

PS: Obviuosly, your 8 CPU allocation is ignored by the VM since you only have 4 physical cores (with 2 threads per core) and you also need to leave something to the host OS.

VMware Fusion 3.1.0 has support for 8 CPU allocation. The i7 Quad-core
has a total of 8 execution cores, and all 8 are being displayed for
Fedora 12. It is the same as when windows reports 8 CPUs on a Quad Core
machine.

Best regards,

Elvis