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:
-
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, -
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 R. 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 C.
Corgan Labs