Recent Changes to UHD causing issue for USRP1?

Dear All,
I am running Ubuntu 10.04 LTS on two systems using Marcus’
script to load/install UHD nad the latest GNURadio. On the first system
on Sat 16th of April, I ran his script and it worked well in the
GR_Companion works etc. and using UHD_find_devices as a diagnostic tool,
I get the following:

john@john-laptop:~$ uhd_find_devices
linux; GNU C++ version 4.4.3; Boost_104000;UHD_003.000.001-98a05d8

Loading firmware image: /usr/local/share/uhd/images/usrp1_fw.ihx… done

– UHD Device 0

Device Address:
type: usrp1
name:
serial: 4c745353

john@john-laptop:~$ uhd_usrp_probe
linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.000.001-98a05d8

Loading FPGA image: /usr/local/share/uhd/images/usrp1_fpga.rbf… done


/
| Device: usrp1 device
| _____________________________________________________
| /
| | Mboard: usrp1 mboard - 4c745353
| | serial: 4c745353
| | _____________________________________________________
| | /
| | | RX DSP: usrp1 ddc0 + hb
| | | Codec Rate: 64.000000 Msps
| | _____________________________________________________
| | /
| | | RX DSP: usrp1 ddc1 + hb
| | | Codec Rate: 64.000000 Msps
| | _____________________________________________________
| | /
| | | TX DSP: usrp1 duc0
| | | Codec Rate: 128.000000 Msps
| | _____________________________________________________
| | /
| | | TX DSP: usrp1 duc1
| | | Codec Rate: 128.000000 Msps
| | _____________________________________________________
| | /
| | | RX Dboard: usrp1 dboard (rx unit) - A
| | | _____________________________________________________
| | | /
| | | | RX Subdev: DBSRX2 (0x0012)
| | | | Antennas: J3
| | | | Freq range: 800.000 to 2400.000 Mhz
| | | | Gain range GC1: 0.0 to 73.0 step 0.1 dB
| | | | Gain range BBG: 0.0 to 15.0 step 1.0 dB
| | | | Connection Type: c
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: usrp1 adc - ad9862 - slot A
| | | | Gain range PGA: 0.0 to 20.0 step 1.0 dB
| | _____________________________________________________
| | /
| | | RX Dboard: usrp1 dboard (rx unit) - B
| | | _____________________________________________________
| | | /
| | | | RX Subdev: Unknown - Unknown (0xffff)
| | | | Antennas:
| | | | Freq range: 0.000 to 0.000 Mhz
| | | | Gain Elements: None
| | | | Connection Type: C
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | RX Codec: usrp1 adc - ad9862 - slot B
| | | | Gain range PGA: 0.0 to 20.0 step 1.0 dB
| | _____________________________________________________
| | /
| | | TX Dboard: usrp1 dboard (tx unit) - A
| | | _____________________________________________________
| | | /
| | | | TX Subdev: Unknown - Unknown (0xffff)
| | | | Antennas:
| | | | Freq range: 0.000 to 0.000 Mhz
| | | | Gain Elements: None
| | | | Connection Type: C
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: usrp1 dac - ad9862 - slot A
| | | | Gain range PGA: -20.0 to 0.0 step 0.1 dB
| | _____________________________________________________
| | /
| | | TX Dboard: usrp1 dboard (tx unit) - B
| | | _____________________________________________________
| | | /
| | | | TX Subdev: LF TX (0x000e) - AB
| | | | Antennas:
| | | | Freq range: -32.000 to 32.000 Mhz
| | | | Gain Elements: None
| | | | Connection Type: C
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Subdev: LF TX (0x000e) - BA
| | | | Antennas:
| | | | Freq range: -32.000 to 32.000 Mhz
| | | | Gain Elements: None
| | | | Connection Type: c
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Subdev: LF TX (0x000e) - A
| | | | Antennas:
| | | | Freq range: -32.000 to 32.000 Mhz
| | | | Gain Elements: None
| | | | Connection Type: R
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Subdev: LF TX (0x000e) - B
| | | | Antennas:
| | | | Freq range: -32.000 to 32.000 Mhz
| | | | Gain Elements: None
| | | | Connection Type: r
| | | | Uses LO offset: No
| | | _____________________________________________________
| | | /
| | | | TX Codec: usrp1 dac - ad9862 - slot B
| | | | Gain range PGA: -20.0 to 0.0 step 0.1 dB

john@john-laptop:~$

On Friday 22nd of April, on another 10.04 Ubuntu system I (re)ran
Marcus’ script and it seemed to go fine however GR-Companion could not
find devices and here is the output of UHD_find_devices:

john@johnsdesktop:~$ uhd_find_devices
linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.000.001-8212f22

No UHD Devices Found
john@johnsdesktop:~$

I should not that I had to work around an issue when Marcus’ script was
running because this line:

wget -nd -r -np
http://www.ettus.com/downloads/uhd_images/UHD-images-most-recent/

/dev/null 2>&1

does not work. I just navigated to the image files in binaries for
release 003.000.001 - 2011/04/01

i.e UHD-images-003.000.001.tar.gz so I think that is not necessarily
the issue.

Since find_devices is such a primitive command, I suspect it might be a
f/w incompatability but don’t know how to progress.

   Any assistance would be greatly appreciated,

         Kind Regards,

                  John

On 04/24/2011 02:47 AM, john wrote:

Since find_devices is such a primitive command, I suspect it might be a
f/w incompatability but don’t know how to progress.

Well, it looks like Josh re-organized the directory tree of where UHD
fpga/firmware images are
kept, so my script can no longer find the relevant files. Arrrg.

You should confirm that you have a /usr/local/share/uhd/images
directory, and it looks roughly like so:

-rw-r–r–. 1 root root 183046 2011-04-05 00:02 usrp1_fpga_4rx.rbf
-rw-r–r–. 1 root root 181588 2011-04-05 00:02 usrp1_fpga.rbf
-rw-r–r–. 1 root root 18552 2011-04-05 00:02 usrp1_fw.ihx
-rw-r–r–. 1 root root 862544 2011-04-05 00:02 usrp2_fpga.bin
-rw-r–r–. 1 root root 16383 2011-04-05 00:02 usrp2_fw.bin
-rw-r–r–. 1 root root 873980 2011-04-05 00:02 usrp_e100_fpga.bin
-rw-r–r–. 1 root root 75056 2011-04-05 00:02 usrp_e100_pt_fpga.bin
-rw-r–r–. 1 root root 1268576 2011-04-05 00:02 usrp_n210_fpga.bin
-rw-r–r–. 1 root root 16383 2011-04-05 00:02 usrp_n2xx_fw.bin


Principal Investigator
Shirleys Bay Radio Astronomy Consortium

john@johnsdesktop:~$ uhd_find_devices
linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.000.001-8212f22

No UHD Devices Found
john@johnsdesktop:~$

Looks like you didnt build w/ USB and USRP1 support?

-Josh

the issue.

I fixed the problem in build-gnuradio due to uhd_images getting shuffled
around on www.ettus.com, and that fixed instance is
now available at the usual location.

However, your failure to find a device may be unrelated. When
build-gnuradio was doing the pre-requisites
install, did it complain about not finding ‘libusb’ after the
pre-requisites install?


Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium

On Sun, 2011-04-24 at 08:36 -0400, Marcus D. Leech wrote:

the issue.

Thanks Marcus, I have:

john@johnsdesktop:/usr/local/share/uhd/images$ ls -l
total 4336
-rw-r–r-- 1 root root 17396 2011-04-22 18:53 22_april_usrp1_fw.ihx
-rw-r–r-- 1 root root 183046 2011-04-22 20:07 usrp1_fpga_4rx.rbf
-rw-r–r-- 1 root root 181588 2011-04-22 20:07 usrp1_fpga.rbf
-rw-r–r-- 1 root root 17396 2011-04-22 20:07 usrp1_fw.ihx
-rw-r–r-- 1 root root 862544 2011-04-22 20:07 usrp2_fpga.bin
-rw-r–r-- 1 root root 16383 2011-04-22 20:07 usrp2_fw.bin
-rw-r–r-- 1 root root 873980 2011-04-22 20:07 usrp_e100_fpga.bin
-rw-r–r-- 1 root root 75056 2011-04-22 20:07 usrp_e100_pt_fpga.bin
-rw-r–r-- 1 root root 892820 2011-04-22 20:07 usrp_n200_fpga.bin
-rw-r–r-- 1 root root 16383 2011-04-22 20:07 usrp_n200_fw.bin
-rw-r–r-- 1 root root 1268576 2011-04-22 20:07 usrp_n210_fpga.bin
-rw-r–r-- 1 root root 16383 2011-04-22 20:07 usrp_n210_fw.bin

I will look into Josh’s suggestion that I did not build with USB and
USRP1 support.

   Thanks,

         Kind Regards,

                 John

On Sun, 2011-04-24 at 09:28 -0700, Josh B. wrote:

-Josh


Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

