GNU Radio Release 3.1.0rc0 now available; New Debian package repository

GNU Radio
1

GNU Radio Release 3.1.0rc0 is now available for testing:

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

In addition, binary installation packages now exist for Ubuntu Linux
(Debian soon), eliminating the need to install build tools and compile
GNU Radio from scratch on this platform.

Release 3.1 is the new “stable” branch. Dot releases in this branch
will only contain bug fixes and new functionality; no changes will be
made that will break existing code compiled against any 3.1.x version.

These release candidate tarballs are a snapshot of the current
development trunk, with the experimental and in-development features
removed. The status of this branch is maintained at:

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

As always, it is strongly recommended you completely uninstall any
existing version of GNU Radio prior to installing a new version.

Please test and report your successes and failures on the list or in
Trac. Documentation about the differences between the 3.0 and 3.1
release branches will be added to the release notes as things crisp up.

GNU Radio now has experimental binary and source packages in the Debian
repository format. These allow you to install GNU Radio onto an Ubuntu
Linux or native Debian (soon) distribution without having to
perform a source compilation of the tree. In addition, the system
package manager is able to identify which runtime dependencies are
needed such that these get installed automatically when the GNU Radio
packages are installed.

Currently, binary and source packages are available for the Ubuntu 7.04
(Feisty) Linux distribution, both 32-bit and 64-bit versions. These
packages may work with other Debian derivative operating systems;
however, this is untested. Packages for Debian Etch will be forthcoming
but are not in the repository yet.

Package files have been created for both the 3.1 stable release branch
and the unstable development trunk. The stable packages will only be
updated at each stable “dot” release. Packages from the trunk will be
updated on an irregular basis until we get the package build process
automated.

Documentation on how to install from the new package repository is here:

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

(Note: We are looking for volunteers who are knowledgeable with the RPM
format.)

Enjoy.

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

2

Johnathan C. schrieb:

GNU Radio Release 3.1.0rc0 is now available for testing:

Release 3.1 will include the new hierachical blocks that enable nested
blocks and reconfiguration of flow graphs.

Is this also enabling threads-per-block or some other multitreading?

Patrick

Engineers motto: cheap, good, fast: choose any two
Patrick S.
Student of Telematik, Techn. University Graz, Austria

3

Patrick S. wrote:

Is this also enabling threads-per-block or some other multitreading?

No, the scheduler in 3.1 is the same as 3.0.

However, it already does support a type of multi-threading. If a flow
graph has “islands of connectivity”, the runtime will detect that and
run each of them in a separate thread. For example, a transceiver
application typically has a receive path and transmit path that are not
connected to each other in any way. In this case, a thread will be
allocated for each, and multi-core processors will run them truly in
parallel.

A “thread per block” scheduler was implemented for the mblock/in-band
development on the trunk, but it has some performance limitations due to
excessive thread switching behavior at runtime. When those are solved,
we will unify the scheduler between gr-blocks and mblocks, as part of
the 3.2 release series.

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

4

Hi,

Is there a documentation for these new features found in 3.1 ?

Regards

Firas

Johnathan C.-2 wrote:

Release 3.1 is the new “stable” branch. Dot releases in this branch
existing version of GNU Radio prior to installing a new version.
needed such that these get installed automatically when the GNU Radio
updated at each stable “dot” release. Packages from the trunk will be
Enjoy.
[email protected]
Discuss-gnuradio Info Page

–
View this message in context:
http://www.nabble.com/GNU-Radio-Release-3.1.0rc0-now-available--New-Debian-package-repository-tf4623431.html#a13228048
Sent from the GnuRadio mailing list archive at Nabble.com.

5

Eng. Firas wrote:

Is there a documentation for these new features found in 3.1 ?

Not yet.

Given the full year between 3.0 and 3.1 branches, the differences are
many and varied. Some help in this area would be greatly welcomed.

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

6

Michael D. wrote:

RC0 passes “make distcheck” on PPC and Intel OSX 10.4.10, XCode 2.4.1,
and MacPorts for all of the background apps/libs/includes. I haven’t
tried using it yet. - MLD

Thanks!

I’m not very familiar with MacPorts. What is the pain involved in
getting things into the binary format it uses?

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

7

On Oct 16, 2007, at 1:25 PM, Johnathan C. wrote:

I’m not very familiar with MacPorts. What is the pain involved in
getting things into the binary format it uses?

MacPorts, née DarwinPorts, is a script (acting much like dpkg,
dselect, apt-get, synaptic, and so forth) that downloads the source
code, applies patches, and then configures, builds, and installs the
‘port’. MP is designed to work on Darwin 6 or newer, and OSX 10.3 or
newer (and supports a few BSDs as well). All of this done via
‘portfile’ scripts that describe all of the properties for this
particular ‘port’ (not XML, but still a text file that’s parsed with
keywords and values), such as what other ports this one depends upon,
where to get the source file(s) and patches, version, portfile
revision and help info, shell environment and commands to use to
configure, build, and check the ‘port’, and so forth. Installs
include dependencies, so trying to install wxPython will first
install wxWidgets (if not already installed), Python, and anything
else needed by those.

