Sylvain, Marcus,
Thanks Sylvain for clairfying that the USRP1 does in fact need GNURadio 3.4.2 in order for it to work with OpenBTS, OsmoTRX, but the problem remains: I have 2 USRP1s, both works with lsusrp and/or UHD, as both drivers recognizes, and loads the firmware correctly on BOTH my USRP1s. The problem is, 1 of the USRP1s can run ANY SDR app, while the other one always fails at the most BASIC apps such as *benchmark*_*usb*.*py* *How can I get the 2nd USRP1 to work just like the 1st USRP1?* On Mon, Dec 7, 2015 at 3:27 AM, Marcus Müller <[email protected]> wrote: > 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]> > [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>http://gnuradio.org/releases/gnuradio/gnuradio-3.4.2.tar.gz > <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 › 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]> >> [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]>[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> >>> 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> >>>> 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 >> [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
