Re: [Discuss-gnuradio] GNURadio roadmap and master thesis

[Johnathan Corgan]

On Wed, Dec 3, 2008 at 1:01 AM, Mikael Johansson
<address@hidden> wrote:

> I am curious about what (and when) to expect from future releases.

As is the case with most open source development projects, the feature
set tends grow "organically" rather than by strict adherence to any
sort of long-term roadmap.  This is primarily because most of the
software (and documentation) gets written by volunteers and
contributed to the project, as distinct from a paid development team
working to a schedule and set of release requirements.

That isn't to say that Eric and I don't have long term plans or that
there isn't a coherent architecture that we have in mind.  Indeed,
some have argued that we have been too strict in accepting
contributions or that we've set the bar too high for developers to
push code into the official release tree.

The last year has been a period of intense development by a number of
individuals and groups that is finally coalescing into a stable 3.2
release.  Among much else, the delta between release 3.2 and 3.1 will
include:

- A switch from a single threaded scheduler to a thread-per-block
scheduler capable of scaling with multi-core and multi-processor
systems

- Support for all C++ applications without the need for Python,
including full support for the USRP/USRP2 in this mode

- A port to support the Cell Broadband Engine processor

- The addition of the GNU Radio Companion, a graphical editor for
building and executing GNU Radio flowgraphs

- An OFDM modulation and demodulation system suitable for packetized
transmission systems

- OpenGL acceleration of the graphical display sinks

- Initial introduction of USRP2 hardware support

All the above has already been available for use as part of the
"development trunk" as it gets developed, so in one sense the 3.2
release is really just a coherent snapshot in time that will be
maintained with bug fixes and API compatibility through the release
series.  Also not captured in the above list are the numerous
additions to the core set of DSP blocks.

There have been a few features that are "on deck" but not quite yet
ready; these will likely show up in the 3.2.x official releases:

- Formal introduction of the 'mblock' concept.  This implements an
event-based block system that greatly simplifies working with
packetized data in the GNU Radio environment.  While the basic mblock
library has existed for quite some time, a satisfactory bridge between
the continuously streaming gr-block domain and event-driven mblock
domain has not been developed, making this overall feature set of
limited appeal and use.  We have been experimenting with an
alternative design that adds event-driven message ports to the
existing gr-block design instead.

- "In-band" signaling for the USRP1 and USRP2.  This supports timed
transmission and reception of samples, as an alternative to the
streaming mode that exists now.  Most of this already exists for USRP1
in the mblock environment, but similarly to the above, is difficult to
integrate with existing GNU Radio blocks.  The low-level C++ API for
the USRP2 hardware already supports timed transmission and reception,
but needs the same support in GNU Radio itself.

- A full set of C++-only programming examples.  The primary thing
lacking here is modification to the GNU Radio build system to support
more granular component dependency checking.

More features are in development, but we tend not to discuss them
publicly until we can actually show some working code that people can
try for themselves.

-Johnathan