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 <[EMAIL PROTECTED]> 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 > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
