Re: [Discuss-gnuradio] various USRP GUIs freezing

[Erik Tollerud]

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.

On 4/2/06, Eric Blossom <address@hidden> wrote:
> On Sat, Apr 01, 2006 at 08:47:07PM +0200, Martin Dvh wrote:
> > 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)
>
> 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
>