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

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.

There's been an expressed desire for better control over the latency of a GNU Radio flowgraph. We have added this capability as of version 3.5.1. Now, when you call tb.start() or tb.run(), these functions take a parameter that specifies the maximum noutput_items a block can ever receive. This means that the most latency you'll see in a block is based off this number.

If you don't change anything in any existing applications, nothing will change as the default is a huge number that no block will ever be asked to process.

Also, for running wxGUI applications, you set this value when create the stdgui2.stdapp as the last parameter called max_noutput_items like in the uhd_fft.py app:

app = stdgui2.stdapp(app_top_block, "UHD FFT", nstatus=1, max_noutput_items=8000)

Right now, this method exerts global control over the flow graph. In the future, if this global control isn't quite enough, we can look into adding a set function to the gr_block class to allow us to set a max noutput_items value for each block that would supersede the global value.

We are really interested to hear feedback from our users who have been requesting this kind of control over latency.

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.

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.

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.