Marcus,


 Thank you for replying my replies inline below:

 On Sat, Dec 5, 2015 at 3:19 AM, Marcus Müller
 <marcus.mueller@ettus.com <mailto:marcus.mueller@ettus.com>> 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 rev4/

 //

     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
     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 list
     Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

     _______________________________________________
     Discuss-gnuradio mailing list
     Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio



 _______________________________________________
 Discuss-gnuradio mailing list
 Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org>
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Pretty much: you can't, but you also don't have to: 1. it's not true that OpenBTS doesn't support UHD. So you're not stuck with the long dead libusrp from GNU Radio 3.4.2. OpenBTS and GNU Radio are completely independent projects. 2. With libusrp, as Marcus Leech mentioned, you simply can't handle two USRPs. This all with a grain of salt, I've never tried to use two USRP1s at once, nor GNU Radio 3.4.2 (since when that was the recent version). In other words: Simply use OpenBTS, OsmoTRX etc with the UHD interface they come with. Don't try to use something that is this outdated. Best regards, Marcus On 06.12.2015 23:07, Hi Hello wrote: > 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 <theliveusb@gmail.com > <mailto:theliveusb@gmail.com>> wrote: > > Marcus, > > > Thank you for replying my replies inline below: > > On Sat, Dec 5, 2015 at 3:19 AM, Marcus Müller > <marcus.mueller@ettus.com <mailto:marcus.mueller@ettus.com>> 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 >> 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 list >> Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Sylvain

Hi, > 1. it's not true that OpenBTS doesn't support UHD. So you're not stuck with > the long dead libusrp from GNU Radio 3.4.2. OpenBTS and GNU Radio are > completely independent projects. For USRP1 you don't have a choice. UHD support in OpenBTS (and derivatives) requires HW timestamp supports. Which the UHD driver for the USRP1 lacks. Only thought libusrp and a special fpga image are hw timestamps supported on the USRP1. Cheers, Sylvain