GnuRadio 3.1.1 and USRP on Fedora 8

GNU Radio
1

After many successful Gnu Radio projects with GR 3.1.1 under
both Fedora 4 and Fedora 6, I tried to install it on a
Fedora 8 32-bit system, but am having a problem.

The build was successful, ‘make check’ passed all tests,
and the install was successful.

The modification to the udev config worked, and an
‘ls -lR /dev/bus/usb’ showed a new dev file with permissions
of ‘crw-rw----’ and an owner/group of ‘root/usrp’ was created
when the usrp was plugged in.

Executing a ‘groups’ command under my user account shows
I am in the ‘usrp’ group.

Whenever I try to execute any app that uses the usrp as
a receiver, such as “test_usrp_standard_rx”, or the usrp diagnostic
in GRC, I get the error:

usrp_open_interface::usb_claim_interface: failed interface 2
could not claim interface 2: No such file or directory

The error even occurs when I run as root.

The same thing happens when trying to use a transmitter,
but the interface number changes to “1”.

I dug into the host-side usrp code, and found that the
'usb_claim_interface" call (in usrp_prims.cc) occurs
AFTER a successful call to usb_open, so it MUST be able
to find the device, contrary to the error message. In
fact, the only two error codes that usb_claim_interface
can return are -EBUSY or -ENOMEM.

Has anyone else seen this? Did something in the USB handling
change for Fedora core 8? Could some automounter be grabbing
the interface before me? Any help would be greatly
appreciated!

Here’s my relevant version info:

Gnu Radio Rel 3.1.1
Fedora Core 8
kernel 2.6.23.14-115-fc8
libusb 0.1.12-10.fc8.i386
libusb-devel 0.1.12-10.fc8.i386
usrp Rev 4 (as reported by usbview)

@(^.^)@ Ed

2

On 2/12/08, Ed Criscuolo [email protected] wrote:

Has anyone else seen this?

Can you confirm that you are in fact using a USB 2.0 controller? Your
symptoms are consistent with what happens when you have USB 1.1. The
enumeration is able to successfully occur, so you get the device,
etc., but when the host tries to establish a high speed endpoint for
data transfer, it fails.

–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com/

3

On Tue, Feb 12, 2008 at 12:25:04PM -0800, Johnathan C. wrote:

On 2/12/08, Ed Criscuolo [email protected] wrote:

Has anyone else seen this?

Can you confirm that you are in fact using a USB 2.0 controller? Your
symptoms are consistent with what happens when you have USB 1.1. The
enumeration is able to successfully occur, so you get the device,
etc., but when the host tries to establish a high speed endpoint for
data transfer, it fails.

You can check this with:

$ lsmod | grep ehci
ehci_hcd 39117 0

ehci_hcd us the name of the USB 2.0 host driver

ohci_hcd and uhci_hcd are the USB 1.1 host drivers.

4

Johnathan C. wrote:

Can you confirm that you are in fact using a USB 2.0 controller? Your
symptoms are consistent with what happens when you have USB 1.1. The
enumeration is able to successfully occur, so you get the device,
etc., but when the host tries to establish a high speed endpoint for
data transfer, it fails.

Arrrgh… you hit the nail on the head! USBView reports that the
built-in hub is “Full-Speed”, which is USB-speak for 1.1!

Thanks.

Any way the error reporting can be improved to explicitly indicate
a 1.1 port?

@(^.^)@ Ed

5

On Tue, Feb 12, 2008 at 04:30:00PM -0500, Ed Criscuolo wrote:

Arrrgh… you hit the nail on the head! USBView reports that the
built-in hub is “Full-Speed”, which is USB-speak for 1.1!

Thanks.

Any way the error reporting can be improved to explicitly indicate
a 1.1 port?

It’s ticket:90. http://gnuradio.org/trac/ticket/90

It needs somebody willing to work on it.

The fix is probably a new function in usrp_prims.cc that fishes out the
bcdUSB field from the libusb usb_device_descriptor. See usrp_usrp_p
for code that extracts info from the same descriptor.

Eric