New OpenGL-based FFT, Waterfall, and Scope displays in trunk

GNU Radio
1

Josh B. has implemented OpenGL-based versions of the FFT, waterfall,
and scope sinks in gr-wxgui. These have been merged into the trunk as of
revision 9291, and will be part of the 3.2 release.

This feature available to those who have installed GNU Radio via a
source code build from the GNU Radio trunk repository. You will not be
able to use it if you are using the release tarballs, the release
repository, or binary package installations.

You will need to have OpenGL available for your graphics card, and have
installed the python-opengl bindings. This is the default for many
systems, but please see your distribution documentation for details.

Currently, the new displays must be explicitly enabled in your GNU Radio
preferences, though in release 3.2 they will become the default with
fall back to the non-GL versions if GL is not available. Please see:

http://gnuradio.org/trac/browser/gnuradio/trunk/gr-wxgui/README.gl

…for details on how to enable. If you have written your own GNU Radio
applications that use wxgui sinks, you will not have to make any changes
to your source code for these.

The existing Python scripts in gr-utils and gnuradio-examples will
automatically take advantage of the new functionality if enabled.

To obtain this new code, you will need to update your GNU Radio trunk
distribution, and re-run the build:

(From the top-level source code directory)

$ svn update
$ ./bootstrap
$ ./configure (…whatever you might currently use…)
$ make
$ make check
$ sudo make install

We are looking for testers, to measure the difference in performance
between the non-GL and GL versions, and in particular, the performance
of the GL versions when using a non-accelerated host-based GL
implementation like Mesa (without DRI).

In particular, the waterfall implementation is a vast improvement over
the existing one. Try usrp_fft.py -W to view.

Thanks, Josh!

2

Quoting Johnathan C. [email protected]:

We are looking for testers, to measure the difference in performance
between the non-GL and GL versions, and in particular, the performance
of the GL versions when using a non-accelerated host-based GL
implementation like Mesa (without DRI).

In particular, the waterfall implementation is a vast improvement over
the existing one. Try usrp_fft.py -W to view.

Thus far it’s a great improvement in apparent response time and update
speed. It “feels” faster. (Let me know how you want this quantified
and I’ll certainly try to do that.)
One thing I’ve noticed, though it may just be this machine: If I
resize usrp_fft.py too much, the GUI stops responding to user input,
though the data display keeps running. (This is using rev 9293, on
Ubuntu Gutsy.) usrp_oscope.py is apparently immune.

That said, it’s an amazing improvement on the current scope/spectrum
analyzer.

Thanks, Josh!

Indeed, thanks a ton, Josh!

–Mason

3

Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

4

On Sat, Aug 16, 2008 at 4:03 AM, Rakesh P. [email protected]
wrote:

the whole window freezes and I can’t update the parameters anymore.
Terminating the application seems to be the only way.

With a smaller time scale, the waterfall must process FFT frames even
faster. Most likely, the UI cannot respond because too much % CPU is
taken
for other processing. Can you report how much CPU usage when this freeze
happens?

Happened to notice some occasional frequent flickering with the windows in
the background. The screenshot is attached. Also the FFT window (only the
graph portion) becomes overlaid over other windows (right now, I can see it
inside Firefox ;)) if it is not minimized.

What kind of graphics card/driver version?

5

Just tested the opengl implementation… Rocks hard ! Update times are
really up on my C2D 2.4G E4600 / 2GB / Intel 82G33/G31 / Ubuntu Hardy.

Had to do a “make clean” also, since it was reporting some
top_block4dump
error while running any GR code. Probably a lone case. In Ubuntu, you
can
get python-opengl bindings with “sudo apt-get install python-opengl”.

Some bugs (ticket #260):

In Waterfall, I can go down the time scale till milliseconds updating,
when
the whole window freezes and I can’t update the parameters anymore.
Terminating the application seems to be the only way.

Happened to notice some occasional frequent flickering with the windows
in
the background. The screenshot is attached. Also the FFT window (only
the
graph portion) becomes overlaid over other windows (right now, I can see
it
inside Firefox ;)) if it is not minimized.