There is no real pain, usually, since it’s just compiling the
sources. It’s mostly just time waiting around for everything to
compile. Sometimes there are options that are not provided by
default, that have to be added to the portfile … such as: I’m using
Python 2.5 to get SVN/Trac running, but GNU Radio relies on the
Framework install of Python (on OSX only, to get the GUI to display),
which isn’t provided by the portfile. Thus I’ve hacked the portfile
(and submitted the changes back to the MacPorts folks) to get the
framework option to work (and it does, nicely; it’s really a simple
change to the portfile).

Because of the number of ports out there, and the number of
developers trying to keep the ports reasonably up to date, sometimes
conflicts arise between ports. For example not too long ago when
wxWidgets and wxPython were around 2.8.1, one developer updated the
portfile for wxPython before the compatible version of wxWidgets was
available, and thus broke the install for wxPython. This mattered
because there was only 1 portfile for wxWidgets, and another for
wxPython; it is impossible to directly install from a previous
portfile (you can go into their SVN repository, find the older
portfile, download it, put it in the correct location, run
‘portindex’, and then do the install … but that’s somewhat of a PITA).

I have a GNU Radio portfile for 3.0.3, which I will update for 3.1
once it’s released, and make available to anyone who wants it (here
on the list) as well as try to get it added to the MacPorts portfile
list. - MLD

8

Michael D. wrote:

I have a GNU Radio portfile for 3.0.3, which I will update for 3.1 once
it’s released, and make available to anyone who wants it (here on the
list) as well as try to get it added to the MacPorts portfile list. - MLD

I think it would be useful to figure out where this could be put into
both the trunk and the release branch so that it can be maintained via
Subversion. It would then be possible to publish a URL for the port
file on the Trac wiki.

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

9

On Oct 14, 2007, at 5:20 PM, Johnathan C. wrote:

http://gnuradio.org/releases/gnuradio/gnuradio-3.1.0rc0.tar.gz

RC0 passes “make distcheck” on PPC and Intel OSX 10.4.10, XCode
2.4.1, and MacPorts for all of the background apps/libs/includes. I
haven’t tried using it yet. - MLD

10

That would be fine by me. MacPorts maintains their own SVN for this
purpose, but having 2 locations would also work.

I will work on rewriting the portfile to allow installation of
individual modules (as dependencies allow). For example, gnuradio-
core must be installed first and can be its own portfile. gr-audio-
osx would be its own portfile, as would gr-trellis and so forth. I
don’t think this is too difficult, and it would be convenient. Some
parts of Python 2.5 are separated that way (for whatever reason).

11

Michael D. wrote:

I will work on rewriting the portfile to allow installation of
individual modules (as dependencies allow). For example, gnuradio-core
must be installed first and can be its own portfile. gr-audio-osx would
be its own portfile, as would gr-trellis and so forth. I don’t think
this is too difficult, and it would be convenient. Some parts of Python
2.5 are separated that way (for whatever reason).

Granularity is good. I would also recommend having the all-in-one (or
two) that “pulls in” the other parts, for ease of installation.

For example, there are actually 31 Debian packages for the trunk, to
split out the various C++ libraries, C++ development headers, Python
components, documentation, examples, FPGA firmware, and complete
applications. Yet there are three meta-packages that will pull-in
(almost) the entire set: ‘gnuradio’, ‘usrp’, and ‘gnuradio-dev’.

Now Debian (and derivatives like Ubuntu) has a very finely grained and
pedantic packaging policy that drives this. The customs and conventions
of OS/X are unfamiliar to me and I don’t know what developers expect.

We can incorporate a directory somewhere in the tree to hold your
collection of portfiles. If you do this for the trunk, we can backport
the changes needed for the 3.1 release branch, ideally during the
release candidate series instead of after the release.

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

12

Oh, and one more question: I noticed a new dependency on numpy. I have
lost track of this issue, is Numeric now no longer required?

Thanks,
Jan

13

rc0 passes make distcheck here:
Linux localhost 2.6.19-gentoo-r5 #1 SMP Tue Feb 27 21:16:23 PST 2007
x86_64 Intel® Core™2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux

Revalidated that ticket 169 is fixed, passes…

I tried the usrp_wfm_rcv.py as a quick sanity check an that works fine,
too.

Are there any more recommendations as fas as “system test” goes? Is
usrp_wfm_rcv.py a good one to use, or are there examples that exercise
more of the system?

Cheers,
Jan

14

On Sun, Oct 21, 2007 at 01:16:00PM -0700, Jan S. wrote:

Oh, and one more question: I noticed a new dependency on numpy. I have
lost track of this issue, is Numeric now no longer required?

Thanks,
Jan

Correct. The Numeric dependency has been replace by a numpy dependency.

Eric