I’m new to gnuradio, but I’ve sucessfully compiled and installed the
gnuradio software and hooked it up to my USRP. My problem (at least,
the first one…) is in running some of the GUI USRP examples.
usrp_wfm_rcv(_anything else).py, usrp_oscope.py, usrp_fft.py all show
this strange bug; When I start them up, they seem to run fine for a
few seconds (or a few minutes for the oscope), and then the interface
freezes up (i.e. I can’t input anything like the center frequency -
clicking just doesn’t do anything), but the graphs continue updating
very slowly, and one at a time. For example. in usrp_wfm_rcv.py, the
“Data from USRP” graph responds for a while while the other two look
frozen, then the “Post Filter” graph does the same while the other two
are frozen, then “Post Deemph”… then the cycle restarts. Any idea
what’s going on?
And the usrp_wfm_rcv does output sound, but I’m not hearing any radio
stations even if I have an antenna connected… I’m not sure if I
should be at this point, but at any rate all I hear is static.
On Thu, Mar 30, 2006 at 03:22:08PM -0800, Erik T. wrote:
frozen, then the “Post Filter” graph does the same while the other two
are frozen, then “Post Deemph”… then the cycle restarts. Any idea
what’s going on?
And the usrp_wfm_rcv does output sound, but I’m not hearing any radio
stations even if I have an antenna connected… I’m not sure if I
should be at this point, but at any rate all I hear is static.
Hi Erik,
Which version of the GNU Radio code? tarball or cvs/svn?
I’m using the CVS gnuradio (as of about a week ago)
running under FC5
wxPython version is 2.6 - I wasn’t sure if I should pick the unicode
or ANSI version, but I think I installed the ANSI (if it matters)
and 256 megs of ram.
As for the processor, I’m not absolutely sure - it’s a Dell GX220, so
It’s some form of pentium III or 4, but I’m not sure how to look up
processor data under linux…
How high is the process load when you are running the code? I
sometimes experience the same behavior, but it usually goes away after
a couple of seconds. It might be an issue with ram if you have a lot
of programs concurrently open. 256MB isn’t much. Can you see how much
memory is in usage?
On Sat, Apr 01, 2006 at 08:47:07PM +0200, Martin D. wrote:
stead of 15.
For me this solves most gui_freeze problems.
If you still have the problem then go even lower as 5 or disable the fft’s.
(change the if 1: to if 0: in front of the code which opens the fft display)
I tried switching the fft_rate in the code (before the update), and it
didn’t help - the ffts look to be going a bit slower, but the GUI is
still locking up. I’ll try in a day or two with the update…
And it uses all the CPU power and memory when I run it - there’s
something like 4MB free, vs 40MB or so when its not running (although
that’s a bit strange, as all I have running is Firefox, and the fft
program…). With just usrp_fft, by contrast, there’s a good 16MB
free and I’m only running at about 70-90% CPU utilization.
I am having this problem all the time.
The defaults for the fft display are to try to display 15 fft’s a second
which is too much for anything but the fastest processors.
In the usrp_wfm_rcv example several fft’s are displaying at the same
time
which worsens the problems.
I allways add the following parameter to all ftt’s.
fft_rate=5
What this does is to tell the fft gui to try to display 5 fft’s a second
in
stead of 15.
For me this solves most gui_freeze problems.
If you still have the problem then go even lower as 5 or disable the
fft’s.
(change the if 1: to if 0: in front of the code which opens the fft
display)
Maybe it is a good idea to add fft_rate as a commandline parameter to
all
examples.
And maybe lower the defaults in the fft gui.
Another problem which I have witth the examples that it always barks at
the
import powermate line (I don’t have a powermate)
If I coment the line out the code runs fine.
Anybody got a solution for this?
How high is the process load when you are running the code? I
sometimes experience the same behavior, but it usually goes away after
a couple of seconds. It might be an issue with ram if you have a lot
of programs concurrently open. 256MB isn’t much. Can you see how much
memory is in usage?
I’m using the CVS gnuradio (as of about a week ago)
running under FC5
wxPython version is 2.6 - I wasn’t sure if I should pick the unicode
or ANSI version, but I think I installed the ANSI (if it matters)
and 256 megs of ram.