Re: [Discuss-gnuradio] Unresponsive GUI behavior and system instability with USRP2 + WBX module

[Alexandru Csete]

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.

On 16 July 2010 09:53, Elvis Dowson <address@hidden> wrote:

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 Dowson


_______________________________________________
Discuss-gnuradio mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio