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 _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
