Home

Annual GNU Radio User's Group Meeting

 

Once again, Matt Ettus and I will be hosting the GNU Radio User's Group Meeting in DC in conjunction with the Wireless Innovation Forum's SDR'11 WinnComm conference.

As you can see in the program, we are on for 8PM on Wednesday, Nov. 30. We don't have a room yet, but it will be located in one of the conference rooms at the Hyatt Regency Crystal City, Arlington, Virginia.

Everyone is invited, even if you are not attending the conference.

 

 

 

Ubuntu 11.10 Troubles

After upgrading to Ubuntu 11.10, I noticed some serious issues compiling and building GNU Radio. I spent the weekend working these out, and I'm happy to report that as of Sunday night, the git maint/master/next branches can all be built on Ubuntu 11.10 (and all previous builds, too, of course).

The work isn't quite done, yet, I'm afraid. There are still some bootstrap issues as the autotools guys have becomes a bit more restrictive/careful. The warnings that are generated are annoying but appear harmless. I worked out what I could, but there's one or two more that are alluding me right now. I'd appreciate any assistance in tracking this down that anyone wants to give me.

The other error was that we didn't explicitly link against the Boost filesystem library in a couple of places. That was another easy one to fix.

But the big issue came because of Ubuntu's change to using Qwt 6. We had been using version 5.2 since we build gr-qtgui. The change to the new API was not trivial, especially when trying to maintain backwards compatibility with 5.2. I'm happy to say that this has been achieved. The code's a lot uglier because of the Qwt version checks, and while I could have probably done it a bit more cleanly, this is still the right way to do things.

While the update to Qwt 6 was pretty painful, the new API and changes that they made have created a much better system. In particular, the waterfall plot has been greatly simplified from version 5.2. Once version 6 starts to take hold in all of our other OSes, I'll go through and clean out the old stuff required in 5.2. This probably won't be for a few years, though, but it will be nice when we can move on and create more simplified implementation.

Lots of work and new looks

If you don't follow our commit messages or look at the main GNU Radio website often, I just wanted to point out a few of the major changes that are going on in the project. First, our website, gnuradio.org, is being updated with the goal of making it more useful and better looking. A huge shout-out and thanks to Martin Braun for his help with this. Martin did the reorganization of the content and layout, which I think makes a huge impact on the accessibility of the information and knowledge in the page. He also helped craft the new look to the web page.

We've also been working hard on pushing towards the next release, v3.5. This release will include a lot of new features.

 

  • New top-level blocks to help organize what's available in GNU Radio as well as make the build and rebuilds simpler
    • gr-digital: moves most of the digital modulation-specific blocks the gnuradio.digital namespace. This also makes some changes to the API of a few blocks to simplify and improve their performance.
    • gr-vocoder: moves all of the vocoder capabilities into one place under gnuradio.vocoder.
  • UHD examples: all of our examples are being migrated over to using UHD instead of either a usrp or usrp2 interface. This should make all examples usable by any of the Ettus products.
  • Cmake: a huge change to the build system is coming up. Specifically, we hope to switch our build system from autotools to cmake. This has a few benefits:
  1.  
    1. Simplify the installation process
    2. Improve the supported platforms of GNU Radio (including adding Volk to all of the known supported platforms)
    3. Makes building deb (and presumably rpm) packages for all components easier. Expect us to start supporting GNU Radio releases through apt-get (from our own server) soon (fingers crossed).
  • We aim to have both the autotools and cmake build structures in place in parallel with the intent of making cmake the default. The autotools is a back up build system for people who experience problems with cmake. Eventually, if cmake becomes problem-free, we will likely remove the autotools completely in v3.6 (maybe...).

Those are just some of the changes we've been making to the code and overall project. I'm sure I will post more soon, especially as we get ready to release 3.5.

 

New Server, New Service

We have recently updated the GNU Radio server to a new platform with updated versions of all of our services. There were a few hiccups along the way as proxies and other caching sites had to be refreshed for everyone to get to the new site properly, but I haven't heard any complaints in a while, so hopefully those initial jitters have gone away.

