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: Marcus D. Leech
Subject: Re: [Discuss-gnuradio] WX GUI FFT Sink Performance
Date: Thu, 16 May 2013 11:59:33 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Fedora/3.1.16-1.fc14 Thunderbird/3.1.16

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?
I think they're implementing an overlapped-FFT option for the QtGUI sinks for "next".  Not sure.  The thing about overlapped display FFTs is that you're
  trading (sometimes significant) temporal accuracy of the estimate for display-update-rate.

Further, given that your display is only probably 1280 pixels wide, I fail to see how you expect to extract any more "useful" information from a
  65536-bin FFT that must necessarily *lose* information when it's mapped to a narrow display.  The wxGUI tools don't support scrolled FFT windows,
  so they necessarily drop bins to satisfy the display requirement.  There are three common "strategies" for mapping a many-binned FFT into a
  smaller display window:

        o drop bins
        o select peak
        o average bins

All of those options lose information in the display.

Internally, of course, for signal processing and data recording purposes, you can have FFTs that are very wide.

The other thing to consider is that ALL the GUI widgets that are "wired in" to Gnu Radio were designed *primarily* for debugging/instrumentation
  purposes--akin to sticking a voltmeter or oscilloscope on your circuit board.  The problem is that they're *just barely*   "good enough" to construct
  applications with, and so there's a natural expectation that they implement all the GUI thingies you might even want to attach to a signal-processing
  stream.

There is *zero* requirement that you use the built-in GUI widgets.   Lots of applications have been built that use the Gnu Radio signal-processing path,
  and completely-different approaches to providing a GUI--GQRX is one such example, and my own IRA software uses an XFORMS based GUI, with
  a Gnu Radio signal flow underneath.

The QtGUI widgets in "next" are, I understand, substantially enhanced over the current set in "master", so perhaps we can see some more
  elegant applications written with the Gnu Radio built-in GUI bits.

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.
That's generally because your flow-graph has some structural problem that is causing the GUI thread to fail to get any cycles.


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

reply via email to

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