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 4096@15fps, 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: mle...@ripnet.com
To: mark.mccar...@live.co.uk; Discuss-gnuradio@gnu.org
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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
