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: mle...@ripnet.com
To: discuss-gnuradio@gnu.org
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
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio                         
                  
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to