USRP/gnuradio Issues in OS X

GNU Radio
1

Hi! I’m new to gnuradio, and I just got my USRP several days ago. I’m
trying to use it with my Mac running Snow Leopard, and I’m having some
issues with some of the USRP utilities and examples. I’ve built the
gnuradio software from the head revision in the git repository, with the
pre-requisite libraries supplied by MacPorts.

My USRP hardware appears to be working correctly, since I can run many
of the examples such as usrp_fft.py, usrp_wfm_rcv.py, usrp_nbfm_rcv.py
and usrp_siggen.py, all with reasonable results. Some of the other
examples and utilities aren’t working for me though. In this message
I’ll just focus on two of them: usrper and usrp_benchmark_usb.py.

I’ve tried running the test routine (?), and it fails like this:

~% usrper load_standard_bits
Assertion failed: (ctx != NULL), function usrp_find_device, file
usrp_prims_libusb1.cc, line 184.
Abort
~%

I’ve also tried running the bandwidth benchmark, and it fails like this:

…examples/usrp% ./usrp_benchmark_usb.py
Testing 2MB/sec… usrp: libusb_control_transfer failed: Unknown error
usrp: failed to get hash
usrp: libusb_control_transfer failed: Unknown error
write_internal_ram failed
usrp: failed to load firmware /usr/local/share/usrp/rev4/std.ihx.
Traceback (most recent call last):
File “./usrp_benchmark_usb.py”, line 106, in
main ()
File “./usrp_benchmark_usb.py”, line 96, in main
ok = run_test (rate, verbose)
File “./usrp_benchmark_usb.py”, line 67, in run_test
usrp_rx = usrp.source_s (0, rx_decim, 1, 0x32103210,
usrp.FPGA_MODE_LOOPBACK)
File
“/usr/local/lib/python2.6/site-packages/gnuradio/usrp/usrp_swig.py”,
line 2067, in source_s
return _usrp_swig.source_s(*args, **kwargs)
RuntimeError: can’t open usrp
…examples/usrp%

Some notes on my build environment:

I found that I need to use the native gcc instead of the one provided by
MacPorts in order for gr-audio-osx to build (it can’t find some of the
core audio headers otherwise), and that I need to pass some flags into
configure so that the required libraries and headers are found. Also,
MacPorts installs “libtoolize” as “glibtoolize” to avoid a name
collision with the native Mac “libtool” program, so I created a symbolic
from /usr/local/bin/libtoolize to /opt/local/bin/glibtoolize in order to
get the bootstrap script to run. I configured the gnuradio software this
way:

./configure CC=“/usr/bin/gcc”
CXX=“/usr/bin/g++”
CPPFLAGS=“-I/opt/local/include -I/opt/local/include/qwt
-I/opt/local/include/qwtplot3d”
LDFLAGS=“-L/opt/local/lib -F/opt/local/Library/Frameworks”
–with-fusb-tech=libusb1
–enable-gr-qtgui
–enable-gr-audio-osx

The two --enable* flags probably aren’t strictly necessary, but they are
leftover from when I was finding the pre-requisites for those packages
by trial and error. Everything seems to build OK, and I can use the USRP
with some of the examples. I tried “make check”, and it passes a whole
bunch of tests and then chokes when a test that I haven’t identified yet
complains about failing to connect to a socket. There are other examples
which presently don’t work for me, such as hfx2.py and
usrp_am_mw_rcv.py… I’ll try debugging those some more myself before I
ask about them here.

Have any of y’all seen these kinds of failures before?

Thanks in advance for any hints or suggestions.

–
Mark J. Blair, NF6X [email protected]
Web page: http://www.nf6x.net/
GnuPG public key available from my web page.

2

Hi Mark - I don’t know where to point you exactly, since some tests
work for you while others don’t. You’re using “–with-fusb-
tech=libusb1”, which should work but hasn’t been thoroughly tested (at
least on OSX). Have you tried configuring without this flag & then re-
testing to see what happens? The native FUSB/OSX drivers do use the
“legacy libusb” (as found on MacPorts), but they are well tested &
just as fast as those provided by libusb1. - MLD

