discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] WX GUI FFT Sink Performance


From: Mark McCarron
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
Date: Thu, 16 May 2013 16:47:58 +0100

Marcus,

Thanks, that would explain the slow updates that I was seeing.  Perhaps an overlapped FFT would be useful for interactive scenarios.  Has one been implemented?

This, however, does not explain why my windows are not responding.  After about 8 seconds, the window turns to grey and the GUI of the FFT becomes frozen.

Regards,

Mark McCarron


Date: Thu, 16 May 2013 09:49:59 -0400
From: address@hidden
To: address@hidden
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance

Marcus,

Sorry for the late reply on this, I've been upgrading my hardware and I'm just catching up.  Here is my issue, in Spectrum lab if I provide a FFT Input length of 65536 on a 192Ksps stream, I get the following characteristics:

Effect of FFT settings with fs= 192.000 kHz:
Width of one FFT-bin: 2.92969 Hz
Equiv. noise bandwidth: 4.39453 Hz
Max freq range: 0.00000 Hz .. 96.0000 kHz
FFT window time: 0.341 s
Overlap from scroll interval: 98.4 %

It runs quite fast.  If I provide the same FFT size to WX GUI FFT sink, it basically hangs.  Do you know why?

Regards,

Mark McCarron
Because apparently SpectrumLab is using an overlapped FFT implementation.  The one in wXGUI doesn't.  Further, the wxGUI implmentation has far
  too much Python involved in processing samples, so trying to process 65536 samples at a time is likely sluggish, to the point that it can't keep
  up in real time.

The underlying FFT implementation itself is very fast--Gnu Radio uses FFTW.

I've regularly built FFT filters with 250e3 taps, and they are able to run in real time with sample rates into the many Msps.

So, if you do the math, a non-overlapped FFT implementation of 65536 bins at 192Ksps means 2.92 FFTs/second.  If the display update rate is
  more than that, there's no way to actually produce an update rate faster than 2 per second under those circumstances, with a non-overlapped
  FFT.


-- 
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

_______________________________________________ Discuss-gnuradio mailing list address@hidden https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

reply via email to

[Prev in Thread] Current Thread [Next in Thread]