On 05/15/2011 07:11 PM, Elvis D. wrote:
Reducing the refresh rate to 5fps makes it a bit more responsive. A value of 10
makes it un-responsive. My sample rate is 3.125M sps using a USRP2, using the UHD
usrp2_fft.py was written for “classic” – did you modify it for UHD?
Also, you reported a decimation
of 16, which gives 6.25Msps with USRP2.
Also, turn on averaging–that seems to help the performance, whose main
issue seems to be inside
the rendering code in OpenGL and the Python “goo” that drives the FFT
display in Gnu Radio.
One of the advantages of the QT graphical sinks is that most of the
computational dancing around
that is required to “set up” the FFT display is done in C++ code,
rather than Python. But I find
the Qt sinks to be very “pre-production”. I don’t like the user
interface very much, and they’re
currently too monolithic and inflexible.
What type of system are you running on? What CPU, what speed? Multi-core or
I just resurrected my old ThinkPad T42p, which is a 1.8GHz Pentium-M centrino
processor, 2GB RAM, ATI FireGL T2 128MB graphics, gigabit ethernet and a 160GB
hard drive, running Ubuntu 11.04 32-bit.
That’s not exactly a really speedy CPU. Might be adequate for
experimenting at low bandwidths
(1Msps or maybe 2Msps), but it’s rather long in the tooth.
I have a T60 that I use sometimes, but only at 1 or 2Msps.
Running gnuradio virtualized on my iMac quad-core had issues with audio with
older releases of gnuradio. I’ll need to check with the recent release though, if
the audio issue still persists using vmware.
I have to say, this old T42p running Ubuntu or Windows XP, is as responsive as
any of today’s multi-core i5 or i7 processors for simple daily tasks (web,
downloads, etc) and bootup and shutdown times. The only areas it doesn’t cut is
for computationally intensive tasks. e.g. handling large datasets, generating a
8192 bit ssh rsa key (took more than 10 mins compared to a few seconds on an i7),
program compilation times, etc.
Well, signal processing is definitely in the “computationally intensive”
Shirleys Bay Radio Astronomy Consortium