[Discuss-gnuradio] GNU Radio 2.x now available for testing!

[Eric Blossom]

Hi Folks,

At long last I've cut a set of tarballs for GNU Radio 2.x.

The code is now broken into multiple tarballs to split out the
hardware dependent pieces of code, and to make it easier to add new
signal processing modules or hardware support without having to mess
with the main library.

We're still lacking an intro, but the README is attached, and online
docs can be browsed at http://www.gnu.org/software/gnuradio/doc/index.html
See also http://comsec.com/wiki?GnuRadio2.X


There are currently 6 tarballs available:

    gnuradio-core-2.0-doc.tar.gz        online docs
    gnuradio-core-2.0.tar.gz            the main library
    gnuradio-examples-0.1.tar.gz        examples
    gr-audio-oss-0.1.tar.gz             sound card support via OSS
    usrp-0.4.tar.gz                     Universal s/w radio peripheral
    gr-usrp-0.1.tar.gz                  Glue to connect USRP to GNU Radio

You can find them at

    ftp://alpha.gnu.org/pub/gnu/gnuradio


This release is still missing some things, but I thought it was time
to get something out so others can start working on it.  We're
currently missing:

  * Lots of simple blocks, sources and sinks.

    These would be great starting places for folks who want to help
    out.  They don't require any signal processing background, just
    a basic grip on C++.

    At a start we need:

       gr_float_to_short        (1 float in, 1 short out [saturate])
       gr_short_to_float        (1 short in, 1 float out)
       gr_float_to_complex      (1 or 2 floats in, 1 complex out)
       gr_complex_to_float      (1 complex in, 1 or 2 floats out)
       gr_complex_to_real       (1 complex in, 1 float out)
       gr_complex_to_imag       (1 complex in, 1 float out)
       gr_complex_to_mag        (1 complex in, 1 float out)
       gr_complex_to_arg        (1 complex in, 1 float out)

       gr_tcp_{source,sink}     Look at gr_file_{source,sink} and 0.9 code base
       gr_file_descriptor_{source,sink}  


  * audio support using ALSA and whatever it's called on OS/X.

    For either, make a copy of the gr-audio-oss tarball, then
    s/oss/alsa/g or s/oss/osx/g and you've got a good framework.
    The main code base already tries to dynamically load these, but of
    course doesn't find them since they're not written.

  * GUI support.

    We could use the same "writing into pipes" strategy that
    was used in 0.9, but I think a simple shared memory buffer
    between the C++ side and python with suitable mutex would be
    easier and more portable to non-POSIX platforms.  This would
    entail creating the appropriate sink on the C++ side and the right
    glue for python.

    In general, we could really use somebody who is either up to speed
    on wxWindows (now call wxWidgets) / wxPython, or is interested in
    getting up to speed.  The 0.9 wxPython graphing sinks had pretty
    poor performance.  There's no need for them to be slow, the signal
    processing isn't the hang up, it's the glue.

  * usrp rev 0 support (straight forward)

  * mc4020 support (semi hairy)

  * port ATSC code to 2.x (mostly straight forward)



I'm sure we'll have some build problems.  Send reports and preferably
fixes to the list.  We've tested on Mandrake 9.2 and Fedora Core 2.

I'll issue releases frequently until it settles down.

Let the fun begin!

FYI, I'm going to be offline Tuesday to Thursday.

Eric


----------------------------------------------------------------
#
# Copyright 2001,2002,2003,2004 Free Software Foundation, Inc.
# 
# This file is part of GNU Radio
# 
# GNU Radio is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
# 
# GNU Radio is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
# 
# You should have received a copy of the GNU General Public License
# along with GNU Radio; see the file COPYING.  If not, write to
# the Free Software Foundation, Inc., 59 Temple Place - Suite 330,
# Boston, MA 02111-1307, USA.
# 

-------------------------------------------------------------------------------

                                IMPORTANT

-------------------------------------------------------------------------------

