USRP and gnuradio errors - seems to disconnect often

GNU Radio
1

I’ve been doing some testing with a new USRP (manufactured 12/2007). My
configuration is an Intel USB interface on a P965-S motherboard. I
dual-boot XP SP2 and Arch Linux. In XP I’ve used Cygwin and MinGW. I’ve
tried removing all but the TVRX board (which is mainly what I’m
attempting to test), and my problems persist. I’ve also switched to
another USB cable just to be sure.

What seems to be happening, is at random intervals while running the
test scripts (mainly usrp_wfm_rcv.py and usrp_tv_rcv), the GUI hangs,
and when I exit the GUI, I get messages as follow:

uOuOuOuOuOuOread: usb_reap_async: usb_reap_async: error: A device
attached to the system is not functioning.

usb_control_msg failed: error sending control message: win error: The
device does not recognize the command.

usb_control_msg failed: error sending control message: win error: The
device does not recognize the command

usrp_basic_rx: set_fpga_rx_enable failed
usb_control_msg failed: error sending control message: win error: The
device does not recognize the command.

usb_control_msg failed: error sending control message: win error: The
device does not recognize the command.

usrp_basic_rx: failed to fini AD9862 RX regs

I’ve tried using two versions of usblib (0.1.10.1 and 0.1.12.1), and
even tried loading different firmware. The result is always the same. It
also does not matter which environment I’m using, Cygwin, MinGW, or
Linux; the result is the same. The other board I’ve tried using is the
FLEX900 – same results with its scripts.

I’m left to assume that I have faulty hardware, but I’m wondering if I’m
the only one who is experiencing such problems. Any ideas? Anyone? I’ve
followed the wiki instructions exactly.

Oh, another symptom (or is it?)… tuning in NTSC, not so good. I can
see the image but it doesn’t sync properly-- I find myself wanting to
look for a those little knobs on the side of old TVs, you know the ones
that sync up the image vertically and horizontally. Tuning in FM audio
sounds fine. It could be my signal is weak, but somehow I doubt it.

Any advise would be appreciated.

-Casey

2

Casey T. wrote:

(mainly usrp_wfm_rcv.py and usrp_tv_rcv), the GUI hangs, and when I exit
the
GUI, I get messages as follow:

uOuOuOuOuOuOread: usb_reap_async: usb_reap_async: error: A device
attached to the system is not functioning.

I am familiar with this message. In my case, it occurs often (with
Cygwin
or MinGW) when I turn on (or sometimes off) any of several devices (desk
lamp, power supply, amplified speakers) in my computer room. Using a
constant-voltage isolation transformer on either the USRP or desk lamp
makes
no difference. The desk lamp, USRP, and computer are plugged into
separate
surge suppressors or outlet boxes. Devices elsewhere in the house have
no
effect.

usb_control_msg failed: error sending control message: win error: The
device
does not recognize the command.

usb_control_msg failed: error sending control message: win error: The
device
does not recognize the command

usrp_basic_rx: set_fpga_rx_enable failed
usb_control_msg failed: error sending control message: win error: The
device
does not recognize the command.

usb_control_msg failed: error sending control message: win error: The
device
does not recognize the command.

usrp_basic_rx: failed to fini AD9862 RX regs

I have not noticed these other messages.

I’ve tried using two versions of usblib (0.1.10.1 and 0.1.12.1), and even
tried
loading different firmware. The result is always the same. It also does
not matter
which environment I’m using, Cygwin, MinGW, or Linux; the result is the
same.
The other board I’ve tried using is the FLEX900 – same results with its
scripts.

I am using LFRX and also get similar errors under Linux.

I’m left to assume that I have faulty hardware, but I’m wondering if I’m
the only
one who is experiencing such problems. Any ideas? Anyone? I’ve followed
the
wiki instructions exactly.

My guess is that it is a hardware problem, but not necessarily in the
USRP
hardware. It would be interesting to see if other USB 2.0 devices that
run
continuosly at high data rates see similar disruptions, but I don’t have
any
other such devices to test.

– Don W.

3

I acquired another USRP with the same configuration yesterday and tested
it,
and I had the exact same results with it as I did with the first one. I
also moved
the power supply to an isolate circuit, and it had no effect. I do have
powered
speakers in my room, but I don’t understand how they would have any
effect
on the stability of my USB device. I use other USB and FireWire devices
in my
computer with a good amount of reliability on all of them. I’ve also
tried
disconnecting these devices as well; nothing changes. BTW, I’m using
gnuradio-3.0.2 on windows, and 3.1.1 on linux.

