GNURadio roadmap and master thesis

GNU Radio
#1

http://www.yigg.de/campvids.php?play=21#playbackHi

This is the first time I write to this list so I firstly would like to
express my appreciation for this project providing vast resources in the
wireless field, Thanks!

I am curious about what (and when) to expect from future releases, I
briefly
searched the mail archive for information with no success. The below
link on
the “Presentations” page is unfortuneately broken (GNU Radio & USRP:
Current
Capabilities and Future Directions @ CCCamp 2007)
.http://www.yigg.de/campvids.php?play=21#playback
I am aware of the Roadmap page but I would like to understand priority
of
different things and also status of ongoing work. The company I work for
is
about to sponsor a couple of master thesis based on GNU radio so maybe
we
could help out by testing some features in Beta state? So how do I know
what
and when stuff is available in Beta state?

Best Regards
Mike

#2

On Wed, Dec 3, 2008 at 1:01 AM, Mikael J.
[email protected] 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