Any idea what can make a usrp stop working?

OSX. I got my USRP up and running, and now it isn’t. In system profile
it
even detects USRP 4, and when I run a program, the light slows down
flashing, but it doesn’t seem to be reading anything.

Here is my error message when I use ./usrp_fft.py

/opt/local/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/_core.py:14448:
UserWarning: wxPython/wxWidgets release number mismatch
warnings.warn(“wxPython/wxWidgets release number mismatch”)
usb_control_msg failed: usb_control_msg(DeviceRequestTO): pipe is
stalled
fusb_ephandle_darwin::read_completed: Expected 32768 bytes; read 0.
fusb_ephandle_darwin::read_completed: Expected 32768 bytes; read 0.
fusb_ephandle_darwin::read_completed: Expected 32768 bytes; read 0.

This website, which is often referenced, doesn’t seem to work (just a
heads
up, as it seems to be on Eric’s site)
http://www.comsec.com/wiki?UsrpInstall

Any advice on troubleshooting? I upgraded all my gnuradio files, remade
everything, tried taking out the daughterboard. Is this a problem with
the
board itself, or something that can be rectified? If I whacked a board I
am
dead…

Are there best practices for connecting and disconnecting the board?
Usually
I do power up → usb in, and then when I’m down, power down → usb out.
I
have only really messed with running code.

On Tue, Jul 28, 2009 at 5:53 PM, Jonathan C.[email protected]
wrote:

OSX. I got my USRP up and running, and now it isn’t. In system profile it

usb_control_msg failed: usb_control_msg(DeviceRequestTO): pipe is stalled
fusb_ephandle_darwin::read_completed: Expected 32768 bytes; read 0.
fusb_ephandle_darwin::read_completed: Expected 32768 bytes; read 0.
fusb_ephandle_darwin::read_completed: Expected 32768 bytes; read 0.

I periodically get this error, I just unplug the usrp and plug it back
and that usually fixes the problem.

I’m not sure if there is a reason that this happens, but the cable
cycling always fixed the problem for me (there were discussions in the
past about the reliability of the USB port’s solder connections, maybe
thats it?)

Jason

I have tried unplugging it and replugging it to no avail. I guess I
don’t
get why it can initialize and whatnot, but can’t send me a signal.

I checked system profiler, and while it does recognize the USRP Rev 4,
it
says that the maximum speed is 12mb. Could it be some problem has popped
up
with the USB interfacing? It seems most reasonable, as the programs load
up
and everything so the USB cord IS working (I imagine that configuring
the
USRP is not simply a writing operation and would involve sending info
back?), but USB2 isn’t?

2009/7/28 Jason U. [email protected]

Which Mac type are you using? PPC Mac’s built-in USB 2.0 isn’t good
enough; you’ll want a PC-card or PCI solution instead. My dual 1.25
GHz G4 Mac can do about 10 M-Bytes/s native, but with a $15 drop-in
USB 2.0 card, it can easily handle 32 MB/s. Intel Mac’s have good USB
2.0, and even the least expensive of them can easily handle 32 MB/s …
amazing what a difference a different architecture makes.

On PPC Macs using native USB, make sure your total data transport
(both input and output) is “low” … meaning decimate / interpolate as
much as possible in the FPGA.

I am on a 2nd gen macbook, so it does have USB2. The weirdest part is a)
that it DID work and b) that the USRP still can get the firmware and
whatnot, but it’s only when it starts polling for stuff that it seems
not to
work

2009/7/29 Michael D. [email protected]

I’ll check the print_db when I go back home, but by worked I mean that I
could even run usrp_wfm_nogui.py and get radio stations

2009/7/29 Michael D. [email protected]

On Jul 29, 2009, at 3:31 PM, Jonathan C. wrote:

I am on a 2nd gen macbook, so it does have USB2.

OK; that computer should work OK w/ a USRP1.

The weirdest part is a) that it DID work

By “did work” do you mean that you have successfully use GNU Radio and
USRP1 together, e.g., usrp_fft? Or do you mean something else?

If you execute ‘usrp_print_db.py’ what’s returned (if anything)?

and b) that the USRP still can get the firmware and whatnot, but
it’s only when it starts polling for stuff that it seems not to work

Strange; maybe others have insight? This has never happened to me.

I just tested my computer with a different USRP, and it works, leading
me to
believe that there is something (weird) wrong with my USRP unit :frowning:
Anyone
have any idea what these things are prone to, or if there’s something I
can
do to restore to to a pristine, “factory state,” for troubleshooting?
It’s
just frustrating because it worked one day, stopped working the next.
Frustrating!!

2009/7/29 Jonathan C. [email protected]