USRP1 full C++ API update merged into trunk


#1

As initially discussed here:

http://lists.gnu.org/archive/html/discuss-gnuradio/2008-12/msg00106.html

…the fully native C++ implementation of the USRP API has been merged
into the GNU Radio trunk. This is one of the last items to be completed
for the official 3.2 release.

Prior to this change, most of the USRP and daughterboard configuration
code was written in Python, and thus was only available to use from
Python GNU Radio applications. This update is a rewrite of all of this
code using C++ and puts it in libusrp library, which allows C++ only
applications to use the full capabilities of the USRP hardware. Much of
this work was done by Tom R…

In spite of this significant rewrite, most Python GNU Radio users do not
have to make any changes to their code and should see no difference in
functionality.

The USRP hardware interface is now provided in three ways:

  1. libusrp, which provides the lowest-level communications services over
    USB to the USRP hardware. This is a C++ based read/write raw sample
    interface and does not provide any of the streaming semantics of GNU
    Radio flowgraphs.

  2. libgnuradio-usrp, which provides the GNU Radio C++ signal processing
    blocks for the USRP. This is implemented on top of libusrp and provides
    the streaming interface to the USRP inside GNU Radio.

  3. The python usrp module. This is now only a thin Python wrapper
    around libgnuradio-usrp, and continues to provide the usrp.source_c,
    usrp.sink_c, etc. blocks that most GNU Radio users have already been
    using.

API CHANGES

One goal of this API update was to remain as backward compatible as
possible 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)

UPDATING YOUR GNU RADIO SOFTWARE INSTALLATION

This only applies to people using the GNU Radio trunk software via svn;
this update does not affect release 3.1.x.

As there are many filename changes in both the source tree and installed
file set, you will need to first uninstall your existing GNU Radio
installation, then clean out the build files, before updating your
source code tree:

$ sudo make uninstall
$ make distclean
$ svn update

Then you can proceed with building the new trunk version as usual, per
the instructions for your particular OS/distribution.

This update adds a new compile and runtime dependency. We have already
been using the Boost shared pointer, threading and date/time libraries;
GNU Radio now also uses the Boost program options library. These are
likely already installed if 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 build ‘configure’ step will tell
you if this library is missing. See:

http://gnuradio.org/trac/browser/gnuradio/trunk/README.building-boost

…if you need further instruction on completing this step.

KNOWN ISSUES

As of this merge, there is one known issue that needs to be resolved.
When using the RFX series of USRP daughterboards, sometimes the ‘tune’
command will correctly tune the card, yet report that the tuning has
failed. Ironically, we think this is because the new tuning code is now
faster, and doesn’t wait long enough for the daughterboard PLL to
settle. A fix is being worked on.

Any problem reports may, as usual, be sent to the mailing list or
entered into the bug database for follow up.

Thank you, and Happy Holidays to everyone from the GNU Radio team.

Johnathan C.
Corgan Enterprises LLC


#2

On Wed, Dec 24, 2008 at 3:12 AM, Johnathan C.
removed_email_address@domain.invalid wrote:

  1. libusrp, which provides the lowest-level communications services over
    USB to the USRP hardware. This is a C++ based read/write raw sample
    interface and does not provide any of the streaming semantics of GNU
    Radio flowgraphs.

Do you know if there are any changes in the libusrp api for the 3.2
release?

Philip


#3

On Wed, Dec 24, 2008 at 01:23:47PM -0500, Philip B. wrote:

On Wed, Dec 24, 2008 at 3:12 AM, Johnathan C.
removed_email_address@domain.invalid wrote:

  1. libusrp, which provides the lowest-level communications services over
    USB to the USRP hardware. This is a C++ based read/write raw sample
    interface and does not provide any of the streaming semantics of GNU
    Radio flowgraphs.

Do you know if there are any changes in the libusrp api for the 3.2 release?

The binary is different (there are new functions in the class), but
the old methods have the same calling sequence.

Eric


#4

On Wed, 2008-12-24 at 13:23 -0500, Philip B. wrote:

