[Discuss-gnuradio] Update on 'next' branch and 3.7 release

[Johnathan Corgan]

tl;dr - This is an update on the status of development work on the GNU Radio repository 'next' branch that will eventually become the 3.7.0 release, and a call for testers.

As a reminder, the new 3.7 API release is primarily a code reorganization and clean up, to accomplish two goals:


1) To remove the gnuradio-core top-level component that has accumulated hundreds of blocks, distribute those blocks into several new top-level components grouped by function, and create a lean, gnuradio-runtime component that has the least possible code and dependencies needed to perform the work of the GNU Radio scheduler and flowgraph management, and,


2) To rewrite GNU Radio blocks using pure virtual interface classes, following the "private implementation" pattern, clean up header file documentation, ensure consistency in directory location/layout among components, correct areas where coding guidelines have not been followed, and in general, try to make the GNU Radio source code tree more readable and understandable. A wiki page that describes the new code organization is here:


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

The overall method to accomplish 1) has been to create new top-level components, organized like 2), on the master branch (and released as part of 3.6.x), which duplicate the blocks in gnuradio-core, merge these up to the next branch, then remove the old-style blocks from gnuradio-core on the next branch.  This allows users to start migrating their code to use the new blocks now.  To this end, the following new top-level components have been created on master (some of these have been there for a while):


gr-blocks (non-signal processing blocks)
gr-analog (blocks typically used for analog waveforms)
gr-digital (blocks typically used for digital waveforms)
gr-fft (blocks implementing Fast Fourier transforms)


gr-filter (blocks implementing FIR, IIR, and related functions)
gr-wavelet (blocks implementing wavelet transforms)

On the next branch, the blocks that have been reimplemented in the above new components have already been removed from gnuradio-core.  In addition, two new (mostly empty) components have been created as placeholders for future, planned work:


gr-channels
gr-fec

Though there are still blocks to migrate out of gnuradio-core, the bulk of this work is done.  The main task remaining for 1) is the implementation of the new gnuradio-runtime, which is in progress.


So, we are calling for more testers to check out, compile, and do testing of the next branch.  Normally, work done on the master branch gets a lot of exposure, as it is what we make our stable releases from, but there is less testing of the next branch.  While the QA unit testing code passes, it is the Python and GRC examples which tend to show up issues that aren't part of the unit testing suite.


This leaves the conversion of blocks for 2) above in the top-level components outside of gnuradio-core.

Already completed:

gr-fcd (blocks for interfacing with the FunCUBE dongle hardware)
gr-video-sdl (blocks for interfacing with the libsdl video library)

gr-trellis (blocks for trellis-coded demodulation)
gr-utils (misc. utils for working with GNU Radio data files)

Not yet started:

gr-atsc (blocks for ATSC digital TV demodulation)
gr-audio (blocks for receiving and generating audio)


gr-comedi (blocks for interfacing with the libcomedi hardware library)
gr-noaa (blocks for demodulating NOAA satellite protocols)
gr-pager (blocks for demodulating FLEX pager protocols)
gr-qtgui (blocks for creating QT-based display objects)


gr-shd (blocks for interfacing with Symplex Communications SHD devices)
gr-uhd (blocks for interfacing with Ettus Research USRP devices)
gr-vocoder (blocks implementing a variety of voice codecs)
gr-wxgui (blocks for creating wxPython-based display objects)

This is a relatively small number of blocks (compared to the hundreds already converted from gnuradio-core), but must be done on the next branch, as the changes must happen in-place and would break user's existing code compiled against the master branch.  

There are other new features that have been implemented on the next branch that will be part of the 3.7, including some of the work done at HackFest 2012, which we'll be documenting as part of the overall release notes for 3.7.0.

Please, feel free to ask any questions and Tom or I will be happy to answer them.

Thank you,

Johnathan Corgan
Corgan Labs