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.



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.

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.


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.

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:

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

Block Core Affinity

I just pushed an update to master/next of GNU Radio that allows us to specifically set the affinity of a block to a particular core. We can do this pretty easily because each block is its own thread in the Thread-Per-Block scheduler, so really what we are doing is setting the thread affinity.

The reason to introduce this behavior is to help us start developing an understanding of GNU Radio on many-core machines. For example, we've been contacted by the Parallella project, and this kind of functionality might be crucial to working well on that platform. On most current systems, we can talk about multi-core, which are a small (up to a dozen or two) number of the same types of processors with shared memory and local cache. The OS scheduler probably does a fantastic job with scheduling the threads in this situations, and kernels like Linux have alternative scheduling strategies we can use for specific purposes. But in a many-core system where we have heterogeneous cores and maybe different access to memory transfers or DMA to IO devices, the ability to selectively choose which cores to run on may be more important. Think about a situation where you want your UHD source block to run on the core that has the closest/fastest access to the GigE system. I'm not saying that this will actually work or help in these scenarios, but it's worth it to make this kind of research and experimentation available.

The API for this is pretty straight-forward, and block affinity can be set before and during the flowgraph run. On a given block, you just call the function 'set_processor_affinity()'.

Notice that the function takes a list (a Python list or a C++ vector of ints), so you can set the affinity to a group of cores if you want. There's an example of how to use this in gnuradio-core/src/examples/mp-sched/affinity_set.py. When you run it, watch your CPU usage monitor(s). This runs two gigantic filters that are designed to take up most of a core, one is set to core 0 and the other is set to either core 0 or 1. As long as at least 1 of the cores specified is present, the system will just use that, so this example will run even on single-core machines (but I have not tested this behavior in Windows). On systems with 2 or more cores, core 0 will be largely taken up by the first filter. The second filter could use core 0, but will likely be scheduled to use core 1.

One thing to note: this is not fully cross-platform. Setting thread affinity seems to be a delicate subject and not fully supported. In fact, the pthread library call pthread_setaffinity_np has that suffix 'np' to specify that it is implicitly non-portable. The GNU Radio Utilities and Etc. Library (GRUEL) has been updated to provide abstracted calls for the different OSes that we support for this. Right now, we have Linux and Windows support. I tried to get OSX support, but their API isn't exactly what we are looking for (they are interested in sharing cache lines, not specifically tying a thread to a core). So until things change, our GRUEL thread affinity calls in OSX are nops.

In the Doxygen manual, look for the Related Pages page named 'Block Thread Affinity' for more details.

Project Updates

As always, we've been hard at work on extending and improving the features in GNU Radio. This is just a quick update on a few of the things we've been working on recently.

First, I have been adding specific pages to the Doxygen Manual that catalogue and describe certain features and functions of GNU Radio. You can find these in the "Related Pages" section. They feature discussions and examples for how to use some of the features in GNU Radio that might not otherwise be obvious. I like this model since it keeps the documentation of the code directly integrated into the code and the build system. You can always have a local copy of the manual for your version. We're also not trying, then, to keep multiple versions of code documentation all over the place.

Today, to make things easier, I expanded our Documentation section on the main GNU Radio webpage to directly link to some of these pages. I'm not sure how many others have found them or are using them already, but I wanted to make sure it was easy to what was available and where to locate the information.

The other thing that I wanted to mention today is the work that's been done on the QTGUI blocks. These are visualization tools for signals in GNU Radio. We've been significantly improving them over the past few months.

The first major improvement has been to add direct user control over the parameters while operating live. The figure below shows a screenshot of the gr-qtgui example *pyqt_freq_c.py*. First, notice the overall color scheme. This is based of the ability to use QT style sheets that can define the look of a QTGUI app. In this running example, I right-clicked outside of the curve canvas itself (where right-click means to unzoom) to pull up the menu. As you can see, the menu allows us to adjust a number of parameters. Some of these are available in all plotters, but others are specific to the type of plot (the FFT size or averaging would be meaningless in a time domain or constellation plot). In this figure, I have adjusted the color of line 'Data 0' to red, increased the width of the other two lines, changed the FFT size to 512, and turned on averaging. I then stopped the graph and tool a screen shot to make this image (notice, though, that there is a 'Save' option in the drop-down menu; this saves the current plot, but it would not have included the menu information).

I would encourage anyone using the QTGUI plotters to play around in these menus to understand the kind of flexibility we now have while looking at signals.