Among the new versions of our software is an updated Redmine. The new Redmine fixes some issues we had with registration, but it will also allow us to support multiple projects and other nice features like that. Keep an eye out for expanding information on the website as we integrate these new features.

Mostly, I hope this change hasn't effected anyone, and it should only serve to make the website more stable and nicer to use. The new server in the background has already saved us a ton of work.

One new change that has come about is an update from running Hudson to Jeknins. This will serve as our new continuous integration tool and I hope to start making good use of it in our project development cycle.

Initially, the most important change is that every time Jenkins builds GNU Radio, on a weekly basis, the resulting packaged tarball for the most recent master development branch will be published on our website. This means that people who don't want to or can't use git to access the software can get a new snapshot of the code weekly. The links to the tarball and the SHA1 sum of the tarball are found on the Downloads page of gnuradio.org.

Jenkins Interface: http://gnuradio.org/jenkins/

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

 

UHD Examples

I recently added a couple of GNU Radio examples that use the UHD interface to the USRP devices. We have been lacking any examples of using the UHD interface, and these new apps are two of the more commonly used apps we have, so I wanted to provide some support as people migrate to UHD-only GNU Radio programs.

You can find these new apps in the source tree under gr-uhd/apps. They are:

 

  • uhd_fft.py: a simple spectrum analyzer program to display a received signal in a WX GUI. You can set the frequency, bandwidth, gain, and antenna, and you can display an FFT, waterfall, or time domain (oscilloscope) plot, where the FFT is the default.
  • uhd_rx_cfile.py: this is a simple script that stores all received samples to a file. Again, you can set parameters like the frequency, bandwidth, gain, and antenna port. You can also save samples as complex shorts (16 bit I&Q). You have to provide the name of the file to save the samples to, and you can either let it run until you stop it or provide a maximum number of samples to capture.

 

These should help us with a few things. First, it will give people who want to write programs with UHD a few examples of what to do, especially if they want to convert another program that we have to using the UHD interface. It will also help us reduce our dependency on the other "legacy" interfaces to USRPs and USRP2s.

Right now, gr-utils depends on gr-usrp, and we want to remove this dependency. Instead, I would rather see each gr-<interface> have an "apps" directory that contain applications using that particular interface. Doing this is going to mean a lot of duplication of code, but that's unavoidable until we construct some kind of hardware abstraction layer.

As a side note, one of the reasons we have been putting off making these kinds of apps is that we had envisioned re-imagining of some of them into full-blown programs. Instead of a uhd_fft.py, we wanted something like a gr_spectrum_analyzer that would provide all sorts of neat bells and whistles and look and feel more like a digital implementation of a spectrum analyzer. However, this is going to take time that no one really has right now. So I just made the decision to go and do these simple applications to get the ball rolling.

Why Isn't GNU Radio Used More?

My first major question I want to put out there from DySPAN relates to the uses and customers of GNU Radio. Specifically, why aren't there more of them?

One of the key aspects of DySPAN is the demonstrations that various companies, universities, and other research firms bring to DySPAN to show off. These demos are in some part related to dynamic spectrum access (DSA), whether it's showing off a spectrum sensing or whitespace-finding device or a policy engine to certify of restrict certain radio behaviors. Having both been involved with the early creation and organization (really, helping Keith Nolan enact his vision), a demonstrator myself in 2007, and watching the demonstrations throughout the years at DySPAN, I have both been pleased with the uses that GNU Radio has been put to for these demos, but I also look around and wonder why more people don't use it?

Many demos and researchers at DySPAN are using USRPs, but not necessarily GNU Radio.

In some cases, I think the answer is due to the fact that the demonstrators are using hardware that does not (currently) work with GNU Radio, such as the Rice University WARP board. Fair enough, but of course, I would be very interested in expanding GNU Radio to communicate with the various SDR hardware platforms that are out there.

In other cases, the demonstrators are either using Matlab/Simulink or have built up their own SDR to communicate with the USRP.