3

On Aug 23, 2010, at 11:52 AM, Michael D. wrote:

Hi Mark - I don’t know where to point you exactly, since some tests work for you while others don’t. You’re using “–with-fusb-tech=libusb1”, which should work but hasn’t been thoroughly tested (at least on OSX). Have you tried configuring without this flag & then re-testing to see what happens? The native FUSB/OSX drivers do use the “legacy libusb” (as found on MacPorts), but they are well tested & just as fast as those provided by libusb1. - MLD

I have the [email protected] port installed rather than the
[email protected] port, because (I think) I have other stuff that
wants the newer libusb port. I discovered that I needed to use the
“–with-fusb-tech=libusb1” flag to get the configure script to properly
identify my libusb version. Before I used that flag everything would
compile, but the usrp executables would fail to find a symbol they
needed in libusb and then crash.

–
Mark J. Blair, NF6X [email protected]
Web page: http://www.nf6x.net/
GnuPG public key available from my web page.

4

Hi Mary - So long as you use MacPorts for background dependencies,
libusb1 and libusb-legacy (v0.1.12) can be installed at the same time
& you can easily choose between them (different PKGCONFIG files). Do
note that “libusb-compat” does NOT work with FUSB/Darwin since GNU
Radio’s FUSB/LIBUSB code uses internals that are not in the ‘compat’
version (only the API is compat, not the internal implementation). On
my MacBook Pro (10.5.8, i386), GNU Radio compiles and executes just
fine using libusb-legacy – so, if you’re having issues using it let
me know & I’ll see what I can do to help out. That said, I’ve also
used libusb1 with some success – so, you might have some other issue
(e.g., a bad USB cable). - MLD

5

On Aug 23, 2010, at 12:09 PM, Michael D. wrote:

Hi Mary - So long as you use MacPorts for background dependencies, libusb1 and libusb-legacy (v0.1.12) can be installed at the same time & you can easily choose between them (different PKGCONFIG files). Do note that “libusb-compat” does NOT work with FUSB/Darwin since GNU Radio’s FUSB/LIBUSB code uses internals that are not in the ‘compat’ version (only the API is compat, not the internal implementation). On my MacBook Pro (10.5.8, i386), GNU Radio compiles and executes just fine using libusb-legacy – so, if you’re having issues using it let me know & I’ll see what I can do to help out. That said, I’ve also used libusb1 with some success – so, you might have some other issue (e.g., a bad USB cable). - MLD

I’ll give libusb-legacy a try tonight (I don’t have my USRP with me at
work today). I’m sure I don’t have a cable problem since I can transmit
and receive signals with my USRP. Thanks for the suggestions!

–
Mark J. Blair, NF6X [email protected]
Web page: http://www.nf6x.net/
GnuPG public key available from my web page.

6

So far, the only way I’ve been able to get gnuradio to link against
libusb-legacy has been to uninstall libusb-1.0. Even when I overrode
pkg-config by setting the USB_* variables, it’d still (apparently) link
against libusb-1.0 and then crash at runtime when it couldn’t find the
“_usb_debug” symbol.

Hopefully I’ll be able to find a workaround for this since I’d like to
use some other stuff that requires libusb-1.0, but in the mean time this
seems to have fixed my usrper problem.

I configured this way:

./configure
CC=/usr/bin/gcc
CXX=/usr/bin/g++
LDFLAGS=“-F/opt/local/Library/Frameworks -L/opt/local/lib”
CPPFLAGS=“-I/opt/local/include -I/opt/local/include/qwt
-I/opt/local/include/qwtplot3d”
–with-fusb-tech=darwin

Now usrper appears to be happy:

~/gnuradio% usrper -v load_standard_bits
usrper: found unconfigured usrp; needs firmware.
~/gnuradio% usrper -v get_hash0
hash: ???7???g8!?_Md
~/gnuradio% usrper -v set_hash0 deadbeef
~/gnuradio% usrper -v get_hash0
hash: deadbeef
~/gnuradio%

While I don’t know what any of those usrper commands are actually doing,
at least they seem to be not-crashing!