Finally, before this post gets too much longer, I wanted to also note that we have just added a new QTGUI plotter to do time raster plots. These types of plots show samples in time, line by line, so both x and y axes are in time. This is often used for looking at data and packet structure. The GNU Radio plotters can accept multiple signals in that are then plotted as an overlay. The intensity is then shown as the sum of the samples, so it will be higher when then overlap and lower when they are different.

The figure below shows the output of the example pyqt_time_raster_b.py that is shipped with GNU Radio. It has one signal that has 10 zeros, then 80 bits of alternating ones and zeros, and then ended with another 10 zeros. Another signal is then overlaid on top that just has a pattern of 3 one part-way into the vector. These vectors are then repeated. We can see the bright white stripe is where we get the 3 ones from signal 1 on top of the samples in signal 0.


Also note the diagonal. We draw these figures on a grid of a number of rows and number of columns. If we had 100 columns in this example, the samples would be plotted in straight columns. But in many situations where these types of plots are useful, we may have some fractional offset we want to handle. This example is showing us that we can set the number of columns to 100.25, so there's a quarter bit overlap between rows that causes this diagonal. Using the drop-down menu, we can adjust the number of columns to 100 to get what we see below.


Update on Filter Design Tool

Some quick work between myself and (mostly) Sreeraj helped me realize something that I instantly wanted to do with his new API for using gr_filter_design. I just wanted to publicize it here.

The gr_filter_design tool nicely ties into Python and GNU Radio projects. We launch the filter design tool from the program and can have it return the resulting filter to us in the code to use directly with our filters. Sreeraj also adds a callback function, so that every time the filter design is updated, this callback function is called and it is passed the filter object.

So what did I want to do? I wanted to do a live update of the filter on a live signal. So we built up an example (found in gr-filter/examples/gr_filtdes_live_upd.py) that constructs a simple flowgraph. Two sinusoids are created at different frequencies, some channel noise is added to them, then they are passed through a filter and finally displayed on a QT GUI. The filter starts of with just a single tap of 1, so it's really not doing any filtering.

We then have a function called 'update_filter' that is used as the callback function with the filter design tool. So when you run this program, both the filter design tool and the QT GUI window showing the signal pop up. Whenever we design a new filter, we can immediately see the effects on the real signal that's running through GNU Radio. I've put a screen shot of both windows below.

This image shows the original signal (we've just been storing the maximum value at all FFT points since the start, so we turn on that plot curve) and the new signal through our filter. In this static case, I just designed a band-reject filter around the higher frequency.

Here's another fun experiment that I did. I first created a simple low-pass filter, so the higher frequency signal was rejected but the lower frequency wasn't. I then used the pole-zero plot to move around a couple of the poles onto the unit circle. Setting two of them at the right phase orientation allowed me to put zeros at the frequency of the lower signal. We can see that we've almost cancelled that one out now, too. I used two because the accuracy of getting just a single zero on the correct frequency was too great, so putting two around it allowed me to hit it pretty good with a null in the filter.

Really good fun (if signal processing is within your definition of fun). Also, really instructive and educational. Seeing how these filters behave as we update their parameters and poles and zeros can really help you learn what's going on with the signal processing.

New Documentation for New Features

Because we've been working on new features in GNU Radio that are not part of a standard GNU Radio application with blocks and a streaming model, I've felt it's increasingly important to explain and document these. So I just pushed some new updates that expand the Doxygen manual with new pages for these new features.

(Also, I'm trying to use the word 'new' here as much as possible, apparently.)

If you build the Doxygen manual, the main page now points to sub-pages for things like:

  • Polymorphic Types
  • Message Passing
  • Metadata Information
  • Instructions for using Volk in GNU Radio
  • Polyphase Filterbanks

Some of these pages have been in the manual for a while, some of them are new. And I plan on adding more of these over time. One reason to have them in this format in the Doxygen manual is because they're part of the source code so that everyone can have access to them, they are tracked in our version control system, and so we can nicely co-locate it all in one place. Also, I plan on adding new links on gnuradio.org that directly point to these pages in the manual that get's published on the website. Some of these pages are not in any release, so we'll wait until we release 3.6.3 (this weekend if all goes well) before we put it all together on gnuradio.org.

Important New Feature

If you haven't already seen our announcements about it, I want to point out the manual page that describes the use of our new message passing system. The API, design, and some examples can all be found in the Doxygen manual page "Message Passing." This is a really powerful new feature that we want to start using as much as possible.


New Filter Design Tool in 'next'

Our 'next' branch now contains the updated gr_filter_design tool! Thanks to Sreeraj Rajendran for his fantastic work on this! Also, thanks to Google for supporting the work through the 2012 Google Summer of Code.

When you build and install the 'next' branch, you'll now get access to the updated design tool. If you haven't seen any of the discussions about it from the conference or anywhere else, check out this YouTube video describing it's capabilities. Below is a screen shot just taken of the version that's now a part of our 'next' branch:

Make sure to check out the examples in the GNU Radio source code (gr-filter/examples/gr_filtdes_*.py). These show you have you can programmatically call the design tool and have it return an object containing the filter parameters and taps. 

Metadata File Format

One thing that I think GNU Radio is great for is science and experimentation. But one of the main drawbacks that we haven't addressed until now is the storage of information about data that we've collected. When making a collection, later on, we'd like to know a lot about the collection setup, properties of the radio, information related to the samples, and possibly many other things (like the date of collection, location, the weather, etc.). Part of the last GR Hackfest was spent figuring out the proper format for including and managing this kind of metadata in our data files.

Well, I'm happy to announce that we now have this capability natively in GNU Radio. We have a file sink to write metadata files and a file source to read these files back again. We have a few simple utilities that can read the metadata out of a file, too. Now that the mechanics for metadata are there, we'll be interested in using this concept more and more. For example, we'd like to update our utility uhd_rx_cfile that just captures raw samples from a UHD device to use metadata. This would very simply put in header data that includes the time stamp from the UHD device and the sample rate, frequency, and gain of the receiver. And then there are some plotting tools that we have to display files in different domains. We need to update these so that they understand the metadata and can adjust themselves accordingly (like setting the right time or frequency axis based on the metadata as well as knowing the right data type of the samples).

We'd also like help in knowing what other tools people would like to have for managing metadata files. Even more, we'd like help in building them! One tool that I can think of is a way to read a metadata file and split it up into multiple files where there's a single metadata header and the data segment for each file. We could then have smaller, more manageable files which we are capable of reconstructing due to the metadata. And I'm sure that there are plenty of other tools that we can create to make the handling of this kind of information more useful.

To start explaining the metadata concept, I'll summarize here by (mostly) copying what I wrote on the Hackfests wiki page (http://gnuradio.org/redmine/projects/gnuradio/wiki/Hackfest1211).

We now have Version 0 of the metadata files in 'master' and 'next', so they will make there way into the 3.6.3 release. There is a blocks::file_meta_sink and blocks::file_meta_source. The file sink creates a file and writes all data to it, along with headers of metadata. The file source is resourceful in that you can just give it the metadata file itself and it's capable of reading out everything it needs in order to pull the data and source it into a flowgraph. Meanwhile, other metadata gets transferred as stream tags so blocks down the line can also know what's happening with the data. Pretty good stuff!

For a more complete discussion of the metadata header format and how to use it, we've added a page to the Doxygen manual that explains it all. This manual page is not on the gnuradio.org's website version of the documentation since we have not made a release containing this capability (but it will be in 3.6.3, which will be released soon). For now, you can build the documentation locally (in either 'master' or 'next') and you'll have access to the page, which is located under "Related Pages" and "Metadata Information."

ControlPort now in 'next' branch

Part of the work at the latest GR Hackfest was to move ControlPort into gnuradio-core and get it ready to be merged into our 'next' branch (which is the upcoming 3.7 release). One of the main reasons why we wanted to put ControlPort into the core of the project was so that anything and everything in GNU Radio could make use of it. The start was to access parts of gr_top_block, the main component of the flowgraph. With (hopefully) a few tweaks, we expect to be able to remotely access the start/stop functionality of the top block, which gives us a whole new layer of control over GNU Radio applications.

The main reason that we didn't put ControlPort into gnuradio-core originally was that it was much easier to build as a conditional and optional component if it was its own separate gr-ctrlport.  But that meant that gr-ctrlport depended on gnuradio-core. We couldn't then also make gnuradio-core use gr-ctrlport, so nothing in gnuradio-core would have been able to use ControlPort functionality. Most of this would have changed come the complete switch over to the 3.7 structure and API where gr-ctrlport would only depend on gnuradio-runtime. But we discussed it and figured that allowing ControlPort options in things like gr_top_block is important, so we had no choice but to move it into gnuradio-core (and in 3.7 it will be in gnuradio-runtime).

The downside of this move was purely personal. I now had to work through the build system to have parts of gnuradio-core built if gr-ctrlport was enabled. But we did it, and now ControlPort is usable on all blocks and in any component. For anyone working off 'next', you now have complete access to ControlPort. Documentation, though, is still forthcoming...

Public Release of ControlPort

/gnu-radio-conference-2012/I've (finally) pushed the ControlPort work out to my public repo on Github. The repo is:


And the branch with ControlPort is, amazingly enough, 'controlport.'

For those reading this who are unfamiliar with ControlPort, we announced it and I demo'd it at GRCon12. You can find my presentation here. ControlPort is a new set of hooks into GNU Radio to allow a remote client to attach to a running GNU Radio program and get and set parameters. It's quite a powerful concept with an SDR application, and we think that there are tons of ways to use this to improve on current work and to think of entirely new ways of using SDR.

When you look at the source code of the branch, and right now that's by far the best way to learn anything since we haven't spent any time on documenting its use, you'll see a few new things. First, there is a new top-level component called gr-ctrlport. This is where all of the code that goes into mechanics of ControlPort live. Second, you can look at a couple of other components for how ControlPort is used and tied into the build system, specifically gr-digital, gr-filter, and gr-channels.

One of the driving concepts behind ControlPort is that it is only an add-on to GNU Radio and not a requirement. We do not want to force people to build this and the required dependencies (we are using ZeroC's ICE for the communications backend) to continue doing their other GNU Radio work. So everything had to be made as separate as possible with the ability to test for ControlPort before being able to use it. So when you look at the directories like gr-digital, you will see that the CMakeLists.txt files check for ENABLE_GR_CTRLPORT before linking against the library or using ControlPort as a dependency. There are other checks that are internal to each block that uses ControlPort for the same purpose.

ControlPort's main focus is to create an external interface to a running GNU Radio application that will advertise parameters that you can set and get remotely. Much of the structure of gr-ctrlport is designed to make this interface simple and generic. Each block is responsible for exporting the variables as either gettable, settable, or both. The two blocks that showcase these capabilities are gr::digital::pfb_clock_sync_ccf and gr::channels::channel_model. You can look at these files to see how we've implemented the exposure of the various block's parameters.

But keep in mind that the interface will likely change. We are even now talking about ways to simplify the declaration of the parameters to be accessible over ControlPort. Hopefully, when we're done, the code will be even more readable.

There are still lots of details to be discussed and documentation of the use and development of ControlPort to come. This is just a general announcement of it's public availability and a brief taste of what we're doing and where we're going.

As a way to get started, the 'controlport' branch includes an example that uses ControlPort (there is a WXGUI and a QTGUI based version of this, actually). In gr-ctrlport/examples you can open the pfb_sync_test[-qt].grc in GNU Radio Companion. This simply simulates a QPSK signal going through a channel model and begin recovered using the PFB clock sync and a Costas Loop. Since the channel model and clock sync blocks both export parameters over control port, we can dynamically alter the simulation from a remote client.

When looking at the GRC canvas, you'll see a couple of ControlPort-specific items. As part of the graph, we have a 'Complex Probe (fixed len)'. This is one of the few blocks in gr-ctrlport. It exposes a vector of samples so that we can access them remotely, such as to plot. The other one is 'CtrlPort Monitor', which is up in the top left near the 'Options' block. This monitor is an application that we wrote to provide access to the items available over ControlPort. First, it looks for exposed endpoints from the running flowgraph, and if found, it will attach itself. Below is a screenshot of this application. You can see that it's a table of parameters with some properties. The key is the parameter name, defined as the name of the block and its unique ID number (unique within the running graph). You then get the current value, any units if they were specified, and a more detailed description.

When you double click on one of the rows, it will pop up with a graph to display that parameter. This is true if a) the block has set a 'get' function for this parameter (which is true here since the application only displays those parameters that are gettable) and b) a default display type was declared when the variable was exported. If no display type was given, nothing will happen. However, right-clicking will bring up a menu where you can select the type of plot to use.

Below is a screenshot of double-clicking on the 'probe2_c1::constellation row. This shows the IQ plot of the samples gathered by the probe in the flowgraph.

If a variable is settable like 'channel_model14::noise, you can right-click and bring up the properties window. This will give you an edit box and a slider to set the value.

Since ControlPort is really meant to be used across a network, this GRC example isn't any more exciting than just hinting at what's possible. But we can easily transform this example into such a remote operation. First, in the GRC graph, bring up the properties of the 'CtrlPort Monitor' block and turn 'Enabled' from True to False. Now, when we run the program, it will not automatically start the monitor application.

In the GRC console window, notice that the application now announces that it has created an endpoint that should be something like "Ice Radio Endpoint: gnuradio -t:tcp -h <local IP> -p <Port #>". This is the Ice endpoint that we connect to. Using a terminal on the local machine or another machine where this GNU Radio branch has been built and installed, you can use the gr-ctrlport-monitor application to connect to the running flowgraph:

gr-ctrlport-monitor 12345

Just make sure you're firewall settings allow you to use that particular port.

There will be a lot more said about ControlPort as we continue to develop it. I'll post more here, but we will be producing more structured documentation for how to use and develop with ControlPort.


Version 3.7: The Work in Progress

We've been hard at work over the past few months on getting GNU Radio completely switched over the the new 3.7 API. It's a hard path to go down with some many files that need to be touched, edited, fixed up, reworked, etc. But we're making progress, and I wanted to update everyone on where we are.

Recently, we finished up the new gr-analog component that takes a lot of blocks from gnuradio-core and moves them into the new analog namespace. These blocks include:

  • agc_cc
  • agc_ff
  • agc2_cc
  • agc2_ff
  • cpfsk_bc
  • ctcss_squelch_ff
  • dpll_bb
  • feedforward_agc_cc
  • fmdet_cf
  • frequency_modulator_fc
  • noise_source_X
  • phase_modulator_fc
  • pll_carriertracking_cc
  • pll_freqdet_cf
  • pll_refout_cc
  • probe_avg_mag_sqrd_c
  • probe_avg_mag_sqrd_cf
  • probe_avg_mag_sqrd_f
  • pwr_squelch_cc
  • pwr_squelch_ff
  • quadrature_demod_cf
  • rail_ff
  • sig_source_X
  • simple_squelch_cc
  • squelch_base_cc
  • squelch_base_ff
The current master branch reflects all of these blocks in gr-analog, but we have not removed and blocks from gnuradio-core, yet. This is part of our contract with our users that we don't change the API on the master branch until we are ready for a new API release. So all code built against master or the 3.6 versions will continue to work. We have simply added gr-analog as another set of blocks. We are encouraging people to start moving over to these new components since when 3.7 is released, anything using blocks in gnuradio-core (or the 'gr.' module in Python) will no longer work.
In the meantime, by duplicating blocks, one thing we are running into is a duplication of blocks in GNU Radio companion. You might notice that if you are working on the master branch that you'll have two sig_source or noise_source or any other blocks in gr-analog. This is just a consequence of using the same block and component names as previously but in two components. This is just something we're going to have to live with for the next couple of months.
You can tell which component you are using from the ID name in the block's properties window. We give them prefixes from the component they are from. So the old blocks will have a "gr_" in front while new blocks from gr-analog will have "analog_". They should be functionally equivalent, but the new "analog_" block is safer to use as it will not go away in the future. It's also, as far as I can tell, true that the top-most block will be the newer block, but it'd still be best to make sure.
When you look at the next branch, though, all of the components moved into places like gr-analog are being removed. Due to certain constraints and dependency issues, we cannot remove all duplicated code out of gnuradio-core until some things have progressed further.
One thing that I wanted to point out in this update is that there are bound to be a few problems that arise during this transition. Us and you will probably get a bit confused here and there. We've made some mistakes, like how gr_rotator is part of gr-analog on master, but we've removed it from there on next as it more appropriately belongs in gr-blocks.
And while we've been trying to make sure all Python, C++, and GRC example codes reflect the changes happening, we're going to miss some of those, too. I only as for both some patience with this process as well as help. Point out where we haven't properly updated some code, or if you'd really like to help, send us a patch!


Community Manager

We are so very pleased to announce that Martin Braun will be taking the position of Community Manager for the GNU Radio project. Martin was the obvious choice for this role since he has already been fulfilling a large portion of the role informally over the past few years.

The Community Manager role is a new one for our project, and so Martin will be establishing its full responsibilities over the next few months. The basics of what we imagine this position will entail includes:

  • Managing, editing, and developing gnuradio.org.
  • Growing the community of developers and other contributors
  • Organizing and spear heading our efforts with the Google Summer of Code.
  • Managing/moderating the mailing list.
  • Helping with the planning, promotion, and execution of the GRCon.

I would personally like to thank Martin for all of his help in the past and his continuing support in his new role.

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:



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.