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.

Sunday
May082011

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?

Sunday
Apr242011

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.

 

Sunday
Apr242011

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.

Thursday
Apr142011

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

 

Saturday
Apr092011

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.