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

[Elvis Dowson]

Hi Alex,

On Jul 16, 2010, at 2:02 PM, Alexandru Csete 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