Send USRP-users mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Re: [Discuss-gnuradio] UHD Updating Question (Richard Bell)
2. Re: E310 Clock Synchronization with internal GPS (Kyle A Logue)
3. Re: E310 Clock Synchronization with internal GPS (Thierry Guichon)
4. Re: RFNOC simulation errors with Modelsim (Jonathon Pendlum)
5. Re: [Discuss-gnuradio] UHD Updating Question (Martin Braun)
6. Re: b200mini: using GPIO pin for PPS reference (re-send)
(Michael West)
7. Re: Feedback with Transmitters and Receiver (Derek Kozel)
8. Re: b200mini: using GPIO pin for PPS reference (re-send)
(Sean Nowlan)
9. Re: update E310 sdcard (liu Jong)
10. Installing UHD for E310 (Rasa Dovilas)
11. N210 w/ UBX Bursting Issue (Dave NotTelling)
12. Re: Installing UHD for E310 (Derek Kozel)
13. E310 FPGA design_Loopback test (BHUSHAN PAWAR)
14. Re: Installing UHD for E310 (Philip Balister)
----------------------------------------------------------------------
Message: 1
Date: Thu, 21 Apr 2016 09:27:39 -0700
From: Richard Bell <[email protected]>
To: Kevin McGuire <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] UHD Updating Question
Message-ID:
<CAMMoi3tL8mB77W6fHHUhmz+PX8Rj+vJW2CEG+=HjwVAZ=0p...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
That's for the feedback Kevin, appreciate it.
Rich
On Thu, Apr 21, 2016 at 5:31 AM, Kevin McGuire via USRP-users <
[email protected]> wrote:
> On Thu, Apr 21, 2016 at 7:19 AM, Kevin McGuire <[email protected]> wrote:
>
>> On Tue, Apr 12, 2016 at 5:09 PM, Richard Bell via USRP-users <
>> [email protected]> wrote:
>>
>>> Johnathan,
>>>
>>> Regarding ccache, do you need to worry about cleaning ccache because of
>>> weird compilation errors at all, or does it always just work? I haven't
>>> used a tool like this before but I'm considering it since you recommend it.
>>>
>>> Rich
>>>
>>> On Tue, Apr 12, 2016 at 2:59 PM, Richard Bell <[email protected]>
>>> wrote:
>>>
>>>> Now that you mention it, I don't think I've ever tried recompiling GNU
>>>> Radio without pulling from gnuradios github first. If I don't pull
>>>> gnuradios latest souce, maybe it would be a fast upgrade for uhd only.
>>>>
>>>> My process for rebuilding gnuradio is to go to where my build directory
>>>> is (without destroying it), and running sudo make install. This is what
>>>> usually takes about an hour.
>>>>
>>>> Rich
>>>>
>>>> On Tue, Apr 12, 2016 at 12:26 PM, Johnathan Corgan <
>>>> [email protected]> wrote:
>>>>
>>>>> On Tue, Apr 12, 2016 at 12:13 PM, Marcus M?ller <
>>>>> [email protected]> wrote:
>>>>>
>>>>>
>>>>>> GR compile time is an interesting issue.
>>>>>>
>>>>>
>>>>> I can't recommend enough using the ccache utility if you are going to
>>>>> be compiling GNU Radio more than once.
>>>>>
>>>>> -Johnathan
>>>>>
>>>>> _______________________________________________
>>>>> Discuss-gnuradio mailing list
>>>>> [email protected]
>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>> I also rebuilt* just* gr-uhd just the other day and it works well. It
>> did require having already compiled the entire GNU Radio source; however, I
>> usually keep that entire directory around.
>>
>> I have used ccache before and it should detect if the input <source> is
>> different than what it contains in the cache. The compilation of source
>> involves only the source, therefore, the same source shall produce the same
>> output and this includes the same header files unless you are using some
>> exotic C/C++ compilation. But, if you run into problems do not fret at the
>> idea of wiping out the cache and giving it a run. It is linking that
>> involves using external components which may change; however, if the tool
>> examines those and can determine they are identical then it can also cache
>> the output.
>>
>> The <same input> = <same output> is the principle, but if it breaks try
>> clearing the cache, LOL.
>>
>> According to the ccache website at https://ccache.samba.org/:
>>
>> Yes. The most important aspect of a compiler cache is to always produce
>> exactly the same output that the real compiler would produce. This includes
>> providing exactly the same object files and exactly the same compiler
>> warnings that would be produced if you use the real compiler. The only way
>> you should be able to tell that you are using ccache is the speed.
>>
>>
>>
> Also, something interesting to think about. You are dealing with a
> reliability factor here versus convenience. Would you use ccache to produce
> output for a binary for a customer. I do not think there is a wrong answer
> here, but I myself *may not* do that and would only use ccache for
> development testing. That way I could push a really basic and straight
> forward build to QA and eventually to the customers and by reducing the
> complexity I reduce the potential for diversion due to many issues.
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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/20160421/5771cd51/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 21 Apr 2016 17:09:16 +0000
From: Kyle A Logue <[email protected]>
To: Ettus Mail List <[email protected]>
Subject: Re: [USRP-users] E310 Clock Synchronization with internal GPS
Message-ID:
<sn1pr09mb097660c4d45ef4b147daa1ddb9...@sn1pr09mb0976.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Thierry:
This question has come up so many times and there isn't a proper solution for
it yet. To me it's the largest outstanding bug in the E310 and a deal-killer
for several applications.
You can use my dance for synchronizing the E310 GPS previously posted here:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-January/017483.html
But the best you can do is GPS time +- 2000ns. Even if you use an external
signal source for time synchronization, the onboard pps trigger is never more
than 20ns accurate to GPS time. As a quick summary, some of the other posts
talking about this problem:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-November/016928.html
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-November/016928.html>http://permalink.gmane.org/gmane.comp.hardware.usrp.e100/18253
The issue seems to arise from an FPGA pps trigger issue, but it's still
unresolved in UHD 003.010.x.
As a side note, you need to be using the Release 4 version of the SD image,
previous releases used the GPSDO quite differently.
Good Luck.
Kyle Logue
________________________________
From: USRP-users <[email protected]> on behalf of Marcus D.
Leech via USRP-users <[email protected]>
Sent: Thursday, April 21, 2016 07:12
To: [email protected]
Subject: Re: [USRP-users] E310 Clock Synchronization with internal GPS
On 04/21/2016 09:04 AM, Thierry Guichon via USRP-users wrote:
Hello
I am facing a problem with the E310 that I do not encounter when using the E100
Here is the relevant configuration to the device:
set_time_next_pps(time_spec_t{}); // Set the time at 0 at the next pps tick
#if device == E31X
set_time_source("gpsdo")
#endif
In both devices, the gps reports to be locked.
We then receive a signal which is externally synchronized to the GPS PPS.
When receiving this signal, the E100 correctly reports the reception time at a
few us after the PPS while the E310 reports this time at a large offset after
the PPS. In addition, for the E310, this offset changes each time the program
is run.
It appears as if on the E310 calling set_time_next_pps(time_spec_t{}) does not
set the time at the internal GPS 1 PPS tick? Did I miss a configuration step?
I am using UHD 003.008.005
If you can, I strongly recommend upgrading your E310 to the latest system
image, which has a much-more-recent UHD.
Use the image from here:
http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg1/sdimage-gnuradio-dev.direct.xz
Using the instructions here:
http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_upgrade_sd_card
Also, we're probably going to have to see more of your setup code to make a
determination about what might be wrong.
Thank you
Thierry
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
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/20160421/2e24daea/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 21 Apr 2016 13:34:01 -0400
From: "Thierry Guichon" <[email protected]>
To: "'USRP Mailing List'" <[email protected]>
Subject: Re: [USRP-users] E310 Clock Synchronization with internal GPS
Message-ID: <E756320712EB40C6BA8FEE8C61376143@Tristan>
Content-Type: text/plain; charset="us-ascii"
Thank you Marcus and Kyle,
It looks like anyhow I need to update my image :-)
The offset of 2 microseconds that you are experiencing will not be a problem
for my application. The offsets that I am currently seeing are more in the
order of several hundreds milliseconds so there is something fundamentally
wrong with either my setup or the UHD version that I am using.
I will see what I get after the upgrade.
Sincerely
Thierry
_____
From: USRP-users [mailto:[email protected]] On Behalf Of
Kyle A Logue via USRP-users
Sent: Thursday, April 21, 2016 1:09 PM
To: Ettus Mail List
Subject: Re: [USRP-users] E310 Clock Synchronization with internal GPS
Thierry:
This question has come up so many times and there isn't a proper solution
for it yet. To me it's the largest outstanding bug in the E310 and a
deal-killer for several applications.
You can use my dance for synchronizing the E310 GPS previously posted here:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-January/017
483.html
But the best you can do is GPS time +- 2000ns. Even if you use an external
signal source for time synchronization, the onboard pps trigger is never
more than 20ns accurate to GPS time. As a quick summary, some of the other
posts talking about this problem:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-November/01
6928.html
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-November/0
16928.html> http://permalink.gmane.org/gmane.comp.hardware.usrp.e100/18253
The issue seems to arise from an FPGA pps trigger issue, but it's still
unresolved in UHD 003.010.x.
As a side note, you need to be using the Release 4 version of the SD image,
previous releases used the GPSDO quite differently.
Good Luck.
Kyle Logue
_____
From: USRP-users <[email protected]> on behalf of Marcus D.
Leech via USRP-users <[email protected]>
Sent: Thursday, April 21, 2016 07:12
To: [email protected]
Subject: Re: [USRP-users] E310 Clock Synchronization with internal GPS
On 04/21/2016 09:04 AM, Thierry Guichon via USRP-users wrote:
Hello
I am facing a problem with the E310 that I do not encounter when using the
E100
Here is the relevant configuration to the device:
set_time_next_pps(time_spec_t{}); // Set the time at 0 at the next pps tick
#if device == E31X
set_time_source("gpsdo")
#endif
In both devices, the gps reports to be locked.
We then receive a signal which is externally synchronized to the GPS PPS.
When receiving this signal, the E100 correctly reports the reception time at
a few us after the PPS while the E310 reports this time at a large offset
after the PPS. In addition, for the E310, this offset changes each time the
program is run.
It appears as if on the E310 calling set_time_next_pps(time_spec_t{}) does
not set the time at the internal GPS 1 PPS tick? Did I miss a configuration
step?
I am using UHD 003.008.005
If you can, I strongly recommend upgrading your E310 to the latest system
image, which has a much-more-recent UHD.
Use the image from here:
http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg1/sdimage-gnu
radio-dev.direct.xz
Using the instructions here:
http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_upgrade_sd_card
Also, we're probably going to have to see more of your setup code to make a
determination about what might be wrong.
Thank you
Thierry
_______________________________________________
USRP-users mailing list
[email protected]
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/20160421/f6696d47/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 21 Apr 2016 10:46:31 -0700
From: Jonathon Pendlum <[email protected]>
To: Nick Foster <[email protected]>
Cc: Weidong Wang <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] RFNOC simulation errors with Modelsim
Message-ID:
<cagdo0ur1gkxa+mxkzcesvkus1rtjokprrkeqcdtlaoxj3nf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey Nick,
Thanks for looking into the setupenv_base.sh issue. Feel free to send me
your fix. I have an update to the test bench infrastructure I'm pushing
very soon where all these issues are resolved. It also adds support for
Vivado XSIM.
Jonathon
On Thu, Apr 21, 2016 at 12:57 AM, Nick Foster <[email protected]> wrote:
> I'm looking at this now and came across the same issue.
>
> setupenv_base.sh just picks the first *linux* Modelsim directory it finds,
> which is linux and not linux_x86_64, even on x86_64 platforms. This should
> probably be fixed.
>
> After fixing that, though, I'm using the latest rfnoc-radio-redo branch
> alongside Vivado 2015.4 and Modelsim 10.1c, and I can't get any of the
> testbenches to compile. The same noc_block_fft_tb that Weidong is trying to
> compile gives me:
>
> # ** Error: ../../../../noc_block_fft_tb.sv(50): Field/method name
> (pull_word) not in 'tb_axis_data'
> # ** Error: ../../../../noc_block_fft_tb.sv(50): Field/method name
> (pull_word) not in 'tb_axis_data'
> # ** Error: ../../../../noc_block_fft_tb.sv(50): Field/method name
> (pull_word) not in 'tb_axis_data'
> # ** Error: ../../../../noc_block_fft_tb.sv(89): (vopt-2730) Undefined
> variable: 'SR_AXI_CONFIG_BASE'.
> # ** Error: ../../../../noc_block_fft_tb.sv(113): Vopt Compiler exiting
> # Error loading design
> # Error: Error loading design
> # Pausing macro execution
>
> ...I find pull_word defined as a member of axis_bus and axis_slave in
> sim_axis_lib.svh. Looking for either of those types instantiated as
> "tb_axis_data", though, I can't find it anywhere. I do note that these
> undefined variables used to be instantiated in older revisions of the fpga
> repo, in sim/rfnoc/sim_rfnoc_lib.vh.
>
> Another example -- trying to "make vsim" the QPSK convolutional encoder
> results in a syntax error (it seems the older Modelsim doesn't like the
> syntax wire [...] <name> [...] = { ....... } and would prefer a separate
> assign statement). Fixing that gives me an undefined variable
> "tb_next_dst". The moving_avg testbench results in the same error.
>
> So it seems like some simulation macro magic isn't being instantiated
> quite right. Jonathan, do these testbenches currently compile for you? If
> so, what's different between your setup and mine?
>
> --n
>
> On Tue, Apr 12, 2016 at 4:59 PM Weidong Wang via USRP-users <
> [email protected]> wrote:
>
>> Hi Jonathon,
>>
>> I do use Ubuntu, I tried the command you proposed, but I still get the
>> same error.
>>
>> I notice when I setup the environment, I have this
>> Setting up a 64-bit FPGA build environment for the USRP-E3x0...
>> - Vivado: Found (/opt/Xilinx/Vivado/2015.4/bin)
>> - Modelsim: Found (SE, /home/wwd/Modelsim_10_2c/modeltech/linux) not
>> linux_x86_64
>> - Modelsim Compiled Libs: Found (/opt/Xilinx/Vivado/2015.4/modelsim32)
>> not modelsim64
>>
>> I think I installed the Modelsim is 64bit version, because its name is
>> Modelsim se-64 10.2c, but the script choose the 32bits directory, is it
>> normal?
>>
>> Thanks,
>>
>> Weidong
>>
>> On 16-04-12 02:04 PM, Jonathon Pendlum wrote:
>>
>> Hi Weidong,
>>
>> I'm not seeing that error. Are you running on Ubuntu? Did you set your
>> default system shell to bash? If not, run 'sudo dpkg-reconfigure dash' and
>> select No (assuming you are using Ubuntu).
>>
>>
>>
>> Jonathon
>>
>> On Tue, Apr 12, 2016 at 10:14 AM, Weidong Wang <[email protected]>
>> wrote:
>>
>>> Hi Jonathon,
>>>
>>> You are right, there are lots of errors:
>>>
>>> Top level modules:
>>> noc_block_fft
>>> Model Technology ModelSim SE-64 vlog 10.2c Compiler 2013.07 Jul 18 2013
>>> ** Error: ../../../../../noc_block_export_io.sv(7): Cannot find
>>> `include file "sim_cvita_lib.sv" in directories:
>>> ../../../../../, ../../../../../../../sim/general,
>>> ../../../../../../../sim/axi, ../../../../../../../sim/control,
>>> ../../../../../../../sim/rfnoc,
>>> /home/wwd/Modelsim_10_2c/modeltech/ovm-2.1.2/../verilog_src/ovm-2.1.2/src,
>>> /home/wwd/Modelsim_10_2c/modeltech/uvm-1.1d/../verilog_src/uvm-1.1d/src
>>> ** Error: ../../../../../noc_block_export_io.sv(8): Cannot find
>>> `include file "sim_set_rb_lib.sv" in directories:
>>> ../../../../../, ../../../../../../../sim/general,
>>> ../../../../../../../sim/axi, ../../../../../../../sim/control,
>>> ../../../../../../../sim/rfnoc,
>>> /home/wwd/Modelsim_10_2c/modeltech/ovm-2.1.2/../verilog_src/ovm-2.1.2/src,
>>> /home/wwd/Modelsim_10_2c/modeltech/uvm-1.1d/../verilog_src/uvm-1.1d/src
>>> ** Error: ../../../../../../control/axi_crossbar_intf.sv(6): Cannot
>>> find `include file "sim_cvita_lib.sv" in directories:
>>> ../../../../../, ../../../../../../../sim/general,
>>> ../../../../../../../sim/axi, ../../../../../../../sim/control,
>>> ../../../../../../../sim/rfnoc,
>>> /home/wwd/Modelsim_10_2c/modeltech/ovm-2.1.2/../verilog_src/ovm-2.1.2/src,
>>> /home/wwd/Modelsim_10_2c/modeltech/uvm-1.1d/../verilog_src/uvm-1.1d/src
>>> ** Error: ../../../../../../control/axi_crossbar_intf.sv(7): Cannot
>>> find `include file "sim_set_rb_lib.sv" in directories:
>>> ../../../../../, ../../../../../../../sim/general,
>>> ../../../../../../../sim/axi, ../../../../../../../sim/control,
>>> ../../../../../../../sim/rfnoc,
>>> /home/wwd/Modelsim_10_2c/modeltech/ovm-2.1.2/../verilog_src/ovm-2.1.2/src,
>>> /home/wwd/Modelsim_10_2c/modeltech/uvm-1.1d/../verilog_src/uvm-1.1d/src
>>> ** Error: ../../../../../../../sim/rfnoc/sim_rfnoc_lib.vh(56): Cannot
>>> find `include file "sim_cvita_lib.sv" in directories:
>>> ../../../../../, ../../../../../../../sim/general,
>>> ../../../../../../../sim/axi, ../../../../../../../sim/control,
>>> ../../../../../../../sim/rfnoc,
>>> /home/wwd/Modelsim_10_2c/modeltech/ovm-2.1.2/../verilog_src/ovm-2.1.2/src,
>>> /home/wwd/Modelsim_10_2c/modeltech/uvm-1.1d/../verilog_src/uvm-1.1d/src
>>> ** Error: ../../../../../../../sim/rfnoc/sim_rfnoc_lib.vh(57): Cannot
>>> find `include file "sim_set_rb_lib.sv" in directories:
>>> ../../../../../, ../../../../../../../sim/general,
>>> ../../../../../../../sim/axi, ../../../../../../../sim/control,
>>> ../../../../../../../sim/rfnoc,
>>> /home/wwd/Modelsim_10_2c/modeltech/ovm-2.1.2/../verilog_src/ovm-2.1.2/src,
>>> /home/wwd/Modelsim_10_2c/modeltech/uvm-1.1d/../verilog_src/uvm-1.1d/src
>>> Model Technology ModelSim SE vlog 10.2c Compiler 2013.07 Jul 18 2013
>>> -- Compiling module glbl
>>>
>>> Top level modules:
>>> glbl
>>> run_program: Time (s): cpu = 00:00:07 ; elapsed = 00:00:08 . Memory
>>> (MB): peak = 940.770 ; gain = 0.000 ; free physical = 289 ; free virtual =
>>> 11776
>>> INFO: [USF-ModelSim-4] ModelSim::Simulate design
>>> INFO: [USF-ModelSim-69] Executing 'SIMULATE' step in
>>> '/home/wwd/Ettus/Rfnoc/pybombs/src/uhd-rfnoc-radio-redo/fpga-src/fpga-rfnoc-radio-redo/usrp3/lib/rfnoc/noc_block_fft_tb/modelsim_proj/modelsim_proj.sim/sim_1/behav'
>>> Program launched (RETURN-CODE=13786)
>>> launch_simulation: Time (s): cpu = 00:00:10 ; elapsed = 00:00:11 .
>>> Memory (MB): peak = 940.770 ; gain = 0.000 ; free physical = 288 ; free
>>> virtual = 11775
>>> # if [string equal $vivado_mode "batch"] {
>>> # puts "BUILDER: Closing project"
>>> # close_project
>>> # } else {
>>> # puts "BUILDER: In GUI mode. Leaving project open."
>>> # }
>>> BUILDER: Closing project
>>> ****** Webtalk v2015.4 (64-bit)
>>> **** SW Build 1412921 on Wed Nov 18 09:44:32 MST 2015
>>> **** IP Build 1412160 on Tue Nov 17 13:47:24 MST 2015
>>> ** Copyright 1986-2015 Xilinx, Inc. All Rights Reserved.
>>>
>>> source
>>> /home/wwd/Ettus/Rfnoc/pybombs/src/uhd-rfnoc-radio-redo/fpga-src/fpga-rfnoc-radio-redo/usrp3/lib/rfnoc/noc_block_fft_tb/modelsim_proj/modelsim_proj.hw/webtalk/labtool_webtalk.tcl
>>> -notrace
>>> INFO: [Common 17-206] Exiting Webtalk at Tue Apr 12 12:44:47 2016...
>>> INFO: [Common 17-206] Exiting Vivado at Tue Apr 12 12:44:47 2016...
>>> Reading pref.tcl
>>>
>>>
>>> There are a lot of missing files, how can I include them?
>>>
>>> Thanks,
>>>
>>> Weidong,
>>>
>>>
>>>
>>> On 16-04-12 12:53 PM, Jonathon Pendlum wrote:
>>>
>>> Hi WWD,
>>>
>>> Can you post the command line output? There was likely an error message.
>>>
>>>
>>>
>>> Jonathon
>>>
>>> On Tue, Apr 12, 2016 at 9:50 AM, Weidong Wang via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I recently installed the Modelsim 10.2c for the simulation of RFNOC
>>>> version radio-redo.
>>>> I successfully set up the Modelsim environment, and generated the
>>>> library. And the output of setenv.sh is like below:
>>>>
>>>> Setting up a 64-bit FPGA build environment for the USRP-E3x0...
>>>> - Vivado: Found (/opt/Xilinx/Vivado/2015.4/bin)
>>>> - Modelsim: Found (SE, /home/wwd/Modelsim_10_2c/modeltech/linux)
>>>> - Modelsim Compiled Libs: Found (/opt/Xilinx/Vivado/2015.4/modelsim32)
>>>>
>>>> Environment successfully initialized.
>>>>
>>>> Then, I went to the noc_block_fft_tb and run the command make vsim,
>>>> the Modelsim successfully showed up, but gave this error:
>>>>
>>>> # ** Note: (vsim-3812) Design is being optimized...
>>>> # ** Error: Failed to find design unit work.noc_block_fft_tb.
>>>> # Optimization failed
>>>> # Error loading design
>>>> # Error: Error loading design
>>>> # Pausing macro execution
>>>> # MACRO ./noc_block_fft_tb_simulate.do PAUSED at line 9
>>>>
>>>> So I am missing here?
>>>>
>>>> Thanks,
>>>>
>>>> WWD
>>>>
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> 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/20160421/ff7ed158/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 21 Apr 2016 11:07:20 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] [Discuss-gnuradio] UHD Updating Question
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 04/21/2016 05:31 AM, Kevin McGuire via USRP-users wrote:
> Also, something interesting to think about. You are dealing with a
> reliability factor here versus convenience. Would you use ccache to
> produce output for a binary for a customer. I do not think there is a
> wrong answer here, but I myself /may not/ do that and would only use
> ccache for development testing. That way I could push a really basic and
> straight forward build to QA and eventually to the customers and by
> reducing the complexity I reduce the potential for diversion due to many
> issues.
FYI, we don't use ccache for any of the binaries we provide, for that
reason. Although I expect using ccache would be fine (but we have an
automated system for the binaries, so I don't care about compile speed).
M
------------------------------
Message: 6
Date: Thu, 21 Apr 2016 11:29:30 -0700
From: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] b200mini: using GPIO pin for PPS reference
(re-send)
Message-ID:
<CAM4xKrrCX6rE3MroMBLuThzZMABwA=mrcoubypcwz3kwyv7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Sean,
To answer your initial question, it would take FPGA modification to route a
GPIO pin to be used as the PPS signal. But there really is no need. If
the PPS signal has sufficient frequency accuracy, you can just use that as
the reference input. In most cases, the frequency accuracy will be
dominated by the accuracy of the reference input (PPS or 10 MHz).
As with all PLLs, the lock indicator for the B200mini's PLL is asserted
when the error is within a certain margin (+/- 1 ppm in the case of
B200mini). But the digital PLL in the B200mini is capable of being
accurate to ~10 ppb after it settles in (after ~10 seconds).
We have found that the VCTXCO is very sensitive to even the slightest
change in temperature. To achieve an accuracy of ~10 ppb, the B200mini
needs to be in an enclosure. We are actually working on a case that I am
told may be available later this year. The digital PLL has a precision of
5 ppb, so +/- 5 ppb is the best accuracy that can be achieved. In my own
testing with the VCTCXO covered, I have measured an accuracy of +/- 10 ppb.
Hope this helps.
Regards,
Michael
On Wed, Apr 20, 2016 at 6:30 PM, Martin Braun via USRP-users <
[email protected]> wrote:
> We've done some measurements; the PPS input has a very good frequency
> accuracy on average. Phase noise might be better if the reference is
> coming from a 10 MHz, but I can't give you a number for that.
>
> Cheers,
> M
>
> On 04/20/2016 05:35 PM, Derek Kozel via USRP-users wrote:
> > Hi Sean,
> >
> > The 10 MHz may provide a small increase in accuracy, but most users find
> > the 1PPS to be sufficient. The internal TCXO is actually spec'd at
> > 0.5ppm. The ref lock sensor returns true when the lock is better than
> 1ppm.
> >
> > What accuracy does your application need? I would try running with the
> > 1PPS and see if it meets your need. The convergence time is slightly
> > slower so take your measurements after the reference locks,
> > approximately 10 seconds. Like any pll loop, the performance will
> > improve over time so testing after 1-2 minutes would also be meaningful.
> >
> > Details of the digital PLL on the B200mini family can be found here.
> >
> https://github.com/EttusResearch/fpgadev/blob/master/usrp3/top/b2xxmini/b205_ref_pll.v
> >
> > Regards,
> > Derek
> >
> >
> > On Wed, Apr 20, 2016 at 3:58 PM, Sean Nowlan <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > So to be clear, there is *no* improvement in clock accuracy and
> > phase noise by using a 10 MHz instead of a 1 PPS?
> >
> > My goal is to provide a very stable 10 MHz frequency reference and
> > use a PPS (phase-locked w/ 10 MHz) to set the time-of-day register
> > on a PPS edge, i.e., the same exact procedure that is commonly used
> > on N2x0 and B2x0 devices that have GPSDO modules.
> >
> > The B200mini's internal TCXO is spec'd at +/- 2 ppm frequency
> > accuracy [1]. What is the best accuracy one could hope to achieve by
> > providing an external frequency reference? Let's say I provide a 10
> > MHz reference from a Firefly 1A GPSDO [2], which has +/- 2.5E-08
> > accuracy in unlocked condition. How close to that number could I
> > expect to get on the B200mini with the stable clock used as external
> > reference?
> >
> > Thanks,
> > Sean
> >
> > [1] https://www.ettus.com/content/files/USRP_B200mini_Data_Sheet.pdf
> > [2] https://www.ettus.com/content/files/gpsdo-kit_4.pdf
> >
> > On Wed, Apr 20, 2016 at 6:00 PM, Derek Kozel <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > Hi Sean,
> >
> > What is your goal with having separate 10 MHz and 1PPS reference
> > inputs? If your 1PPS is coming from a source with the same
> > quality as your 10 MHz, such as an integrated GPSDO, then the
> > B200mini's reference disciplining architecture will provide
> > equivalent phase noise and frequency stability from either
> > reference. Using a 1PPS signal will provide both time and
> > frequency references.
> >
> > If you want to use Marcus' trick of triggering events using
> > timed commands and the 1PPS input then you could route a GPIO
> > pin to the internal 1PPS signal with minor Verilog changes.
> >
> > Your message did get through earlier today by the way
> > (
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-April/019621.html
> ).
> >
> > Regards,
> > Derek
> >
> > On Wed, Apr 20, 2016 at 2:40 PM, Sean Nowlan via USRP-users
> > <[email protected] <mailto:[email protected]>>
> > wrote:
> >
> > Hi all -
> >
> > I sent this earlier today but never saw it show up on the
> > list, so I'm retrying:
> >
> > What modifications would need to be made to the b200mini
> > FPGA source to allow using a GPIO pin for a PPS input? We'd
> > like to supply a GPSDO 10 MHz reference to the SYNC port and
> > a PPS signal to a GPIO pin to set the time-of-day register
> > with set_time_next_pps(). Basically we'd like to duplicate
> > the functionality available on N2x0 and B2x0 devices that
> > have dedicated 10 MHz and PPS reference ports.
> >
> > Sean
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected] <mailto:
> [email protected]>
> >
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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/20160421/2f4e35be/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 21 Apr 2016 15:52:50 -0700
From: Derek Kozel <[email protected]>
To: Pavan Yedavalli <[email protected]>,
"[email protected]" <[email protected]>
Cc: GNURadio Discussion List <[email protected]>
Subject: Re: [USRP-users] Feedback with Transmitters and Receiver
Message-ID:
<CAA+K=ts52vMv1-1GLA5jhGJ_M1D+X5WA6n7wUf0=qoiq7+b...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Pavan,
This is a USRP/UHD question really so I'm including the usrp-users mailing
list. If you're not already the list already then you should certainly join
as that's a better resource for questions about UHD/USRPs.
1) Any SMA cable will work. For the best performance their electrical
lengths should be the same. In practice this usually means equal physical
lengths of the same type of coax. This ensures that the signals arrive at
the same time (and phase).
2) Most radio systems don't have GPS timebases available and use various
protocol level methods for aligning their clocks, if needed. In a very
simple system the receiver could simply listen continuously until it
receives a full message, then transmits a response if needed. Look up Time
Division Multiplexing and Frequency Division Multiplexing. This is an area
where there are nearly as many possibilities as there are radio systems.
3) Once you connect all the Octoclock signals then in GNU Radio you can
select the Clock and Time sources to be External and the Sync to be Unknown
PPS. Your pair of units connected via a MIMO cable are special, the master
should have the External time and clock sources, the companion USRP should
have MIMO selected for time and clock. The Sync should still be Unknown PPS.
Here's a page that talks about synchronization of USRPs. Read this, get
your hardware all setup, and try setting up a basic GRC flowgraph with your
three radios. Think of what tests you could use to verify that both your
MIMO cabled radios are transmitting at the same time. You should look into
timed commands in UHD and tags in GNU Radio.
http://files.ettus.com/manual/page_sync.html
https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp_updated.pdf
If this is your first use of USRPs and GNU Radio then I'd suggest reading
through the tutorials available online and not get too focused on MIMO
until you feel comfortable with the basics of the environment and tools
that you have.
http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorials
Once you've given this a try let us know if you have additional questions.
Regards,
Derek
On Thu, Apr 21, 2016 at 3:27 PM, Pavan Yedavalli <[email protected]>
wrote:
> Hi Derek,
>
> Thanks for getting back to me. So, I do have an Octoclock, so I think
> we're getting somewhere and this is starting to make more sense. A few
> follow up questions:
>
> 1.) Do I need special cables to connect all of the units to the Octoclock,
> or are they robust SMA cables?
>
> 2.) I feel like this seems particularly involved to send a signal from a
> transmitter to a receiver. I am assuming most non-MIMO, non-beamforming
> related tasks have always used your second option of using the GPSDO kits?
> I purchased an Octoclock knowing I would do MIMO experiments, but obviously
> I'm guessing more conventional communication techniques (like a simple BPSK
> or QPSK between tx and rx) would have probably used the GPSDO kits?
>
> 3.) Once I connect them all to the Octoclock, then I don't need to a
> protocol level time synchronization, right? Once they're all synchronized
> and I see that in the plots, then I guess the next step would be to figure
> out how to implement my actual feedback loop. At that point, then I would
> need to figure out how to do burst mode to transmit and receiver timed
> signals? Would this end up needing to be one flow graph or would I have to
> use two flow graphs? (One for to and one for rx, the way I am doing it now)
>
> Thank you again for all the help. I think I'm starting to understand what
> I need in the setup.
>
> On Thu, Apr 21, 2016 at 4:56 PM, Derek Kozel <[email protected]>
> wrote:
>
>> Hello Pavan,
>>
>> I think we both are starting to understand the setup and the problem.
>> Here are the two hardware solutions:
>>
>> Connect a shared 1PPS signal to *both* the master USRP of your MIMO
>> cabled pair and to the receiver (For example using an octoclock:
>> https://www.ettus.com/product/details/OctoClock-G)
>>
>> OR
>>
>> Connect GPS referenced 1PPS signals to both the master USRP of your MIMO
>> cabled pair and the receiver (For example using two of the GPSDO kits:
>> https://www.ettus.com/product/details/GPSDO-KIT)
>>
>>
>> There are many ways of implementing a protocol level time synchronization
>> in software/DSP. The paper I linked to talks about one way, there are
>> certainly others. I do not know of any example projects implementing them
>> though so you would have to develop your own.
>>
>> Regards,
>> Derek
>>
>> On Thu, Apr 21, 2016 at 8:04 AM, Pavan Yedavalli <[email protected]>
>> wrote:
>>
>>> Hi Derek,
>>>
>>> I'll answer your questions in-line, because I think what you are saying
>>> is beginning to make me understand what I need:
>>>
>>>
>>> On Wed, Apr 20, 2016 at 9:03 PM, Derek Kozel <[email protected]>
>>> wrote:
>>>
>>>> Hello Pavan,
>>>>
>>>> Are you trying to create a shared timebase between the two USRPs
>>>> without having a shared 1PPS or GPS reference? You are still not using
>>>> enough detail for us to understand fully.
>>>>
>>>
>>> To clarify, my setup is two USRPs connected via MIMO cable, and then
>>> another USRP acting as a receiver. So are you asking whether I'm trying to
>>> create a shared timebase between the two-USRP *unit* (because they are
>>> MIMO cabled) and the receiving USRP without having a shared 1 PPS or GPS
>>> reference? I think my answer to that must be yes, because I have not done
>>> anything else but connect them to the computer via ethernet and just have
>>> two of them connected via MIMO cable and the other one by itself. I'm
>>> assuming I need to have a shared reference between the transmit USRPs and
>>> the receive USRP, so how would I be able to do that? This could certainly
>>> be one of my problems.
>>>
>>>>
>>>> In Figure 5 both USRPs are connected with a MIMO cable and so have both
>>>> shared frequency and time bases. What is your weight block doing to the
>>>> sample stream? Is it a time delay block? I don't know what gnuradio would
>>>> do if you specified 10*sample_rate as the delay there as that's likely to
>>>> be a very large number of samples.
>>>>
>>>
>>> My weight block is applying a normalized magnitude phase correction to
>>> each antenna's transmitted signal, so, yes, it is essentially creating a
>>> time delay. Each weight is a complex value with magnitude 1 and a
>>> calculated phase. You are saying this could be a problem if it's
>>> calculating a value that is too high?
>>>
>>>>
>>>> If you have both USRPs connected with a time synchronization (shared
>>>> 1PPS, GPSDO, or MIMO cable) and have your flowgraph configured correctly,
>>>> then you can just use timed commands to the USRP_alpha to start
>>>> transmitting at time X and USRP_beta to start receiving at time X and you
>>>> will see your signal. You can then move to using burst mode using tags to
>>>> define the number of samples to send/receive along with timed commands to
>>>> send/receive bursts of samples. This works because the clocks in both USRPs
>>>> will be aligned to each other.
>>>>
>>>
>>> I feel like there are two steps here. First, I need to get the
>>> transmitting USRPs (which are conneced via MIMO cable) to time sync to each
>>> other (which I believe I have done through using USRP sink in GRC and
>>> setting the second channels time and clock to MIMO cable?), and second, I
>>> need to get the receive USRP to receive at the same time. So, just as
>>> above, I need to get my receive USRP to be on the same time as my transmit
>>> USRPs? Once I'm able to do that, then I can do burst mode to transmit and
>>> receive timed signals, as you are mentioning?
>>>
>>>>
>>>> If you do *NOT* have a shared time source for each radio, for instance
>>>> they are far apart and do not have GPS references, then you need to do some
>>>> sort of protocol level alignment to create a shared understanding of time
>>>> between them. A frequently used method is for USRP_alpha to transmit a
>>>> beacon with a known period (say once every 10 seconds). All other USRPs
>>>> then receive for longer than 10 seconds to be guaranteed to receive the
>>>> beacon (assuming they're within range of the transmission). When the
>>>> receiving USRPs detect the incoming beacon they align their local time to
>>>> the master (Beacon transmitting) USRP.
>>>>
>>>
>>> I guess a similar question to the above: can I have a shared time source
>>> between the transmit USRPs (which are already MIMO cabled to each other)
>>> and the receive USRP? It seems like that would be easier to do than going
>>> through this protocol level alignment, but maybe it's not possible given my
>>> setup.
>>>
>>>>
>>>> Here's a quick paper talking about this topic. The technique is widely
>>>> used.
>>>> http://www.ece.uah.edu/~milenka/docs/dc_ssst05_synch.pdf
>>>>
>>>>
>>>> I hope this helps and is applicable to your need. If you have more
>>>> questions please try drawing your desired system and maybe include a
>>>> timeline of events that you expect the radios to do. Attaching your
>>>> existing flowgraphs, either as photos using GRC's screen capture feature
>>>> (file>screen capture) or the actual GRC file, also helps us understand what
>>>> exactly you are working with.
>>>>
>>>
>>> I had to take down the setup because I am moving labs, but I will send
>>> some flowgraphs and the diagram of the system next week. Thank you again
>>> for being so patient and trying to help me. I think I'm just a bit lost on
>>> a few of the simple things, but once those are figured out, then I think it
>>> should be smoother sailing.
>>>
>>>>
>>>> Derek
>>>>
>>>> On Wed, Apr 20, 2016 at 4:05 PM, Pavan Yedavalli <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi Martin,
>>>>>
>>>>> I guess I have a few questions:
>>>>>
>>>>> 1.) Are there any examples in the gnuradio codebase/flowgraph
>>>>> repository that show how to do synchronized feedback between two USRPs? In
>>>>> other words, I send a signal from a transmit USRP, and then I receive that
>>>>> signal at the receive USRP, and then I send back something else from the
>>>>> receive USRP back to the transmit USRP, and this would be a sequential
>>>>> process in which they are aligned and know when to transmit and/or
>>>>> receive?
>>>>> I saw a post
>>>>> <http://stackoverflow.com/questions/28710869/how-to-set-usrp-transmitting-time-and-receiving-time-in-gnu-radio>
>>>>> that
>>>>> I think would be relevant, but I'm not sure how to apply it.
>>>>>
>>>>> I believe this should be a pretty standard scenario in which you want
>>>>> to have two USRPs communicate with each other synchronously. I guess I'm
>>>>> just having trouble finding an example of how to do this.
>>>>>
>>>>> 2.) Related to the above question, maybe there are no examples to do
>>>>> feedback in one flowgraph, so what I have been doing is the following in
>>>>> my
>>>>> flowgraphs:
>>>>>
>>>>> Flowgraph A:
>>>>>
>>>>> The synchronized MIMO flowgraph (Figure 5) from this
>>>>> <https://www.ettus.com/content/files/kb/mimo_and_sync_with_usrp.pdf>,
>>>>> so essentially I have two USRPs synchronized and transmitting out two
>>>>> signals that should be offset but frequency aligned. In my own flowgraph's
>>>>> main(), instead of applying a "phase shift" block, I am applying my own
>>>>> "weights" block to both transmissions.
>>>>>
>>>>> So, I am now sending a signal that has those weights applied to it.
>>>>> So, after I do tb.start(), then I sleep for 10 seconds (by doing
>>>>> sleep(10))
>>>>> hoping that in the 10 seconds my receiver will catch the signal that I'm
>>>>> transmitting and put it into file.
>>>>>
>>>>> Flowgraph B:
>>>>>
>>>>> My own receiver.py in which I have a USRP sink->FFT->Complex to
>>>>> Mag->File sink. I also have a connection from FFT->QT GUI to see a plot of
>>>>> what is being captured.
>>>>>
>>>>> I now run Flowgraph A in one terminal and Flowgraph B in another
>>>>> terminal. I need to capture A's transmission with the first weights within
>>>>> the 10 seconds (as it's sleeping) into the file sink. Then, A will send a
>>>>> signal with another set of weights applied, and I will need to capture
>>>>> that
>>>>> in the next 10 seconds, and so on. My problem is that I'm often capturing
>>>>> noise because my receive was not aligned with when I was transmitting my
>>>>> desired signal. So, I end up only capturing noise after the transmission
>>>>> stops as opposed to the actual signal when the transmission is happening.
>>>>>
>>>>> Essentially, I am trying to mimic feedback by doing the above, but I
>>>>> don't know how to align my transmitter and receiver, especially because
>>>>> they are two different blocks. Is there a way to make both the
>>>>> transmission
>>>>> and reception one block so that I can do sleep(rx_time +
>>>>> n_samples_since_tag/sampling_rate) (I think this could be right?) as
>>>>> opposed to my static sleep(10) and pray for the best?
>>>>>
>>>>> Would it be helpful at all if I showed you my code? I still feel like
>>>>> I'm not being clear. Sorry about that. If there were any examples, then I
>>>>> think that would be the best for me to look at.
>>>>>
>>>>> Thanks for any help again.
>>>>>
>>>>>
>>>>> --
>>>>> Pavan
>>>>>
>>>>> _______________________________________________
>>>>> Discuss-gnuradio mailing list
>>>>> [email protected]
>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Pavan
>>>
>>
>>
>
>
> --
> Pavan
>
>
> --
> Pavan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160421/f024a9fe/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 21 Apr 2016 19:05:17 -0400
From: Sean Nowlan <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] b200mini: using GPIO pin for PPS reference
(re-send)
Message-ID:
<CAGmpSno+vmXMpD=34vszcchwtzgnprw5v2zg5pbf+t6xgnw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Thanks, all. I appreciate you sharing the results of frequency accuracy
measurements you've made and the precision available from the digital PLL
design. The numbers look "good enough" so we're going to proceed with
PPS-only for now. I verified that a B200mini reported "ref_locked"=locked
with an external PPS and was able to set the time-of-day register using
set_time_next_pps.
I looked over the Verilog source and saw that it would be pretty trivial to
hook up a GPIO pin to the PPS_IN signal, but for now I agree it's not
necessary to do this.
Sean
On Thu, Apr 21, 2016 at 2:29 PM, Michael West via USRP-users <
[email protected]> wrote:
> Hi Sean,
>
> To answer your initial question, it would take FPGA modification to route
> a GPIO pin to be used as the PPS signal. But there really is no need. If
> the PPS signal has sufficient frequency accuracy, you can just use that as
> the reference input. In most cases, the frequency accuracy will be
> dominated by the accuracy of the reference input (PPS or 10 MHz).
>
> As with all PLLs, the lock indicator for the B200mini's PLL is asserted
> when the error is within a certain margin (+/- 1 ppm in the case of
> B200mini). But the digital PLL in the B200mini is capable of being
> accurate to ~10 ppb after it settles in (after ~10 seconds).
>
> We have found that the VCTXCO is very sensitive to even the slightest
> change in temperature. To achieve an accuracy of ~10 ppb, the B200mini
> needs to be in an enclosure. We are actually working on a case that I am
> told may be available later this year. The digital PLL has a precision of
> 5 ppb, so +/- 5 ppb is the best accuracy that can be achieved. In my own
> testing with the VCTCXO covered, I have measured an accuracy of +/- 10 ppb.
>
> Hope this helps.
>
> Regards,
> Michael
>
> On Wed, Apr 20, 2016 at 6:30 PM, Martin Braun via USRP-users <
> [email protected]> wrote:
>
>> We've done some measurements; the PPS input has a very good frequency
>> accuracy on average. Phase noise might be better if the reference is
>> coming from a 10 MHz, but I can't give you a number for that.
>>
>> Cheers,
>> M
>>
>> On 04/20/2016 05:35 PM, Derek Kozel via USRP-users wrote:
>> > Hi Sean,
>> >
>> > The 10 MHz may provide a small increase in accuracy, but most users find
>> > the 1PPS to be sufficient. The internal TCXO is actually spec'd at
>> > 0.5ppm. The ref lock sensor returns true when the lock is better than
>> 1ppm.
>> >
>> > What accuracy does your application need? I would try running with the
>> > 1PPS and see if it meets your need. The convergence time is slightly
>> > slower so take your measurements after the reference locks,
>> > approximately 10 seconds. Like any pll loop, the performance will
>> > improve over time so testing after 1-2 minutes would also be meaningful.
>> >
>> > Details of the digital PLL on the B200mini family can be found here.
>> >
>> https://github.com/EttusResearch/fpgadev/blob/master/usrp3/top/b2xxmini/b205_ref_pll.v
>> >
>> > Regards,
>> > Derek
>> >
>> >
>> > On Wed, Apr 20, 2016 at 3:58 PM, Sean Nowlan <[email protected]
>> > <mailto:[email protected]>> wrote:
>> >
>> > So to be clear, there is *no* improvement in clock accuracy and
>> > phase noise by using a 10 MHz instead of a 1 PPS?
>> >
>> > My goal is to provide a very stable 10 MHz frequency reference and
>> > use a PPS (phase-locked w/ 10 MHz) to set the time-of-day register
>> > on a PPS edge, i.e., the same exact procedure that is commonly used
>> > on N2x0 and B2x0 devices that have GPSDO modules.
>> >
>> > The B200mini's internal TCXO is spec'd at +/- 2 ppm frequency
>> > accuracy [1]. What is the best accuracy one could hope to achieve by
>> > providing an external frequency reference? Let's say I provide a 10
>> > MHz reference from a Firefly 1A GPSDO [2], which has +/- 2.5E-08
>> > accuracy in unlocked condition. How close to that number could I
>> > expect to get on the B200mini with the stable clock used as external
>> > reference?
>> >
>> > Thanks,
>> > Sean
>> >
>> > [1]
>> https://www.ettus.com/content/files/USRP_B200mini_Data_Sheet.pdf
>> > [2] https://www.ettus.com/content/files/gpsdo-kit_4.pdf
>> >
>> > On Wed, Apr 20, 2016 at 6:00 PM, Derek Kozel <[email protected]
>> > <mailto:[email protected]>> wrote:
>> >
>> > Hi Sean,
>> >
>> > What is your goal with having separate 10 MHz and 1PPS reference
>> > inputs? If your 1PPS is coming from a source with the same
>> > quality as your 10 MHz, such as an integrated GPSDO, then the
>> > B200mini's reference disciplining architecture will provide
>> > equivalent phase noise and frequency stability from either
>> > reference. Using a 1PPS signal will provide both time and
>> > frequency references.
>> >
>> > If you want to use Marcus' trick of triggering events using
>> > timed commands and the 1PPS input then you could route a GPIO
>> > pin to the internal 1PPS signal with minor Verilog changes.
>> >
>> > Your message did get through earlier today by the way
>> > (
>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2016-April/019621.html
>> ).
>> >
>> > Regards,
>> > Derek
>> >
>> > On Wed, Apr 20, 2016 at 2:40 PM, Sean Nowlan via USRP-users
>> > <[email protected] <mailto:[email protected]
>> >>
>> > wrote:
>> >
>> > Hi all -
>> >
>> > I sent this earlier today but never saw it show up on the
>> > list, so I'm retrying:
>> >
>> > What modifications would need to be made to the b200mini
>> > FPGA source to allow using a GPIO pin for a PPS input? We'd
>> > like to supply a GPSDO 10 MHz reference to the SYNC port and
>> > a PPS signal to a GPIO pin to set the time-of-day register
>> > with set_time_next_pps(). Basically we'd like to duplicate
>> > the functionality available on N2x0 and B2x0 devices that
>> > have dedicated 10 MHz and PPS reference ports.
>> >
>> > Sean
>> >
>> > _______________________________________________
>> > USRP-users mailing list
>> > [email protected] <mailto:
>> [email protected]>
>> >
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > USRP-users mailing list
>> > [email protected]
>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> >
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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/20160421/4d7ba118/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 22 Apr 2016 09:08:07 +0800
From: liu Jong <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] update E310 sdcard
Message-ID:
<caeui2n1mttecopu0n1661cuuenjjjhwvwzza_xna9somxia...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Marcus,
thank you.
2016-04-21 17:00 GMT+08:00 Marcus M?ller <[email protected]>:
> Hi John,
>
> you'd probably need the -sg1 (speed-grade 1) image, not the -sg3 one.
> More explanations are in the readme file [1].
>
> Best regards,
> Marcus
>
> [1] http://files.ettus.com/e3xx_images/README
>
>
> On 21.04.2016 10:56, john liu via USRP-users wrote:
>
> Dear all,
> I am using the sdimage-gnuradio-dev.direct,and i followed the instruction
> of
> http://files.ettus.com/manual/page_usrp_e3x0.html to update my E310
> sdcard.
>
> i am using *
> <http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg3/sdimage-gnuradio-dev.direct.xz>http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg3/sdimage-gnuradio-dev.direct.xz
> <http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg3/sdimage-gnuradio-dev.direct.xz>*
> i uncompress it at first.
> when i write the image into sdcard,with command dd,and i power the e310,
> and use the
>
> sudo screen /dev/ttyUSB0 115200.
> i see
>
> U-Boot 2015.10 (Jan 07 2016 - 14:47:08 -0800)
>
> Model: NI Ettus Research USRP E3xx SDR
> Board: NI Ettus Research USRP E3xx SDR
> I2C: ready
> DRAM: ECC disabled 1 GiB
> MMC: zynq_sdhci: 0
> Using default environment
>
> In: serial
> Out: serial
> Err: serial
> Model: NI Ettus Research USRP E3xx SDR
> Board: NI Ettus Research USRP E3xx SDR
> MB: Found E3XX RevE - Speedgrade 1
> DB: Found E310 MIMO XCVR RevD
> RAM test... PASSED RAM TEST!
> Net: Gem.e000b000
> Hit any key to stop autoboot: 0
> Loading fpga image from SD to HW...
> reading fpga.bin
> 4045564 bytes read in 191 ms (20.2 MiB/s)
> zynq_align_dma_buffer: Bitstream is not swapped(1) - swap it
> Copying kernel from SD to RAM...
> reading uImage
> 3416624 bytes read in 164 ms (19.9 MiB/s)
> reading uImage-zynq-e31x-1.dtb
> ** Unable to read file uImage-zynq-e31x-1.dtb **
> =>
>
> then e310 stopped.
> there is something wrong?how can i solve it?
> thank for your help.
>
> best regards
> John
>
>
> _______________________________________________
> USRP-users mailing
> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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/20160422/5f82f08d/attachment-0001.html>
------------------------------
Message: 10
Date: Thu, 21 Apr 2016 18:38:00 -0700
From: "Rasa Dovilas" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Installing UHD for E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
I have an E310 with an SD card running the latest Release 4 (which includes
includes UHD 3.9.2 and GNU Radio 3.7.9) and can successfully get the
root@ettus-e3xx-sg1:~# prompt.
>From other posts, I read that my next step would require me to install the
UHD that version matches the SD card for the E310 and that I would need to
add -DENABLE_E300=ON during the install. This means that I can NOT just use
the following which is a newer UHD version:
sudo add-apt-repository ppa:ettusresearch/uhd
sudo apt-get update
sudo apt-get install libuhd-dev libuhd003 uhd-host
Therefore, I went and downloaded the binary for UHD 3.9.2 from
http://files.ettus.com/binaries/images/.
(uhd-images_003.009.002-release.tar.gz)
The manual only has instructions for how to install the SDK. How do I
install the UHD on my computer with the -DENABLE_300=ON?
(My attempt to run cmake in a build directory did not work.)
Also, does the GnuRadio version on my computer need to match what is on the
SD card?
Thanks!
-- Rasa
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160421/5412ca74/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 10491 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160421/5412ca74/attachment-0001.p7s>
------------------------------
Message: 11
Date: Thu, 21 Apr 2016 21:51:53 -0400
From: Dave NotTelling <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] N210 w/ UBX Bursting Issue
Message-ID:
<CAK6GVuNfPkfsLN4Ox2Dx3hQd=xnysoxyunuc9vqeart1hnx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I am working on creating an app that transmits very short bursts (< 100
bytes) very rapidly over a range of frequencies (FHSS). In order to
accomplish the bursting I am using tx_time and tx_freq. The SOB and EOB
values are being calculated automatically by the UHD library since I have a
length tag. What I am seeing is that after a period of time (varies
heavily) the data frame being sent will not correlate with the frequency.
If 0x123456 was to be transmitted on freq1 and 0x789012 to be transmittedon
freq2 then what I will see is 0x123456 on freq2.
I have an example attached to this message. The file (when unzipped)
contains binary data. It is the output of the demodulator piped through a
frame synchronizer I wrote. Two signals are transmitted at 5 MHz apart.
The actual space between them is something around 3 MHz. I have a low pass
filter that selects just the 1 MHz of spectrum I need to capture one of the
signals for demodulation. One signal is transmitting: [0x00, 0xff, 0xaa,
0xaa, 0x00, 0x00, 0x7e, 0x7e, 121, 239, 87, 19, 23, 101, 69, 9, 187, 6, 18,
222, 173, 191, 180, 11, 232, 135, 250, 159, 167, 212, 215, 138, 76, 12] and
the other is transmitting [0x00, 0xff, 0xaa, 0xaa, 0xff, 0xff, 105, 42,
121, 239, 87, 19, 23, 101, 69, 9, 187, 6, 18, 222, 173, 191, 180, 11, 232,
135, 250, 159, 167, 212, 215, 138, 76, 12]. The last 8 bytes of both are
actually replaced with the current time in microseconds in order to
synchronize both signals. The attached file contains just one of those
signals (the first one). Both patterns are almost identical except for the
4-7th (0-based) bytes. This was intentional so that it would be easy to
see that the demod is working correctly and that the issue is not with the
actual demod steps.
Anywho, the file starts off well with the correct bit pattern showing up
(000000001111111110101010101010100000000000000000011111100111111001111001111011110101011100010011000101110110010101000101000010011011101100000110000100101101111010101101101111111011010000001011111010001000011100000000000001010011000100001000010101110010000011100101101000)
remembering that the last 64 bits are a timestamp and change on each
frame. If it's of any use, the time stamps should be something on the
order of 5 milliseconds apart. At frame number 8614 you can see that the
pattern has changed to what the other channel is sending
(000000001111111110101010101010101111111111111111011010010010101001111001111011110101011100010011000101110110010101000101000010011011101100000110000100101101111010101101101111111011010000001011111010001000011100000000000001010011000100001000010111010000101000010110111010).
This happens again at 9745, 11619, 16219, 16376, 19266, 28360, and lots
more.
The farther you get in the file the worse things get. But, it's no longer
an issue of the other channels data getting through, but now the bits are
getting cut off. You'll notice that around line 39670 things start to get
cut off bad. There are lots of ones because I am using a squelch to only
let the bursts through which yields a much better demod. By around line
61583 things have seriously deteriorated. It gets worse from there until
line 81697 where I restarted the modulation graph. Now things look peachy
again. But, you can see that right off the bat the data from the other
channel is now in this channel.
At the end of the file I was stopping and starting the modulator just to
see if I always got data from the other channel when the modulator was
starting.
At no point in this file did I get any errors. No underflows, overflows,
lates, etc.
So, it appears as though either the tx_freq tag or the vector is getting
munged somewhere before making it out of the transmitter.
I discovered this oddity when my receiver was suddenly losing sync even
though I was still transmitting. For a test I pointed my demod to a FIFO
and ran it through the frame sync tool to see the bits live and found that
the data on channel X was the data that should be on channel Y. Sometimes
it takes several minutes to swap over. It's really inconsistent.
If anyone from Ettus would like the flow graph and custom modules I'd be
happy to send them. They are not in a way that I'd like to publicly
release them at the moment though.
Oh, and I have had this issue with 3.9.2 and 3.10 (what's in the Git repo
as of today). 3.9.3 has issues with my X310 not doing simultaneous RX and
TX. I am using an N210 with the UBX-40 for transmission and the X310 with
UBX-160 for reception. I have tried connecting the two directly together
with 60 dB worth of attenuators and just over the air with the antennas
inches apart. The X310 is hooked up to an Intel X710 10Gb NIC using 10Gb
direct attach copper cables. The N210 is hooked up to my motherboard's 1
Gb NIC. The CPU load was stable at around 1/8th total capacity. Nothing
else was going on while the test was running.
My GNU Radio version is 885b5a75 (fresh install from Git this morning)
Thank you!
(I've included the actual file as well as a link to my Google Drive account
in case the attachment gets stripped)
?
uhd_error.txt.gz
<https://drive.google.com/file/d/0BzpbYvv0G2kMTUNqQ05mNEQydHM/view?usp=drive_web>
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160421/df44d4c7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uhd_error.txt.gz
Type: application/x-gzip
Size: 650528 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160421/df44d4c7/attachment-0001.gz>
------------------------------
Message: 12
Date: Thu, 21 Apr 2016 18:54:41 -0700
From: Derek Kozel <[email protected]>
To: Rasa Dovilas <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Installing UHD for E310
Message-ID:
<CAA+K=tseup0w5ootpghpvzhpw3ywcuo3unm7jrvtgcb1uu6...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Rasa,
You will need to compile UHD from source rather than use the binary
installer. The cmake step is slightly changed as described in the manual.
http://files.ettus.com/manual/page_build_guide.html
http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_network_mode
GNU Radio (specifically gr-uhd) needs to be compiled to match the UHD
version you've built and installed.
http://gnuradio.org/redmine/projects/gnuradio/wiki/BuildGuide
If you have already built GNU Radio all you have to do, after installing
the UHD with E310 support, is to run make and make install in the
build/gr-uhd directory.
Regards,
Derek
On Thu, Apr 21, 2016 at 6:38 PM, Rasa Dovilas via USRP-users <
[email protected]> wrote:
> I have an E310 with an SD card running the latest Release 4 (which
> includes includes UHD 3.9.2 and GNU Radio 3.7.9) and can successfully get
> the root@ettus-e3xx-sg1:~# prompt.
>
>
>
> From other posts, I read that my next step would require me to install the
> UHD that version matches the SD card for the E310 and that I would need to
> add -DENABLE_E300=ON during the install. This means that I can NOT just use
> the following which is a newer UHD version:
>
> sudo add-apt-repository ppa:ettusresearch/uhd
>
> sudo apt-get update
>
> sudo apt-get install libuhd-dev libuhd003 uhd-host
>
>
>
> Therefore, I went and downloaded the binary for UHD 3.9.2 from
> http://files.ettus.com/binaries/images/.
> (uhd-images_003.009.002-release.tar.gz)
>
>
>
> The manual only has instructions for how to install the SDK. How do I
> install the UHD on my computer with the ?DENABLE_300=ON?
>
> (My attempt to run cmake in a build directory did not work.)
>
>
>
> Also, does the GnuRadio version on my computer need to match what is on
> the SD card?
>
> Thanks!
>
> -- Rasa
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> 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/20160421/3cec9d1b/attachment-0001.html>
------------------------------
Message: 13
Date: Fri, 22 Apr 2016 13:09:26 +0200
From: BHUSHAN PAWAR <[email protected]>
To: [email protected], [email protected],
Jonathon Pendlum <[email protected]>, Nikos Balkanas
<[email protected]>, Daniel Rudolf <[email protected]>
Subject: [USRP-users] E310 FPGA design_Loopback test
Message-ID:
<CAFvcn__U63Gw5+Sa2RKs-CqmL0Yj7VY=dk7yzj40cnk8wax...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello all,
I am trying to achieve Rx to Tx loopback by editing current FPGA design. In
the current FPGA, data is moved from E310_core --> FIFO --> Processing
System --> FIFO --> E310_core.
In the edited FPGA design, I am trying to bypass Processing system in the
data path to reduce time delay. When I load the edited bit file on E310 it
gives below errors,
[pawa_bh@ohff24 ~]$ ssh -X [email protected]
Last login: Fri Jan 22 00:54:11 2016 from ohff24.local
root@ettus-e3xx-sg1:~# uhd_usrp_probe --args='fpga=/tmp/e300.bit'
linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.009.002-0-unknown
-- Loading FPGA image: /tmp/e300.bit... done
-- Detecting internal GPSDO .... found
-- Initializing core control...
-- Performing register loopback test... pass
-- Performing register loopback test... Error: EnvironmentError: IOError:
Radio ctrl (0) no response packet - AssertionError: bool(buff)
in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
at
/home/balister/release-4/build/tmp-glibc/work/armv7ahf-vfp-neon-oe-linux-gnueabi/uhd/3.9.2-r0/uhd-3.9.2/lib/usrp/cores/radio_ctrl_core_3000.cpp:198
Can you explain the reason for this error? Also we can see, during
initailiazation E310 performs few tests like register loopback test(3
times) and CODEC loopback (2 times) and Timer loopback test (2 times). Can
you briefly explain each test or suggest some data to read to understand
this issue?
*Thanks & Regards,*
*Bhushan R.V. Pawar.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160422/594fe1d0/attachment-0001.html>
------------------------------
Message: 14
Date: Fri, 22 Apr 2016 08:12:40 -0400
From: Philip Balister <[email protected]>
To: Derek Kozel <[email protected]>, Rasa Dovilas
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Installing UHD for E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 04/21/2016 09:54 PM, Derek Kozel via USRP-users wrote:
> Hello Rasa,
>
> You will need to compile UHD from source rather than use the binary
> installer. The cmake step is slightly changed as described in the manual.
> http://files.ettus.com/manual/page_build_guide.html
> http://files.ettus.com/manual/page_usrp_e3x0.html#e3x0_network_mode
>
> GNU Radio (specifically gr-uhd) needs to be compiled to match the UHD
> version you've built and installed.
> http://gnuradio.org/redmine/projects/gnuradio/wiki/BuildGuide
>
> If you have already built GNU Radio all you have to do, after installing
> the UHD with E310 support, is to run make and make install in the
> build/gr-uhd directory.
I'd also suggest that if your goal is use the E310 in network mode,
build uhd-3.9.2 for the PC and not rebuild uhd for the E310.
Philip
>
> Regards,
> Derek
>
>
> On Thu, Apr 21, 2016 at 6:38 PM, Rasa Dovilas via USRP-users <
> [email protected]> wrote:
>
>> I have an E310 with an SD card running the latest Release 4 (which
>> includes includes UHD 3.9.2 and GNU Radio 3.7.9) and can successfully get
>> the root@ettus-e3xx-sg1:~# prompt.
>>
>>
>>
>> From other posts, I read that my next step would require me to install the
>> UHD that version matches the SD card for the E310 and that I would need to
>> add -DENABLE_E300=ON during the install. This means that I can NOT just use
>> the following which is a newer UHD version:
>>
>> sudo add-apt-repository ppa:ettusresearch/uhd
>>
>> sudo apt-get update
>>
>> sudo apt-get install libuhd-dev libuhd003 uhd-host
>>
>>
>>
>> Therefore, I went and downloaded the binary for UHD 3.9.2 from
>> http://files.ettus.com/binaries/images/.
>> (uhd-images_003.009.002-release.tar.gz)
>>
>>
>>
>> The manual only has instructions for how to install the SDK. How do I
>> install the UHD on my computer with the ?DENABLE_300=ON?
>>
>> (My attempt to run cmake in a build directory did not work.)
>>
>>
>>
>> Also, does the GnuRadio version on my computer need to match what is on
>> the SD card?
>>
>> Thanks!
>>
>> -- Rasa
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 68, Issue 23
******************************************