–
Mark J. Blair, NF6X [email protected]
Web page: http://www.nf6x.net/
GnuPG public key available from my web page.

7

Hi Mark - I’m glad you got it working; if you installed all of the
background dependencies with MacPorts, compiling GNU Radio should be
as simple as:

[fix bootstrap]
./bootstrap
./configure
make
make check
sudo make install

with no other options. IIRC, the 3 primary environment variables you
need to have set are PATH (so that /opt/local/bin comes first),
PYTHONPATH (so that /opt/local/lib/python2.6/site-packages comes
first), and PKG_CONFIG_PATH (so that /opt/local/lib/pkgconfig comes
first). You do not need to set “–with-fusb-tech” at all; it will
auto-detect. You also don’t need to set LDFLAGS as you have.
Further, I don’t think gr-qtgui is working on OSX just yet, so you
really don’t need to set CPPFLAGS either. And, you can have MacPorts
select the CC and CXX for you via “gcc_select” – so those aren’t
necessary.

My question now is whether or not the other tests you talked about
work (e.g., usrp_benchmark_usb.py). If that works, then you’re good
to go & can play around with all the other pieces of GNU Radio &
USRP. But, I’m glad you’ve gotten this far. - MLD

8

On Tue, Aug 24, 2010 at 4:18 PM, Mark J. Blair [email protected] wrote:

~/gnuradio%

While I don’t know what any of those usrper commands are actually doing, at least they seem to be not-crashing!

Good to hear that it’s all working. Unless you’re writing your own
firmware, usrper is usually limited in terms usefulness. If you’re
wondering, the hash commands are used for conditional loading of the
fpga or USB controller.

Thomas

9

On Aug 24, 2010, at 4:58 PM, Michael D. wrote:

Hi Mark - I’m glad you got it working; if you installed all of the background dependencies with MacPorts, compiling GNU Radio should be as simple as:

[fix bootstrap]
./bootstrap
./configure

Should be… but isn’t.

with no other options. IIRC, the 3 primary environment variables you need to have set are PATH (so that /opt/local/bin comes first), PYTHONPATH (so that /opt/local/lib/python2.6/site-packages comes first), and PKG_CONFIG_PATH (so that /opt/local/lib/pkgconfig comes first). You do not need to set “–with-fusb-tech” at all; it will auto-detect. You also don’t need to set LDFLAGS as you have. Further, I don’t think gr-qtgui is working on OSX just yet, so you really don’t need to set CPPFLAGS either. And, you can have MacPorts select the CC and CXX for you via “gcc_select” – so those aren’t necessary.

The --with-fusb-tech probably isn’t necessary for me since I temporarily
uninstalled libusb-1.0, but with that installed I found it to be
necessary to specify --with-fusb-tech=libusb1 to get it to work.
Anyhting else would cause the USRP code to crash when it failed to find
the _usb_debug symbol.

I have /opt/local/lib in my path, but I found it necessary to force the
compilation to use the native compilers in /usr/bin instead in order to
find the Mac frameworks. I chose to do this with the CC and CXX
variables instead of gcc_select in this case.

I modified my site.py file so it wouldn’t be necessary to add that
site-packages directory to my PYTHONPATH.

The CPPFLAGS and LDFLAGS variable settings were necessary to get
gr-qtgui to build, though I don’t know if it actually works yet. In
particular, some of the code included qwt and qwtplot3d headers without
specifying their subdirectories (i.e., <foo.h> vs. <qwt/foo.h>), so I
had to add the -I flags to get them to be found. I also had to add that
-F flag for the linker to find the QtOpenGL framework.

I don’t know if there’s something screwy about my system configuration,
but that’s what I had to do to get things to build and run.

My question now is whether or not the other tests you talked about work (e.g., usrp_benchmark_usb.py). If that works, then you’re good to go & can play around with all the other pieces of GNU Radio & USRP.

Ah, good question. I’ve already been playing with some of the scripts
such as usrp_fft.pw, usrp_siggen.py and a few others, and with grc, but
there have been a bunch of pieces that didn’t work. I’ll try the
benchmark script now that I’ve fixed (?) the USB stuff… Success! It
consistently gives me one USB under-run (I think; it prints “uU”) at the
beginning, but then runs and declares I can get 32MB/sec throughput.