GNU Radio is now broken up into several packages.  You're looking at
the gnuradio-core.  You'll probably want some or all of these too.
Build and install them in the order listed here:

  gnuradio-core     # main library
  gr-audio-oss      # support for sounds cards using OSS
  usrp              # non-GNU Radio specific portion of usrp
  gr-usrp           # glues usrp into GNU Radio
  gnuradio-examples # examples


----------------------------------------------------------------


Prerequisites (you may already have these):

(1)  pkgconfig 0.15.0 or later  http://www.freedesktop.org/Software/pkgconfig

>From the web site:

pkgconfig is a system for managing library compile/link flags that
works with automake and autoconf. It replaces the ubiquitous *-config
scripts you may have seen with a single tool.


(2)  FFTW 3.0 or later        http://www.fftw.org

IMPORTANT!!!  When building FFTW, you MUST use the --enable-single and
--enable-shared configure options.  This builds the single precision
floating point version which we use.  You should also use either the
--enable-3dnow or --enable-sse options if your on an Athlon or Pentium
respectively.


(3) Python 2.3 or later       http://www.python.org

Python 2.3 or later is now required.  If your distribution splits
python into a bunch of separate RPMS including python-devel or
libpython you'll most likely need those too.


(4) The Boost C++ Libraries     http://www.boost.org

We use the Smart Pointer library.  Fedore Core 2 has a package for
this, boost-devel-1.31.0-7.  Otherwise download the source and follow
the build instructions.  They're a bit different from the normal
./configure && make


(5) cppunit 1.9.14 or later.    http://cppunit.sourceforge.net

Unit testing framework for C++.

----------------------------------------------------------------

For the impatient, just do the following:

        $ ./configure
        $ make
        $ make check
        $ make install

If it doesn't work, fix it and send us a patch...


See http://www.gnu.org/software/gnuradio/ for an overview.
The project is hosted at http://savannah.gnu.org/projects/gnuradio/


If you've got doxygen installed, the build process creates
documentation for the class hierarchy etc.  Point your browser at
.../doc/html/index.html  If you've got the graphviz "dot" tool, it
generates extremely cool looking collaboration diagrams


To run the examples you'll need to set PYTHONPATH.

  $ export PYTHONPATH=/usr/local/lib/python2.3/site-packages

You may want to add this to your ~/.bash_profile



----------------------------------------------------------------

    Notes on building GNU Radio from the CVS repository

----------------------------------------------------------------

If you're building from the CVS repository YOU MUST BE PLAYING BY THE
RULES THAT THE OTHER DEVELOPERS ARE USING.  This is especially true
with regard to the versions of the tools below...

Ensure that you've got THESE VERSIONS of the following tools:

       autoconf 2.57    or later
       automake 1.7.4   or later
       libtool  1.5     or later
       swig     1.3.21  or later

If you're using earlier versions than these, don't expect the system
to build.  Get these versions or something later.  They're available
at any of the GNU mirrors.

Then, check out a copy of GNU Radio.  

See http://www.gnu.org/software/gnuradio for directions on anonymous
access to the CVS repository.

Then in the top level directory, execute

     $ ./bootstrap

This builds configure from configure.ac and also builds all the
Makefile.in's from the Makefile.am's.

Then ./configure adding the  --enable-maintainer-mode flag.
This enables the maintainer rules in the Makefiles that allow for the
regeneration of Makefile.in's from Makefile.am's.

FYI, in the tarballs that we distribute, these rules are turned off to
ensure that end users don't need the versions of the auto tools that
we're using.  We generate the Makefile.in's from the Makefile.am's
when we build the tarball, and include them in the distribution.  This
generally causes less pain, since they aren't likely to be wanting to
modify Makefile.am's.  Since you want to build from the CVS
repository, (or modify Makefile.am's) you need to be operating with
the tools we're using.

     $ ./bootstrap
     $ ./configure --enable-maintainer-mode
     $ make
     $ make check
     $ su
     # make install



Another handy trick if for example your fftw includes and libs are
installed in, say ~/local/include and ~/local/lib, instead of
/usr/local is this:

    $ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/local/lib
    $ make CPPFLAGS="-I$HOME/local/include"