http://imagebin.ca/view/6zuODeL6.html
http://imagebin.ca/view/HIMraDE.html

Indeed, thanks to Josh and team for the release…

Regards,

rakesh

On Fri, Aug 15, 2008 at 12:51 AM, Johnathan C. <

6

Rakesh P. wrote:

Hi Josh…

The CPU usage goes around 75% for the application when I goto the
millisecond scales. Do take a look at the snapshot…

http://imagebin.ca/view/3ZJeY0.html

I am thinking that this is probably a limitation of the graphics
pipeline. The screen updates are too large and too frequent.

I’m using an Intel G33 chipset with Linux AGPGart driver. Other applications
like the video player VLC in OpenGL mode also seems to have the similar
issue (?). So probably out of our hands :wink:

Probably, but I will take note.

From dmesg output:

[ 35.546210] Linux agpgart interface v0.102
[ 35.584679] agpgart: Detected an Intel G33 Chipset.
[ 35.585409] agpgart: Detected 7164K stolen memory.
[ 35.599048] agpgart: AGP aperture is 256M @ 0xd0000000

Btw, is it possible to give callbacks from the wxgui sink to the
application, like click on waterfall to change center frequency ??

Not at the moment. The way we did this in the old fft sink was
incompatible. This feature will be restored for future releases.

7

Hi,

  1. Great Work.

  2. I think screen refresh (drawing times) is too high (on my system)
    that
    leads to flickering.

  3. Compiling a fresh trunk copy (rev 9311) on my C2D running Ubuntu
    8.04,
    the running of usrp_fft.py for the first time leads to the following
    error :

