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.

Friday
May042012

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

 

Thursday
May032012

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
release.

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
improvements.

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".

Johnathan

Wednesday
May022012

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.

 

Sunday
Apr082012

Two Releases in One Month!

We've been busy producing a lot of new material for GNU Radio. We've fixed a number of bugs, improved the code, added a few new features (like support for the FunCube Dongle). Since the last news update here, we've released 3.5.2 (and a bug release of 3.5.2.1) and just yesterday released 3.5.3.

Here's the email to the GNU Radio Mailing List from Johnathan Corgan about the release:

GNU Radio release version 3.5.3 is now available for download:

http://gnuradio.org/redmine/attachments/download/320/gnuradio-3.5.3.tar.gz
http://gnuradio.org/redmine/attachments/download/321/gr-howto-write-a-block-3.5.3.tar.gz

The release notes are here:

http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeLogV3_5_3

This is the last planned 3.5 API compatible release; there may be bug
fix releases along 3.5.3.x, but no new 3.5.4 release is planned.  Work
on the master branch will be focused on generating a 3.6.0 release.

Contributors this release:

Achilleas Anastasopoulos
Alexandru Csete
Ben Reynwar
Dimitri Stolnikov
Johnathan Corgan
Josh Blum
Michael Dickens
Nicholas Corgan
Philip Balister
Tom Rondeau

Enjoy!

We're on the path for a 3.6.0 release shortly where we'll be going full cmake build.

 

Sunday
Jan152012

GNU Radio 3.5.1 Released

Version 3.5.1 of GNU Radio has recently been released. The download can be found here:

http://gnuradio.org/redmine/projects/gnuradio/wiki/Download

The release includes the following:

 

  • Added new SNR estimators to gr-digital; both a probe (sink) and an inline block that copies input to output and sends tags with SNR.
  • Ability to set an upper limit on the noutput_items blocks receive. Allows control over latency.
  • Cmake build enhancements and bug fixes.
  • Support for different over-the-wire data types in UHD.
  • Python GIL fix for gr_bin_statistics.
  • Doxygen documentation bug fixes and enhancements.
  • Added more get/set functions for various blocks (digital_fll_band_edge, gr_noise_source, gr_channel_model).
  • General bug fixes.