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

Reply via email to