Forum: GNU Radio GNURadio roadmap and master thesis

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
E5c15853127fadbda6c0908608973345?d=identicon&s=25 Mikael Johansson (Guest)
on 2008-12-03 10:02
(Received via mailing list)

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
searched the mail archive for information with no success. The below
link on
the "Presentations" page is unfortuneately broken (GNU Radio & USRP:
Capabilities and Future Directions @ CCCamp 2007)
I am aware of the Roadmap page but I would like to understand priority
different things and also status of ongoing work. The company I work for
about to sponsor a couple of master thesis based on GNU radio so maybe
could help out by testing some features in Beta state? So how do I know
and when stuff is available in Beta state?

Best Regards
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2008-12-04 20:03
(Received via mailing list)
On Wed, Dec 3, 2008 at 1:01 AM, Mikael Johansson
<> 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

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

- 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.

This topic is locked and can not be replied to.