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
Oct092011

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.

 

Sunday
Jul032011

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

 

Friday
Jun102011

GNURadioWaves

I have created a new Twitter acount where I will be posting news, information, and event updates about GNU Radio. So follow along @GNURadioWaves.

Monday
May162011

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.

Wednesday
May112011

Intellectual Property for Dummies... I mean engineers...

I saw this today and it looks interesting (having known of Peren's work, already, too):

http://www.eventbee.com/event?eid=738880394

Too bad I won't be anywhere near Dayton, and $200 isn't a bad price for the amount of time.

As engineers, we really need to be as informed as possible on IP issues, especially with open source projects, and Bruce has done some great work in this kind of education.