Usrp2_fft.grc hangs when executed

GNU Radio
1

Hi,
When I run usrp2_fft.grc, it just hangs on execution, nothing
gets displayed and the FFT plot doesn’t get updated.

I’ve set the frequency to 104.1M, decimation value to 16.

The FFT Plot gui is completely un-responsive. I’m using Ubuntu-11.04
with gnuradio-3.4.0.

Elvis D.

2

Try doing two things:

Turn on averaging
Turn down the FFT frame display rate from the default 30, to something
like 5

What type of system are you running on? What CPU, what speed?
Multi-core or single-core?

–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

3

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
drivers.

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
single-core?

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”
zone :slight_smile:

–
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

4

On May 16, 2011, at 3:20 AM, Marcus D. Leech wrote:

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
drivers.

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.

Yes, I modified it for UHD. A sample rate of 3.125Msps and a refresh
rate of 5 fps worked just barely. If I reduced the sample rate to 800k
it worked fine at 15fps. Anyway, my T42p laptop is pretty under powered
for this type of stuff. :slight_smile:

Elvis D.

5

Hi,
FWIW, I re-ran the same test using the USRP2 and the UHD drivers,
on a vmware virtual machine running on my iMac quad-core, running
Ubuntu-10.04 64-bit with gnuradio-3.4.0.

I was able to get 20Msps (decimation factor of 5) with the USRP2, and
the FFT plot GUI was responsive at a refresh rate of 30fps.

If I tried to run it at 25Msps (decimation factor of 4), I got an
over-run, with a bunch of Os displayed on the GRC output console.

The only thing still wrong with using a virtual machine is the audio
sink.

I get still audio under-runs aUaU, and choppy FM reception when it runs
on a virtual machine with gnuradio-3.4.0.

On a dedicated low-powered system like my T42p laptop, the audio sink
works fine.

Elvis D.

6

Hi Marcus,

On May 16, 2011, at 2:44 AM, Marcus D. Leech wrote:

Try doing two things:

Turn on averaging
Turn down the FFT frame display rate from the default 30, to something like 5

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 drivers.

What type of system are you running on? What CPU, what speed? Multi-core or
single-core?

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.

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.

Elvis D.