File “./usrp_fft.py”, line 306, in
main ()
File “./usrp_fft.py”, line 302, in main
app = stdgui2.stdapp(app_top_block, “USRP FFT”, nstatus=1)
File
“/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py”,
line 36, in init
wx.App.init (self, redirect=False)
File
“/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py”,
line 7836, in init
self._BootstrapApp()
File
“/usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode/wx/_core.py”,
line 7433, in _BootstrapApp
return core.PyApp__BootstrapApp(*args, **kwargs)
File
“/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py”,
line 39, in OnInit
frame = stdframe (self.top_block_maker, self.title, self._nstatus)
File
“/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py”,
line 60, in init
self.panel = stdpanel (self, self, top_block_maker)
File
“/usr/local/lib/python2.5/site-packages/gnuradio/wxgui/stdgui2.py”,
line 81, in init
self.top_block = top_block_maker (frame, self, vbox, sys.argv)
File “./usrp_fft.py”, line 122, in init
self.scope = fftsink2.fft_sink_c (panel, fft_size=1024,
sample_rate=input_rate,
AttributeError: ‘module’ object has no attribute ‘fft_sink_c’

as mentioned in “README.gl”, creating the file ~/.gnuradio/config.conf
removed the error and everything was working fine in the second
usrp_fft.py
shot. I think this file should be creating automatically with the option
style=gl (or at least style = auto)

Best Regards,

Firas

–
View this message in context:
http://www.nabble.com/New-OpenGL-based-FFT%2C-Waterfall%2C-and-Scope-displays-in-trunk-tp18988013p19030103.html
Sent from the GnuRadio mailing list archive at Nabble.com.

8

Hi,

Johnathan C. wrote :

What directory were you running ‘usrp_fft.py’ from?

I was running from gr-utils/src/python/

Regards,

Firas

View this message in context:
http://www.nabble.com/New-OpenGL-based-FFT%2C-Waterfall%2C-and-Scope-displays-in-trunk-tp18988013p19035634.html
Sent from the GnuRadio mailing list archive at Nabble.com.

9

I was bit by this as well. In my case I get the AttributeError error if
config.conf is missing or has a typo (“type=nogl”). A present and
correct
config.conf works fine.

10

On Mon, Aug 18, 2008 at 4:57 AM, Firas A. [email protected]
wrote:

  1. I think screen refresh (drawing times) is too high (on my system) that
    leads to flickering.

You can lower the frame rate from the default of 30 by adding the
following line(s) to your config.conf:

[wxgui]
fft_rate=15 (…or whatever frame rate you want)

This will work with either the old or the new sinks.

File “./usrp_fft.py”, line 122, in init
self.scope = fftsink2.fft_sink_c (panel, fft_size=1024,
sample_rate=input_rate,
AttributeError: ‘module’ object has no attribute ‘fft_sink_c’

Please see if you can duplicate this problem. What directory were you
running ‘usrp_fft.py’ from?

as mentioned in “README.gl”, creating the file ~/.gnuradio/config.conf
removed the error and everything was working fine in the second usrp_fft.py
shot.

Actually, if the config.conf is missing, the software just defaults to
the non-gl implementation, so this shouldn’t have made a difference.

I think this file should be creating automatically with the option
style=gl (or at least style = auto)

Since this is still experimental code in the trunk, we default to not
using it until someone explicitly enables it. In release 3.2, it will
become the default unless GL support is missing, then will fall back
to using the non-GL version.

–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/

11

On Mon, Aug 18, 2008 at 1:22 PM, Eric S.
[email protected] wrote:

I was bit by this as well. In my case I get the AttributeError error if
config.conf is missing or has a typo (“type=nogl”). A present and correct
config.conf works fine.

Okay, as of r9315 on the trunk, the type selection has been made more
robust. Right now, anything other than ‘gl’ (including mispellings)
or if the config file is missing forces the use of the old code.

This is a Python only change, so if you were on a very recent trunk
version, all you need to do is:

$ svn update
$ sudo make -C gr-wxgui install

This will just install the gr-wxgui component without having to do a
full build.

–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/

12

The flickering issue is fixed in the trunk r9333.

Certain machines defaulted to “single” buffering. Double buffering is
now explicitly enabled.

cd gnuradio
cd gr-wxgui
svn up
sudo make install

-Josh

13

On Tue, Aug 19, 2008 at 11:41 PM, Josh B. [email protected] wrote:

The flickering issue is fixed in the trunk r9333.

Certain machines defaulted to “single” buffering. Double buffering is now
explicitly enabled.

cd gnuradio
cd gr-wxgui
svn up
sudo make install

While this will mostly work for this particular case, in general is it
not advised to only update a portion of the source code tree, as it
leaves the working copy in an inconsistent state. The user’s working
copy might have been old enough that there were other, required
changes in other parts of the tree that would have been needed.

–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/

14

On Monday 18 August 2008 18:04:23 Johnathan C. wrote:

This will work with either the old or the new sinks.
Unfortunately, this is not the case - waterfallsink_gl.py uses
DEFAULT_FRAME_RATE, which is set waterfall_window.py to the fixed value
of 30.

There is another problem with the frame rate, if it is decreased often
enough,
old_framerate*0.75 will yield 0, and this leads to various problems.

Stefan

Stefan Brüns / Bergstraße 21 / 52062 Aachen
phone: +49 241 53809034 mobile: +49 151 50412019

15

On Fri, Aug 22, 2008 at 07:26:07PM +0200, Stefan Bruens wrote:

This will work with either the old or the new sinks.

Unfortunately, this is not the case - waterfallsink_gl.py uses
DEFAULT_FRAME_RATE, which is set waterfall_window.py to the fixed value of 30.

It works if you make sure there’s no #… following the 15.
I stumbled on to that one myself.

Eric

16

On Fri, Aug 22, 2008 at 11:33:18AM -0700, Josh B. wrote:

I think we need another preference parameter for the “waterfall rate”. It
should not be the same rate as the fft rate.

Howabout “waterfall_rate”?

OK. What are the units, and how would it behave?

Eric

17

I think we need another preference parameter for the “waterfall rate”.
It
should not be the same rate as the fft rate.

Howabout “waterfall_rate”?

18

The waterfall rate is exactly like the fft rate: a decimation is
computed so that the actual rate of fft frames per second (from the log
power fft block) is approximately the given fft rate.

The reason for adding a new preference is that the CPU and graphics
requirements are different for the waterfall plot, so it should have its
own separate configurable rate.

-Josh