[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Unresponsive GUI behavior and system instability
Re: [Discuss-gnuradio] Unresponsive GUI behavior and system instability with USRP2 + WBX module
Fri, 16 Jul 2010 14:21:09 +0400
On Jul 16, 2010, at 2:02 PM, Alexandru Csete wrote:
> I do not have experience with USRP2 but maybe my experience with USRP1
> 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
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.