Forum: GNU Radio USRP1 full C++ API update merged into trunk

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2008-12-24 09:13
(Received via mailing list)
As initially discussed here:

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

...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 Rondeau.

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/RE...

...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 Corgan
Corgan Enterprises LLC
9c2ab60bcd7045e9acc36aa8074a3336?d=identicon&s=25 Philip Balister (Guest)
on 2008-12-24 19:24
(Received via mailing list)
On Wed, Dec 24, 2008 at 3:12 AM, Johnathan Corgan
<jcorgan@corganenterprises.com> 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
745d8202ef5a58c1058d0e5395a78f9c?d=identicon&s=25 Eric Blossom (Guest)
on 2008-12-24 20:09
(Received via mailing list)
On Wed, Dec 24, 2008 at 01:23:47PM -0500, Philip Balister wrote:
> On Wed, Dec 24, 2008 at 3:12 AM, Johnathan Corgan
> <jcorgan@corganenterprises.com> 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
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2008-12-24 20:25
(Received via mailing list)
On Wed, 2008-12-24 at 13:23 -0500, Philip Balister wrote:
> On Wed, Dec 24, 2008 at 3:12 AM, Johnathan Corgan
> <jcorgan@corganenterprises.com> 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
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2008-12-26 06:55
(Received via mailing list)
Johnathan Corgan wrote:
> On Wed, 2008-12-24 at 13:23 -0500, Philip Balister 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 Leech
Principal Investigator, Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2008-12-26 08:22
(Received via mailing list)
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
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2008-12-26 20:34
(Received via mailing list)
On Thu, Dec 25, 2008 at 11:21 PM, Johnathan Corgan
<jcorgan@corganenterprises.com> 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
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2008-12-28 02:56
(Received via mailing list)
Johnathan Corgan 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 Leech
Principal Investigator, Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2008-12-28 03:00
(Received via mailing list)
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
558c40b97bd1af8d912424757714bda9?d=identicon&s=25 Marcus D. Leech (Guest)
on 2008-12-28 04:02
(Received via mailing list)
Johnathan Corgan 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 Leech
Principal Investigator, Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2008-12-28 04:04
(Received via mailing list)
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
D0072e69d706bb3ca211d33a1b536e2c?d=identicon&s=25 Johnathan Corgan (Guest)
on 2008-12-28 23:58
(Received via mailing list)
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
This topic is locked and can not be replied to.