Call for testers: USRP1 and daughterboard API update

As part of an overall transition to make the use of Python optional for
Radio application development, we are “pushing down” into C++ the API
those things that were previously only possible from Python. One of
areas is the USRP1 operation and daughterboard control. With this
development, it is now possible to write C++ only GNU Radio applications
that use the USRP1 without hacking one’s own daughterboard interface

However, since access from Python is still needed for Python users, the
Python API for the USRP has been re-created using the SWIG wrapper
generator, in the same way we do this for the rest of the GNU Radio C++
API. This has necessitated a couple very minor changes (see below) to
user’s Python code.

When this code is merged into the development trunk, it will replace the
entire USRP Python API. As such, it is critical that this get
testing on all the platforms that GNU Radio supports.


The testing feature branch may be checked out from:

Building this branch follows the same process as building the GNU Radio
trunk, with some caveats:

  • Do not try to install this “over” an existing GNU Radio installation.
    you have compiled the GNU Radio trunk or official release from an svn
    checkout or tarball, and still have the source tree, perform a “sudo
    uninstall” to remove the system installation before building the test
    branch. If you have installed from binary packages, uninstall these
    your package manager. The key is to ensure all of an existing GNU Radio
    removed from the system directories. If you know what you are doing, it
    possible to maintain multiple installations of GNU Radio using
    variables and/or symlinks; this would continue to work for this testing

  • The test branch adds a new dependency. We are already using the Boost
    shared pointer, threading and date/time libraries; this branch also now
    the Boost program options library. These are likely already installed
    you have Boost supplied by your OS distribution. If you had to compile
    Boost from scratch, you will need recompile and reinstall, adding
    ‘program_options’ to the list of libraries to install. The GNU Radio
    ‘configure’ step will tell you if this library is missing.


One goal of this API update was to remain as backward compatible as
with existing code users have written. Unfortunately, because of slight
incompatibilities, two functions have changed.

The way to obtain a daughterboard instance subdevice number has been to
reference the _which instance variable. This has changed to a function
call. This is mostly commonly seen in this snippet of code:

tr = usrp.tune(self.subdev._which, self.subdev, target_freq)

…which is now:

tr = usrp.tune(self.subdev.which(), self.subdev, target_freq)

The other change has been to the installed daughterboard instance array,
which can be but isn’t normally accessed by user code:

u = usrp.source_c()
subdev = u.db[0, 0]

…now also becomes a function call:

subdev = u.db(0, 0)

The few occasions where these changes are needed in the GNU Radio
directory have already been changed on the branch, and testers may need
modify their code to accommodate.


First and foremost is to make sure we haven’t broken anything. This
both to daughterboard operation (tuning, gain, etc.) and API
So please run all your usual USRP Python code and examples to make sure
all works the same.

Secondly, there are two new C++ applications which mirror the
and Python applications. These do not get installed,
may be found in the source tree after compilation at:

These are examples of how to write C++ only applications in GNU Radio,
operate in a similar fashion to their Python counterparts. One
is that we haven’t implemented the SI unit command line parsing yet, so
instead of something like ‘-f 16M’ you’ll need to put ‘-f 16e6’.

Finally, the new daughterboard API has actually been pushed all the way
into the non-GNU Radio libusrp library. So anyone using this library
USRP use can try out the new daughterboard code instead of what they
themselves have hacked togther.


Success reports should be posted to the list. Expect lots of bugs,
especially in the beginning. If you run into difficulties, please post
on the list first, and include details about your setup and relevant
If it is a bonafide new bug and we don’t fix it immediately, feel free
create a new ticket in the bug system:

You will need to login to do so. The user name is ‘guest’, the password

This is one of the few remaining items pending for the official 3.2
release. Your help in shaking this feature out will be greatly

Johnathan C.
Corgan Enterprises LLC

A question out of curiosity: you write “non-GNU Radio libusrp library”.
library is built when I download and compile the trunk. Isn’t it a part
GNU Radio ? Does python applications use this library ?

I am looking forward to test when my schedule allows!


On Mon, Dec 8, 2008 at 1:48 AM, Per Z.
[email protected] wrote:

A question out of curiosity: you write “non-GNU Radio libusrp library”. This
library is built when I download and compile the trunk. Isn’t it a part of
GNU Radio ? Does python applications use this library ?

To clarify, it would have been more accurate to say “non-GNU Radio
framework”. Both the USRP and USRP2 have low-level C++ libraries
(libusrp and libusrp2) which provide the lowest level communications
to the hardware. These provide a generic read/write API and don’t use
the GNU Radio runtime themselves. Some people have written
applications which only use this interface.

The GNU Radio source and sink blocks for the USRP and USRP2 (in
gr-usrp and gr-usrp2) are wrappers around this low-level interface and
provide the high-level streaming GNU Radio flowgraph semantics for C++
and Python GNU Radio applications.

Currently, much of the auxiliary USRP configuration and all of the
daughterboard handling code is written in Python, and thus can only be
used from Python. The new API code in cppdb-test rewrites all this in
C++ and puts it in libusrp. Thus, now C+±only GNU Radio applications
and libusrp-only applications can also use the full range of USRP

Our eventual goal is to have 100% of the GNU Radio feature set
available in C++, with the Python API being a pure wrapper around it.
We’re nearly there; the USRP daughterboard handling was the largest
chunk of what is left.


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