Hi Peter, ah, I can see my misunderstanding now; I'll have to apologize.
If you have two USRPs with the same libusrp-compatible firmware, then you'd be using libusrp as driver for both USRPs. If your "second" application is not OpenBTS / doesn't rely on using this very old driver, you can use the first USRP with libusrp firmware, and the second with UHD firmware, and use it with SDR software that uses the modern UHD driver. This really depends on what you want to do with the second USRP. Best regards, Marcus On 06.12.2015 23:26, Hi Hello wrote: > Marcus, > > > On Sun, Dec 6, 2015 at 4:11 PM, Marcus Müller > <[email protected] <mailto:[email protected]>>wrote: > > 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. > > > The USRP1 only works with libusrp if your using either OpenBTS or > OsmoTRX. > > http://openbts.org/w/index.php/USRP1 = /The official Ettus Research > driver, UHD, does not support FPGA timestamp functionality for the > USRP1. As a result, an alternative FPGA firmware and driver > configuration is required for using the USRP1 with OpenBTS. The > alternative configuration is based on a customized FPGA image and the > now deprecated 'libusrp' driver found in early versions of GNU Radio. > / > > /The last release version of GNU Radio to contain the libusrp driver > is 3.4.2. Note that this version of GNU Radio is not maintained, and > installation on recent Linux distributions may be difficult - detailed > setup instructions are no longer available./ > > /http://gnuradio.org/releases/gnuradio/gnuradio-3.4.2.tar.gz/ > > > > > > 2. With libusrp, as Marcus Leech mentioned, you simply can't > handle two USRPs. > > > I'm NOT handling 2 USRP1s with the libusrp driver, (AT THE SAME TIME): > > I can connect 1 USRP1 to the computer, and run either /lsusrp/, via > the libusrp driver, or /UHD/, and both drivers identifies the USRP1 as > a USRP1 correctly loading the firmware, and the USRP1's LED blinks > calmly & happily. > > When I connect the 2nd USRP1 to the computer, after disconnecting the > 1st USRP1, I can run either libusrp > > or UHD, and it too loads the firmware correctly and reports back > that I've connected a USRP1 to the computer. The LED lights blinks > the same as the 1st USRP1. > > > BUT, whenever I attempt to run the 2nd USRP1 with ANY SDR app, such as > *benchmark*_*usb*.*py > , it always fails. > * > * > > * > > > 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. > > > Again, the USRP1 can't be utilized with the UHD driver as documented > here: > > OpenBTS, USRP1 and UHD - SourceForge > <http://sourceforge.net/p/openbts/mailman/message/31896213/> > sourceforge.net <http://sourceforge.net> › Browse › Projects › OpenBTS > <https://www.google.com/search?q=openbts+usrp1&oq=openbts+usrp1&aqs=chrome..69i57j69i65j0l2.2000j0j4&sourceid=chrome&es_sm=93&ie=UTF-8#> > > > * > > > * > > > > Higher versions of OpenBTS work only with UHD, but USRP1 > cannot work > with UHD as USRP1 doesn't have timestamps. Wrong - latest version > works just fine ... > > I appreciate the assistance, but we're not there yet with the answer. > > Any assistance would be appreciated please :-) > > Yours Trully, > > > Peter > > > > 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 <[email protected] >> <mailto:[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] <mailto:[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 >>> 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 >>> [email protected] <mailto:[email protected]> >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] <mailto:[email protected]> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] <mailto:[email protected]> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] <mailto:[email protected]> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] <mailto:[email protected]> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
