Forum: GNU Radio various USRP GUIs freezing

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ce0bf656556f498c6c6519702d65c774?d=identicon&s=25 Erik Tollerud (Guest)
on 2006-03-31 01:24
(Received via mailing list)
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.
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2006-03-31 05:18
(Received via mailing list)
On Thu, Mar 30, 2006 at 03:22:08PM -0800, Erik Tollerud 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?
* What OS / version / disribution are you using?
* What version of wxPython?
* What kind of  processor do you have?
* How much RAM?

Anything else you can tell us that might help...

Eric
Ce0bf656556f498c6c6519702d65c774?d=identicon&s=25 Erik Tollerud (Guest)
on 2006-03-31 20:59
(Received via mailing list)
I suppose that would be helpful...

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...
3596cfe1d579c65b9babd35e8787977c?d=identicon&s=25 Matt Ettus (Guest)
on 2006-03-31 21:08
(Received via mailing list)
Erik Tollerud wrote:
> processor data under linux...
Start one of those CPU usage monitors, and look at what it reads when
the app is running.

Matt
0dfa1a815559738fc7e0f17b0cbf9e54?d=identicon&s=25 Thomas Schmid (Guest)
on 2006-03-31 21:14
(Received via mailing list)
cat /proc/cpuinfo

usually gives you all you want to know about your processor.

Thomas
Ce0bf656556f498c6c6519702d65c774?d=identicon&s=25 Erik Tollerud (Guest)
on 2006-04-01 00:02
(Received via mailing list)
So it does: P4 1.8 GHz
0dfa1a815559738fc7e0f17b0cbf9e54?d=identicon&s=25 Thomas Schmid (Guest)
on 2006-04-01 00:08
(Received via mailing list)
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?

You can use top and free to get this information.

Thomas
3719f4fea703e38bcbf8de6fe6bcdf55?d=identicon&s=25 Martin Dvh (Guest)
on 2006-04-01 20:21
(Received via mailing list)
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?

Greetings,
Martin
----- Original Message -----
From: "Thomas Schmid" <thomas.schmid@gmail.com>
To: "Erik Tollerud" <etollerud@ups.edu>
Cc: "Matt Ettus" <matt@ettus.com>; <discuss-gnuradio@gnu.org>
Sent: Saturday, April 01, 2006 12:05 AM
Subject: Re: [Discuss-gnuradio] various USRP GUIs freezing


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?

You can use top and free to get this information.

Thomas

On 3/31/06, Erik Tollerud <etollerud@ups.edu> wrote:
> > > Erik Tollerud wrote:
> > > > I suppose that would be helpful...
> > > >
> > > > 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
> > > Discuss-gnuradio mailing list
> > > Discuss-gnuradio@gnu.org
> > > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > >
> >
>


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2006-04-02 17:29
(Received via mailing list)
On Sat, Apr 01, 2006 at 08:47:07PM +0200, Martin Dvh 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)

Hi folks,

I've added a couple of new system defaults:

  [wxgui]

  fft_rate = 15     # fftsink & waterfallsink
  frame_decim = 1   # scopesink

You can override the system defaults in
~/.gnuradio/config.conf

Update gr-wxgui to pick up this change.

Eric
Ce0bf656556f498c6c6519702d65c774?d=identicon&s=25 Erik Tollerud (Guest)
on 2006-04-03 02:20
(Received via mailing list)
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.
This topic is locked and can not be replied to.