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.

Wednesday
Sep042013

GRCon13 is Almost Here

Over the past week, we've been really gearing up GRCon13. It's just less than a month away! The important news right now is:

  1. We have announced the agenda, which includes a number of areas of talks and shows a very strong program.
  2. We have had a lot of buy-in from the SDR hardware vendors and will be giving away hardware at the end of the conference.

The abstracts for most of the talks are also available if you want to know more about any one. Many of the abstracts for the tutorial talks are not yet up but will be over the next few days.

 

Friday
Jul192013

PyBOMBS

GNU Radio is a huge project in both the in-tree code as well as the growing number of out-of-tree projects. We have two main issues with the installation and use of GNU Radio that follow from this:

  1. Lots of dependencies with different projects, and each may have different levels of difficult to install on various systems.
  2. Lots of out-of-tree projects that can do incredible stuff but are difficult to know about, find, and install.

PyBOMBS is a new GNU Radio package manager that helps solve both problems. For the past year of so, Marcus Leech has provided the brilliant 'build-gnuradio' script, which went a long way to solving problem 1. It was, however, and not to demean it's impact, just a shell script designed for apt-get (Debian, Ubuntu) and yum (Red Hat, Fedora) Linux systems only. It could be fragile and required a lot of upkeep from Marcus. It also did little to solve the second problem of providing access to the OOT projects.

CGRAN is an attempt to solve the second problem. I still support the idea of CGRAN as an archive and a site to promote the existence of different OOT projects. But users would still have to search through the archive to find projects and then figure out how to install them. The other problem is that various projects would be out of date with GNU Radio versions, which isn't always clear.

PyBOMBS addresses both problem, and we are slowly trying to move everyone over to using it. For one thing, Marcus has declared his intent to stop working on build-gnuradio, and secondly, there's a strong, developing community of OOT projects that we want to help support. And while supporting and providing easy access to OOT project, we also provide some guarantee that a project that is included as a PyBOMBS recipe is built against and works with the version of GNU Radio that PyBOMBS installs.

That's the main intent of PyBOMBS, and we encourage people to use it and submit new recipes for their OOT projects. You can find out more information about how to use it on the PyBOMBS Redmine development page.

I also leave you with a link to Ben Hilburn's really nice peice on PyBOMBS and why he's excited about it for the GNU Radio community.

Wednesday
Jul172013

The 3.7.0 Release

Strangely, I seem to be the last to report our first major release of the 3.7 GNU Radio branch. We've been working on it for over a year and a half and it represents some serious improvements both structurally and stylistically. But luckily other's weren't as lax as I was in promoting the good news.

In the development of 3.7, we have introduced so many new and powerful features of GNU Radio that it's hard to keep track of them.  Let me just try to list off a few:

  • Message passing interface and easy Python access
  • ControlPort
  • Performance Counters and Performance Monitor
  • VOLK (been here for a while, but a new structure in 3.7 makes significant improvements)
  • A full logging API
  • Metadata files and sources/sinks to work with them
  • Block thread affinity (and thread priority)
  • Tagged stream blocks
  • New and improved OFDM implementation (and in GRC)
  • Improved support for packet data transmission

Each of these items deserves its own write-up. Luckily, another major improvement in our work on 3.7 is a lot more documentation. The main GNU Radio manual (our 'Doxygen' manual) has more and more pages dedicated to explaining these features such as how to use the API and examples of using them in your own code or application. So keep an eye out for improvements in the documentation as we move forward with 3.7.

The Vision for 3.7

It took us a year and a half to produce 3.7. In some respects, that feels like a fairly long time between an API release like this. And we felt that, too, when the 'master' and 'next' development branches were diverging so much and so quickly that we couldn't merge one into the other without major conflicts. But on the other hand, with so many changes and new features, we needed to make sure we had everything where it needed to be before a release.

