Project Overview

GNU Radio is a free software development toolkit that provides the signal processing runtime and processing blocks to implement software radios using readily-available, low-cost external RF hardware and commodity processors. It is widely used in hobbyist, academic and commercial environments to support wireless communications research as well as to implement real-world radio systems.


GRCon12 Hackfest

The 2012 GNU Radio conference is over, but we're still getting all of the material together to publish. I should be putting up more of the presentations tonight and more as they come in (see the Abstracts page to download them).

What I really wanted to mention here was the GRCon12 Hackfest page. I'm trying to collect info here on what happened at the Hackfest and where people can go for more information (such as other web pages) and the code developed. So check it out, and hopefully it will be beneficial.


Student Travel Award for GRCon 2012

The GNU Radio Conference this year has been awarded a grant from the National Science Foundation (NSF) to support student travel to attend. This is big news for us and a real treat.

We have an application form for any students wishing to use this opportunity to attend the conference. All of the information can be found here:



GRCon2012 Call for Presentations

We have opened up our call for presentations for the 2012 GNU Radio Conference.

We are inviting anyone interested in presenting their work at the conference to provide us with an abstract (500 words or less) about it.

Important dates are:

  • June 29: Last day to submit an abstract
  • July 13:  Acceptance notifications for presentations



What's Happening in GNU Radio

There are lots of changes on the way in GNU Radio. But since I don't think that I can say it better, here is Johnathan Corgan's email to the GNU Radio mailing list from yesterday describing it:

Some of you may have noticed recent check-ins that have added new
top-level components (like gr-fft), or duplication of blocks (such as
into gr-digital.)  I'd like to explain the master plan Tom and I are
working from and what to expect over the next few weeks.

Essentially, we are making two things happen at the same time:

- libgnuradio-core is going away, and its blocks are being reorganized
into several new, smaller libraries

- The C++ API is changing to use pure virtual interface classes, C++
namespaces, and segregated header files

These two transitions will occur in such a way that as much work as
possible will be completed on the master branch but without requiring
any changes to your existing code, and the rest will happen on the
next branch.

The gnuradio-core component has accumulated hundreds of blocks over
the last 10 years.  In order to simplify and organize things, we are
creating several new top-level components to replace it.  The first
step of this was done when gr-digital collected much of the digital
modulation/demodulation code up into its own component.  The second
step was to create gr-wavelet and move the wavelet blocks into that.
When we are done, the following top-level components will hold all the
code that used to be in gnuradio-core:

* gr-blocks - "basic" blocks used widely across many flowgraphs, like
math operations, type conversions, stream/vector manipulation,
file/message/network sources/sinks, etc.

* gr-analog - analog waveform processing blocks such as signal
sources, AM/FM modulation/demodulation, AGC, squelch, power
measurement, etc.

* gr-digital - digital waveform processing blocks such as PSK and OFDM
modulation, scramblers, timing and carrier recovery, channel
equalization, bit packing/unpacking, framers, deframers, CRC, etc.

* gr-fec - Reed-Solomon and convolutional coding, future development

* gr-fft - blocks that wrap the external FFTW library

* gr-filter - FIR and IIR filters, filter design, resampling,
channelizers, channel models

* gr-vocoder - voice processing codecs

* gr-wavelet - wavelet processing blocks, future development

* gnuradio-runtime - top block and friends and runtime scheduler, very
small number of blocks for QA testing of runtime (vector source/sink,
null source/sink, etc.)

The process we are following to get this done is to create the new top
level components on the master branch and copy the existing blocks
into them, then remove the old blocks from gnuradio-core *on the next
branch only*.  In this way, developers can, if they wish, start
migrating their applications to use the new block hierarchy in their
applications as they become available, without having to do it all at
once.  Existing code, however, can also be left alone without any
impact as gnuradio-core itself will remain unchanged until the 3.7

Part of this process is already done--gr-vocoder, gr-digital, and
gr-wavelet are part of the current release.  The new gr-fft was merged
into master recently.  Soon, gr-filter will be added in, and then we
will remove all fft and filter blocks out of gnuradio-core on the 3.7
branch only.  Today, several more blocks from gnuradio-core were
copied into gr-digital, and again, we'll soon delete those blocks out
of gnuradio-core on the 3.7 branch only.

Since we're touching so much code, we're taking the opportunity make a
change to the C++ API to implement pure virtual interface classes for
API visible code.  This was discussed on the mailing list March 12.
In addition, we're reorganizing the API to use C++ namespaces, which
shortens filenames, simplifies the Python wrapper generation, and
eliminates some redundancies in class naming.  You can see an example
of this in the new gr-fft directory on the master branch, or in the
gr-wavelet directory on the next branch.

The same process for dividing the work between the master branch and
next branch applies here.  Where possible, when we copy over blocks
from gnuradio-core to the new top-level components, we'll convert them
to use the new C++ coding style.  This won't affect any existing
user's code, as the old blocks will stay in gnuradio-core.  For all
the rest of GNU Radio outside of gnuradio-core, we'll be making the
C++ changes on the next branch, again so as to not disturb existing
user's code.

Finally, during all this, as we implement the new block structure,
we're going to pay special attention to:

- Reimplementing functionality using libvolk vector optimization where possible
- Updating or adding missing header file documentation
- Converting code where needed to conform to the GNU Radio coding style guide
- Adding QA test code if missing
- Creating GRC block wrappers if missing
- Removing obsolete code or other cruft

Few of these changes will impact Python or GRC users, except that most
blocks that once lived in the 'gr' namespace imported from gnuradio
will instead import from a different namespace under gnuradio, such as
is already done for gr-audio, gr-digital, gr-uhd, etc.

The net of all this is that we expect the 3.7 C++ API to be better
organized, easier to use, and have better documentation, but without
changing much of the functionality other than performance

Tom and I will be working up documentation on the wiki detailing the
changes as we go along, and there will be a 3.6->3.7 conversion guide
for C++, Python, and GRC GNU Radio applications.

So, as they say, "pardon our dust".



In Case You Missed It... v3.6.0 Release

I've been remiss in updating my blog with the latest 3.6.0 release of GNU Radio. This continues our efforts to constantly move forward and focus more on making sure updated, stable releases are available that people can rely on.

There were a number of updates that you can find on the changelog page in the above link to the release. The most important one is that, finally, our long national nightmare of hosting and supporting two build systems is at an end! We have remove the autotools build in favor of cmake. Not only have we worked hard enough to make sure cmake satisfied all of our build needs, but we really started focusing our energies there, often leaving behind the old autotools way of compiling the code. No longer. We have moved over to cmake. In most ways, this is a positive move. People familiar with cmake, I'm sure, love it. Those unfamiliar may have a bit of growing pains, but I think you'll soon find that as a user, it is very simple to work with. Our build guide shows you the steps to using it to build GNU Radio from scratch (hint: basically replace configure with cmake).

In another major advancement, GNU Radio users might have noticed that our website has been a bit slow and groggy. In a way, this was a really positive thing for the project because it meant that we receive a ton of traffic. It was, however, annoying and needed to be fixed. This past week, Johnathan Corgan and I updated the server machine to a faster system. The change in the responsiveness of the website was immediate, and I think all of our users will be pleased.