Thanks for your response Josh. I have rebuilt with Marcus’ latest script
and get the following:

john@johnsdesktop:~$ uhd_find_devices
linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.000.001-627075e


– UHD Device 0

Device Address:
type: usrp1
name:
serial:

( as an aside, I think I would have gotten this the last time if I had
allowed the USRP unit a bit of time to load itself after powering on).

It finds/defaults to usrp1 (which IS the unit) but does not return the
serial number (4c745353) so perhaps it is not really detecting anything?

when I check if USRP is ‘being recognised’ I get:

john@johnsdesktop:~$ ls -lR /dev/bus/usb | grep usrp
crw-rw---- 1 root usrp 189, 138 2011-04-25 15:23 011

A bit of a head-scratcher,

     Kind Regards,

              John

( as an aside, I think I would have gotten this the last time if I had
allowed the USRP unit a bit of time to load itself after powering on).

It finds/defaults to usrp1 (which IS the unit) but does not return the
serial number (4c745353) so perhaps it is not really detecting anything?

Its reading the serial directly from eeprom as an ascii string. If the
first character wasnt valid ASCII, then it would just return with a
blank string. I wouldnt worry about it, your USRP seems to be working
just fine.

-josh

Device Address:
serial: 4c745353

I am ‘feeding’ in the serial number on the UHD: USRP source block.

I was trying to use uhd_find_devices as the diagnostic tool.

I should repeat that on the ‘good’ environment, the probe indentifies
USRP DBs correctly.

So to recap:

  • The UHD cannot read the eeprom on USRP1 on your older machine: No
    dboard IDs no mboard serial number.

  • But same USRP1 works perfectly fine on another computer.

  • However, the libgnuradio-usrp driver can read the eeprom perfectly
    fine on both computers.

So, the firmware is actually doing the I2C transactions. The reads from
a host perspective are just libusb control transactions. One thing that
comes to mind, what libusb are you running? libgnuradio-usrp uses
libusb0.1, but UHD is exclusively libusb1.0. Perhaps you have old buggy
libusb1.0 implementation on your older machine? Something along those
lines…

My best guess,
-Josh

On Sun, 2011-04-24 at 20:57 -0700, Josh B. wrote:

blank string. I wouldnt worry about it, your USRP seems to be working
just fine.

-josh
Thanks Josh but the issue is that on one UBUNTU 10.04 system I get the
serial number returned by uhd_find_devices and GnuRadioCompanion works
and on the other, I don’t get a serial number on uhd_find_devices and
GRC complains with:

linux; GNU C++ version 4.4.3; Boost_104000; UHD_003.000.001-627075e

gr_fir_ccc: using 3DNow!Ext
Loading firmware image: /home/john/usrp1_fw.ihx… done
Traceback (most recent call last):
File “/home/john/fm_rx.py”, line 502, in
tb = fm_rx()
File “/home/john/fm_rx.py”, line 269, in init
num_channels=1,
File
“/usr/local/lib/python2.6/dist-packages/gnuradio/uhd/init.py”, line
74, in constructor_interceptor
return old_constructor(*args, **kwargs)
File
“/usr/local/lib/python2.6/dist-packages/gnuradio/uhd/uhd_swig.py”, line
1656, in usrp_source
return _uhd_swig.usrp_source(*args, **kwargs)
RuntimeError: LookupError: KeyError: No devices found for ----->
Device Address:
serial: 4c745353

I am ‘feeding’ in the serial number on the UHD: USRP source block.

I was trying to use uhd_find_devices as the diagnostic tool.

I should repeat that on the ‘good’ environment, the probe indentifies
USRP DBs correctly.

   Kind Regards,

           John

On Mon, 2011-04-25 at 18:18 -0700, Josh B. wrote:

So, the firmware is actually doing the I2C transactions. The reads from
a host perspective are just libusb control transactions. One thing that
comes to mind, what libusb are you running? libgnuradio-usrp uses
libusb0.1, but UHD is exclusively libusb1.0. Perhaps you have old buggy
libusb1.0 implementation on your older machine? Something along those
lines…

My best guess,
-Josh

Great diagnosis, Josh!

Synaptic tells me that I have libusb-0.1-4, libusb-1.0-0 and their dev
components.

I have been here before, I think, and when I try to uninstall the 0.1
variant, it removes ‘the world’. The last time I didn’t check on what
was being removed so had to reinstall OS and everything from the ground
up.

Is there a smarter way to remove the pesky 0.1 s?

     Thanks again for solving the mystery,

          Kind Regards,

              John