Home

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:

git://github.com/trondeau/gnuradio.git

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 192.168.1.1 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:

/grcon2012-student-travel/

 

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

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

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

Johnathan

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.

 

Two Releases in One Month!

We've been busy producing a lot of new material for GNU Radio. We've fixed a number of bugs, improved the code, added a few new features (like support for the FunCube Dongle). Since the last news update here, we've released 3.5.2 (and a bug release of 3.5.2.1) and just yesterday released 3.5.3.

Here's the email to the GNU Radio Mailing List from Johnathan Corgan about the release:

GNU Radio release version 3.5.3 is now available for download:

http://gnuradio.org/redmine/attachments/download/320/gnuradio-3.5.3.tar.gz
http://gnuradio.org/redmine/attachments/download/321/gr-howto-write-a-block-3.5.3.tar.gz

The release notes are here:

http://gnuradio.org/redmine/projects/gnuradio/wiki/ChangeLogV3_5_3

This is the last planned 3.5 API compatible release; there may be bug
fix releases along 3.5.3.x, but no new 3.5.4 release is planned.  Work
on the master branch will be focused on generating a 3.6.0 release.

Contributors this release:

Achilleas Anastasopoulos
Alexandru Csete
Ben Reynwar
Dimitri Stolnikov
Johnathan Corgan
Josh Blum
Michael Dickens
Nicholas Corgan
Philip Balister
Tom Rondeau

Enjoy!

We're on the path for a 3.6.0 release shortly where we'll be going full cmake build.

 

GNU Radio 3.5.1 Released

Version 3.5.1 of GNU Radio has recently been released. The download can be found here:

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

The release includes the following:

 

  • Added new SNR estimators to gr-digital; both a probe (sink) and an inline block that copies input to output and sends tags with SNR.
  • Ability to set an upper limit on the noutput_items blocks receive. Allows control over latency.
  • Cmake build enhancements and bug fixes.
  • Support for different over-the-wire data types in UHD.
  • Python GIL fix for gr_bin_statistics.
  • Doxygen documentation bug fixes and enhancements.
  • Added more get/set functions for various blocks (digital_fll_band_edge, gr_noise_source, gr_channel_model).
  • General bug fixes.

 

 

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