Hello,
I'm still stuck with the below described, and though Mr. Mueller forwarded this to the USRP-users list, I've still not been able to either post on that list, nor received an answer. How can I resolve the situtation? Yours Trully, Peter On Sat, Dec 5, 2015 at 3:35 AM, Hi Hello <[email protected]> wrote: > Marcus, > > > Thank you for replying my replies inline below: > > On Sat, Dec 5, 2015 at 3:19 AM, Marcus Müller <[email protected]> > wrote: > >> Hi Peter, >> >> wow: GNU Radio 3.4.2, that is OLD. >> >> With firmwares that old, I can really not tell from experience how the >> USB behaviour should be -- the link (and bcdDevice numbers) you mention >> might or might not apply. >> > > It applies because when you first plug in your USRP device, then provide > power, and do a lsusb, ( WITHOUT LAUNCHING lsusrp or ANY UHD commands ), > you'll come up with what Thomas Tsou posted: > > *Try running "lsusb -v"* > >*>>> and look for the line bcdDevice under the fffe:0002 section. You* > >*>>> should be seeing 0.04, which means unconfigured (high byte) and rev4* > >*>>> (low byte).* > >*>>>* > >*>>> Thomas* > > > The USRP firmwares have gone through significant rework since the libusrp >> times to now work consistently with UHD. Whilst libusrp used to be a GNU >> Radio component, UHD is a standalone driver that can be used by software >> such as OpenBTS without needing any GNU Radio to operate. >> > >> You don't need GNU Radio for modern OpenBTS, it integrates its own UHD >> driver interface as far as I know, which should be able to talk to your >> hardware; I might be incorrect, though - I've never used an USRP1 with >> OpenBTS. >> > > UHD doesn't work for USRP1 devices with certain "SDR APPs" such as > OpenBTS, OsmoTRX, YateBTS, etc., etc. > > I'm including the USRP-users mailing list in this reply -- this is really >> not much of a GNU Radio problem, and my hopes are that there are more >> people knowledgeable about firmware of that era over there. Please feel >> free to sign up to the list [1] and follow up there. >> > > UHD 3.10.0 even recognizes BOTH USRP1s, and loads the firmware > successfully, but 1 of the USRP1 always fails at running ANY "SDR App". > > Why would 2 USRP1s work with both the old driver, *LibUSRP*, and the > current driver, *UHD*, but yet 1 of the 2 always fails with SDR apps such > as usrp_benchmark_usb.py? = https://www.ruby-forum.com/topic/144823 > > I thank you for replying and the additional prospective support from the > USRP-users Mailing list. > > >> Best regards, >> Marcus >> >> [1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> > Yours trully, > > > Peter > > >> >> On 05.12.2015 01:45, Hi Hello wrote: >> >> Hello, >> >> >> I have 2 USRP1s, and either issuing the commands of *lsusrp*, from >> Gnuradio-3.4.2, (to work with OpenBTS), both USRP1s reports back that I >> have a USRP1 with WBX daughter cards. >> >> And of the 2 USRPs, when I run *lsusb -v*, it DOES show the following >> correctly: *bcdDevice 1.04 *just as it should per this following link: >> >> Re: [Discuss-gnuradio] Can't find firmware: std.ihx >> >> <https://lists.gnu.org/archive/html/discuss-gnuradio/2010-07/msg00523.html> >> https://lists.gnu.org/archive/html/discuss-gnuradio/2010-07/msg00523.html >> >> But if I run any SDR apps, such as *OpenBTS*, or *USRP_benchmark.py*, or >> *USRPping*, one of the two USRP1s just sits there, while the other always >> works correctly. When I ran *USRP_benchmark.py* on one of the USRP1s, while >> it doesn't report back anything, I'll disconnect the power cord, and then >> the command prompt reports back USB Protocol Errors -71. The other USRP1, ( >> the one that works), when I pull the power cord, the command line reports >> back fusb repeatedly and it always works with NO issues. >> >> Why would 2 USRP1s work correctly when loading firmware, but only 1 of them >> can run any SDR app without errors? Both USRP1s are in mint condition too >> and have matching Molex USB connectors. >> >> Please help. >> >> Peter >> >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing >> [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
