On Wed, Dec 3, 2008 at 1:01 AM, Mikael Johansson <[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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
