Ah, and I forgot to mention one more thing. The errors that I get when running usrp_fft.py are methodical, with one every second or so, which seems odd. if I wasn't getting anything I'd imagine it to flood the screen (which is what happens i the USB cord is yanked)
2009/7/30 Jonathan Coveney <[email protected]> > Ok, this is my attempt at a definitive bug report for this problem. Since > it's mysterious, I'm going to try and be as descriptive as possible. Thanks > in advance for your patience and help. > > I am on a second gen macbook, OSX, running the latest (as of a day or two > ago) from the svn trunk > > First, running usrp_print_db.py, I get this > > usb_control_msg failed: usb_control_msg(DeviceRequestTO): pipe is stalled > usb_control_msg failed: usb_control_msg(DeviceRequestTO): pipe is stalled > usb_control_msg failed: usb_control_msg(DeviceRequestTO): pipe is stalled > RX d'board A: Basic Rx > RX d'board B: <none> > TX d'board A: <none> > TX d'board B: <none> > > I imagine that to get this information, information had to be sent over the > USRP to my computer, so both sending and receiving information over the USB > is possible. > > Here is the info from system profiler: > > USRP Rev 4: > > Product ID: 0x0002 > Vendor ID: 0xfffe > Version: 1.04 > Speed: Up to 12 Mb/sec > Manufacturer: Free Software Folks > Location ID: 0x04100000 > Current Available (mA): 500 > Current Required (mA): Unknown (Device has not been configured) > > This is a screenshot of what happens on running usrp_fftp.py > > http://www.jcoveney.com/Picture%201.png > > As you can see, everything loads properly, but then it doesn't capture any > data. Very odd. Could this perhaps be a problem with the batch USB data > transfer? IE for some reason, I can still send and receive data, but not in > bulk? > (also, there is a wx related error that I've always gotten and has never > effected it before, and doing some research seems not to matter, but if you > think it would help to fix it, I'm all ears) > > Obviously, if I run other stuff relying on the daughterboard, the same > happens. I've talked to some people and they think that it could be static, > but I don't know. What on the board could be whacked such that this is what > does not work? > > Is there any recourse for fixing USRP's, or am I at the western frontier of > open source development? As always, your help is greatly appreciated. >
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
