Send USRP-users mailing list submissions to
usrp-users@lists.ettus.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
usrp-users-requ...@lists.ettus.com
You can reach the person managing the list at
usrp-users-ow...@lists.ettus.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. RFNoC Simulation not working (Jason Matusiak)
2. Re: RFNoC Simulation not working (Jonathon Pendlum)
3. Re: RFNoC Simulation not working (Jason Matusiak)
4. UHD & LibUSRP works with both but...Re: [Discuss-gnuradio] 2
USRP1s, both loads firmware correctly, but only 1 can run ANY sdr
apps. Why? (Hi Hello)
5. Re: [Discuss-gnuradio] UHD & LibUSRP works with both
but...Re: 2 USRP1s, both loads firmware correctly, but only 1 can
run ANY sdr apps. Why? (Hi Hello)
6. [Discuss-gnuradio] UHD & LibUSRP works with both but...Re: 2
USRP1s, both loads firmware correctly, but only 1 can run ANY sdr
apps. Why? (Hi Hello)
7. Re: [Discuss-gnuradio] UHD & LibUSRP works with both
but...Re: 2 USRP1s, both loads firmware correctly, but only 1 can
run ANY sdr apps. Why? (Peter Cielos)
8. Re: USRP E110 sync clock (Rafael)
9. (Bidding) sale USRP + daughterboard (Anak Galer)
10. Re: [Discuss-gnuradio] UHD & LibUSRP works with both
but...Re: 2 USRP1s, both loads firmware correctly, but only 1 can
run ANY sdr apps. Why? (Sylvain Munaut)
11. Re: (Bidding) sale USRP + daughterboard (Sylvain Munaut)
12. Unusual looong delay before "Creating the usrp device
with..." (Crozzoli Maurizio)
13. Re: Unusual looong delay before "Creating the usrp device
with..." (Marcus M?ller)
14. Re: Unusual looong delay before "Creating the usrp device
with..." (Crozzoli Maurizio)
15. Re: Unusual looong delay before "Creating the usrp device
with..." (Crozzoli Maurizio)
16. Tonight! Cyberspectrum: Software Defined Radio Meetup (Wed
9th Dec) 6:30pm (Balint Seeber)
----------------------------------------------------------------------
Message: 1
Date: Tue, 08 Dec 2015 10:16:49 -0700
From: "Jason Matusiak" <ja...@gardettoengineering.com>
To: "Ettus Mail List" <usrp-users@lists.ettus.com>
Subject: [USRP-users] RFNoC Simulation not working
Message-ID:
<20151208101649.ba066092a6e013ef68fa4f5a8d80e9ee.087da8f68f....@email02.secureserver.net>
Content-Type: text/plain; charset="utf-8"
I have the latest UHD and submodule in my pybombs directory. I go to
the directory uhd/fpga-src/usrp3/lib/rfnoc/noc_block_moving_avg_tb
and run: make xsim GUI=1
but I get the error:
Completed static elaboration
ERROR: [XSIM 43-3980] File "sim_axis_lib.sv" Line 27 : The "System
Verilog virtual" is not supported yet for simulation.
Am I doing something wrong? I was hoping to run your testbenches on
this file so I can recreate one of my own to work through my module.
TIA.
------------------------------
Message: 2
Date: Tue, 8 Dec 2015 09:37:14 -0800
From: Jonathon Pendlum <jonathon.pend...@ettus.com>
To: Jason Matusiak <ja...@gardettoengineering.com>
Cc: Ettus Mail List <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] RFNoC Simulation not working
Message-ID:
<CAGdo0uS4d2N1PHuFA3Ey_ga7=oz1eikwgfzazuvg_0q3jud...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Jason,
Right now we only support Modelsim for RFNoC test benches. As Vivado
support for SystemVerilog improves, we will be able to support using xsim.
Jonathon
On Tue, Dec 8, 2015 at 9:16 AM, Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:
> I have the latest UHD and submodule in my pybombs directory. I go to
> the directory uhd/fpga-src/usrp3/lib/rfnoc/noc_block_moving_avg_tb
> and run: make xsim GUI=1
> but I get the error:
> Completed static elaboration
> ERROR: [XSIM 43-3980] File "sim_axis_lib.sv" Line 27 : The "System
> Verilog virtual" is not supported yet for simulation.
>
> Am I doing something wrong? I was hoping to run your testbenches on
> this file so I can recreate one of my own to work through my module.
> TIA.
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151208/f8248a04/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 08 Dec 2015 11:18:44 -0700
From: "Jason Matusiak" <ja...@gardettoengineering.com>
To: "Jonathon Pendlum" <jonathon.pend...@ettus.com>
Cc: "Ettus Mail List" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] RFNoC Simulation not working
Message-ID:
<20151208111844.ba066092a6e013ef68fa4f5a8d80e9ee.1edfe0aaa7....@email02.secureserver.net>
Content-Type: text/plain; charset="utf-8"
> Right now we only support Modelsim for RFNoC test benches. As Vivado support
> for SystemVerilog improves, we
> will be able to support using xsim.
Thanks for the quick response Jonathon. That is a shame, but not that
you mention it, I feel like I remember it being mentioned up at GRCON...
I am a little worried about my valid/last/ready/etc. flags being setup
properly, is there anything that a non-modelsim user can leverage to
make sure things are setup properly in a custom design?
------------------------------
Message: 4
Date: Sat, 5 Dec 2015 03:35:26 -0600
From: Hi Hello <thelive...@gmail.com>
To: "usrp-users@lists.ettus.com" <USRP-users@lists.ettus.com>
Cc: discuss-gnura...@gnu.org
Subject: [USRP-users] UHD & LibUSRP works with both but...Re:
[Discuss-gnuradio] 2 USRP1s, both loads firmware correctly, but only 1
can run ANY sdr apps. Why?
Message-ID:
<cahowx1ceqmsjzc1mhwkd6pjjx1ryqxs9kjeuvdfh2h_+j2z...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Marcus,
Thank you for replying my replies inline below:
On Sat, Dec 5, 2015 at 3:19 AM, Marcus M?ller <marcus.muel...@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>
> 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
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> discuss-gnura...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151205/c80d5a38/attachment-0001.html>
------------------------------
Message: 5
Date: Sun, 6 Dec 2015 16:07:08 -0600
From: Hi Hello <thelive...@gmail.com>
To: "usrp-users@lists.ettus.com" <USRP-users@lists.ettus.com>,
Johnathan Corgan <johnat...@corganlabs.com>
Cc: discuss-gnura...@gnu.org
Subject: Re: [USRP-users] [Discuss-gnuradio] UHD & LibUSRP works with
both but...Re: 2 USRP1s, both loads firmware correctly, but only 1 can
run ANY sdr apps. Why?
Message-ID:
<cahowx1dp5damdma3x1lbcqnaejb6cbxxjyhpdthmri1deme...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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 <thelive...@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.muel...@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>
>> 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
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> discuss-gnura...@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> discuss-gnura...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151206/316a01e1/attachment-0001.html>
------------------------------
Message: 6
Date: Sun, 6 Dec 2015 16:26:23 -0600
From: Hi Hello <thelive...@gmail.com>
To: Marcus M?ller <marcus.muel...@ettus.com>,
discuss-gnura...@gnu.org, "usrp-users@lists.ettus.com"
<USRP-users@lists.ettus.com>
Subject: [USRP-users] [Discuss-gnuradio] UHD & LibUSRP works with both
but...Re: 2 USRP1s, both loads firmware correctly, but only 1 can run
ANY sdr apps. Why?
Message-ID:
<CAHOWX1cum4PHNXKZSi4kpQQ86BEu=sfbnnfpdcq60zudjsn...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Marcus,
On Sun, Dec 6, 2015 at 4:11 PM, Marcus M?ller <marcus.muel...@ettus.com>
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>*
?
> 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#>
-
<http://webcache.googleusercontent.com/search?q=cache:GAtQIX28oa4J:sourceforge.net/p/openbts/mailman/message/31896213/+&cd=4&hl=en&ct=clnk&gl=us>
-
<https://www.google.com/search?q=related:sourceforge.net/p/openbts/mailman/message/31896213/+openbts+usrp1&tbo=1&sa=X&ved=0ahUKEwjMpbuJosjJAhVGrIMKHSFPAecQHwg6MAM>
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 <thelive...@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.muel...@ettus.com>marcus.muel...@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>
>>> 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
>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> discuss-gnura...@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> discuss-gnura...@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
> _______________________________________________
> Discuss-gnuradio mailing
> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> discuss-gnura...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151206/e73694a2/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 8 Dec 2015 11:00:26 -0600
From: Peter Cielos <thelive...@gmail.com>
To: Marcus M?ller <marcus.muel...@ettus.com>, Sylvain Munaut
<246...@gmail.com>
Cc: discuss-gnura...@gnu.org, "usrp-users@lists.ettus.com"
<USRP-users@lists.ettus.com>
Subject: Re: [USRP-users] [Discuss-gnuradio] UHD & LibUSRP works with
both but...Re: 2 USRP1s, both loads firmware correctly, but only 1 can
run ANY sdr apps. Why?
Message-ID:
<CAHOWX1c=ik+rzhnfcosmmb_dvaby4bpet8xpymxxhf0lz9b...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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 <marcus.muel...@ettus.com>
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 < <marcus.muel...@ettus.com>
> marcus.muel...@ettus.com> 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 < <thelive...@gmail.com>
>> thelive...@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.muel...@ettus.com>marcus.muel...@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>
>>> 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
>>>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Discuss-gnuradio mailing list
>>>> discuss-gnura...@gnu.org
>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> discuss-gnura...@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing
>> listDiscuss-gnuradio@gnu.orghttps://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> discuss-gnura...@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151208/f0e83a60/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 8 Dec 2015 23:17:57 -0200
From: Rafael <rafael.asilvacoe...@gmail.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] USRP E110 sync clock
Message-ID: <91589e36-83c1-45db-83a7-1fa33fbcb...@gmail.com>
Content-Type: text/plain; charset=us-ascii
Hello!
Following what Derek said, I got the external device in order to generate 1PPS
and then reach synchronization with 1s accuracy.
Thank you all.
Rafael
--
Rafael A S Coelho
> On Dec 5, 2015, at 3:00 PM, usrp-users-requ...@lists.ettus.com wrote:
>
> Send USRP-users mailing list submissions to
> usrp-users@lists.ettus.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> or, via email, send a message with subject or body 'help' to
> usrp-users-requ...@lists.ettus.com
>
> You can reach the person managing the list at
> usrp-users-ow...@lists.ettus.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of USRP-users digest..."
>
>
> Today's Topics:
>
> 1. Re: purpose of split_stream_fifo module (Jonathon Pendlum)
> 2. USRP E110 sync clock (Rafael Augusto)
> 3. USRP2 B210. Problems with new bin-files (??????? ???????)
> 4. Re: UHD and RFNoC engines (Nick Foster)
> 5. Re: UHD and RFNoC engines (Martin Braun)
> 6. Re: time accuracy at 100 MSps with X310 (Michael West)
> 7. Re: USRP2 B210. Problems with new bin-files (James Humphries)
> 8. Re: time accuracy at 100 MSps with X310 (Sanjoy Basak)
> 9. Re: time accuracy at 100 MSps with X310 (Michael West)
> 10. Re: time accuracy at 100 MSps with X310 (Sanjoy Basak)
> 11. Re: time accuracy at 100 MSps with X310 (Michael West)
> 12. Re: USRP2 B210. Problems with new bin-files (Derek Kozel)
> 13. Re: USRP E110 sync clock (Derek Kozel)
> 14. Re: USRP E110 sync clock (Marcus D. Leech)
> 15. Re: USRP E110 sync clock (Rafael Augusto)
> 16. Re: [Discuss-gnuradio] 2 USRP1s, both loads firmware
> correctly, but only 1 can run ANY sdr apps. Why? (Marcus M?ller)
> 17. Re: [Discuss-gnuradio] 2 USRP1s, both loads firmware
> correctly, but only 1 can run ANY sdr apps. Why? (Marcus D. Leech)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 4 Dec 2015 10:22:25 -0800
> From: Jonathon Pendlum <jonathon.pend...@ettus.com>
> To: Jason Matusiak <ja...@gardettoengineering.com>
> Cc: Ettus Mail List <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] purpose of split_stream_fifo module
> Message-ID:
> <cagdo0utycmognqrvwzvg-nboklv-xm+y+my6r0hq4l7njtf...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Jason,
>
> But you don't //have// to do it that way, right? You example is similar
>> to my situation in that I pass the original signal out my block as well
>> as the correlated value. So I am taking a single input stream and
>> working on it in two ways in parallel (even though nothing new is
>> happening to the original stream except getting delayed), but I handle
>> it in my timesync.v module that is called from noc_block_timesync.v. So
>> in that case, would I still need to split the stream?
>
>
> Typically I would use split stream but you do not have to. You could, for
> instance, concatenate a calculated value with the original sample to make a
> larger tdata. For example, I could make an adder block that also keeps the
> original samples:
>
>
> module adder_concat (
> input [31:0] i_tdata,
> input i_tvalid,
> input i_tlast,
> input i_tready,
> output [47:0] o_tdata,
> output o_tvalid,
> output o_tlast,
> input o_tready);
>
> assign o_tdata = {i_tdata,i_tdata[31:16] + i_tdata[15:0]};
> assign o_tvalid = i_tvalid;
> assign o_tlast = i_tlast;
> assign i_tready = o_tready;
>
> endmodule
>
>
> In this case, I saved some resources and I am guaranteed my calculated
> value is aligned with my sample. On the other hand, now my tdata has a
> special format that I'll have to be aware of when interfacing with other
> modules.
>
> Where are you coming up with the producer/consumer_block modules? I
>> think I am missing something with that (sadly nothing new there for me).
>
>
> Those are module names I made up to try to make the example clearer.
>
>
>
> Jonathon
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151204/4228b5ec/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 4 Dec 2015 15:06:52 -0200
> From: Rafael Augusto <rafael.asilvacoe...@gmail.com>
> To: usrp-users@lists.ettus.com
> Subject: [USRP-users] USRP E110 sync clock
> Message-ID:
> <CAHKEYjtEVHCL1PhPZ=8+ppkpuz3oknyshccq9gnar7dx_lj...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi everyone,
>
> I am getting started with Ettus E110, and I would like to get any
> information or document about clock synchronization among two USRP(E110)
> without GPS module and/or octoclock. Actually, I would like to know if can
> I set internal clock and export (via e.g. set_time_source_out) in order to
> synchronize the USRP?
>
> Any help would be appreciated.
> Thanks in advanced.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151204/d341f5a9/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 4 Dec 2015 20:59:08 +0300
> From: ??????? ??????? <evgeniy.miron...@mail.ru>
> To: usrp-users@lists.ettus.com
> Subject: [USRP-users] USRP2 B210. Problems with new bin-files
> Message-ID:
> <cajon6qzrfvvrxurfpmpiacsqxsbmdtymqa3ppmp9ne7_ueb...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello!
> I have a board USRP B210 and software SDRSharp. When I use file
> "usrp_b200_fw.hex" (size 593139 bytes) from
> "uhd-images_003.007.000-70-gfcc85c95.zip" everything is fine.
> 1 When I try to use file "usrp_b200_fw.hex" (size 365222 bytes) from
> "uhd-images_003.009.rfnoc-381-gb15afd60.zip" I see next error message:
> -----------------------------------------
> Failed to create device without device hint:
>
> While creating UHD device: RuntimeError: Expected firmware compatibility
> number 0x4, but got 0x7.0:
> The firmware build is not compatible with the host code build.
> As an Administrator, please run:
>
> "C:\Program Files (x86)\UHD\lib\uhd\utils\uhd_images_downloader.py"
> -----------------------------------------
> 2 When I try to use new bin-image "usrp_b210_fpga.bin" (size 4222424 bytes)
> from "uhd-images_003.009.rfnoc-381-gb15afd60.zip" result is not good. I see
> ----------------------------------------
> Failed to create device without device hint:
>
> While creating UHD device: RuntimeError: Expected FPGA compatibility number
> 0x3, but got 0x4.0:
> The FPGA build is not compatible with the host code build.
> As an Administrator, please run:
>
> "C:\Program Files (x86)\UHD\lib\uhd\utils\uhd_images_downloader.py"
> ----------------------------------------
>
> Why? New images are not work correctly now? Perhaps any recomendations are
> required for using new images additionally "for dummers"?
> Thanks in advance for any answers.
> Regards, Evgeniy
>
> P.S.: My OS is Windows 7.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151204/780cc4c7/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 04 Dec 2015 22:39:42 +0000
> From: Nick Foster <bistrom...@gmail.com>
> To: Eugene Chai <eug...@nec-labs.com>, Martin Braun
> <martin.br...@ettus.com>
> Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] UHD and RFNoC engines
> Message-ID:
> <ca+jmmq8qwra_ndxgnjyl9kuxewud4b8decbfn-awewpl7ve...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Guys,
>
> Just resurrecting this thread because I don't completely understand when
> it's necessary to use the uhd::device3 handle instead of the
> uhd::multi_usrp handle. Can someone provide some clarification? I
> experienced the same issue Eugene did, and I've solved it in the same way,
> but a) I don't understand what the underlying necessity is, b) it wasn't a
> problem before, and c) there's still some lingering problems in my
> code (samples
> not streaming) as I migrated it to the most recent UHD.
>
> Any hints?
>
> --n
>
> On Wed, Nov 11, 2015 at 1:46 PM Eugene Chai via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi Martin,
>>
>> I got this to work. It was a mistake on my part. I used
>> ?device->get_tx_streamer? instead of ?device3->get_tx_streamer?.
>>
>> Thanks,
>> Eugene
>>
>>>> On Nov 11, 2015, at 1:39 PM, Martin Braun <martin.br...@ettus.com>
>>> wrote:
>>>
>>> You're trying to construct a streamer with 4 parallel channels, but
>>> aren't specifying how to address individual blocks.
>>>
>>> Are you using set_tx_channel() / set_rx_channel()?
>>>
>>> M
>>>
>>>
>>>> On 10.11.2015 16:45, Eugene Chai wrote:
>>>> Hi Martin,
>>>>
>>>> Yes, ?uhd_usrp_probe ?init-only? works. I?ve attached the output here.
>>>>
>>>> Thanks,
>>>> Eugene
>>>>
>>>>
>>>>
>>>>> On Nov 10, 2015, at 7:02 PM, Martin Braun <martin.br...@ettus.com>
>> wrote:
>>>>>
>>>>> Eugene,
>>>>>
>>>>> does uhd_usrp_probe work, and if so, can you post the output of
>>>>> 'uhd_usrp_probe --init-only'?
>>>>>
>>>>> Thanks,
>>>>> Martin
>>>>>
>>>>>> On 09.11.2015 21:54, Eugene Chai via USRP-users wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I encountered a problem when attempting to use a new RFNoC CE with
>> UHD on a X310.
>>>>>>
>>>>>> I have a custom RFNoC CE with 4 inputs and 2 outputs. In order to
>> use this with UHD, I setup 6 channels (4 input and 2 output), and
>> associated a FIFO block with each channel (via ?set_tx_channel? and
>> ?set_rx_channel?). I modified the firmware to include 6 FIFO blocks and
>> removed the null source/sink, addsub, vector_iir, keep_one_in_n, and
>> fosphor blocks. The FIFO blocks are connected to the input and output
>> ports of the custom CE. I then setup the Tx and Rx streamers with 4 and 2
>> channels respectively. However, the streamer setup function call
>> consistently fails. As an example, the Rx streamer setup fails with the
>> following error:
>>>>>>
>>>>>> Error: LookupError: IndexError: multi_usrp::get_rx_subdev_spec(0)
>> failed to make default spec - LookupError: Path not found in tree:
>> /channels/rx/2/args
>>>>>>
>>>>>> The Tx streamer setup fails with:
>>>>>>
>>>>>> Error: LookupError: IndexError: multi_usrp::get_tx_subdev_spec(0)
>> failed to make default spec - LookupError: Path not found in tree:
>> /channels/tx/4/args
>>>>>>
>>>>>> The code used to setup the tx and rx streamers is
>>>>>>
>>>>>> std::cout << "Constructing Tx streamer..." << std::endl;
>>>>>> std::vector<size_t> tx_channels {0,1,2,3};
>>>>>> uhd::stream_args_t tx_stream_args("sc16", "sc16");
>>>>>> tx_stream_args.channels = tx_channels;
>>>>>> uhd::tx_streamer::sptr tx_stream =
>> usrp->get_tx_stream(tx_stream_args);
>>>>>>
>>>>>> std::cout << "Constructing Rx streamer..." << std::endl;
>>>>>> std::vector<size_t> rx_channels {0,1};
>>>>>> uhd::stream_args_t rx_stream_args("sc16", "sc16");
>>>>>> rx_stream_args.channels = rx_channels;
>>>>>> uhd::rx_streamer::sptr rx_stream =
>> usrp->get_rx_stream(rx_stream_args);
>>>>>>
>>>>>> Can anyone tell me how I can fix this?
>>>>>>
>>>>>> Thanks,
>>>>>> Eugene
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> USRP-users@lists.ettus.com
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151204/1eef9094/attachment-0001.html>
>
> ------------------------------
>
> Message: 5
> Date: Fri, 4 Dec 2015 14:54:55 -0800
> From: Martin Braun <martin.br...@ettus.com>
> To: Nick Foster <bistrom...@gmail.com>, Eugene Chai
> <eug...@nec-labs.com>
> Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] UHD and RFNoC engines
> Message-ID: <566219bf.9020...@ettus.com>
> Content-Type: text/plain; charset=utf-8
>
> There's a bug somewhere in here, and I agree that
> multi_usrp::get_rx_stream() should work. The problem is that multi_usrp
> is kind of stuck in a pre-RFNoC framework, and doesn't always do the
> right thing with an RFNoC-based device. This'll become more important in
> the future, and we'll add some backward-compatibility layer to make the
> transition seamless and hassle-free.
>
> However, there's a good reason we have device and device3. Old device
> code made certain assumptions about a device topology that simply aren't
> true anymore. This is why multi_usrp::get_tx_stream() fails, because it
> adds some checks that are handled elsewhere for the RFNoC case.
>
> If you do the device3::get_tx_stream(), you end up in the correct code
> path. An easy fix we can provide immediately is to check if we're a
> device3 or not and do the right thing. However, at some point the
> multi_usrp design might simply not cut it anymore and you need to switch
> to more modular solutions as provided by RFNoC. But that's our job to
> make that obvious and easy, and we'll fix this first and then provide
> more examples.
>
> Cheers,
> Martin
>
>> On 04.12.2015 14:39, Nick Foster wrote:
>> Guys,
>>
>> Just resurrecting this thread because I don't completely understand when
>> it's necessary to use the uhd::device3 handle instead of the
>> uhd::multi_usrp handle. Can someone provide some clarification? I
>> experienced the same issue Eugene did, and I've solved it in the same
>> way, but a) I don't understand what the underlying necessity is, b) it
>> wasn't a problem before, and c) there's still some lingering problems in
>> my code (samples not streaming) as I migrated it to the most recent UHD.
>>
>> Any hints?
>>
>> --n
>>
>> On Wed, Nov 11, 2015 at 1:46 PM Eugene Chai via USRP-users
>> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>>
>> Hi Martin,
>>
>> I got this to work. It was a mistake on my part. I used
>> ?device->get_tx_streamer? instead of ?device3->get_tx_streamer?.
>>
>> Thanks,
>> Eugene
>>
>>>> On Nov 11, 2015, at 1:39 PM, Martin Braun <martin.br...@ettus.com
>>> <mailto:martin.br...@ettus.com>> wrote:
>>>
>>> You're trying to construct a streamer with 4 parallel channels, but
>>> aren't specifying how to address individual blocks.
>>>
>>> Are you using set_tx_channel() / set_rx_channel()?
>>>
>>> M
>>>
>>>
>>>> On 10.11.2015 16:45, Eugene Chai wrote:
>>>> Hi Martin,
>>>>
>>>> Yes, ?uhd_usrp_probe ?init-only? works. I?ve attached the output
>> here.
>>>>
>>>> Thanks,
>>>> Eugene
>>>>
>>>>
>>>>
>>>>> On Nov 10, 2015, at 7:02 PM, Martin Braun
>> <martin.br...@ettus.com <mailto:martin.br...@ettus.com>> wrote:
>>>>>
>>>>> Eugene,
>>>>>
>>>>> does uhd_usrp_probe work, and if so, can you post the output of
>>>>> 'uhd_usrp_probe --init-only'?
>>>>>
>>>>> Thanks,
>>>>> Martin
>>>>>
>>>>>> On 09.11.2015 21:54, Eugene Chai via USRP-users wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I encountered a problem when attempting to use a new RFNoC CE
>> with UHD on a X310.
>>>>>>
>>>>>> I have a custom RFNoC CE with 4 inputs and 2 outputs. In order
>> to use this with UHD, I setup 6 channels (4 input and 2 output), and
>> associated a FIFO block with each channel (via ?set_tx_channel? and
>> ?set_rx_channel?). I modified the firmware to include 6 FIFO blocks
>> and removed the null source/sink, addsub, vector_iir, keep_one_in_n,
>> and fosphor blocks. The FIFO blocks are connected to the input and
>> output ports of the custom CE. I then setup the Tx and Rx streamers
>> with 4 and 2 channels respectively. However, the streamer setup
>> function call consistently fails. As an example, the Rx streamer
>> setup fails with the following error:
>>>>>>
>>>>>> Error: LookupError: IndexError:
>> multi_usrp::get_rx_subdev_spec(0) failed to make default spec -
>> LookupError: Path not found in tree: /channels/rx/2/args
>>>>>>
>>>>>> The Tx streamer setup fails with:
>>>>>>
>>>>>> Error: LookupError: IndexError:
>> multi_usrp::get_tx_subdev_spec(0) failed to make default spec -
>> LookupError: Path not found in tree: /channels/tx/4/args
>>>>>>
>>>>>> The code used to setup the tx and rx streamers is
>>>>>>
>>>>>> std::cout << "Constructing Tx streamer..." << std::endl;
>>>>>> std::vector<size_t> tx_channels {0,1,2,3};
>>>>>> uhd::stream_args_t tx_stream_args("sc16", "sc16");
>>>>>> tx_stream_args.channels = tx_channels;
>>>>>> uhd::tx_streamer::sptr tx_stream =
>> usrp->get_tx_stream(tx_stream_args);
>>>>>>
>>>>>> std::cout << "Constructing Rx streamer..." << std::endl;
>>>>>> std::vector<size_t> rx_channels {0,1};
>>>>>> uhd::stream_args_t rx_stream_args("sc16", "sc16");
>>>>>> rx_stream_args.channels = rx_channels;
>>>>>> uhd::rx_streamer::sptr rx_stream =
>> usrp->get_rx_stream(rx_stream_args);
>>>>>>
>>>>>> Can anyone tell me how I can fix this?
>>>>>>
>>>>>> Thanks,
>>>>>> Eugene
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 4 Dec 2015 15:16:14 -0800
> From: Michael West <michael.w...@ettus.com>
> To: Sanjoy Basak <sanjoybasa...@gmail.com>
> Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] time accuracy at 100 MSps with X310
> Message-ID:
> <CAM4xKromqj6jh7uo8q-y_AeeC1V760oYD9+EQWJAnGrp+=0...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Sanjoy,
>
> Can you explain what a bin is and how exactly you are measuring the start
> point?
>
> Regards,
> Michael
>
> On Fri, Dec 4, 2015 at 6:12 AM, Sanjoy Basak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all,
>> I am trying to get time sync with 1 X310 at 100 MSps for 1Tx 1 Rx with
>> SBX-120 daughterboards. I used gpsdo as time and freq ref.
>> With my application time sync worked fine till 25 MSps. With 50 MSps, I
>> got the similar problem as with 100 MSps.
>>
>> I don't see any latency error at 100 MSps. No underrun/late packet. But
>> the start point is varying.
>> For example, I took 17 measurements. I got start bin 119 -> 4 times; 120
>> ->6 times; 121 ->6 times; 122 -> 1 time;
>> So, mostly the start point is varying in between 3 bins.
>> What I require is, a constant start point, which does not vary with
>> initiations.
>>
>> I am doing offline processing. I put my matlab generated binary file in
>> ramdisk and then file open and putting into buffer and then repeating the
>> buffer for transmission. At receive side, I am storing with file sink and
>> saving the file in another ramdisk. Finally processing with matlab.
>>
>> I am using uhd source and sink and using set_start_time for time sync.
>>
>> I am using uhd 3.10 and fpga HG image.
>> Please let me know how to solve this problem and also let me know if you
>> need more information about setup.
>> My OS is ubuntu 14.4.3
>>
>> best regards
>> Sanjoy
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151204/9a2f6842/attachment-0001.html>
>
> ------------------------------
>
> Message: 7
> Date: Fri, 4 Dec 2015 18:18:31 -0500
> From: James Humphries <james.humphr...@ettus.com>
> To: ??????? ??????? <evgeniy.miron...@mail.ru>
> Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] USRP2 B210. Problems with new bin-files
> Message-ID:
> <CAEwGFhVMiEfiJk73a6NFCo11nyZM=ddem538oyundyymvf1...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Evgeniy,
>
> UHD checks the FPGA and firmware for compatibility numbers to ensure that
> UHD is compatible with the current FPGA/firmware images. UHD and the FPGA
> are updated in 'lockstep' and that means that whatever version of UHD you
> have installed will expect a certain version of the FPGA and firmware. The
> FPGA designs evolve over time with improvements and added features which
> are not always compatible with older versions of UHD.
>
> You are trying to use FPGA and firmware images that are compatible with
> only the most recent releases of UHD. It appears that you computer has
> version 3.7.0 installed (which is pretty old at this point). If you want to
> use the newest FPGA images you will have to update UHD on your computer.
>
> I have not used SDR#, and maybe someone else can clarify, but does it
> bundle UHD with its installer. It may only be compatible with an older
> version of UHD and images.
>
> -Trip
>
>
> On Fri, Dec 4, 2015 at 12:59 PM, ??????? ??????? <usrp-users@lists.ettus.com
>> wrote:
>
>> Hello!
>> I have a board USRP B210 and software SDRSharp. When I use file
>> "usrp_b200_fw.hex" (size 593139 bytes) from
>> "uhd-images_003.007.000-70-gfcc85c95.zip" everything is fine.
>> 1 When I try to use file "usrp_b200_fw.hex" (size 365222 bytes) from
>> "uhd-images_003.009.rfnoc-381-gb15afd60.zip" I see next error message:
>> -----------------------------------------
>> Failed to create device without device hint:
>>
>> While creating UHD device: RuntimeError: Expected firmware compatibility
>> number 0x4, but got 0x7.0:
>> The firmware build is not compatible with the host code build.
>> As an Administrator, please run:
>>
>> "C:\Program Files (x86)\UHD\lib\uhd\utils\uhd_images_downloader.py"
>> -----------------------------------------
>> 2 When I try to use new bin-image "usrp_b210_fpga.bin" (size 4222424
>> bytes) from "uhd-images_003.009.rfnoc-381-gb15afd60.zip" result is not
>> good. I see
>> ----------------------------------------
>> Failed to create device without device hint:
>>
>> While creating UHD device: RuntimeError: Expected FPGA compatibility
>> number 0x3, but got 0x4.0:
>> The FPGA build is not compatible with the host code build.
>> As an Administrator, please run:
>>
>> "C:\Program Files (x86)\UHD\lib\uhd\utils\uhd_images_downloader.py"
>> ----------------------------------------
>>
>> Why? New images are not work correctly now? Perhaps any recomendations are
>> required for using new images additionally "for dummers"?
>> Thanks in advance for any answers.
>> Regards, Evgeniy
>>
>> P.S.: My OS is Windows 7.
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151204/c1566b84/attachment-0001.html>
>
> ------------------------------
>
> Message: 8
> Date: Sat, 5 Dec 2015 00:39:48 +0100
> From: Sanjoy Basak <sanjoybasa...@gmail.com>
> To: Michael West <michael.w...@ettus.com>
> Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] time accuracy at 100 MSps with X310
> Message-ID:
> <CAJPQ1a3w8a4fLGfsT6=p_noyw6ofqb_ikfbduk4zykn8sx2...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Michael,
> I am transmitting OFDM signal and after receiving I am checking the start
> point by cross correlation of Rx(receive) and Tx(transmit) signal in
> matlab.
> I am saving the Rx signal in binary format. The start point of signal, I
> referred as the 119th bin/ 120th bin. (or 119th/120th complex data--which
> shows the start point of signal from cross correlation).
> In general, what I get is, for example with 25 MSps, the start point to be
> 49th (I forgot the exact number) bin and this is constant. (from 1-48th bin
> all zeros)
>
> So, basically what I meant was, the start point I found varying and not
> stable at 100 MSps.
>
> Regards
> Sanjoy
>
> On Sat, Dec 5, 2015 at 12:16 AM, Michael West <michael.w...@ettus.com>
> wrote:
>
>> Hi Sanjoy,
>>
>> Can you explain what a bin is and how exactly you are measuring the start
>> point?
>>
>> Regards,
>> Michael
>>
>> On Fri, Dec 4, 2015 at 6:12 AM, Sanjoy Basak via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi all,
>>> I am trying to get time sync with 1 X310 at 100 MSps for 1Tx 1 Rx with
>>> SBX-120 daughterboards. I used gpsdo as time and freq ref.
>>> With my application time sync worked fine till 25 MSps. With 50 MSps, I
>>> got the similar problem as with 100 MSps.
>>>
>>> I don't see any latency error at 100 MSps. No underrun/late packet. But
>>> the start point is varying.
>>> For example, I took 17 measurements. I got start bin 119 -> 4 times; 120
>>> ->6 times; 121 ->6 times; 122 -> 1 time;
>>> So, mostly the start point is varying in between 3 bins.
>>> What I require is, a constant start point, which does not vary with
>>> initiations.
>>>
>>> I am doing offline processing. I put my matlab generated binary file in
>>> ramdisk and then file open and putting into buffer and then repeating the
>>> buffer for transmission. At receive side, I am storing with file sink and
>>> saving the file in another ramdisk. Finally processing with matlab.
>>>
>>> I am using uhd source and sink and using set_start_time for time sync.
>>>
>>> I am using uhd 3.10 and fpga HG image.
>>> Please let me know how to solve this problem and also let me know if you
>>> need more information about setup.
>>> My OS is ubuntu 14.4.3
>>>
>>> best regards
>>> Sanjoy
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151205/859635e3/attachment-0001.html>
>
> ------------------------------
>
> Message: 9
> Date: Fri, 4 Dec 2015 15:52:47 -0800
> From: Michael West <michael.w...@ettus.com>
> To: Sanjoy Basak <sanjoybasa...@gmail.com>
> Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] time accuracy at 100 MSps with X310
> Message-ID:
> <cam4xkrqtwfckcueutmoz_dvxjoduahz1eqqxm3ng9npimbt...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Sanjoy,
>
> Are you looping back on the same device through a cable or over the air?
> If not, how are you time synchronizing the transmitter and the receiver?
> Are you verifying that you have a GPS lock?
>
> The GPSDO has a tolerance of about +/- 50ns once locked, so that is the
> tolerance of your start time if you are using separate devices for transmit
> and receive and are using GPSDO to synchronize their times. It may take
> several minutes to obtain a stable GPS lock and the time will get more
> accurate the longer the lock is held.
>
> Regards,
> Michael
>
> On Fri, Dec 4, 2015 at 3:39 PM, Sanjoy Basak <sanjoybasa...@gmail.com>
> wrote:
>
>> Hi Michael,
>> I am transmitting OFDM signal and after receiving I am checking the start
>> point by cross correlation of Rx(receive) and Tx(transmit) signal in
>> matlab.
>> I am saving the Rx signal in binary format. The start point of signal, I
>> referred as the 119th bin/ 120th bin. (or 119th/120th complex data--which
>> shows the start point of signal from cross correlation).
>> In general, what I get is, for example with 25 MSps, the start point to be
>> 49th (I forgot the exact number) bin and this is constant. (from 1-48th bin
>> all zeros)
>>
>> So, basically what I meant was, the start point I found varying and not
>> stable at 100 MSps.
>>
>> Regards
>> Sanjoy
>>
>> On Sat, Dec 5, 2015 at 12:16 AM, Michael West <michael.w...@ettus.com>
>> wrote:
>>
>>> Hi Sanjoy,
>>>
>>> Can you explain what a bin is and how exactly you are measuring the start
>>> point?
>>>
>>> Regards,
>>> Michael
>>>
>>> On Fri, Dec 4, 2015 at 6:12 AM, Sanjoy Basak via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
>>>> Hi all,
>>>> I am trying to get time sync with 1 X310 at 100 MSps for 1Tx 1 Rx with
>>>> SBX-120 daughterboards. I used gpsdo as time and freq ref.
>>>> With my application time sync worked fine till 25 MSps. With 50 MSps, I
>>>> got the similar problem as with 100 MSps.
>>>>
>>>> I don't see any latency error at 100 MSps. No underrun/late packet. But
>>>> the start point is varying.
>>>> For example, I took 17 measurements. I got start bin 119 -> 4 times; 120
>>>> ->6 times; 121 ->6 times; 122 -> 1 time;
>>>> So, mostly the start point is varying in between 3 bins.
>>>> What I require is, a constant start point, which does not vary with
>>>> initiations.
>>>>
>>>> I am doing offline processing. I put my matlab generated binary file in
>>>> ramdisk and then file open and putting into buffer and then repeating the
>>>> buffer for transmission. At receive side, I am storing with file sink and
>>>> saving the file in another ramdisk. Finally processing with matlab.
>>>>
>>>> I am using uhd source and sink and using set_start_time for time sync.
>>>>
>>>> I am using uhd 3.10 and fpga HG image.
>>>> Please let me know how to solve this problem and also let me know if you
>>>> need more information about setup.
>>>> My OS is ubuntu 14.4.3
>>>>
>>>> best regards
>>>> Sanjoy
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> USRP-users@lists.ettus.com
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151204/3ed0e8d9/attachment-0001.html>
>
> ------------------------------
>
> Message: 10
> Date: Sat, 5 Dec 2015 01:16:28 +0100
> From: Sanjoy Basak <sanjoybasa...@gmail.com>
> To: Michael West <michael.w...@ettus.com>
> Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] time accuracy at 100 MSps with X310
> Message-ID:
> <cajpq1a2hyaxxkbecxugfy7osfwm2w9s0zxm4s5xx_14zsan...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Micheal,
> I am using 1 X310, TX and RX ports on different daughterboards. TX and RX
> is connected with a 40 cm cable and a 30 dB attenuator. I am not using gps
> signal.
> For time and freq reference I am using GPSDO.
>
> Could you please explain more about the tolerance for 1 X310 on GPSDO?
> If I am trying to get timing accuracy or a constant start time/start point
> with 100 MSps, which means I require time accuracy of 10 ns. What I mean
> is, if I am defining start time to be 1.5 seconds after startup with
> (Tx.set_start_time(uhd.time_spec(1.5)) and same for Rx), both TX and RX
> port starts exactly at that time not 10 ns after or before that and with
> every initiation this is constant.
> Is that possible?
>
> Regards
> Sanjoy
>
> On Sat, Dec 5, 2015 at 12:52 AM, Michael West <michael.w...@ettus.com>
> wrote:
>
>> Hi Sanjoy,
>>
>> Are you looping back on the same device through a cable or over the air?
>> If not, how are you time synchronizing the transmitter and the receiver?
>> Are you verifying that you have a GPS lock?
>>
>> The GPSDO has a tolerance of about +/- 50ns once locked, so that is the
>> tolerance of your start time if you are using separate devices for transmit
>> and receive and are using GPSDO to synchronize their times. It may take
>> several minutes to obtain a stable GPS lock and the time will get more
>> accurate the longer the lock is held.
>>
>> Regards,
>> Michael
>>
>> On Fri, Dec 4, 2015 at 3:39 PM, Sanjoy Basak <sanjoybasa...@gmail.com>
>> wrote:
>>
>>> Hi Michael,
>>> I am transmitting OFDM signal and after receiving I am checking the start
>>> point by cross correlation of Rx(receive) and Tx(transmit) signal in
>>> matlab.
>>> I am saving the Rx signal in binary format. The start point of signal, I
>>> referred as the 119th bin/ 120th bin. (or 119th/120th complex data--which
>>> shows the start point of signal from cross correlation).
>>> In general, what I get is, for example with 25 MSps, the start point to
>>> be 49th (I forgot the exact number) bin and this is constant. (from 1-48th
>>> bin all zeros)
>>>
>>> So, basically what I meant was, the start point I found varying and not
>>> stable at 100 MSps.
>>>
>>> Regards
>>> Sanjoy
>>>
>>> On Sat, Dec 5, 2015 at 12:16 AM, Michael West <michael.w...@ettus.com>
>>> wrote:
>>>
>>>> Hi Sanjoy,
>>>>
>>>> Can you explain what a bin is and how exactly you are measuring the
>>>> start point?
>>>>
>>>> Regards,
>>>> Michael
>>>>
>>>> On Fri, Dec 4, 2015 at 6:12 AM, Sanjoy Basak via USRP-users <
>>>> usrp-users@lists.ettus.com> wrote:
>>>>
>>>>> Hi all,
>>>>> I am trying to get time sync with 1 X310 at 100 MSps for 1Tx 1 Rx with
>>>>> SBX-120 daughterboards. I used gpsdo as time and freq ref.
>>>>> With my application time sync worked fine till 25 MSps. With 50 MSps, I
>>>>> got the similar problem as with 100 MSps.
>>>>>
>>>>> I don't see any latency error at 100 MSps. No underrun/late packet. But
>>>>> the start point is varying.
>>>>> For example, I took 17 measurements. I got start bin 119 -> 4 times;
>>>>> 120 ->6 times; 121 ->6 times; 122 -> 1 time;
>>>>> So, mostly the start point is varying in between 3 bins.
>>>>> What I require is, a constant start point, which does not vary with
>>>>> initiations.
>>>>>
>>>>> I am doing offline processing. I put my matlab generated binary file in
>>>>> ramdisk and then file open and putting into buffer and then repeating the
>>>>> buffer for transmission. At receive side, I am storing with file sink and
>>>>> saving the file in another ramdisk. Finally processing with matlab.
>>>>>
>>>>> I am using uhd source and sink and using set_start_time for time sync.
>>>>>
>>>>> I am using uhd 3.10 and fpga HG image.
>>>>> Please let me know how to solve this problem and also let me know if
>>>>> you need more information about setup.
>>>>> My OS is ubuntu 14.4.3
>>>>>
>>>>> best regards
>>>>> Sanjoy
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> USRP-users@lists.ettus.com
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151205/c9d32639/attachment-0001.html>
>
> ------------------------------
>
> Message: 11
> Date: Fri, 4 Dec 2015 16:30:48 -0800
> From: Michael West <michael.w...@ettus.com>
> To: Sanjoy Basak <sanjoybasa...@gmail.com>
> Cc: "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] time accuracy at 100 MSps with X310
> Message-ID:
> <CAM4xKro=5l6qth3y-epri8hvrkdoj+bgqf_r7wtls7o2m2g...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Sanjoy,
>
> The +/- 50ns tolerance only applies to GPSDOs on separate devices. On the
> same device there will be no variance.
>
> You can use the internal (default) clock and time sources if you are using
> a single device, but you need to make sure you set the times on the
> radios. Make sure your source and sink blocks have the Sync set to
> "unknown PPS" and that will synchronize the times across the radios. And
> change the start time to be relative to the current time (i.e.
> Tx.set_start_time(Tx.get_time_now() + uhd.time_spec(1.5)).
>
> Regards,
> Michael
>
> On Fri, Dec 4, 2015 at 4:16 PM, Sanjoy Basak <sanjoybasa...@gmail.com>
> wrote:
>
>> Hi Micheal,
>> I am using 1 X310, TX and RX ports on different daughterboards. TX and RX
>> is connected with a 40 cm cable and a 30 dB attenuator. I am not using gps
>> signal.
>> For time and freq reference I am using GPSDO.
>>
>> Could you please explain more about the tolerance for 1 X310 on GPSDO?
>> If I am trying to get timing accuracy or a constant start time/start point
>> with 100 MSps, which means I require time accuracy of 10 ns. What I mean
>> is, if I am defining start time to be 1.5 seconds after startup with
>> (Tx.set_start_time(uhd.time_spec(1.5)) and same for Rx), both TX and RX
>> port starts exactly at that time not 10 ns after or before that and with
>> every initiation this is constant.
>> Is that possible?
>>
>> Regards
>> Sanjoy
>>
>> On Sat, Dec 5, 2015 at 12:52 AM, Michael West <michael.w...@ettus.com>
>> wrote:
>>
>>> Hi Sanjoy,
>>>
>>> Are you looping back on the same device through a cable or over the air?
>>> If not, how are you time synchronizing the transmitter and the receiver?
>>> Are you verifying that you have a GPS lock?
>>>
>>> The GPSDO has a tolerance of about +/- 50ns once locked, so that is the
>>> tolerance of your start time if you are using separate devices for transmit
>>> and receive and are using GPSDO to synchronize their times. It may take
>>> several minutes to obtain a stable GPS lock and the time will get more
>>> accurate the longer the lock is held.
>>>
>>> Regards,
>>> Michael
>>>
>>> On Fri, Dec 4, 2015 at 3:39 PM, Sanjoy Basak <sanjoybasa...@gmail.com>
>>> wrote:
>>>
>>>> Hi Michael,
>>>> I am transmitting OFDM signal and after receiving I am checking the
>>>> start point by cross correlation of Rx(receive) and Tx(transmit) signal in
>>>> matlab.
>>>> I am saving the Rx signal in binary format. The start point of signal, I
>>>> referred as the 119th bin/ 120th bin. (or 119th/120th complex data--which
>>>> shows the start point of signal from cross correlation).
>>>> In general, what I get is, for example with 25 MSps, the start point to
>>>> be 49th (I forgot the exact number) bin and this is constant. (from 1-48th
>>>> bin all zeros)
>>>>
>>>> So, basically what I meant was, the start point I found varying and not
>>>> stable at 100 MSps.
>>>>
>>>> Regards
>>>> Sanjoy
>>>>
>>>> On Sat, Dec 5, 2015 at 12:16 AM, Michael West <michael.w...@ettus.com>
>>>> wrote:
>>>>
>>>>> Hi Sanjoy,
>>>>>
>>>>> Can you explain what a bin is and how exactly you are measuring the
>>>>> start point?
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>> On Fri, Dec 4, 2015 at 6:12 AM, Sanjoy Basak via USRP-users <
>>>>> usrp-users@lists.ettus.com> wrote:
>>>>>
>>>>>> Hi all,
>>>>>> I am trying to get time sync with 1 X310 at 100 MSps for 1Tx 1 Rx with
>>>>>> SBX-120 daughterboards. I used gpsdo as time and freq ref.
>>>>>> With my application time sync worked fine till 25 MSps. With 50 MSps,
>>>>>> I got the similar problem as with 100 MSps.
>>>>>>
>>>>>> I don't see any latency error at 100 MSps. No underrun/late packet.
>>>>>> But the start point is varying.
>>>>>> For example, I took 17 measurements. I got start bin 119 -> 4 times;
>>>>>> 120 ->6 times; 121 ->6 times; 122 -> 1 time;
>>>>>> So, mostly the start point is varying in between 3 bins.
>>>>>> What I require is, a constant start point, which does not vary with
>>>>>> initiations.
>>>>>>
>>>>>> I am doing offline processing. I put my matlab generated binary file
>>>>>> in ramdisk and then file open and putting into buffer and then repeating
>>>>>> the buffer for transmission. At receive side, I am storing with file sink
>>>>>> and saving the file in another ramdisk. Finally processing with matlab.
>>>>>>
>>>>>> I am using uhd source and sink and using set_start_time for time sync.
>>>>>>
>>>>>> I am using uhd 3.10 and fpga HG image.
>>>>>> Please let me know how to solve this problem and also let me know if
>>>>>> you need more information about setup.
>>>>>> My OS is ubuntu 14.4.3
>>>>>>
>>>>>> best regards
>>>>>> Sanjoy
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> USRP-users@lists.ettus.com
>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151204/bd8954ae/attachment-0001.html>
>
> ------------------------------
>
> Message: 12
> Date: Fri, 4 Dec 2015 17:17:29 -0800
> From: Derek Kozel <derek.ko...@ettus.com>
> To: James Humphries <james.humphr...@ettus.com>
> Cc: ??????? ??????? <evgeniy.miron...@mail.ru>,
> "USRP-users@lists.ettus.com" <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] USRP2 B210. Problems with new bin-files
> Message-ID:
> <CAA+K=ttbo8smmA+Y_tReFYKEQrRiO-N9WgK=_dtt2d+ddvy...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello Evgeniy,
>
> SDR# uses EXTIO as an interface to UHD. EXTIO is no longer maintained by
> it's author and so an older version of UHD is required as you found. You
> will be unable to use SDR# with more recent versions of UHD unfortunately.
> Hopefully someone will update it in the future.
>
> http://wiki.spench.net/wiki/ExtIO_USRP
>
> Regards,
> Derek
>
> On Fri, Dec 4, 2015 at 3:18 PM, James Humphries via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi Evgeniy,
>>
>> UHD checks the FPGA and firmware for compatibility numbers to ensure that
>> UHD is compatible with the current FPGA/firmware images. UHD and the FPGA
>> are updated in 'lockstep' and that means that whatever version of UHD you
>> have installed will expect a certain version of the FPGA and firmware. The
>> FPGA designs evolve over time with improvements and added features which
>> are not always compatible with older versions of UHD.
>>
>> You are trying to use FPGA and firmware images that are compatible with
>> only the most recent releases of UHD. It appears that you computer has
>> version 3.7.0 installed (which is pretty old at this point). If you want to
>> use the newest FPGA images you will have to update UHD on your computer.
>>
>> I have not used SDR#, and maybe someone else can clarify, but does it
>> bundle UHD with its installer. It may only be compatible with an older
>> version of UHD and images.
>>
>> -Trip
>>
>>
>> On Fri, Dec 4, 2015 at 12:59 PM, ??????? ??????? <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello!
>>> I have a board USRP B210 and software SDRSharp. When I use file
>>> "usrp_b200_fw.hex" (size 593139 bytes) from
>>> "uhd-images_003.007.000-70-gfcc85c95.zip" everything is fine.
>>> 1 When I try to use file "usrp_b200_fw.hex" (size 365222 bytes) from
>>> "uhd-images_003.009.rfnoc-381-gb15afd60.zip" I see next error message:
>>> -----------------------------------------
>>> Failed to create device without device hint:
>>>
>>> While creating UHD device: RuntimeError: Expected firmware compatibility
>>> number 0x4, but got 0x7.0:
>>> The firmware build is not compatible with the host code build.
>>> As an Administrator, please run:
>>>
>>> "C:\Program Files (x86)\UHD\lib\uhd\utils\uhd_images_downloader.py"
>>> -----------------------------------------
>>> 2 When I try to use new bin-image "usrp_b210_fpga.bin" (size 4222424
>>> bytes) from "uhd-images_003.009.rfnoc-381-gb15afd60.zip" result is not
>>> good. I see
>>> ----------------------------------------
>>> Failed to create device without device hint:
>>>
>>> While creating UHD device: RuntimeError: Expected FPGA compatibility
>>> number 0x3, but got 0x4.0:
>>> The FPGA build is not compatible with the host code build.
>>> As an Administrator, please run:
>>>
>>> "C:\Program Files (x86)\UHD\lib\uhd\utils\uhd_images_downloader.py"
>>> ----------------------------------------
>>>
>>> Why? New images are not work correctly now? Perhaps any recomendations
>>> are required for using new images additionally "for dummers"?
>>> Thanks in advance for any answers.
>>> Regards, Evgeniy
>>>
>>> P.S.: My OS is Windows 7.
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151204/9209733f/attachment-0001.html>
>
> ------------------------------
>
> Message: 13
> Date: Fri, 4 Dec 2015 17:29:50 -0800
> From: Derek Kozel <derek.ko...@ettus.com>
> To: Rafael Augusto <rafael.asilvacoe...@gmail.com>
> Cc: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
> Subject: Re: [USRP-users] USRP E110 sync clock
> Message-ID:
> <CAA+K=tvqkiMPcdyH=vs6tanor6ckdj6nueecszjqxtga5c7...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello Rafael,
>
> What accuracy of time synchronization do you need? Without supplying the
> same 1PPS signal to both E110s you will be unable to get better accuracy
> than 1 second using only software methods. There will always be some drift
> between internal clocks in different USRPs so the repeated, synchronized
> input is needed to discipline them. You don't need an octoclock or internal
> GPS modules, but you do need some source of 1PPS and a splitter at least.
> There are a wide variety of GPS development boards which can output 1PPS
> signals, some more conveniently than others.
>
> Regards,
> Derek
>
> On Fri, Dec 4, 2015 at 9:06 AM, Rafael Augusto via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi everyone,
>>
>> I am getting started with Ettus E110, and I would like to get any
>> information or document about clock synchronization among two USRP(E110)
>> without GPS module and/or octoclock. Actually, I would like to know if can
>> I set internal clock and export (via e.g. set_time_source_out) in order to
>> synchronize the USRP?
>>
>> Any help would be appreciated.
>> Thanks in advanced.
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151204/76e279fe/attachment-0001.html>
>
> ------------------------------
>
> Message: 14
> Date: Fri, 04 Dec 2015 20:41:41 -0500
> From: "Marcus D. Leech" <mle...@ripnet.com>
> To: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] USRP E110 sync clock
> Message-ID: <566240d5.2080...@ripnet.com>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
>> On 12/04/2015 08:29 PM, Derek Kozel via USRP-users wrote:
>> Hello Rafael,
>>
>> What accuracy of time synchronization do you need? Without supplying
>> the same 1PPS signal to both E110s you will be unable to get better
>> accuracy than 1 second using only software methods. There will always
>> be some drift between internal clocks in different USRPs so the
>> repeated, synchronized input is needed to discipline them. You don't
>> need an octoclock or internal GPS modules, but you do need some source
>> of 1PPS and a splitter at least. There are a wide variety of GPS
>> development boards which can output 1PPS signals, some more
>> conveniently than others.
>>
>> Regards,
>> Derek
> Rafael will need a common 10Mhz source as well. The 1PPS is like a
> "trigger", but without a common reference, the two sample clocks
> will slowly drift apart.
>
>
>> On Fri, Dec 4, 2015 at 9:06 AM, Rafael Augusto via USRP-users
>> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>>
>> Hi everyone,
>>
>> I am getting started with Ettus E110, and I would like to get any
>> information or document about clock synchronization among two
>> USRP(E110) without GPS module and/or octoclock. Actually, I would
>> like to know if can I set internal clock and export (via e.g.
>> set_time_source_out) in order to synchronize the USRP?
>>
>> Any help would be appreciated.
>> Thanks in advanced.
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com>
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151204/cad704ec/attachment-0001.html>
>
> ------------------------------
>
> Message: 15
> Date: Sat, 5 Dec 2015 00:36:30 -0200
> From: Rafael Augusto <rafael.asilvacoe...@gmail.com>
> To: Derek Kozel <derek.ko...@ettus.com>
> Cc: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] USRP E110 sync clock
> Message-ID:
> <cahkeyjscsjust+fdahd5ns8rzmwc9khsx0twla+7hx_y38b...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi Derk, thanks for reply.
>
> I need accuracy of time about 800ms, but perhaps 1s maybe is enough. So,
> can I use set_time_source_out or other output function as PPS among USRPs?
> In this case, how can I do to perform synchronization based on software?
>
> Thanks in advanced.
>> On Dec 4, 2015 23:30, "Derek Kozel" <derek.ko...@ettus.com> wrote:
>>
>> Hello Rafael,
>>
>> What accuracy of time synchronization do you need? Without supplying the
>> same 1PPS signal to both E110s you will be unable to get better accuracy
>> than 1 second using only software methods. There will always be some drift
>> between internal clocks in different USRPs so the repeated, synchronized
>> input is needed to discipline them. You don't need an octoclock or internal
>> GPS modules, but you do need some source of 1PPS and a splitter at least.
>> There are a wide variety of GPS development boards which can output 1PPS
>> signals, some more conveniently than others.
>>
>> Regards,
>> Derek
>>
>> On Fri, Dec 4, 2015 at 9:06 AM, Rafael Augusto via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi everyone,
>>>
>>> I am getting started with Ettus E110, and I would like to get any
>>> information or document about clock synchronization among two USRP(E110)
>>> without GPS module and/or octoclock. Actually, I would like to know if can
>>> I set internal clock and export (via e.g. set_time_source_out) in order to
>>> synchronize the USRP?
>>>
>>> Any help would be appreciated.
>>> Thanks in advanced.
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151205/7f4490f3/attachment-0001.html>
>
> ------------------------------
>
> Message: 16
> Date: Sat, 5 Dec 2015 10:19:38 +0100
> From: Marcus M?ller <marcus.muel...@ettus.com>
> To: discuss-gnura...@gnu.org, "usrp-users@lists.ettus.com"
> <USRP-users@lists.ettus.com>
> Subject: Re: [USRP-users] [Discuss-gnuradio] 2 USRP1s, both loads
> firmware correctly, but only 1 can run ANY sdr apps. Why?
> Message-ID: <5662ac2a.7020...@ettus.com>
> Content-Type: text/plain; charset="windows-1252"
>
> 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. 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.
>
> 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.
>
> Best regards,
> Marcus
>
> [1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>> 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-gnura...@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151205/76f03353/attachment-0001.html>
>
> ------------------------------
>
> Message: 17
> Date: Sat, 05 Dec 2015 09:47:20 -0500
> From: "Marcus D. Leech" <mle...@ripnet.com>
> To: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] [Discuss-gnuradio] 2 USRP1s, both loads
> firmware correctly, but only 1 can run ANY sdr apps. Why?
> Message-ID: <5662f8f8.9000...@ripnet.com>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
>> On 12/05/2015 04:19 AM, Marcus M?ller via USRP-users 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. 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.
>>
>> 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.
>>
>> Best regards,
>> Marcus
>>
>> [1] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> My recollection is that early versions of libusrp didn't have a
> mechanism for supporting more than one USRP1 on your system. I don't recall
> whether the ability to address more than one came with UHD, or with a
> later libusrp.
>
> Regardless, GR 3.4.2 is *ancient*, and libusrp is utterly deprecated. I
> believe that for USRP1 support in OpenBTS, there's special firmware,
> and a special version of libusrp. But perhaps Tom Tsou can comment.
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151205/9dbda48d/attachment-0001.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> ------------------------------
>
> End of USRP-users Digest, Vol 64, Issue 5
> *****************************************
------------------------------
Message: 9
Date: Wed, 9 Dec 2015 11:58:29 +0700
From: Anak Galer <galersek...@gmail.com>
To: usrp-users <usrp-users@lists.ettus.com>
Cc: tri sumarno <tri.sumarno...@gmail.com>
Subject: [USRP-users] (Bidding) sale USRP + daughterboard
Message-ID:
<cao_+gxloaycs8ojtv99mx0gtdv5h71sz3zwd113fygmulgk...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Dear All
Hai all, just helping my friend for sale usrp.
He want sale (bidding) USRP + complete daughterboard. start bidding
from $ 2,900usd and every bid $100, ($ 75 + shipping). will commence
from today's date (9 december 2015) to 4 day (13 december 2015).
for detail pic
https://drive.google.com/file/d/0B2AuSZ6hkrlYbVMtZFN3VHJuV1k/view
Regards
note :
1. without wbx + sbx = (sell to alex , austria)
2. for winner can call tri.sumarno...@gmail.com
3. payment wire transfer , paypal.
4. shipping EMS (post service)
------------------------------
Message: 10
Date: Wed, 9 Dec 2015 08:10:08 +0100
From: Sylvain Munaut <246...@gmail.com>
To: Peter Cielos <thelive...@gmail.com>
Cc: Marcus M?ller <marcus.muel...@ettus.com>, GNURadio Discussion List
<discuss-gnura...@gnu.org>, "usrp-users@lists.ettus.com"
<USRP-users@lists.ettus.com>
Subject: Re: [USRP-users] [Discuss-gnuradio] UHD & LibUSRP works with
both but...Re: 2 USRP1s, both loads firmware correctly, but only 1 can
run ANY sdr apps. Why?
Message-ID:
<CAHL+j0_X4+wEOzYqdvCznM1+0HcBTHU0vROj8t7P-t=co+4...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
> How can I get the 2nd USRP1 to work just like the 1st USRP1?
If both USRP are the same hw rev and have the same DB with also same
hw rev, and one works with a given software stack and the other
doesn't, then most likely the HW is damaged.
Cheers,
Sylvain
------------------------------
Message: 11
Date: Wed, 9 Dec 2015 10:54:06 +0100
From: Sylvain Munaut <246...@gmail.com>
To: Anak Galer <galersek...@gmail.com>
Cc: usrp-users <usrp-users@lists.ettus.com>, tri sumarno
<tri.sumarno...@gmail.com>
Subject: Re: [USRP-users] (Bidding) sale USRP + daughterboard
Message-ID:
<cahl+j0-uk8oqsxj-hcolzsdn_yv4_c3a6z+7ere7k1bimgo...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
> Hai all, just helping my friend for sale usrp.
You realize this is a community mailing list and not ebay right ?
Cheers,
Sylvain
------------------------------
Message: 12
Date: Wed, 9 Dec 2015 11:11:23 +0000
From: Crozzoli Maurizio <maurizio.crozz...@telecomitalia.it>
To: "USRP-users@lists.ettus.com" <USRP-users@lists.ettus.com>
Subject: [USRP-users] Unusual looong delay before "Creating the usrp
device with..."
Message-ID:
<4E5E1EB98793EC4EA4BD2B7C3F38F2F23DCAEC0F@TELMBB006RM001.telecomitalia.local>
Content-Type: text/plain; charset="us-ascii"
Hi!
Suddenly the execution of a code I have been running many many times in these
days became very very slow soon after the command is given: it prints out
immediately the usual "linux; GNU C++ version 4.9.1; Boost_105600;
UHD_003.008.004-0-unknown" but then you have to wait tens of seconds before it
moves on to "Creating the usrp device with: master_clock_rate=30720000...",
then everything goes on the way it has to (see the log below).
That is really unusual!
What could have gone wrong?
Needless to say that any help would be more than welcome.
TIA!
BR,
Maurizio.
root@ettus-e300:~/invito# ./my_code
linux; GNU C++ version 4.9.1; Boost_105600; UHD_003.008.004-0-unknown
Creating the usrp device with: master_clock_rate=30720000...
-- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga.bit... done
-- Detecting internal GPSDO.... found
-- Initializing core control...
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing register loopback test... pass
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- Setting time source to internal
-- Asking for clock rate 30.72 MHz
-- Actually got clock rate 30.72 MHz
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
-- Initializing time to the internal GPSDO
^C
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate
ricevuto questo documento per errore siete cortesemente pregati di darne
immediata comunicazione al mittente e di provvedere alla sua distruzione,
Grazie.
This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the sender
by return e-mail, Thanks.
[rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non ?
necessario.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151209/e8e96c98/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo Ambiente_foglia2.jpg
Type: image/jpeg
Size: 677 bytes
Desc: logo Ambiente_foglia2.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151209/e8e96c98/attachment-0001.jpg>
------------------------------
Message: 13
Date: Wed, 9 Dec 2015 12:19:41 +0100
From: Marcus M?ller <marcus.muel...@ettus.com>
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Unusual looong delay before "Creating the
usrp device with..."
Message-ID: <56680e4d.9020...@ettus.com>
Content-Type: text/plain; charset="windows-1252"
Dear Maurizio,
the "Creating the usrp..." line is in your code, not part of UHD; so
could you share what your program does before you send that string to
stdout?
Best regards,
Marcus
On 09.12.2015 12:11, Crozzoli Maurizio via USRP-users wrote:
>
> Hi!
>
>
>
> Suddenly the execution of a code I have been running many many times
> in these days became very very slow soon after the command is given:
> it prints out immediately the usual ?linux; GNU C++ version 4.9.1;
> Boost_105600; UHD_003.008.004-0-unknown? but then you have to wait
> tens of seconds before it moves on to ?Creating the usrp device with:
> master_clock_rate=30720000...?, then everything goes on the way it has
> to (see the log below).
>
>
>
> That is really unusual!
>
>
>
> What could have gone wrong?
>
>
>
> Needless to say that any help would be more than welcome.
>
>
>
> TIA!
>
>
>
> BR,
>
> Maurizio.
>
>
>
>
>
> root@ettus-e300:~/invito# ./my_code
>
> linux; GNU C++ version 4.9.1; Boost_105600; UHD_003.008.004-0-unknown
>
>
>
>
>
> Creating the usrp device with: master_clock_rate=30720000...
>
> -- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga.bit... done
>
> -- Detecting internal GPSDO.... found
>
> -- Initializing core control...
>
> -- Performing register loopback test... pass
>
> -- Performing register loopback test... pass
>
> -- Performing register loopback test... pass
>
> -- Performing CODEC loopback test... pass
>
> -- Performing CODEC loopback test... pass
>
> -- Setting time source to internal
>
> -- Asking for clock rate 30.72 MHz
>
> -- Actually got clock rate 30.72 MHz
>
> -- Performing timer loopback test... pass
>
> -- Performing timer loopback test... pass
>
> -- Initializing time to the internal GPSDO
>
> ^C
>
> Questo messaggio e i suoi allegati sono indirizzati esclusivamente
> alle persone indicate. La diffusione, copia o qualsiasi altra azione
> derivante dalla conoscenza di queste informazioni sono rigorosamente
> vietate. Qualora abbiate ricevuto questo documento per errore siete
> cortesemente pregati di darne immediata comunicazione al mittente e di
> provvedere alla sua distruzione, Grazie.
>
> /This e-mail and any attachments// is //confidential and may contain
> privileged information intended for the addressee(s) only.
> Dissemination, copying, printing or use by anybody else is
> unauthorised. If you are not the intended recipient, please delete
> this message and any attachments and advise the sender by return
> e-mail, Thanks./
>
> *rispetta l'ambienteRispetta l'ambiente. Non stampare questa mail se
> non ? necessario.*
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151209/42f74426/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 9 Dec 2015 13:34:06 +0000
From: Crozzoli Maurizio <maurizio.crozz...@telecomitalia.it>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Unusual looong delay before "Creating the
usrp device with..."
Message-ID:
<4E5E1EB98793EC4EA4BD2B7C3F38F2F23DCAECFE@TELMBB006RM001.telecomitalia.local>
Content-Type: text/plain; charset="us-ascii"
Marcus,
you are right. Here is the code, from the very beginning to the "Creating..."
printout:
#include <uhd/utils/thread_priority.hpp>
#include <uhd/utils/safe_main.hpp>
#include <uhd/usrp/multi_usrp.hpp>
#include <boost/program_options.hpp>
#include <boost/format.hpp>
#include <boost/thread.hpp>
#include <boost/lexical_cast.hpp>
#include <boost/algorithm/string.hpp>
#include <iostream>
#include <fstream>
#include <complex>
using namespace std;
namespace po = boost::program_options;
int UHD_SAFE_MAIN(int argc, char *argv[])
{
uhd::set_thread_priority_safe();
//variables to be set by po
std::string args, sync, subdev, channel_list, ref;
double seconds_in_future, freq, gain, bw;
size_t total_num_samps;
double rate;
ofstream OutCh0, OutCh1;
//setup the program options
po::options_description desc("Allowed options");
desc.add_options()
("help", "help message")
("args", po::value<std::string>(&args)->default_value(""), "single uhd
device address args")
("freq", po::value<double>(&freq), "RF center frequency in Hz")
("gain", po::value<double>(&gain), "gain for the RF chain")
("secs", po::value<double>(&seconds_in_future)->default_value(1.5),
"number of seconds in the future to receive")
("bw", po::value<double>(&bw), "analog frontend filter bandwidth in
Hz")
("nsamps", po::value<size_t>(&total_num_samps)->default_value(10000),
"total number of samples to receive")
("rate", po::value<double>(&rate)->default_value(100e6/16), "rate of
incoming samples")
("sync", po::value<std::string>(&sync)->default_value("now"),
"synchronization method: now, pps, mimo")
("subdev", po::value<std::string>(&subdev), "subdev spec (homogeneous
across motherboards)")
("dilv", "specify to disable inner-loop verbose")
("ref", po::value<std::string>(&ref)->default_value("internal"),
"reference source (internal, external, mimo)")
("channels", po::value<std::string>(&channel_list)->default_value("0"),
"which channel(s) to use (specify \"0\", \"1\", \"0,1\", etc)");
po::variables_map vm;
po::store(po::parse_command_line(argc, argv, desc), vm);
po::notify(vm);
//print the help message
if (vm.count("help"))
{
std::cout << boost::format("UHD RX Multi Samples %s") % desc <<
std::endl;
std::cout <<
" This is a demonstration of how to receive aligned data from
multiple channels.\n"
" This example can receive from multiple DSPs, multiple
motherboards, or both.\n"
" The MIMO cable or PPS can be used to synchronize the
configuration. See --sync\n"
"\n"
" Specify --subdev to select multiple channels per motherboard.\n"
" Ex: --subdev=\"0:A 0:B\" to get 2 channels on a Basic RX.\n"
"\n"
" Specify --args to select multiple motherboards in a
configuration.\n"
" Ex: --args=\"addr0=192.168.10.2, addr1=192.168.10.3\"\n"
<< std::endl;
return ~0;
}
bool verbose = vm.count("dilv") == 0;
//create a usrp device
std::cout << std::endl;
std::cout << boost::format("Creating the usrp device with: %s...") % args
<< std::endl;
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);
Once again, what is strange is that until the first part of this morning we
could change the code, compile and run it continuously. Then, suddenly, is
started to become slow, so slow that it took tenS os seconds to come to the
line "Creating...". After that line is printed out, everything goes as usual
but such behavior is not usual at all!
Any ideas of what might be going wrong?
Maurizio.
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate
ricevuto questo documento per errore siete cortesemente pregati di darne
immediata comunicazione al mittente e di provvedere alla sua distruzione,
Grazie.
This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the sender
by return e-mail, Thanks.
[rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non ?
necessario.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151209/797d6a5f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo Ambiente_foglia2.jpg
Type: image/jpeg
Size: 677 bytes
Desc: logo Ambiente_foglia2.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151209/797d6a5f/attachment-0001.jpg>
------------------------------
Message: 15
Date: Wed, 9 Dec 2015 14:18:26 +0000
From: Crozzoli Maurizio <maurizio.crozz...@telecomitalia.it>
To: "usrp-users@lists.ettus.com" <usrp-users@lists.ettus.com>
Subject: Re: [USRP-users] Unusual looong delay before "Creating the
usrp device with..."
Message-ID:
<4E5E1EB98793EC4EA4BD2B7C3F38F2F23DCAED6C@TELMBB006RM001.telecomitalia.local>
Content-Type: text/plain; charset="us-ascii"
We finally solved the problem by reflashing the image on the E310 but that is
really strange!
Comments are welcome.
Maurizio.
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate
ricevuto questo documento per errore siete cortesemente pregati di darne
immediata comunicazione al mittente e di provvedere alla sua distruzione,
Grazie.
This e-mail and any attachments is confidential and may contain privileged
information intended for the addressee(s) only. Dissemination, copying,
printing or use by anybody else is unauthorised. If you are not the intended
recipient, please delete this message and any attachments and advise the sender
by return e-mail, Thanks.
[rispetta l'ambiente]Rispetta l'ambiente. Non stampare questa mail se non ?
necessario.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151209/09fa5ae6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo Ambiente_foglia2.jpg
Type: image/jpeg
Size: 677 bytes
Desc: logo Ambiente_foglia2.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151209/09fa5ae6/attachment-0001.jpg>
------------------------------
Message: 16
Date: Wed, 9 Dec 2015 08:40:04 -0800
From: Balint Seeber <balint...@gmail.com>
To: usrp-users@lists.ettus.com, discuss-gnura...@gnu.org
Subject: [USRP-users] Tonight! Cyberspectrum: Software Defined Radio
Meetup (Wed 9th Dec) 6:30pm
Message-ID:
<CAD39kUxFyJOoqEMFhTtZtWXeZnk-3p-tsmU=njgym2vsnzb...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
Announcing the twelfth Cyberspectrum meetup tonight in San Francisco!
Come along at 6:30pm for a 7pm sharp kickoff in the Hackatorium, and for
those unable to attend we'll set up a live stream like last time:
https://www.youtube.com/watch?v=1K6LUAZpaWg
There's also IRC: #cyberspectrum on Freenode, and updates on Twitter
<https://twitter.com/spenchdotnet>.
Full details, including the speaker lineup/topics, are here:
http://www.meetup.com/Cyberspectrum/events/226918542/
And the Noisebridge event page is here:
https://noisebridge.net/wiki/Cyberspectrum
We'll be hearing about:
- "An integrated proof-of-concept 'all-digital' feed for 21cm radio
astronomy" by Marcus Leech from SBRAC <http://www.sbrac.org/>
- "ZigBee Smart Homes - A Hacker's Open House" by Tobias Zillner from
Cognosec <https://www.cognosec.com/>
If you're not familiar with Cyberspectrum: "The Bay Area SDR Meetup will
serve as a forum to exchange knowledge and ideas related to Software
Defined Radio (the software and hardware), and generally aim to get people
excited about all the applications that can be realised with the
technology. At each meetup, attendees will have the opportunity to present
their work/ideas to the group. Engineers, enthusiasts, hobbyists and people
of all experience levels are welcome, no matter what your software/hardware
background."
As always, if you would like to present at a future event about a project
you're working on, or something interesting you've discovered, please get
in touch!
Hope to see you tonight,
Balint
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151209/78d04f01/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 64, Issue 9
*****************************************