That having been said, I'm going to say now that we probably won't see a 3.8 for about as long, maybe even longer. One of the drawbacks to all of this new stuff in the code is that we tend to leave people behind. The API changes alone are going to take a lot of projects some time to update their code. And it will also take a lot of time, documentation, and examples to help use the new features. So while we will continue to innovate and push forward with new stuff in an ongoing effort to improve GNU Radio, we are also increasingly interested in building and helping to build new applications that take advantage of all of the new features and improvements. There will be a lot more writing, examples, and example applications being written this year towards this end.

 

Saturday
Mar232013

Major Milestone in v3.7 Progress

Earlier this week, we finished converting all of the main blocks over to the new 3.7 style and top-level components. We still haven't fully addressed gr-atsc and gr-shd, but I'm holding off on those two right now on purpose.

The main win here is that you will only see minor changes in which modules you pull blocks in from. Any changes now are bug fixes, but they will be minor and easily corrected. So you can now rebuild your Python and GRC flowgraphs around the 'next' branch, and you should be pretty much good to go.

Note that we've removed an 'blocks' from gnuradio-core. So now, the only things you pull in from the Python gr. module are data structure sizes, the top block, message queue stuff, and similar. If it's a block, it's now located in one of the other blocks. We'll try to post our spreadsheet of where each block is now, but hopefully we've done it so it's pretty intuitive. And if you don't know where something should be, it's probable in gr-blocks (from gnuradio import blocks).

We're really starting to close in on the release of 3.7, so the major churn from our users' perspective should be slowing down.

Tuesday
Feb192013

Configuring ControlPort

We've just pushed some new code to the 'next' branch for better control over ControlPort. Part of this was to make using configuration/preference files more easily and widely used in GNU Radio. While we've had a bunch of configuration files installed, we only really used them for some audio and wxgui parameters. I think we might start using them more heavily in the future for better control over how GNU Radio works, especially now that we're adding a lot of new features that need a finer touch to handle.

First, a word on the preference files. These get installed by default into ${prefix}/etc/gnuradio/conf.d. Each component has its own, but we actually treat it as a flattened list of sections and options (and so we have to be careful that we don't duplicate section and option names). These config files would be system-wide defaults. However, any option can be overwritten for a user by making a [HOME]/.gnuradio/config.conf file. Just duplicate the section name and the option name in this file, and it will take precedence over the system file.

For example, gnuradio-core.conf has a section [ControlPort] and an option "on". This toggles ControlPort on/off. Say by default we want to keep ControlPort off (which is how GNU Radio is installed be default now). So our /opt/etc/gnuradio/conf.d/gnuradio-core.conf file has the "on" option set to "Off" (or False, or 0). But a particular user wants to use ControlPort. So he would create a file /home/me/.gnuradio/config.conf and put in the following:

[ControlPort]
on = True

And then next time GNU Radio is launched, this preference is read and ControlPort is turned on.

As a side note, we can also control any preference with the use of environmental variables. Just take the section name and option name and convert them into all caps with underscores between them. Then append "GR_CONF_" to it and you have your variable name. Set this to whatever you'd like. So our user me above could use "export GR_CONF_CONTROLPORT_ON=True" to manipulate that setting.

But back to the main point here. ControlPort can now be easily configured based on any configuration parameters available through ICE. We have a section:option in gnuradio-core.conf called "ControlPort:config" that points to the ICE configuration file location. I've made a really simple example that you can find installed at ${prefix}/etc/gnuradio/ctrlport.conf.example. This just shows you the format of creating a specific endpoint, like:

ControlPort.Endpoints = tcp -t 300 -h 127.0.0.1 -p 23456

Why would this be important? Well, by default ControlPort doesn't know which interface or ports you want to use in your setup, so it defaults to opening a random port on all possible interfaces. This is good because it makes it easy and is the right behavior when no one knows any better, but it is also bad for two reasons. First, it's a security risk to open a random port on all of your machines network interfaces. Second, you probably want to know which port you are using so that you can connect remotely, possibly through a firewall. Setting specific endpoints allows us to control where ControlPort is exposed and on what port. And, frankly, it's about time.

By the way, most of what I've discussed here is also available in the Doxygen manual that you can build off the code in master/next (and will be made available online with the next release).