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: Reducing noise / alternative cooling (Matt Ettus)
2. Re: building an E310 RFNoC FPGA image with HLS (Jonathon Pendlum)
3. RFNOC simulation errors with Modelsim (Weidong Wang)
4. Re: RFNOC simulation errors with Modelsim (Jonathon Pendlum)
5. Re: RFNOC simulation errors with Modelsim (Weidong Wang)
6. UHD Updating Question (Richard Bell)
7. Re: RFNOC simulation errors with Modelsim (Jonathon Pendlum)
8. Re: UHD Updating Question (James Humphries)
9. Re: UHD Updating Question (Derek Kozel)
10. Re: How to choose a ocxo for usrp B2X0? (geo)
11. Re: How to choose a ocxo for usrp B2X0? (Marcus D. Leech)
12. Re: X310 GPS LED (devin kelly)
13. Re: UHD Updating Question (Richard Bell)
14. Re: UHD Updating Question (Marcus M?ller)
15. Re: UHD Updating Question (Derek Kozel)
16. Re: UHD Updating Question (Martin Braun)
17. Re: X310 GPS LED (Martin Braun)
18. Questions about running your FOSDEM 2014 Tutorial: OFDM
Packet Transceivers (Swanson, Craig)
19. Re: [Discuss-gnuradio] UHD Updating Question (Richard Bell)
20. Re: [Discuss-gnuradio] UHD Updating Question (Richard Bell)
21. Re: Questions about running your FOSDEM 2014 Tutorial: OFDM
Packet Transceivers (Martin Braun)
22. Re: Questions about running your FOSDEM 2014 Tutorial: OFDM
Packet Transceivers (Martin Braun)
23. Re: RFNOC simulation errors with Modelsim (Weidong Wang)
24. IOE Error Using USB 3.0 to Ethernet Adapter (Zhihong Luo)
25. Re: IOE Error Using USB 3.0 to Ethernet Adapter (Marcus D. Leech)
26. E312 Multiple Sample Rates in GNU Radio (LB Belella)
27. the working temperature of E312 (john liu)
28. restore default values x300 usrp (Peter-Rene Schroeter)
29. Re: IOE Error Using USB 3.0 to Ethernet Adapter (Marcus M?ller)
30. Re: restore default values x300 usrp (Marcus M?ller)
31. Re: restore default values x300 usrp (Marcus M?ller)
32. Re: IOE Error Using USB 3.0 to Ethernet Adapter
(Alexander Levedahl)
33. Re: the working temperature of E312 (James Humphries)
----------------------------------------------------------------------
Message: 1
Date: Tue, 12 Apr 2016 19:23:09 +0300
From: Matt Ettus <[email protected]>
To: Lars Almon <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Reducing noise / alternative cooling
Message-ID:
<CAN=1kn_nb+gc6dbnoevdfsdiwsqzbxvrhqr269onilxa9r5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Lars,
My suggestion would be to find other fans which would have less noise,
rather than go to the trouble of what you describe. You could also try
putting a resistor in the fan's voltage supply line to reduce the speed.
Matt
On Tue, Apr 12, 2016 at 10:46 AM, Lars Almon via USRP-users <
[email protected]> wrote:
> Hello list,
>
> has anyone experience in alternative cooling methods for the USRPs
> (preferably the X310 series)?
>
> For a testbed we are going to deploy some X310s around the campus in
> normal offices (indoor, ~21?C ambient temperature).
> To increase the acceptance factor we would like to reduce the noise to a
> minimum.
>
> This means removing / deactivating the two small fans.
>
> But to ensure proper cooling, we thought about creating a custom casing
> with a larger heat sink and a bigger more silent fan.
> Of course a passive solution would be best.
>
> I would be interested if anyone of you already did something similar,
> maybe with other USRPs?
>
> Thank you!
>
> - Lars Almon
>
>
> _______________________________________________
> 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/20160412/eaf3ae65/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 12 Apr 2016 09:46:51 -0700
From: Jonathon Pendlum <[email protected]>
To: [email protected]
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] building an E310 RFNoC FPGA image with HLS
Message-ID:
<cagdo0urdimldb+m_-dhv8dh7wdmc6h58vc6h1x1dlbzu41f...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi An Qi,
Check out our Getting Started guide (
https://github.com/EttusResearch/uhd/wiki/RFNoC:-Getting-Started). We will
also have more comprehensive documentation coming in the pipeline. For now,
take a look at noc_block_skeleton.v as a starting place. noc_block_fft.v
and noc_block_fir_filter.v are good examples showing how to integrate
Xilinx IP.
Jonathon
On Tue, Apr 12, 2016 at 7:29 AM, <[email protected]> wrote:
> (Resending this since I forgot to click "reply to all")
>
>
> Hi Jonathon,
>
> So I've been following the addsub block example, and I was wondering how
> to create a noc_block verilog file. Looking at the other noc_block files
> only gives me a vague idea. Also I was wondering if you had some
> documentation that I could read about what the noc_block verilog file
> should contain.
>
> Thanks,
> An Qi
>
> Quoting Jonathon Pendlum <[email protected]>:
>
> Hi An Qi,
>>
>> To build an image using HLS, you need to include a block that uses HLS and
>> then run 'make E310_RFNOC_HLS'. To try it out, we have an example block
>> that can use HLS, noc_block_addsub (usrp3/lib/rfnoc/noc_block_addsub.v).
>> To
>> build an image with that block in it for the E310, you would would add
>> noc_block_addsub (with parameter USE_HLS set to 1) to
>> rfnoc_ce_auto_inst_e310.v and then run 'make E310_RFNOC_HLS'. If you want
>> to use HLS in your own blocks, you can add your C/C++ code in the
>> directory
>> /usrp3/lib/hls using addsub_hls as an example.
>>
>>
>>
>> Jonathon
>>
>> On Fri, Apr 8, 2016 at 12:45 PM, An Qi Zhang via USRP-users <
>> [email protected]> wrote:
>>
>> Hello,
>>>
>>> I was building the RFNoC FPGA image for the E310 and noticed there was an
>>> option to build the FPGA image using Vivado HLS. I was wondering if you
>>> had
>>> a complete set of instructions for building a custom FPGA image using the
>>> E310_RFNOC_HLS option.
>>>
>>> Thanks,
>>> An Qi
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20160412/54663b81/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 12 Apr 2016 16:50:23 +0000
From: Weidong Wang <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] RFNOC simulation errors with Modelsim
Message-ID:
<bl2pr03mb4666000c8e78b9b1f08a8a1f0...@bl2pr03mb466.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160412/07dc5654/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 12 Apr 2016 09:53:45 -0700
From: Jonathon Pendlum <[email protected]>
To: Weidong Wang <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNOC simulation errors with Modelsim
Message-ID:
<CAGdo0uSYLnbTm_7+nN6PhrB6kHa2R=pCW77CT=xcdkhztre...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160412/d11e2929/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 12 Apr 2016 17:14:52 +0000
From: Weidong Wang <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNOC simulation errors with Modelsim
Message-ID:
<bl2pr03mb4664bd373ae4b5b37609cc3f0...@bl2pr03mb466.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
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
<<mailto:[email protected]>[email protected]<mailto:[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]<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/20160412/301da712/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 12 Apr 2016 11:02:53 -0700
From: Richard Bell <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] UHD Updating Question
Message-ID:
<cammoi3toeyhzg+7vpyrkg0twfxzgkejsxgn0tau9x+pmwjf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I'd like to update UHD and my images on the USRPs, but not recompile GNU
Radio if I don't have to. Can I pull the latest UHD, recompile it and flash
the USRPs and not touch GNU Radio?
Using Ubuntu 14.04 LTS
Thanks,
Rich
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160412/e33194a7/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 12 Apr 2016 11:04:21 -0700
From: Jonathon Pendlum <[email protected]>
To: Weidong Wang <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNOC simulation errors with Modelsim
Message-ID:
<CAGdo0uRPE4T=ayd1nywjroeq9s-b9jjborohp7ewhq8vgnt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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]>[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
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160412/d81c581c/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 12 Apr 2016 14:11:21 -0400
From: James Humphries <[email protected]>
To: Richard Bell <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD Updating Question
Message-ID:
<caewgfhxxmt46zpfq3vadqojecerbm9oehef0yyxtwj4bace...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Rich,
I usually recompile both at the same time, I believe you will end up with a
broken interface to UHD through gr-uhd if you do not recompile gnuradio
after upgrading UHD.
Is there any reason you don't want to recompile GNU Radio?
-Trip
On Tue, Apr 12, 2016 at 2:02 PM, Richard Bell via USRP-users <
[email protected]> wrote:
> I'd like to update UHD and my images on the USRPs, but not recompile GNU
> Radio if I don't have to. Can I pull the latest UHD, recompile it and flash
> the USRPs and not touch GNU Radio?
>
> Using Ubuntu 14.04 LTS
>
> Thanks,
> Rich
>
> _______________________________________________
> 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/20160412/64a235f3/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 12 Apr 2016 11:13:03 -0700
From: Derek Kozel <[email protected]>
To: Richard Bell <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD Updating Question
Message-ID:
<CAA+K=tv3fWA0VtF9Wpv_fJ3o31+Apqrvq_kYPATDZH1=ack...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Rich,
No, you'll need to recompile the gr-uhd module which is included with GNU
Radio. This contains C++ code which links directly to UHD.
Strictly speaking there are some releases (or development commits) of UHD
which you can move between without recompiling gr-uhd, but those are very
uncommon. If you run GNU Radio with a UHD block and the ABI versions don't
match you will receive this error message.
RuntimeError:
GR-UHD detected ABI compatibility mismatch with UHD library.
GR-UHD was build against ABI: 3.4.0-1,
but UHD library reports ABI: 3.4.0-2
Suggestion: install an ABI compatible version of UHD,
or rebuild GR-UHD component against this ABI version
Regards,
Derek
On Tue, Apr 12, 2016 at 11:02 AM, Richard Bell via USRP-users <
[email protected]> wrote:
> I'd like to update UHD and my images on the USRPs, but not recompile GNU
> Radio if I don't have to. Can I pull the latest UHD, recompile it and flash
> the USRPs and not touch GNU Radio?
>
> Using Ubuntu 14.04 LTS
>
> Thanks,
> Rich
>
> _______________________________________________
> 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/20160412/bc286c39/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 12 Apr 2016 18:20:21 +0000 (UTC)
From: geo <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] How to choose a ocxo for usrp B2X0?
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi,
I have a question regarding the use of an external 10MHz external reference
clock.
With the external reference clock connected to b200 how do I tell uhd_rx_cfile
to use the external reference instead of the internal one ? Is it done
automatically ? I see no parameter related to this.
Thanks and Regards,George
On Wednesday, January 6, 2016 8:41 PM, geo via USRP-users
<[email protected]> wrote:
Hi Marcus,
regarding the option to use an OCXO for the 10MHz reference.
Can you please give some details regarding the additional circuitry needed to
adapt a 12V OCXO to the ADF4001.
this is what I got:
http://www.ebay.com/itm/10MHz-double-oven-ultra-precision-high-stability-ocxo-/170471367031?hash=item27b0e2a177:g:LQYAAOxyepRRwMsl
The 12Vpp output is a problem and probably impedance matching must also be
considered.
Thanks and Regards,
George
_______________________________________________
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/20160412/c782979c/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 12 Apr 2016 14:29:38 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] How to choose a ocxo for usrp B2X0?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
On 04/12/2016 02:20 PM, geo via USRP-users wrote:
>
> Hi,
>
> I have a question regarding the use of an external 10MHz external
> reference clock.
>
> With the external reference clock connected to b200 how do I tell
> uhd_rx_cfile to use the external reference instead of the internal one
> ? Is it done automatically ? I see no parameter related to this.
>
> Thanks and Regards,
> George
>
>
>
>
>
>
>
> On Wednesday, January 6, 2016 8:41 PM, geo via USRP-users
> <[email protected]> wrote:
>
>
>
>
> Hi Marcus,
>
> regarding the option to use an OCXO for the 10MHz reference.
>
> Can you please give some details regarding the additional circuitry
> needed to adapt a 12V OCXO to the ADF4001.
>
> this is what I got:
>
> http://www.ebay.com/itm/10MHz-double-oven-ultra-precision-high-stability-ocxo-/170471367031?hash=item27b0e2a177:g:LQYAAOxyepRRwMsl
>
> The 12Vpp output is a problem and probably impedance matching must
> also be considered.
>
>
> Thanks and Regards,
> George
Not all applications support the entirety of the UHD device API, and I
guess uhd_rx_cfile is one of them.
You might instead use the UHD-only rx_samples_to_file example.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160412/766f1261/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 12 Apr 2016 14:50:09 -0400
From: devin kelly <[email protected]>
To: usrp-users <[email protected]>
Subject: Re: [USRP-users] X310 GPS LED
Message-ID:
<CAANLyuZZS9Sm=_yyp_eeweuz9bt_h9jo3yxkshcs8vqgbfx...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Anyone have any ideas on this?
Thanks,
Devin
On Fri, Apr 8, 2016 at 11:14 AM, devin kelly <[email protected]> wrote:
> Hello,
>
> I've noticed that I'll turn on on my X310 the GPS LED is off and, after a
> few minutes, I can run query_gpsdo_sensors and that reports a lock (with
> the LED still off). Eventually the GPS LED turns on. I don't notice any
> differences between the the output of query_gpsdo_sensors before and after
> the LED lights up.
>
> What controls when the LED lights up?
>
> This is the UHD I'm using: UHD_003.009.003-0-gf0720677
>
> Devin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160412/70937b05/attachment-0001.html>
------------------------------
Message: 13
Date: Tue, 12 Apr 2016 12:11:17 -0700
From: Richard Bell <[email protected]>
To: Derek Kozel <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD Updating Question
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Alright thanks. I was just wondering if I could save the hour of compile time
is all. No other reason.
Rich
Sent from my iPhone
> On Apr 12, 2016, at 11:13 AM, Derek Kozel <[email protected]> wrote:
>
> Hello Rich,
>
> No, you'll need to recompile the gr-uhd module which is included with GNU
> Radio. This contains C++ code which links directly to UHD.
>
> Strictly speaking there are some releases (or development commits) of UHD
> which you can move between without recompiling gr-uhd, but those are very
> uncommon. If you run GNU Radio with a UHD block and the ABI versions don't
> match you will receive this error message.
>
> RuntimeError:
> GR-UHD detected ABI compatibility mismatch with UHD library.
> GR-UHD was build against ABI: 3.4.0-1,
> but UHD library reports ABI: 3.4.0-2
> Suggestion: install an ABI compatible version of UHD,
> or rebuild GR-UHD component against this ABI version
>
> Regards,
> Derek
>
>> On Tue, Apr 12, 2016 at 11:02 AM, Richard Bell via USRP-users
>> <[email protected]> wrote:
>> I'd like to update UHD and my images on the USRPs, but not recompile GNU
>> Radio if I don't have to. Can I pull the latest UHD, recompile it and flash
>> the USRPs and not touch GNU Radio?
>>
>> Using Ubuntu 14.04 LTS
>>
>> Thanks,
>> Rich
>>
>> _______________________________________________
>> 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/20160412/ab8d0848/attachment-0001.html>
------------------------------
Message: 14
Date: Tue, 12 Apr 2016 21:13:39 +0200
From: Marcus M?ller <[email protected]>
To: [email protected], GNURadio Discussion List
<[email protected]>
Subject: Re: [USRP-users] UHD Updating Question
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
An hour?
That's much. How are you building GNU Radio?
Best regards,
Marcus
PS: taking the discuss-gnuradio mailing list into CC: here; GR compile
time is an interesting issue.
On 12.04.2016 21:11, Richard Bell via USRP-users wrote:
> Alright thanks. I was just wondering if I could save the hour of
> compile time is all. No other reason.
>
> Rich
>
> Sent from my iPhone
>
> On Apr 12, 2016, at 11:13 AM, Derek Kozel <[email protected]
> <mailto:[email protected]>> wrote:
>
>> Hello Rich,
>>
>> No, you'll need to recompile the gr-uhd module which is included with
>> GNU Radio. This contains C++ code which links directly to UHD.
>>
>> Strictly speaking there are some releases (or development commits) of
>> UHD which you can move between without recompiling gr-uhd, but those
>> are very uncommon. If you run GNU Radio with a UHD block and the ABI
>> versions don't match you will receive this error message.
>>
>> RuntimeError:
>> GR-UHD detected ABI compatibility mismatch with UHD library.
>> GR-UHD was build against ABI: 3.4.0-1,
>> but UHD library reports ABI: 3.4.0-2
>> Suggestion: install an ABI compatible version of UHD,
>> or rebuild GR-UHD component against this ABI version
>>
>> Regards,
>> Derek
>>
>> On Tue, Apr 12, 2016 at 11:02 AM, Richard Bell via USRP-users
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> I'd like to update UHD and my images on the USRPs, but not
>> recompile GNU Radio if I don't have to. Can I pull the latest
>> UHD, recompile it and flash the USRPs and not touch GNU Radio?
>>
>> Using Ubuntu 14.04 LTS
>>
>> Thanks,
>> Rich
>>
>> _______________________________________________
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160412/4fb4b1b5/attachment-0001.html>
------------------------------
Message: 15
Date: Tue, 12 Apr 2016 12:17:00 -0700
From: Derek Kozel <[email protected]>
To: Richard Bell <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD Updating Question
Message-ID:
<CAA+K=tvmJ7+f-YEUcon=r4UT7Gh9vz2POUWVyAKx6tdZ_=m...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
You can recompile only gr-uhd if you still have the build directory. That
usually takes me 1-2 minutes on a not super fast machine.
cd <gnuradio_source>/build/gr-uhd
make clean
make -j #CPUs-1
sudo make install
On Tue, Apr 12, 2016 at 12:11 PM, Richard Bell <[email protected]>
wrote:
> Alright thanks. I was just wondering if I could save the hour of compile
> time is all. No other reason.
>
> Rich
>
> Sent from my iPhone
>
> On Apr 12, 2016, at 11:13 AM, Derek Kozel <[email protected]> wrote:
>
> Hello Rich,
>
> No, you'll need to recompile the gr-uhd module which is included with GNU
> Radio. This contains C++ code which links directly to UHD.
>
> Strictly speaking there are some releases (or development commits) of UHD
> which you can move between without recompiling gr-uhd, but those are very
> uncommon. If you run GNU Radio with a UHD block and the ABI versions don't
> match you will receive this error message.
>
> RuntimeError:
> GR-UHD detected ABI compatibility mismatch with UHD library.
> GR-UHD was build against ABI: 3.4.0-1,
> but UHD library reports ABI: 3.4.0-2
> Suggestion: install an ABI compatible version of UHD,
> or rebuild GR-UHD component against this ABI version
>
> Regards,
> Derek
>
> On Tue, Apr 12, 2016 at 11:02 AM, Richard Bell via USRP-users <
> [email protected]> wrote:
>
>> I'd like to update UHD and my images on the USRPs, but not recompile GNU
>> Radio if I don't have to. Can I pull the latest UHD, recompile it and flash
>> the USRPs and not touch GNU Radio?
>>
>> Using Ubuntu 14.04 LTS
>>
>> Thanks,
>> Rich
>>
>> _______________________________________________
>> 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/20160412/56b27adf/attachment-0001.html>
------------------------------
Message: 16
Date: Tue, 12 Apr 2016 12:18:17 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] UHD Updating Question
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 04/12/2016 12:11 PM, Richard Bell via USRP-users wrote:
> Alright thanks. I was just wondering if I could save the hour of compile
> time is all. No other reason.
FYI, this in theory possible *if* the ABI of UHD doesn't change. Major
UHD updates usually don't keep a stable ABI, though.
Cheers,
M
>
> Rich
>
> Sent from my iPhone
>
> On Apr 12, 2016, at 11:13 AM, Derek Kozel <[email protected]
> <mailto:[email protected]>> wrote:
>
>> Hello Rich,
>>
>> No, you'll need to recompile the gr-uhd module which is included with
>> GNU Radio. This contains C++ code which links directly to UHD.
>>
>> Strictly speaking there are some releases (or development commits) of
>> UHD which you can move between without recompiling gr-uhd, but those
>> are very uncommon. If you run GNU Radio with a UHD block and the ABI
>> versions don't match you will receive this error message.
>>
>> RuntimeError:
>> GR-UHD detected ABI compatibility mismatch with UHD library.
>> GR-UHD was build against ABI: 3.4.0-1,
>> but UHD library reports ABI: 3.4.0-2
>> Suggestion: install an ABI compatible version of UHD,
>> or rebuild GR-UHD component against this ABI version
>>
>> Regards,
>> Derek
>>
>> On Tue, Apr 12, 2016 at 11:02 AM, Richard Bell via USRP-users
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>> I'd like to update UHD and my images on the USRPs, but not
>> recompile GNU Radio if I don't have to. Can I pull the latest UHD,
>> recompile it and flash the USRPs and not touch GNU Radio?
>>
>> Using Ubuntu 14.04 LTS
>>
>> Thanks,
>> Rich
>>
>> _______________________________________________
>> 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
>
------------------------------
Message: 17
Date: Tue, 12 Apr 2016 12:52:12 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] X310 GPS LED
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Devin,
the LED is controlled directly from the GPSDO (i.e. pin 3 LOCK_OK is
tied to that LED, albeit routed through the FPGA). For the sensor value,
we read the GPGGA and parse that, which also gives us a 'gps fix'
information.
I don't know how the GPSDO internally differentiates between those two,
though.
Cheers,
Martin
On 04/08/2016 08:14 AM, devin kelly via USRP-users wrote:
> Hello,
>
> I've noticed that I'll turn on on my X310 the GPS LED is off and, after
> a few minutes, I can run query_gpsdo_sensors and that reports a lock
> (with the LED still off). Eventually the GPS LED turns on. I don't
> notice any differences between the the output of query_gpsdo_sensors
> before and after the LED lights up.
>
> What controls when the LED lights up?
>
> This is the UHD I'm using: UHD_003.009.003-0-gf0720677
>
> Devin
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 18
Date: Tue, 12 Apr 2016 21:47:53 +0000
From: "Swanson, Craig" <[email protected]>
To: Martin Braun <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [USRP-users] Questions about running your FOSDEM 2014
Tutorial: OFDM Packet Transceivers
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Martin,
I purchased the identical hardware that you had. I have the following:
* RTLSDR Dongle (NooElec E4000 SDR & DVB-T NESDR XTR) plus antenna
* B210
* GNU Radio
* Gr-osmosdr + dependencies
Would you mind sending me your flowgraphs and anything else, so I could
duplicate your very simple demo?
Thanks,
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th Street NW
Atlanta, GA 30318
Cell: 770-298-9156
http://www.gtri.gatech.edu
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160412/2160f229/attachment-0001.html>
------------------------------
Message: 19
Date: Tue, 12 Apr 2016 14:59:01 -0700
From: Richard Bell <[email protected]>
To: Johnathan Corgan <[email protected]>
Cc: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>, GNURadio
Discussion List <[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] UHD Updating Question
Message-ID:
<cammoi3v2dvm-mj9xh_kfzvpe2aj+-n1m36wagadrsjm59z+...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160412/b5f6def3/attachment-0001.html>
------------------------------
Message: 20
Date: Tue, 12 Apr 2016 15:09:29 -0700
From: Richard Bell <[email protected]>
To: Johnathan Corgan <[email protected]>
Cc: Marcus M?ller <[email protected]>,
"[email protected]" <[email protected]>, GNURadio
Discussion List <[email protected]>
Subject: Re: [USRP-users] [Discuss-gnuradio] UHD Updating Question
Message-ID:
<CAMMoi3ubLE346ikRUoB2s4VZMoepcnzVLa+Pxx=kj80jio5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160412/78f87e4e/attachment-0001.html>
------------------------------
Message: 21
Date: Tue, 12 Apr 2016 15:47:33 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] Questions about running your FOSDEM 2014
Tutorial: OFDM Packet Transceivers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 04/12/2016 02:47 PM, Swanson, Craig wrote:
> Martin,
>
> I purchased the identical hardware that you had. I have the following:
>
> ? RTLSDR Dongle (NooElec E4000 SDR & DVB-T NESDR XTR) plus antenna
>
> ? B210
>
> ? GNU Radio
>
> ? Gr-osmosdr + dependencies
>
>
>
> Would you mind sending me your flowgraphs and anything else, so I could
> duplicate your very simple demo?
You can get it here, but I haven't touched this code in a while. You'll
need to rummage around to figure out what's what.
Cheers,
M
------------------------------
Message: 22
Date: Tue, 12 Apr 2016 15:52:39 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] Questions about running your FOSDEM 2014
Tutorial: OFDM Packet Transceivers
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 04/12/2016 03:47 PM, Martin Braun wrote:
> You can get it here, but I haven't touched this code in a while. You'll
> need to rummage around to figure out what's what.
And by 'here', obviously, I mean here: https://github.com/mbr0wn/gr-fosdem
M
------------------------------
Message: 23
Date: Tue, 12 Apr 2016 23:58:03 +0000
From: Weidong Wang <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNOC simulation errors with Modelsim
Message-ID:
<bl2pr03mb46699f79460c188a585c7b9f0...@bl2pr03mb466.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
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]<mailto:[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<http://noc_block_export_io.sv>(7): Cannot
find `include file "sim_cvita_lib.sv<http://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<http://noc_block_export_io.sv>(8): Cannot
find `include file "sim_set_rb_lib.sv<http://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<http://axi_crossbar_intf.sv>(6):
Cannot find `include file "sim_cvita_lib.sv<http://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<http://axi_crossbar_intf.sv>(7):
Cannot find `include file "sim_set_rb_lib.sv<http://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<http://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<http://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]<mailto:[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]<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/20160412/e867608e/attachment-0001.html>
------------------------------
Message: 24
Date: Tue, 12 Apr 2016 23:17:53 -0400
From: Zhihong Luo <[email protected]>
To: Zhihong Luo via USRP-users <[email protected]>
Subject: [USRP-users] IOE Error Using USB 3.0 to Ethernet Adapter
Message-ID:
<CAH4wXLpdqWBj9KYYFXDRnoKEQWTkr6S-hv90q2tW=duha6f...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
HI all,
I tried to connect to X310 to the laptop using the 1 Gigabit Ethernet port.
I used a USB3.0 to Gigabit Ethernet Adapter for this because the laptop has
no ethernet ports. I set the ip address to 192.168.10.1 and tried
uhd_find_devices and ran into IOE error:
linux; GNU C++ version 5.3.1 20160407; Boost_105800;
UHD_003.010.rfnoc-316-gb7546712
UHD Error:
x300 fw communication failure #1
EnvironmentError: IOError: x300 fw peek32 - reply timed out
UHD Error:
x300 fw communication failure #1
EnvironmentError: IOError: x300 fw peek32 - reply timed out
UHD Error:
x300 fw communication failure #2
EnvironmentError: IOError: x300 fw peek32 - reply timed out
^C
The MTU is fixed as 1500. I tried to ping 192.168.10.1, there are
considerable percentage of packet loss (30%, 40% or more). Is it because I
neglected some special settings for laptops, or the speed of the adapter is
simply not fast enough (it claims to have Gigabit throughput though...) ?
Thanks in advance for any help.
Thanks,
Zhihong
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160412/eec25a18/attachment-0001.html>
------------------------------
Message: 25
Date: Tue, 12 Apr 2016 23:21:32 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] IOE Error Using USB 3.0 to Ethernet Adapter
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252; format=flowed
On 04/12/2016 11:17 PM, Zhihong Luo via USRP-users wrote:
> HI all,
>
> I tried to connect to X310 to the laptop using the 1 Gigabit Ethernet
> port. I used a USB3.0 to Gigabit Ethernet Adapter for this because the
> laptop has no ethernet ports. I set the ip address to 192.168.10.1 and
> tried uhd_find_devices and ran into IOE error:
>
> linux; GNU C++ version 5.3.1 20160407; Boost_105800;
> UHD_003.010.rfnoc-316-gb7546712
>
>
> UHD Error:
> x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw peek32 - reply timed out
>
> UHD Error:
> x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw peek32 - reply timed out
>
> UHD Error:
> x300 fw communication failure #2
> EnvironmentError: IOError: x300 fw peek32 - reply timed out
> ^C
>
> The MTU is fixed as 1500. I tried to ping 192.168.10.1, there are
> considerable percentage of packet loss (30%, 40% or more). Is it
> because I neglected some special settings for laptops, or the speed of
> the adapter is simply not fast enough (it claims to have Gigabit
> throughput though...) ? Thanks in advance for any help.
>
> Thanks,
> Zhihong
>
>
These USB-3.0 to 1GiGe adapters are mostly garbage, unfortunately. They
*don't* support the rates they advertise, and *worse* the very often
re-order traffic that has no business being re-ordered, which is fatal
to a protocol that expects *zero* re-ordering by the underlying layers.
------------------------------
Message: 26
Date: Tue, 12 Apr 2016 18:40:38 -0400
From: LB Belella <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] E312 Multiple Sample Rates in GNU Radio
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Greetings all. Is
it possible to set the sample rate for each RX channel of an E312 independently
using the usrp_source driver? Looking at the uhd driver I can see there
is a uhd::usrp::multi_usrp::set_rx_rate function that can take a channel index
but it doesn't look like that translates into the gr-uhd wrapper. Is
there another way to achieve this? I'm new to the USRP stuff and I
was hoping someone could provide a little insight.
Thanks in advance!
lb
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160412/03263b65/attachment-0001.html>
------------------------------
Message: 27
Date: Wed, 13 Apr 2016 12:13:29 +0800
From: john liu <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] the working temperature of E312
Message-ID:
<caf6nntl26uukmyuuwtexnz_de7v67ju-1uxkkq5b8yzko9a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
From battery data sheet of E312,we know the battery can work normally
on -20~60?.That is to say,the E312 can work fine on -20~60??
thank you for help
best regards
John
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160413/5c7a0fd0/attachment-0001.html>
------------------------------
Message: 28
Date: Wed, 13 Apr 2016 08:49:30 +0200
From: Peter-Rene Schroeter <[email protected]>
To: [email protected]
Subject: [USRP-users] restore default values x300 usrp
Message-ID:
<20160413084930.horde.u0awgac8-aiyozgmtawx...@webmail.tu-berlin.de>
Content-Type: text/plain; charset="utf-8"; Format="flowed";
DelSp="Yes"
Dear all,
it is impossible to restore default values of our x300 usrp. See
attachment. It uses default IP address 192.168.10.2. Also the current
uhd tools (self build) could not find it but ping IP address works.
Any idea?
Thank you for your help.
Best regards,
Peter?
-------------- next part --------------
robat@harry:~/uhd/host/build/utils$ uhd_usrp_probe
linux; GNU C++ version 4.8.4; Boost_105500; UHD_003.009.003-11-g1a002d38
-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
Error: RuntimeError: No revision compat detected. MB EEPROM must be
reprogrammed!
/usr/local/lib/uhd/utils/uhd_images_downloader.py
/usr/local/bin/uhd_image_loader --args="type=x300,addr=192.168.10.2"
power cycle
./usrp_burn_mb_eeprom --args="recover_mb_eeprom,addr=192.168.10.2"
--values="revision=6"
linux; GNU C++ version 4.8.4; Boost_105500; UHD_003.009.003-11-g1a002d38
Creating USRP device from address: recover_mb_eeprom,addr=192.168.10.2
-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
UHD Warning:
UHD is operating in EEPROM Recovery Mode which disables hardware version
checks.
Operating in this mode may cause hardware damage and unstable radio
performance!
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Detecting internal GPSDO.... No GPSDO found
-- Initialize Radio0 control...
-- Performing register loopback test... pass
-- Initialize Radio1 control...
-- Performing register loopback test... pass
Error: RuntimeError: ADC self-test failed! Ramp checker status: {ADC0_I=Bit
Errors!, ADC0_Q=Bit Errors!, ADC1_I=Good, ADC1_Q=Good}
------------------------------
Message: 29
Date: Wed, 13 Apr 2016 10:30:38 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] IOE Error Using USB 3.0 to Ethernet Adapter
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
As the other Marcus wrote, there's several customers who've had terrible
experiences with USB3-to-gigabit network interfaces. The most important
reason is that their firmware or drivers reorder ethernet packets?,
which is OK when you're mainly doing TCP transfers over it (e.g. you use
the network interface to surf the web or exchange files with your
company's storage server), but for real-time protocols, that simply
doesn't make any sense. Hence, UHD can't work with that.
Moreover, USB is a terrible protocol for encapsulating high-rate Network
transfers, because there's no automated DMA that could take the data
from the device to a specific position in RAM without the CPU and OS
assisting on every packet. The CPU overhead is substantial.
I'm afraid the proper choice here is using a laptop with a Gigabit
Ethernet interface integrated directly into the mainboard's chipset or
attached via PCIexpress (and not attached internally via USB, as some
manufacturers have decided to do). Another option would be using an
ExpressCard adapter like [1] , but to be honest: I'd expect a notebook
with expresscard slot to have native gigabit ethernet, too.
Maybe you have a modern Macbook or another high-end laptop with
Thunderbolt? The Thunderbolt to Gigabit adapter apple sells should work
? it internally uses a broadcom chipset attached via PCIe; I've never
tested that, though.
Also, there's external thunderbolt boxes that allow you to use arbitrary
PCIe cards, for example 10GE cards. Customers have done this with such a
box produced by Sonnet, to attach the X310 to their laptop using 10GE.
Best regards,
Marcus
? in fact, together with a customer, I dug into the USB-network stack of
linux, and I'm pretty sure it's the firmware/USB device itself, not the
driver)
[1] http://www.delock.de/produkte/G_66216/merkmale.html?setLanguage=en
On 13.04.2016 05:17, Zhihong Luo via USRP-users wrote:
> HI all,
>
> I tried to connect to X310 to the laptop using the 1 Gigabit Ethernet
> port. I used a USB3.0 to Gigabit Ethernet Adapter for this because the
> laptop has no ethernet ports. I set the ip address to 192.168.10.1 and
> tried uhd_find_devices and ran into IOE error:
>
> linux; GNU C++ version 5.3.1 20160407; Boost_105800;
> UHD_003.010.rfnoc-316-gb7546712
>
>
> UHD Error:
> x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw peek32 - reply timed out
>
> UHD Error:
> x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw peek32 - reply timed out
>
> UHD Error:
> x300 fw communication failure #2
> EnvironmentError: IOError: x300 fw peek32 - reply timed out
> ^C
>
> The MTU is fixed as 1500. I tried to ping 192.168.10.1, there are
> considerable percentage of packet loss (30%, 40% or more). Is it
> because I neglected some special settings for laptops, or the speed of
> the adapter is simply not fast enough (it claims to have Gigabit
> throughput though...) ? Thanks in advance for any help.
>
> Thanks,
> Zhihong
>
>
> _______________________________________________
> 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/20160413/dfae9039/attachment-0001.html>
------------------------------
Message: 30
Date: Wed, 13 Apr 2016 10:32:42 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] restore default values x300 usrp
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Dear Peter,
copying a mail from my colleage Trip [1]:
> There is a utility
> that you can use to restore the EEPROM.
>
> First, you need to determine the revision of your X310. There should be a
> sticker near the AUX I/O connector that will have the part number. It
> should look similar to 123456<R>-<YYY>. You are looking for the letter code
> <R> on the sticker. The letter maps to a revision number:
>
> C=3
> D=4
> E=5
> F=6
>
> Use the usrp_burn_mb_eeprom utility to restore the revision code. It is
> located in your build directory. The command will look like this with your
> arguments:
>
> ./usrp_burn_mb_eeprom --args="recover_mb_eeprom, addr=192.168.10.2"
> --values="revision=<Revision_Number>"
>
> After you have done this, make sure to power cycle the X310. Let me know if
> you still have any issues.
I hope that helps!
Best regards,
Marcus
[1]
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2015-November/016879.html
On 13.04.2016 08:49, Peter-Rene Schroeter via USRP-users wrote:
> Dear all,
>
> it is impossible to restore default values of our x300 usrp. See
> attachment. It uses default IP address 192.168.10.2. Also the current
> uhd tools (self build) could not find it but ping IP address works.
> Any idea?
>
> Thank you for your help.
>
> Best regards,
> Peter?
>
>
> _______________________________________________
> 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/20160413/1608ebd2/attachment-0001.html>
------------------------------
Message: 31
Date: Wed, 13 Apr 2016 10:34:31 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] restore default values x300 usrp
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Ah, wait, you already did that; my mail client cut off the mail.
Ok, so, first question is whether the revision=6 is actually correct.
If it is, we might have something more complicated at hand.
Best regards,
Marcus
On 13.04.2016 08:49, Peter-Rene Schroeter via USRP-users wrote:
> Dear all,
>
> it is impossible to restore default values of our x300 usrp. See
> attachment. It uses default IP address 192.168.10.2. Also the current
> uhd tools (self build) could not find it but ping IP address works.
> Any idea?
>
> Thank you for your help.
>
> Best regards,
> Peter?
>
>
> _______________________________________________
> 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/20160413/59a83b56/attachment-0001.html>
------------------------------
Message: 32
Date: Wed, 13 Apr 2016 08:45:36 -0400
From: Alexander Levedahl <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] IOE Error Using USB 3.0 to Ethernet Adapter
Message-ID:
<ca+z+ori_csoxnyxhzovqgp4akmgedjjm427mv+mg3rgqmv5...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Marcus Muller,
You mention that the CPU intervenes when transferring data via USB 3. Does
this happen to the B2xx USRPS?
Thanks,
Alex
On Wed, Apr 13, 2016 at 4:30 AM, Marcus M?ller <[email protected]>
wrote:
> As the other Marcus wrote, there's several customers who've had terrible
> experiences with USB3-to-gigabit network interfaces. The most important
> reason is that their firmware or drivers reorder ethernet packets?, which
> is OK when you're mainly doing TCP transfers over it (e.g. you use the
> network interface to surf the web or exchange files with your company's
> storage server), but for real-time protocols, that simply doesn't make any
> sense. Hence, UHD can't work with that.
>
> Moreover, USB is a terrible protocol for encapsulating high-rate Network
> transfers, because there's no automated DMA that could take the data from
> the device to a specific position in RAM without the CPU and OS assisting
> on every packet. The CPU overhead is substantial.
>
> I'm afraid the proper choice here is using a laptop with a Gigabit
> Ethernet interface integrated directly into the mainboard's chipset or
> attached via PCIexpress (and not attached internally via USB, as some
> manufacturers have decided to do). Another option would be using an
> ExpressCard adapter like [1] , but to be honest: I'd expect a notebook with
> expresscard slot to have native gigabit ethernet, too.
> Maybe you have a modern Macbook or another high-end laptop with
> Thunderbolt? The Thunderbolt to Gigabit adapter apple sells should work ?
> it internally uses a broadcom chipset attached via PCIe; I've never tested
> that, though.
> Also, there's external thunderbolt boxes that allow you to use arbitrary
> PCIe cards, for example 10GE cards. Customers have done this with such a
> box produced by Sonnet, to attach the X310 to their laptop using 10GE.
>
> Best regards,
> Marcus
>
> ? in fact, together with a customer, I dug into the USB-network stack of
> linux, and I'm pretty sure it's the firmware/USB device itself, not the
> driver)
>
> [1] http://www.delock.de/produkte/G_66216/merkmale.html?setLanguage=en
>
>
> On 13.04.2016 05:17, Zhihong Luo via USRP-users wrote:
>
> HI all,
>
> I tried to connect to X310 to the laptop using the 1 Gigabit Ethernet
> port. I used a USB3.0 to Gigabit Ethernet Adapter for this because the
> laptop has no ethernet ports. I set the ip address to 192.168.10.1 and
> tried uhd_find_devices and ran into IOE error:
>
> linux; GNU C++ version 5.3.1 20160407; Boost_105800;
> UHD_003.010.rfnoc-316-gb7546712
>
>
> UHD Error:
> x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw peek32 - reply timed out
>
> UHD Error:
> x300 fw communication failure #1
> EnvironmentError: IOError: x300 fw peek32 - reply timed out
>
> UHD Error:
> x300 fw communication failure #2
> EnvironmentError: IOError: x300 fw peek32 - reply timed out
> ^C
>
> The MTU is fixed as 1500. I tried to ping 192.168.10.1, there are
> considerable percentage of packet loss (30%, 40% or more). Is it because I
> neglected some special settings for laptops, or the speed of the adapter is
> simply not fast enough (it claims to have Gigabit throughput though...) ?
> Thanks in advance for any help.
>
> Thanks,
> Zhihong
>
>
> _______________________________________________
> 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/20160413/47992642/attachment-0001.html>
------------------------------
Message: 33
Date: Wed, 13 Apr 2016 11:38:06 -0400
From: James Humphries <[email protected]>
To: john liu <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] the working temperature of E312
Message-ID:
<CAEwGFhUVEtMbut6Mnzie_OTSzKjWa_T=8ybcr9wfkqshc8j...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi John,
Which data sheet are you referring to?
https://www.ettus.com/content/files/USRP_E312_Datasheet.pdf
Operating temperature for E312 is 0-45 C.
-Trip
On Wed, Apr 13, 2016 at 12:13 AM, john liu via USRP-users <
[email protected]> wrote:
> Dear all,
> From battery data sheet of E312,we know the battery can work
> normally on -20~60?.That is to say,the E312 can work fine on -20~60??
> thank you for help
> best regards
> John
>
> _______________________________________________
> 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/20160413/9a076a20/attachment-0001.html>
------------------------------
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 13
******************************************