I wonder, and really don't know, if this has something to do with the complexity of GNU Radio and a discomfort by developers to using others' software (especially one that isn't fully, or, let's be honest, properly documented). Conversely, USRPs have a single, simple function and are general enough to use for many purposes. This is not to say that USRPs are simple, but that they have a standard, bounded interface and is meant to get bits between a computer and the air. GNU Radio, on the other hand, is more open-ended and therefore complicated to use. Sitting down for the first time in front of GNU Radio and all it is capable of must be a hugely daunting task. Where do you begin and where does it end?

I remember when I was first starting to program more than just basic C++ applications. I would see that there was some library or other that might help me out, but I was too new and inexperienced to grasp how best to use it. Or I would be arrogant enough to think that maybe I could do it better, especially if all I needed was maybe 10% of what the library would offer. Of course, I never came up with anything nearly as efficient, stable, and reusable as the standard solutions out there. It took some time and repeatedly getting my butt kicked before I was able to appreciate and use the solutions others had created for me. This is one thing that makes open source software so fantastic, and it is the same reason why GNU Radio has so many dependencies.

Conversely, the DSA community seems to want to keep reinventing solutions. Every year we see demos that are slightly more polished and maybe a bit more expansive than the previous year's, but we still aren't really seeing huge leaps and bounds in the technology that I think we could and should be seeing. As a community, we aren't seeing people building on each others work. Everything must be new, and so each time, a new research group must build their solutions up from the start. This gets into another issue that I see with the lack of real science going on in this space, but that's another post. Also, I hope that I am not sounding too hard on the demonstrators or their accomplishments. I am trying to suggest how much better we as a community could all be.

Is it an intellectual property issue? I understand that people are are trying to build a product in many cases and that DySPAN is a technology conference and not really a science conference, but are we a little too protective of the work? Especially from the research institutions, where I think we want to encourage dissemination in a way that both protects their claims to the invention, discoveries, and ideas, but also allows others to follow in their footsteps (or to employ an overly-used metaphor: stand on their shoulders).

Is GNU Radio the answer to some of these issues? I know I am biased, but as an open source project with years of work to make a robust and powerful product, it seems like the obvious answer. What are we missing (aside from proper documentation)? How can we do better to serve these fields?

QtGUI updates: new time sink block

I have added a new qtgui_time_sink block (for complex and float) to GNU Radio in the git master repo. This block just displays the time-domain waveform of a set of signals. Most importantly, I think, is that it allows us to connect multiple signals to the sink that will be plotted on the same time axis.

Each signal has a name and dfferent color that is specified in the plot legend. The signals can also have their name changed with set_title(which, name) where which is the index of the signal to be be renamed to name. It also has a set_color(which, color) to set the color of the signals, where color is a string name for a color, which are those available in Qt and can be found in the QColor documentation under "Predefined Colors." These settings can also be adjusted through the Qt signal/slot concept by emiting the signal with the proper values. A pyqt_time_c.py and pyqt_time_f.py examples in the gr-qtgui/apps show both of these concepts and how to attach multiple signals.

This is the first in a series of updates I plan on making to our gr-qtgui interface. I should be able to split out the other components into individual blocks, like the FFT, waterfall, and constellation plotting tools. I should also hopefully be able to improve the efficiency of the system and add more capabilities to these plotters.

 

Change of Time for Developers' Call

Just a quick note that we have decided to change the dates of the GNU Radio developers' calls. We will now have the calls on every third Thursday of the month instead of the third Friday. The time will still be 6 PM EDT. Our next call will occur on Thursday, May 19, 2011.

GNU Radio Developers Conference Calls

I have been meaning to write about this for a while, so I'll just say a few words about it now.

We have been conducting monthly conference calls held on a SIP bridge and over IRC to keep logs and add another layer of contact (there's also the chatbot that helps us out, too, but I'll save that for later). These calls are designed to get the GNU Radio developers and those interested in the project process and progress together on a monthly basis at a set time to discuss the various happenings in GNU Radio. We mostly discuss the code, such as future features and improvements as well as problems and bugs that need to be addressed. I also take the time to think about other issues of GNU Radio in general, such as our web presence and upcoming conference.

I and the others that I have talked to about this have all said that these calls have been really useful to us. From my point of view, it helps me keep my thoughts in order, see where everyone is on various projects and aspects of GR, and to give me perspective on what to focus on. This sappy portion of the blog has been brought to you by my thanks for your participation.

 

