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

[Mark McCarron]

Marcus,

Thanks for highlighting the limitations of the current implementation.  It explains a lot.  Personally, I would like to see a little more emphasis on useful GUI elements, not just accurate GUI elements. 

In regards to the WX GUI FFT window not responding.  I have tested it with a very simple flow-graph.  A USRP source and the WX FFT GUI block.  If the settings are at address@hidden, it works fine, try anything higher and the windows greys out.  So, I don't really see where the issue is.

Regards,

Mark McCarron

---

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

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