One of the other things that hasn’t been working still isn’t, but I
think it’s an unrelated error. When I run usrp_am_mw_rcv.py it
complains:

RuntimeError: gr_remez: insufficient extremals – cannot continue

But, I’m glad you’ve gotten this far. - MLD

Thanks! I didn’t expect it to be entirely painless (particularly since
I’m running not-Linux here), and I’ll keep plugging along.

–
Mark J. Blair, NF6X [email protected]
Web page: http://www.nf6x.net/
GnuPG public key available from my web page.

10

I just updated to the latest GIT master & indeed “make check” fails in
gr-usrp with the “Symbol not found: _usb_debug” in gr-usrp if MacPorts
‘libusb-compat’ is installed – thanks for the pointer, Mark. I’ll
request in MacPorts that the PKGCONFIG file for ‘libusb-compat’ be
renamed to reflect that (may or not work). And for GNU Radio, I’m
tweaking the config/usrp_libusb.m4 script to also check for the symbol
“_usb_debug” when a legacy library is found (the ‘compat’ version does
not have this symbol). I’ll create a branch for testing later today
if all goes well. - MLD

11

On Aug 25, 2010, at Wednesday|August 25, 2010|11:04 AM, Michael
Dickens wrote:

I just updated to the latest GIT master & indeed “make check” fails
in gr-usrp with the “Symbol not found: _usb_debug” in gr-usrp if
MacPorts ‘libusb-compat’ is installed – thanks for the pointer,
Mark. I’ll request in MacPorts that the PKGCONFIG file for ‘libusb-
compat’ be renamed to reflect that (may or not work). And for GNU
Radio, I’m tweaking the config/usrp_libusb.m4 script to also check
for the symbol “_usb_debug” when a legacy library is found (the
‘compat’ version does not have this symbol). I’ll create a branch
for testing later today if all goes well. - MLD

What we really, really want is a DMG file :wink:

CONFIDENTIALITY: Any information contained in this e-mail (including
attachments) is the property of The State of Texas and unauthorized
disclosure or use is prohibited. Sending, receiving or forwarding of
confidential, proprietary and privileged information is prohibited under
Lamar Policy. If you received this e-mail in error, please notify the
sender and delete this e-mail from your system.

12

On Aug 26, 2010, at 10:25 AM, Michael D. wrote:

On Aug 26, 2010, at 11:12 AM, HR Myler wrote:

What we really, really want is a DMG file :wink:

That would be awesome, and very difficult to create because of the extensive background dependencies of GNU Radio / Companion (even just for gnuradio-core). I did once create a DMG installable .app for Companion which did work. It weighed in at about 1 GB IIRC, because I didn’t pare down the dependencies (configure, build, run) – only the latter is required (those applications and libraries required for execution), but for building purposes one needs the former 2 as well (and, once built they can be removed from the DMG). If any OSX user want a special project, this would be a great one IMHO! - MLD

Michael, I’d suggest it to Elvis, but I don’t know if he is Mac-savvy
enough to pull it off.

Oops, did this just go to the general list?

CONFIDENTIALITY: Any information contained in this e-mail (including
attachments) is the property of The State of Texas and unauthorized
disclosure or use is prohibited. Sending, receiving or forwarding of
confidential, proprietary and privileged information is prohibited under
Lamar Policy. If you received this e-mail in error, please notify the
sender and delete this e-mail from your system.

13

On Aug 26, 2010, at 11:12 AM, HR Myler wrote:

What we really, really want is a DMG file :wink:

That would be awesome, and very difficult to create because of the
extensive background dependencies of GNU Radio / Companion (even just
for gnuradio-core). I did once create a DMG installable .app for
Companion which did work. It weighed in at about 1 GB IIRC, because I
didn’t pare down the dependencies (configure, build, run) – only the
latter is required (those applications and libraries required for
execution), but for building purposes one needs the former 2 as well
(and, once built they can be removed from the DMG). If any OSX user
want a special project, this would be a great one IMHO! - MLD