Our next call will be held on April 15, 2011. Here are the details:

Agenda:

  • Review of the state of GR 3.4
    • Outstanding issues? Windows, OSX, E100?
    • Volk?
    • Testing/testers
    • Timeline (maybe)
  • GR Conference
    • I will update on recent developments
    • Getting down to the wire to make a few decisions

 

One-step installation script

I have just posted a link on our gnuraido.org Build Guide webpage to a one-step installation script for GNU Radio on Ubuntu and Fedora. The script was built by Marcus Leech and is hosted from his website, so thanks Marcus!

http://gnuradio.org/redmine/wiki/gnuradio/BuildGuide

This scrpt is designd for Fedora and Ubuntu. Specifically, Fedora 12 to 15 and Ubuntu 9.04 to 10.10. I have made it work under Ubuntu 11.04, and expect the script to be udated shortly for that OS version.

Marcus feels, and I concur, that the majority of GNU Radio users use Fedora or Ubuntu, so this script can make it easy for a large portion of our user base to quickly and easily install GNU Radio and all of its dependencies.

New library linking in Linux

It seems like Linux is changing its build policies and forcing us to be more explicit in our linkage. This does not seem to have affected any of the current stable releases of the main Linux distros, but apparently, the next versions of the big ones are going to start enforcing this. This includes  Ubuntu 11.04, Debian 7, and the next releases of Fedora. Others too, probably, if I went and looked.

In the end, I think this is probably a good thing since it forces us to be more explicit about what we link against.

I am currently going through and figuring out the various places that require this fix and trying to think if there is an elegent way to handle this in our build structure. But honestly, and this might just be in light of it being late, I think we just need to make sure that when we create a target program to build, we make sure to iinclude the necessary libraries in LDADD.

For instance, in Gruel we build the program test_gruel, so we set it up as:

   noinst_PROGRAMS = test_gruel

   test_gruel_LDADD = pmt/libpmt-qa.lib libgruel.la

Now, the trick was that libgruel already knew their linkage to the necessary libraries, so we didn't pass these on to test_gruel. Under the new way, we have to specify all of the libraries, and so the LDADD line looks like:

    test_gruel_LDADD = $(BOOST_THREAD_LIB) $(BOOST_SYSTEM_LIB) $(BOOST_FILESYSTEM_LIB) pmt/libpmt-qa.lib libgruel.la

Which allows it to build against these specific Boost libraries (the variables having been set during the configuration process).

This is an overly simplistic explination of what's really happening, but it's the basics of how it is affectig GNU Radio. Here's some more info on the change: http://wiki.debian.org/ToolChain/DSOLinking

State of the Project, 2011

I wanted to update everyone on the current state of GNU Radio in the new year. While we haven't had a new release out for quite a while, we are due for one soon. Over the past many months, a number of bug fixes and enhancements have been finding their way into the source code. These additions will be released shortly in version 3.3.1. 

Aside from these fixes and improvements, we have been working hard on many new features of GNU Radio. Among the latest contributions to the project are:

 

  • UHD: the Ettus Research Universal Hardware Drive that unifies the interface to the Ettus USRP hardware.
  • VOLK: a set of Vector-Optimized Library of Kernels to make use of GPP SIMD instructions that should give a significant boost to the speed and efficiency of GNU Radio.
  • Stream tags: a in-band signalling method for passing information through the flowgraph.

Each of these is a pretty drastic piece of work that will take time to explore and explain. I hope to publish more information in the coming months to help people make use of these features.

But we are still moving forward with a lot of new ideas for the new year. Soon, we will be moving on, which means, first, a release of GNU Radio v3.3.1. We will then be able to focus on the next release of 3.4 to include the components discussed above.

So keep an eye out for announcements as we roll out these features and releases. If you want to keep abreast of everything as it comes out, follow along with the source code in the Git repository.

 

New Format

To help manage the information about the GNU Radio project, we are updating the webpage interface. The new Home will be mainly for major project announcements and updates. The Blog will be dedicated to the more daily activities and work that's going on. If you follow using RSS, please update your feed.