On Wed, Dec 24, 2008 at 3:12 AM, Johnathan C.
removed_email_address@domain.invalid wrote:

  1. libusrp, which provides the lowest-level communications services over
    USB to the USRP hardware. This is a C++ based read/write raw sample
    interface and does not provide any of the streaming semantics of GNU
    Radio flowgraphs.

Do you know if there are any changes in the libusrp api for the 3.2 release?

To previously existing code? Yes, though relatively minor. Of course,
this last update adds the entire daughterboard control infrastructure,
and some USRP configuration methods that were previously only in Python.

The main difference is that the usrp_standard_* class ‘make’ functions
return a shared pointer rather than a raw pointer. This return type is
typdef’ed, so:

usrp_standard_rx *rx;

…becomes

usrp_standard_rx_sptr rx;

-Johnathan


#5

On Fri, 2008-12-26 at 00:54 -0500, Marcus D. Leech wrote:

But I’m also running into a problem with set_bw() not being recognized
as an attribute of
a USRP object. Did this get missed?

Yep, sure did (at least from the Python API). I’ll fix in the morning.

-Johnathan


#6

On Thu, Dec 25, 2008 at 11:21 PM, Johnathan C.
removed_email_address@domain.invalid wrote:

But I’m also running into a problem with set_bw() not being recognized
as an attribute of
a USRP object. Did this get missed?

Yep, sure did (at least from the Python API). I’ll fix in the morning.

This is done, please update and let me know how it works for you.

-Johnathan


#7

Johnathan C. wrote:

On Wed, 2008-12-24 at 13:23 -0500, Philip B. wrote:

So, usrp_ra_receiver.py fell over due to the removal of _which replaced
by which().

But I’m also running into a problem with set_bw() not being recognized
as an attribute of
a USRP object. Did this get missed?


Marcus L.
Principal Investigator, Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


#8

On Sat, 2008-12-27 at 20:55 -0500, Marcus D. Leech wrote:

I just re-built from the latest trunk SVN (complete re-build, including
complete SVN co), and the usrp objects still
don’t have a set_bw() method in Python.

The set_bw() is a method on the daughterboard, not USRP.

-Johnathan


#9

Johnathan C. wrote:

This is done, please update and let me know how it works for you.

-Johnathan

I just re-built from the latest trunk SVN (complete re-build, including
complete SVN co), and the usrp objects still
don’t have a set_bw() method in Python.


Marcus L.
Principal Investigator, Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


#10

On Sat, 2008-12-27 at 22:01 -0500, Marcus D. Leech wrote:

This code worked as of a couple of weeks ago:

self.subdev[0].set_bw(lbw)

Okay, I’ll dig into it.

-Johnathan


#11

Johnathan C. wrote:

-Johnathan

This code worked as of a couple of weeks ago:

self.subdev[0].set_bw(lbw)

It now provokes:

File
“/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py”,
line 60, in init
self.panel = stdpanel (self, self, top_block_maker)
File
“/usr/local/lib64/python2.5/site-packages/gnuradio/wxgui/stdgui2.py”,
line 81, in init
self.top_block = top_block_maker (frame, self, vbox, sys.argv)
File “/usr/local/bin/usrp_ra_receiver.py”, line 439, in init
self.subdev[0].set_bw(lbw)
AttributeError: ‘db_base_sptr’ object has no attribute ‘set_bw’


Marcus L.
Principal Investigator, Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


#12

On Sat, 2008-12-27 at 22:01 -0500, Marcus D. Leech wrote:

This code worked as of a couple of weeks ago:

self.subdev[0].set_bw(lbw)

It now provokes:
[…]
AttributeError: ‘db_base_sptr’ object has no attribute ‘set_bw’

Just a reminder that when updating using svn from the trunk, one should
run ‘sudo make uninstall’ and ‘make distclean’ from the existing source
code tree first. You can usually get away with not doing this, but
not at the moment. The above problem was caused by stray files left
from a previous installation.

-Johnathan