4

On 2/16/08, Casey T. [email protected] wrote:

BTW, I’m using gnuradio-3.0.2 on windows, and 3.1.1 on linux.

Are you seeing the same symptoms with GNU 3.1.1 on Linux?

There was a significant bug fix in 3.0.4 related to the USRP firmware
and USB power management. We only saw the issue with certain versions
of the Linux kernel, but it may be related.

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

5

This is probably unrelated, but I once had random errors similar to
this when I used an under-rated power supply with USRP. Another
possibility is a loose power supply jack connector. But I guess you
have pretty much ruled these out already.

juha

6

OK, I booted into Arch Linux again for some testing. This time
my
kernel was upgraded to 2.4.24. I hooked up my USRP and
ran the python
scripts and walked away for 20 minutes. When
I came back, it was still
sitting there trying to tune an NTSC
signal and failing miserably at
synchronizing the video stream,
but it did not freeze or bail out with
any of the prior errors of
the device not being found, so it could
indeed be the Linux
kernel that I was using. I’m using the SVN version
of gnuradio,
so it is >= 3.1.1 I guess. As for Windows, I haven’t
done any
further testing, but am left to assume that my 3.0.2 on XP
will
continue to fail.

I would like to get the SVN (or at least a
more recent) version
to compile under Windows, but the Wiki articles do
not indicate
which libraries are compatible, and I think this is a real
shame
for those of us who prefer to enable non-linux-gurus to use
FOSS.
Any advise on compiling under MSYS or Cygwin would
be greatly appreciated.

Sidebar: as for the NTSC signal not synching… Should I just
play
around with the signal routing, or is it more of a decimation
thing? I’ve tried many different decimation values and
have had the
best success with 10, 14, 20, and 28.

From: [email protected]
Are you seeing the same symptoms with GNU 3.1.1 on Linux?

There was a significant bug fix in 3.0.4 related to the USRP firmware
and USB power management. We only saw the issue with certain versions
of the Linux kernel, but it may be related.

From: [email protected]
This is probably unrelated, but I once had random errors similar to
this when I used an under-rated power supply with USRP. Another
possibility is a loose power supply jack connector. But I guess you
have pretty much ruled these out already.

Yes, I believe the power supplies are fine but thanks for bringing that
up.

7

On 2/18/08, Casey T. [email protected] wrote:

Sidebar: as for the NTSC signal not synching…

From the script source code comments–sync has never been written for
this block.

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

8

Casey T. wrote:

I would like to get the SVN (or at least a more recent) version
to compile under Windows, but the Wiki articles do not indicate
which libraries are compatible, and I think this is a real shame
for those of us who prefer to enable non-linux-gurus to use FOSS.
Any advise on compiling under MSYS or Cygwin would
be greatly appreciated.

Except as noted, the libraries needed for the SVN build under Cygwin are
the
same as for the release. If you run into trouble, post specifics to the
list and we can find a solution and update the wiki. The MinGW wiki is
more
likely to be out of date.

(I assume you are looking at
http://www.gnuradio.org/trac/wiki/CygwinInstallMain and not some older
wiki
page.)

– Don W.

9

On Mon, Feb 18, 2008 at 06:40:24PM +0000, Casey T. wrote:

OK, I booted into Arch Linux again for some testing. This time my
kernel was upgraded to 2.4.24.

That’s certainly a “mature” kernel.

I hooked up my USRP and ran the python scripts and walked away for
20 minutes. When I came back, it was still sitting there trying to
tune an NTSC signal and failing miserably at synchronizing the video
stream, but it did not freeze or bail out with any of the prior
errors of the device not being found, so it could indeed be the
Linux kernel that I was using. I’m using the SVN version of
gnuradio, so it is >= 3.1.1 I guess. As for Windows, I haven’t done
any further testing, but am left to assume that my 3.0.2 on XP will
continue to fail.

Casey, if you’d take a look at the first comment in usrp_tv_rcv.py you
would see that it explicitly indicates that “There is no
synchronization yet”.

Free software gets written by people like you who want particular
features to work. If you want an NTSC receiver you could help work on
it.

I would like to get the SVN (or at least a more recent) version to
compile under Windows, but the Wiki articles do not indicate which
libraries are compatible, and I think this is a real shame for those
of us who prefer to enable non-linux-gurus to use FOSS. Any advise
on compiling under MSYS or Cygwin would be greatly appreciated.

If you use Ubuntu or Debian, there are binary packages for GNU Radio
available.

Eric