GNU Radio 3.1.0 Release Tarballs Available

GNU Radio stable release 3.1.0 is now available for download:

http://gnuradio.org/releases/gnuradio/gnuradio-3.1.0.tar.gz
http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.1.0.tar.gz

Binary installation packages for Ubuntu 32-bit and 64-bit systems are
documented at:

http://gnuradio.org/trac/wiki/DebianPackages

Release 3.1.0 is based on a snapshot of the current development trunk,
with a few incomplete or buggy portions removed. Changes on this stable
branch are documented at:

http://gnuradio.org/trac/wiki/Release3.1Branch

If you want to check out a Subversion branch that only includes updates
along this series, use:

$ svn co http://gnuradio.org/svn/gnuradio/branches/releases/3.1

While 3.1.0 is based on the current development trunk that many are
familiar with, it has been a full year since the last stable branch was
cleaved from the trunk. The changes between then and now are many and
varied; here are some highlights:

  • New hierarchical flow graph code, allowing arbitrarily nested
    flow graphs and runtime flow graph reconfiguration (gr.top_block,
    gr.hier_block2). All the gnuradio-examples programs have been ported to
    this new way of doing things, to illustrate the differences in syntax.
    (The stable branch, however, also maintains the existing gr.flow_graph()
    based API.)

  • New top-level components

    • gr-atsc (ATSC TV receiver, not real-time)
    • gr-comedi (drivers for Linux Control and Measurement Interfaces)
    • gr-pager (Wideband multi-channel FLEX pager receiver/decoder)
    • gr-radar-mono (Monostatic Active Radar with up to 32 MHz LFM chirps)
    • gr-sounder (Channel sounder for up to 32 MHz wide passband channels)
    • gr-utils (Commonly used USRP and other scripts moved from examples)
  • Streamlined build and installation

    • Binary packaging for Debian/Ubuntu and similar systems
    • Reduced memory footprint for compilation
  • Many, many bug fixes and updates all over the tree (documentation
    volunteers welcomed…)

This new stable branch will be maintained such that existing Python and
C++ code based upon it will not break due to updates in the series. New
releases in this series will have backported bug fixes and new features
added. However, no changes will be made that (intentionally!) result in
existing user code not functioning.

If it sounds like this means we will be making such changes on the
trunk, you are absolutely right. Several features targeted for the 3.2
stable branch will require deep surgery and will break user code that
doesn’t keep up:

  • Removal of gr.flow_graph(), leaving only gr.top_block() added in 3.1
  • Removal of gr.hier_block(), leaving only gr.hier_block2() added in 3.1
  • In-band signaling for USRP communications
  • M-blocks, a new message/packet-oriented hierarchical flow model
  • Pure C++ GNU Radio applications, with no Python involved
  • Scheduler changes to better scale to multi-core CPUs

Install and develop for the 3.1 stable branch if you want to avoid any
issues, or work off the trunk and enjoy the ride.


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com

Johnathan C. wrote:

GNU Radio stable release 3.1.0 is now available for download:

The official signed tarballs are now up at gnu.org:

ftp://ftp.gnu.org/gnu/gnuradio/gnuradio-3.1.0.tar.gz
ftp://ftp.gnu.org/gnu/gnuradio/gr-howto-write-a-block-3.1.0.tar.gz


Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com

On Mon, Oct 22, 2007 at 07:05:43PM -0700, Johnathan C. wrote:

GNU Radio stable release 3.1.0 is now available for download:

To emphasize what Johnathan already said:

  • Removal of gr.flow_graph(), leaving only gr.top_block() added in 3.1
  • Removal of gr.hier_block(), leaving only gr.hier_block2() added in 3.1

Install and develop for the 3.1 stable branch if you want to avoid any
issues, or work off the trunk and enjoy the ride.

We’ll probably start tearing the old flow graph code out of the trunk
in the next 24 hours or so.

FAQ: Why are you doing this?

Answer: the 3.1 stable branch contains two parallel implementations of
more or less the same functionality. The old one is Python and C++,
the new one is pure C++. They do not build on a common core (except
at the very bottom). We want to move forward with the Cell port, a
new “thread-per-block” scheduler (SMP/SMT goodness) and gluing mblocks
and gr_blocks together. Ripping out the old code “clears the decks”
for the new development. The new stuff will support Python + C++
(like we do now), but will also enable all C++ development.

We don’t intend to change the interface to the new
top_block/hier_block2 code, so if you’ve already converted your code
to use that, the trunk should remain a safe place for development.

If you’re tracking the trunk, and have code that hasn’t already been
converted to top_block/hier_block2 you’ll probably want to consider
tracking the 3.1 stable branch instead of the trunk.
(See http://gnuradio.org/trac/wiki/BuildGuide for svn instructions)

Eric

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs