UHD Driver in E100/Beagleboard

GNU Radio
1

I was wondering about people’s experience with the UHD driver on the
E100 or the Beagleboard. I am able to use it to receive IQ data from
the USRP but I can’t seem to transmit anything from it … if I take the
same flowgraph to a laptop I’m able to transmit IQ using the same
USRP/daughterboard and the UHD driver however when I try to run the same
transmitter on the Beagleboard and I check my spectrum analyzer I don’t
see anything

I already did a signal capture before sending to the USRP and made sure
that there is data getting pushed through … is there a problem with
UHD/USRP sinking on the E100 and the Beagleboard ??? I also made sure
that I’m using the latest UHD firmware on the beagleboard.

The following is the version info printed when I run the flowgraph:
linux; GNU C++ version 4.5.3 20110214 (prerelease); Boost_104500;
UHD_0001.20110224034946.1

thanks

al fayez

2

I cannot comment on the Beagleboard, but using UHD on the E100 works
great for me. I have been using it reliably for the last few weeks.
I haven’t rebuilt UHD in probably a week and a half or so, but I was
planning on doing that in the next couple of days using the next
branch.

I’ll let you know if I run into issues, but right now everything is
smooth sailing.

Cheers,
Ben

3

Hrm, I just realized that I should clarify something:

I can use UHD + E100 no problem. I have not tested UHD + GNURadio +
E100 recently.

Sorry for the confusion!

Cheers,
Ben

4

I have been using the E100 for about two weeks and have no problems. I
have built various GNU Radio Companion projects (text mode no wxgui) and
they run fine. Are you trying to be too ambitious with your transmitted
bandwidth?

The benchmark tests on mine indicate a maximum of 2.4Msps or
thereabouts.

I have the following UHD version:
root@usrp-e1xx:~# uhd_find_devices
linux; GNU C++ version 4.5.2 20101204 (prerelease); Boost_104100;
UHD_0001.20101214211912.1

Cheers,

Ingmar

5

On 02/23/2011 11:25 PM, Almohanad F. wrote:

I was wondering about people’s experience with the UHD driver on the E100 or the
Beagleboard. I am able to use it to receive IQ data from the USRP but I can’t
seem to transmit anything from it … if I take the same flowgraph to a laptop I’m
able to transmit IQ using the same USRP/daughterboard and the UHD driver however
when I try to run the same transmitter on the Beagleboard and I check my spectrum
analyzer I don’t see anything

Data comes out of the E100 fine, I assume you have a USRP1 attached to a
beagle via USB?

Philip

6

On 02/23/2011 11:25 PM, Almohanad F. wrote:

I was wondering about people’s experience with the UHD driver on the E100 or the
Beagleboard. I am able to use it to receive IQ data from the USRP but I can’t
seem to transmit anything from it … if I take the same flowgraph to a laptop I’m
able to transmit IQ using the same USRP/daughterboard and the UHD driver however
when I try to run the same transmitter on the Beagleboard and I check my spectrum
analyzer I don’t see anything

I already did a signal capture before sending to the USRP and made sure that
there is data getting pushed through … is there a problem with UHD/USRP sinking
on the E100 and the Beagleboard ??? I also made sure that I’m using the latest
UHD firmware on the beagleboard.

The following is the version info printed when I run the flowgraph:
linux; GNU C++ version 4.5.3 20110214 (prerelease); Boost_104500;
UHD_0001.20110224034946.1

Al,

Which USB port are you using to connect the USRP1? What kernel version?

Can you run dmesg and see if there are any usb related messages at the
end?

Philip

7

1- I’m using the host USB not the OTG
2- I’m using the 2.6.37 kernel with Angstrom 2010
3- The following is the dmesg output which looks ok … at least to me
:slight_smile:

[ 108.369293] usb 1-2.3.1: USB disconnect, address 4
[ 108.770874] usb 1-2.3.1: new high speed USB device using ehci-omap
and address 6
[ 108.889404] usb 1-2.3.1: New USB device found, idVendor=fffe,
idProduct=0002
[ 108.889434] usb 1-2.3.1: New USB device strings: Mfr=1, Product=2,
SerialNumber=6
[ 108.889465] usb 1-2.3.1: Product: USRP Rev 4
[ 108.889465] usb 1-2.3.1: Manufacturer: Free Software Folks
[ 108.889495] usb 1-2.3.1: SerialNumber: 4bd1d69b

I think I’ll try to attempt to redo your libusb hack by copying it from
the older gnuradio recipes and attempt to use the original USRP USB
driver if the problem ends up being too major … unless you want to do
that as a favor to me and push the recipe into the openembedded tree !!!
pretty please :slight_smile:

al fayez

8

I think I made some progress in diagnosing the UHD/Beagleboard USRP1
issue. I’ve tried bitbaking Philip’s GNU Radio 3.2.1 recipe and the
compilation fails because of the libusb-0.1.12 link, more specifically
the “libusb-gnur.a” library. For some reason GCC is expecting the
library to have the “-fPIC” flag passed when building the library which
doesn’t make sense since it’s trying to link against a static library
and not a shared librar … it was complaining about an ARM_MOV or
something like that assembly command. To my understanding the libtool
included in the libusb should make sure that such confusion doesn’t
happen which in using GCC 4.3 was not an issue but with the GCC 4.5
included in the new tree is an issue.

I also tried incorporating the libusb fix against the GNU Radio GIT
recipe but the configure stage fails because gnuradio can’t find the
“USB_BULK_WRITE” function in the libusb library from libusb-0.1.12 which
when I looked is actually there. When I bypass the configure check for
USB_BULK_WRITE the gnuradio compilation fails at the same stage as
gnuradio 3.2.1. I feel like the libusb-0.1.12 static library is corrupt
for some reason more specifically I think libtool might be the culprit.

I assume that USB_BULK_WRITE is used in the USRP sink UHD block which
might explain why I can receive but I can’t write using the UHD driver.
The libusb-0.1.12 fix included in the UHD driver, did it use GCC 4.5?
did it use libusb-0.1.12? an older or newer version maybe? did it use a
different libtool?

I need to find a way to pass the -fPIC flag to the configure stage of
libusb-0.1.12 unfortunately I can’t seem to find an easy way to do it
and I’m about to head out of town for a few days. Other than that doese
anyone have any suggestion?

Josh or Philip :slight_smile:

al fayez

9

On Wed, Feb 23, 2011 at 11:25 PM, Almohanad F. [email protected]
wrote:

I was wondering about people’s experience with the UHD driver on the E100 or
the Beagleboard. I am able to use it to receive IQ data from the USRP but I
can’t seem to transmit anything from it … if I take the same flowgraph to
a laptop I’m able to transmit IQ using the same USRP/daughterboard and the
UHD driver however when I try to run the same transmitter on the Beagleboard
and I check my spectrum analyzer I don’t see anything

After some bad judgement on my part, my E100 is back up and running.
Now with the USRP1 attached, I can transmit up to 4 Msps before I get
underruns using tx_timed_samples. The scope output checks out as well.
With gnuradio, however, I get underruns rather severely at any sample
rate; I didn’t do any digging to find out why.

I already did a signal capture before sending to the USRP and made sure that
there is data getting pushed through … is there a problem with UHD/USRP
sinking on the E100 and the Beagleboard ??? I also made sure that I’m using
the latest UHD firmware on the beagleboard.

Can you run some of the UHD examples without gnuradio?

The following is the version info printed when I run the flowgraph:
linux; GNU C++ version 4.5.3 20110214 (prerelease); Boost_104500;
UHD_0001.20110224034946.

On the E100:

linux; GNU C++ version 4.5.2 20101204 (prerelease); Boost_104100;
UHD_003.20110226000831.77641c6

Thomas

10

On Sun, Feb 27, 2011 at 11:39 PM, Almohanad F. [email protected]
wrote:

I think I made some progress in diagnosing the UHD/Beagleboard USRP1 issue.
I’ve triedbitbaking Philip’s GNU Radio 3.2.1 recipe and the compilation
fails because of the libusb-0.1.12 link, more specifically the
“libusb-gnur.a” library. For some reason GCC is expecting the library to
have the “-fPIC” flag passed when building the library which doesn’t make
sense since it’s trying to link against a static library and not a shared
librar … it was complaining about an ARM_MOV or something like that
assembly command. To my understanding the libtool included in the libusb
should make sure that such confusion doesn’t happen which in using GCC 4.3
was not an issue but with the GCC 4.5 included in the new tree is an issue.

UHD uses libusb-1.0 and does not support libusb-0.1. Despite some
similarities in the API, version 1.0 is a complete rewrite there is no
compatibility or relation between versions. In that sense, the
gnuradio 3.2 recipe is completely unrelated to UHD.

I also tried incorporating the libusb fix against the GNU Radio GIT recipe
but the configure stage fails because gnuradio can’t find the
“USB_BULK_WRITE” function in the libusb library from libusb-0.1.12 which
when I looked is actually there. When I bypass the configure check for
USB_BULK_WRITE the gnuradio compilation fails at the same stage as gnuradio
3.2.1. I feel like the libusb-0.1.12 static library is corrupt for some
reason more specifically I think libtool might be the culprit.

If you are using libusb-0.1 and the gnuradio driver, you generally
don’t want to be using the mentioned libusb calls, which are
synchronous (slow). Normally, with libusb-0.1, the control and setup
functions go through libusb, while data flows through a separate OS
specific implementation - usbdevfs in the case of Linux. The only time
you should be seeing usb_bulk_write is when configure falls back to
the synchronous calls in the absence of any “fast” version. Now the
Linux implementation does have some evil bits, so perhaps this isn’t
surprising.

I assume that USB_BULK_WRITE is used in the USRP sink UHD block which might
explain why I can receive but I can’t write using the UHD driver. The
libusb-0.1.12 fix included in the UHD driver, did it use GCC 4.5? did it use
libusb-0.1.12? an older or newer version maybe? did it use a different
libtool?

Again, usb_bulk_write and libusb-0.1.12 have no relation to UHD.

I need to find a way to pass the -fPIC flag to the configure stage of
libusb-0.1.12 unfortunately I can’t seem to find an easy way to do it and
I’m about to head out of town for a few days. Other than that doese anyone
have any suggestion?

In UHD with libusb-1.0, sends and receives are treated similarly (USB
is host driven) where pre-allocated buffers are submitted and
retrieved from the device. The difference is mainly in flags and
endpoint settings; the problem, IMO, is unlikely to be build related.
Of course, that doesn’t provide any insight into why this is only
coming up on the Beagle.

I’d like to recreate this issue on my newly setup E100, but, at the
moment, I’m not seeing any USB devices, and I think I just bricked my
FPGA. So I need to get a little bit more settled until I can try out
additional things. Perhaps later this week…

Thomas