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. Unable to load rfnoc-radio-redo bit file into E310
(Swanson, Craig)
2. Re: RFNoC: RuntimeError: On node 0/CostasLoop_0, output port
0 is already connected (Jason Matusiak)
3. Re: Unable to load rfnoc-radio-redo bit file into E310
(Jonathon Pendlum)
4. Re: Unable to load rfnoc-radio-redo bit file into E310
(Martin Braun)
5. Re: RFNoC: RuntimeError: On node 0/CostasLoop_0, output port
0 is already connected (Martin Braun)
6. Re: X310 RFNOC FFT block issue (Martin Braun)
7. Problem of running two channels of TVRX2 (Tai Wooi Ling)
8. Re: Wish list suggestions for future tutorials (Swanson, Craig)
9. Re: Wish list suggestions for future tutorials ([email protected])
10. How to use memory in RFNoC CE (Zhihong Luo)
11. Re: Thunderbolt? 3 on Laptop to 10 Gigabit Ethernet (Zhihong Luo)
12. Re: How to use memory in RFNoC CE (Jonathon Pendlum)
13. Re: master clock of X300 (Ashish Chaudhari)
14. Re: Thunderbolt? 3 on Laptop to 10 Gigabit Ethernet (Serge Malo)
15. Re: RFNoC: RuntimeError: On node 0/CostasLoop_0, output port
0 is already connected (Jason Matusiak)
16. Re: RFNoC: RuntimeError: On node 0/CostasLoop_0, output port
0 is already connected (Sylvain Munaut)
17. Re: X310 RFNOC FFT block issue (James Wagner)
18. Re: B210: 20db difference between RX2 antenna on A:A and A:B
(Patrick Sathyanathan)
19. questions about usrp b210 (liangyong)
20. gr-ettus will not build (Swanson, Craig)
21. Re: gr-ettus will not build (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Fri, 6 May 2016 16:15:11 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [USRP-users] Unable to load rfnoc-radio-redo bit file into
E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Jonathon,
Two issues:
Also it would be nice if you would call the rfnoc-devel branch bit file the
same name in the top/e300/build directory as in the rfnoc-radio-redo branch.
craig@craig-VirtualBox:~/uhd/rfnoc-radio-redo/usrp3/top/e300/build
(rfnoc-devel)$ ls
usrp_e310_fpga_RFNOC.bin usrp_e310_fpga_RFNOC.bit usrp_e310_fpga_RFNOC.rpt
craig@craig-VirtualBox:~/uhd/rfnoc-devel/usrp3/top/e300/build (rfnoc-devel)$ ls
usrp_e310_rfnoc_fpga.bin usrp_e310_rfnoc_fpga.bit usrp_e310_rfnoc_fpga.rpt
In rfnoc-radio-redo, I successfully generated a bit file, then copied it over
to the E310, then uhd_usrp_probe --init-only and got the following results:
?
root@ettus-e300:~/rfnoc_Receiver# uhd_usrp_probe --init-only
linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.010.rfnoc-316-gb7546712
-- Loading FPGA image: /home/root/rfnoc_Receiver/usrp_e310_fpga.bit... done
-- Initializing core control...
-- Performing register loopback test... pass
-- [E300] Setting up dest map for host ep 0 to be stream 0
-- Performing register loopback test... fail
-- [RFNOC] ------- Radio Setup -----------
-- [RFNoC Factory] block_ctrl_base::make()
-- [RFNoC Factory] Using controller key 'Radio' and block name 'Radio'
-- block_ctrl_base()
-- base_path = "/usr/share/uhd/rfnoc"
-- base_path = "/usr/share/uhd/rfnoc"
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/block.xml
-- NOC ID: 0x12AD100000000000 Block ID: 0/Radio_0
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/0: type = ''
pkt_size = '0' vlen = '0'
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/0: type = ''
pkt_size = '0' vlen = '0'
-- radio_ctrl::radio_ctrl() _rx_spp==364
-- setting xbar/Radio_0/ports/out/0
-- [0/Radio_0] radio_ctrl::_update_spp(): Requested spp: 364
-- [0/Radio_0] radio_ctrl::_update_spp(): Setting spp to: 364
-- [0/Radio_0] radio_ctrl::_update_rx_args()
-- Setting VITA core
-- Setting DSP core
-- Updating muxes
-- [0/Radio_0] radio_ctrl::update_muxes()
-- [0/Radio_0] radio_ctrl::_update_tx_args()
-- Setting VITA core
-- Setting DSP core
-- Updating muxes
-- [0/Radio_0] radio_ctrl::update_muxes()
-- [0/Radio_0] radio_ctrl::update_muxes()
-- dboards/A/tx_frontends/A/connection == IQ
-- [0/Radio_0] radio_ctrl::update_muxes()
-- dboards/A/rx_frontends/A/connection == IQ
-- [E300] Setting up dest map for host ep 1 to be stream 1
-- Performing register loopback test... fail
-- [RFNOC] ------- Radio Setup -----------
-- [RFNoC Factory] block_ctrl_base::make()
-- [RFNoC Factory] Using controller key 'Radio' and block name 'Radio'
-- block_ctrl_base()
-- base_path = "/usr/share/uhd/rfnoc"
-- Reading XML file: /usr/share/uhd/rfnoc/blocks/fifo.xml
-- Found valid blockdef
-- NOC ID: 0xF1F0000000000000 Block ID: 0/Radio_1
-- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/in/0: type = ''
pkt_size = '0' vlen = '0'
-- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/out/0: type = ''
pkt_size = '0' vlen = '0'
-- radio_ctrl::radio_ctrl() _rx_spp==364
-- setting xbar/Radio_1/ports/out/0
-- [0/Radio_1] radio_ctrl::_update_spp(): Requested spp: 364
-- [0/Radio_1] radio_ctrl::_update_spp(): Setting spp to: 364
-- [0/Radio_1] radio_ctrl::_update_rx_args()
-- Setting VITA core
-- Setting DSP core
-- Updating muxes
-- [0/Radio_1] radio_ctrl::update_muxes()
-- [0/Radio_1] radio_ctrl::_update_tx_args()
-- Setting VITA core
-- Setting DSP core
-- Updating muxes
-- [0/Radio_1] radio_ctrl::update_muxes()
-- [0/Radio_1] radio_ctrl::update_muxes()
-- dboards/A/tx_frontends/B/connection == IQ
-- [0/Radio_1] radio_ctrl::update_muxes()
-- dboards/A/rx_frontends/B/connection == IQ
-- Performing CODEC loopback test... fail
Error: RuntimeError: CODEC loopback test failed.
?
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160506/72510c8b/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 6 May 2016 12:20:42 -0400
From: Jason Matusiak <[email protected]>
To: Sylvain Munaut <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC: RuntimeError: On node 0/CostasLoop_0,
output port 0 is already connected
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
> Not sure if it's the "right" fix, but that seemed to have helped for me.
Sylvain, Were you able to verify that this solved all of your issues
(potentially indirectly, I know)?
~Jason
------------------------------
Message: 3
Date: Fri, 6 May 2016 11:22:26 -0500
From: Jonathon Pendlum <[email protected]>
To: "Swanson, Craig" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Unable to load rfnoc-radio-redo bit file
into E310
Message-ID:
<cagdo0urih+saep30wa8vou1+z2vffkuyoh6ca_ajsw91fpo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Craig,
Are you using the latest uhd rfnoc-radio-redo branch commit? From the log,
it looks like you are using an old commit.
Jonathon
On Fri, May 6, 2016 at 11:15 AM, Swanson, Craig <
[email protected]> wrote:
> Jonathon,
>
>
> Two issues:
>
>
> Also it would be nice if you would call the rfnoc-devel branch bit file
> the same name in the top/e300/build directory as in the
> rfnoc-radio-redo branch.
>
>
> craig@craig-VirtualBox:~/uhd/rfnoc-radio-redo/usrp3/top/e300/build
> (rfnoc-devel)$ ls
> usrp_e310_fpga_RFNOC.bin usrp_e310_fpga_RFNOC.bit
> usrp_e310_fpga_RFNOC.rpt
>
> craig@craig-VirtualBox:~/uhd/rfnoc-devel/usrp3/top/e300/build
> (rfnoc-devel)$ ls
> usrp_e310_rfnoc_fpga.bin usrp_e310_rfnoc_fpga.bit
> usrp_e310_rfnoc_fpga.rpt
>
>
>
> In rfnoc-radio-redo, I successfully generated a bit file, then copied it
> over to the E310, then uhd_usrp_probe --init-only and got the following
> results:
> ?
> root@ettus-e300:~/rfnoc_Receiver# uhd_usrp_probe --init-only
> linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.010.rfnoc-316-gb7546712
>
> -- Loading FPGA image: /home/root/rfnoc_Receiver/usrp_e310_fpga.bit... done
> -- Initializing core control...
> -- Performing register loopback test... pass
> -- [E300] Setting up dest map for host ep 0 to be stream 0
> -- Performing register loopback test... fail
> -- [RFNOC] ------- Radio Setup -----------
> -- [RFNoC Factory] block_ctrl_base::make()
> -- [RFNoC Factory] Using controller key 'Radio' and block name 'Radio'
> -- block_ctrl_base()
> -- base_path = "/usr/share/uhd/rfnoc"
> -- base_path = "/usr/share/uhd/rfnoc"
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/block.xml
> -- NOC ID: 0x12AD100000000000 Block ID: 0/Radio_0
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/0: type =
> '' pkt_size = '0' vlen = '0'
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/0: type =
> '' pkt_size = '0' vlen = '0'
> -- radio_ctrl::radio_ctrl() _rx_spp==364
> -- setting xbar/Radio_0/ports/out/0
> -- [0/Radio_0] radio_ctrl::_update_spp(): Requested spp: 364
> -- [0/Radio_0] radio_ctrl::_update_spp(): Setting spp to: 364
> -- [0/Radio_0] radio_ctrl::_update_rx_args()
> -- Setting VITA core
> -- Setting DSP core
> -- Updating muxes
> -- [0/Radio_0] radio_ctrl::update_muxes()
> -- [0/Radio_0] radio_ctrl::_update_tx_args()
> -- Setting VITA core
> -- Setting DSP core
> -- Updating muxes
> -- [0/Radio_0] radio_ctrl::update_muxes()
> -- [0/Radio_0] radio_ctrl::update_muxes()
> -- dboards/A/tx_frontends/A/connection == IQ
> -- [0/Radio_0] radio_ctrl::update_muxes()
> -- dboards/A/rx_frontends/A/connection == IQ
> -- [E300] Setting up dest map for host ep 1 to be stream 1
> -- Performing register loopback test... fail
> -- [RFNOC] ------- Radio Setup -----------
> -- [RFNoC Factory] block_ctrl_base::make()
> -- [RFNoC Factory] Using controller key 'Radio' and block name 'Radio'
> -- block_ctrl_base()
> -- base_path = "/usr/share/uhd/rfnoc"
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/fifo.xml
> -- Found valid blockdef
> -- NOC ID: 0xF1F0000000000000 Block ID: 0/Radio_1
> -- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/in/0: type =
> '' pkt_size = '0' vlen = '0'
> -- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/out/0: type =
> '' pkt_size = '0' vlen = '0'
> -- radio_ctrl::radio_ctrl() _rx_spp==364
> -- setting xbar/Radio_1/ports/out/0
> -- [0/Radio_1] radio_ctrl::_update_spp(): Requested spp: 364
> -- [0/Radio_1] radio_ctrl::_update_spp(): Setting spp to: 364
> -- [0/Radio_1] radio_ctrl::_update_rx_args()
> -- Setting VITA core
> -- Setting DSP core
> -- Updating muxes
> -- [0/Radio_1] radio_ctrl::update_muxes()
> -- [0/Radio_1] radio_ctrl::_update_tx_args()
> -- Setting VITA core
> -- Setting DSP core
> -- Updating muxes
> -- [0/Radio_1] radio_ctrl::update_muxes()
> -- [0/Radio_1] radio_ctrl::update_muxes()
> -- dboards/A/tx_frontends/B/connection == IQ
> -- [0/Radio_1] radio_ctrl::update_muxes()
> -- dboards/A/rx_frontends/B/connection == IQ
> -- Performing CODEC loopback test... fail
> Error: RuntimeError: CODEC loopback test failed.
>
>
>
>
> ?
>
>
>
>
> *Craig F. Swanson*
>
> *Research Engineer II *
> *Information and Communications Laboratory*
> *Communications, Systems, and Spectrum Division*
> *Georgia Tech Research Institute*
>
>
> *Room 560 250 14th St NW *
> *Atlanta, GA 30318*
> *Cell: 770.298.9156 <770.298.9156>*
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160506/2a8e9600/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 6 May 2016 09:25:08 -0700
From: Martin Braun <[email protected]>
To: "Swanson, Craig" <[email protected]>, Jonathon Pendlum
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Unable to load rfnoc-radio-redo bit file
into E310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
On 05/06/2016 09:15 AM, Swanson, Craig via USRP-users wrote:
> Jonathon,
>
>
> Two issues:
>
>
> Also it would be nice if you would call the rfnoc-devel branch bit file
> the same name in the top/e300/build directory as in the
> rfnoc-radio-redo branch.
Will will fix that soon; the naming from radio-redo will be the official
one.
> craig@craig-VirtualBox:~/uhd/rfnoc-radio-redo/usrp3/top/e300/build
> (rfnoc-devel)$ ls
> usrp_e310_fpga_RFNOC.bin usrp_e310_fpga_RFNOC.bit usrp_e310_fpga_RFNOC.rpt
>
> craig@craig-VirtualBox:~/uhd/rfnoc-devel/usrp3/top/e300/build
> (rfnoc-devel)$ ls
> usrp_e310_rfnoc_fpga.bin usrp_e310_rfnoc_fpga.bit usrp_e310_rfnoc_fpga.rpt
>
>
>
> In rfnoc-radio-redo, I successfully generated a bit file, then copied it
> over to the E310, then uhd_usrp_probe --init-only and got the following
> results:
Can you confirm you've reset your local branches to the current remotes
for both FPGA and UHD?
M
>
> ?
> root@ettus-e300:~/rfnoc_Receiver# uhd_usrp_probe --init-only
> linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.010.rfnoc-316-gb7546712
>
> -- Loading FPGA image: /home/root/rfnoc_Receiver/usrp_e310_fpga.bit... done
> -- Initializing core control...
> -- Performing register loopback test... pass
> -- [E300] Setting up dest map for host ep 0 to be stream 0
> -- Performing register loopback test... fail
> -- [RFNOC] ------- Radio Setup -----------
> -- [RFNoC Factory] block_ctrl_base::make()
> -- [RFNoC Factory] Using controller key 'Radio' and block name 'Radio'
> -- block_ctrl_base()
> -- base_path = "/usr/share/uhd/rfnoc"
> -- base_path = "/usr/share/uhd/rfnoc"
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/block.xml
> -- NOC ID: 0x12AD100000000000 Block ID: 0/Radio_0
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/0: type =
> '' pkt_size = '0' vlen = '0'
> -- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/0: type
> = '' pkt_size = '0' vlen = '0'
> -- radio_ctrl::radio_ctrl() _rx_spp==364
> -- setting xbar/Radio_0/ports/out/0
> -- [0/Radio_0] radio_ctrl::_update_spp(): Requested spp: 364
> -- [0/Radio_0] radio_ctrl::_update_spp(): Setting spp to: 364
> -- [0/Radio_0] radio_ctrl::_update_rx_args()
> -- Setting VITA core
> -- Setting DSP core
> -- Updating muxes
> -- [0/Radio_0] radio_ctrl::update_muxes()
> -- [0/Radio_0] radio_ctrl::_update_tx_args()
> -- Setting VITA core
> -- Setting DSP core
> -- Updating muxes
> -- [0/Radio_0] radio_ctrl::update_muxes()
> -- [0/Radio_0] radio_ctrl::update_muxes()
> -- dboards/A/tx_frontends/A/connection == IQ
> -- [0/Radio_0] radio_ctrl::update_muxes()
> -- dboards/A/rx_frontends/A/connection == IQ
> -- [E300] Setting up dest map for host ep 1 to be stream 1
> -- Performing register loopback test... fail
> -- [RFNOC] ------- Radio Setup -----------
> -- [RFNoC Factory] block_ctrl_base::make()
> -- [RFNoC Factory] Using controller key 'Radio' and block name 'Radio'
> -- block_ctrl_base()
> -- base_path = "/usr/share/uhd/rfnoc"
> -- Reading XML file: /usr/share/uhd/rfnoc/blocks/fifo.xml
> -- Found valid blockdef
> -- NOC ID: 0xF1F0000000000000 Block ID: 0/Radio_1
> -- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/in/0: type =
> '' pkt_size = '0' vlen = '0'
> -- [0/Radio_1] Adding port definition at xbar/Radio_1/ports/out/0: type
> = '' pkt_size = '0' vlen = '0'
> -- radio_ctrl::radio_ctrl() _rx_spp==364
> -- setting xbar/Radio_1/ports/out/0
> -- [0/Radio_1] radio_ctrl::_update_spp(): Requested spp: 364
> -- [0/Radio_1] radio_ctrl::_update_spp(): Setting spp to: 364
> -- [0/Radio_1] radio_ctrl::_update_rx_args()
> -- Setting VITA core
> -- Setting DSP core
> -- Updating muxes
> -- [0/Radio_1] radio_ctrl::update_muxes()
> -- [0/Radio_1] radio_ctrl::_update_tx_args()
> -- Setting VITA core
> -- Setting DSP core
> -- Updating muxes
> -- [0/Radio_1] radio_ctrl::update_muxes()
> -- [0/Radio_1] radio_ctrl::update_muxes()
> -- dboards/A/tx_frontends/B/connection == IQ
> -- [0/Radio_1] radio_ctrl::update_muxes()
> -- dboards/A/rx_frontends/B/connection == IQ
> -- Performing CODEC loopback test... fail
> Error: RuntimeError: CODEC loopback test failed.
>
>
>
>
> ?
>
>
>
>
> *Craig F. Swanson*
> */Research Engineer II
> /*
> */Information and Communications Laboratory/*
> */Communications, Systems, and Spectrum Division/*
> /Georgia Tech Research Institute/
> /Room 560
> 250 14th St NW
> /
> /Atlanta, GA 30318/
> /Cell: 770.298.9156/
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 5
Date: Fri, 6 May 2016 09:27:10 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] RFNoC: RuntimeError: On node 0/CostasLoop_0,
output port 0 is already connected
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
This is a different error, it comes from multi_usrp. Are you changing
about the subdev specs or something like that?
M
On 05/05/2016 12:39 PM, Jason Matusiak via USRP-users wrote:
> I made the change, did a make && make install && sudo ldconfig, but I am
> still getting an error (though slightly different now):
> thread[thread-per-block[5]: <block uhd_rfnoc_CostasLoop (2)>]:
> LookupError: IndexError: multi_usrp: RX channel 2 out of range for
> configured RX frontends
>
> ~Jason
>
> On 05/05/2016 03:32 PM, Sylvain Munaut wrote:
>> _rx.stream_args.args["block_port"] = str(boost::format("%d") % i);
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 6
Date: Fri, 6 May 2016 09:31:30 -0700
From: Martin Braun <[email protected]>
To: "'[email protected]'" <[email protected]>
Subject: Re: [USRP-users] X310 RFNOC FFT block issue
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
On 05/05/2016 09:14 AM, James Wagner wrote:
> well I partially resolved this one. in the C++ code a line got commented
> out that connects the Radio to the FFT block. I have not dug too deep
> into the issue_stream command but I am guessing it tries to issue a
> corresponding command to the radio and when it did not find the radio it
> tried to issue it to the FFT block.
Yes, that would happen.
>
> but this really only showed that the warning
>
> issue_stream_cmd() not implemented for 0/FFT_0
>
> is unrelated to the problem.
>
> it turns out that if i run this code directly on the E310 it works. I
> also found that there are two failure modes depending on the
> configuration. when pass data directly to both sides of the FPGA there
> is simply no output from the FPGA and the streamer delivers 0
> packets. however if I connect the input of the FFT to the radio two
> error messages are produced
>
> EnviromentError: IOError x300 fw communication failure # 3
> EnviroemntError: IOError x300 fw poke32 - reply timed out
>
> this is consistent across both my own code and GNURadio.
...those errors come from an X-series though. And you said this is on an
E310? Are you maybe discovering the wrong device on the network?
M
>
>
>
>
> On Mon, May 2, 2016 at 2:01 PM, James Wagner <[email protected]
> <mailto:[email protected]>> wrote:
>
> something like
> std::string stream_arguments = "";
> uhd::stream_args_t stream_args(cpu_format,wire_format);
> stream_args.args = stream_arguments;
> uhd::rx_streamer::sptr rx_stream =
> usrp->get_rx_stream(stream_args);
> uhd::stream_cmd_t
> stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
> stream_cmd.num_samps = 100000;
> stream_cmd.stream_now = true;
> stream_cmd.time_spec = uhd::time_spec_t();
> rx_stream->issue_stream_cmd(stream_cmd);
>
> while( some tests)
> {
> num_rx_samps = rx_stream->recv(&buff.front(),
> buff.size()/2, md, 3.0, true);
> if(num_rx_samps)
> {
> std::cout << "got samples\n";
> num_fails = 0;
> }
>
>
>
> }
>
>
> On Mon, May 2, 2016 at 1:16 PM, Martin Braun via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> How does your C++ code look like? It looks like you're calling
> issue_stream_cmd() on the actual FFT block, which you shouldn't
> be doing
> -- you'd only call that on a radio, or you streamers.
>
> Cheers,
> m
>
> On 05/02/2016 10:23 AM, James Wagner via USRP-users wrote:
> > I am currently working with RFNOC on the X310 after doing some
> work on
> > the E310 and I seem to be having an issue getting the FFT
> block to work.
> > I have tried the block in both GNURadio and with C++ code which
> > previously worked with the E310. in GNURadio Chan 0 timeouts
> immediately
> > and no data seems to pass through. when i run my C++ code i get a
> > warning saying
> >
> > UHD warning:
> > issue_stream_cmd() not implemented for 0/FFT_0
> >
> > and the recv method for the streamer never returns a non-zero
> value.
> >
> >
> >
> > additional information
> > Ubuntu 14.0.4
> > UHD_003.010.rfnoc-300-g74d178b5
> >
> >
> > _______________________________________________
> > 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] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
------------------------------
Message: 7
Date: Fri, 6 May 2016 14:41:34 +0800
From: Tai Wooi Ling <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Problem of running two channels of TVRX2
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi.
I am recently using TVRX2 and USRP1 to receive 150MHz and 400MHZ. Hence, i use
both channels of TVRX2. However, i found that i cannot run both channels at the
same time. But when only one channel, it works ok. So, i wonder have i miss
some procedure before using TVRX2?
Your help is appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160506/760166bf/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 6 May 2016 16:39:42 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>, Martin Braun
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Wish list suggestions for future tutorials
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Jonathon and Martin,
Thanks for all the hard work you do and I look forward towards more tutorials
including the steamer-less flow graphs.
Also, did you get a chance to think about why the keep_one_in_n only works for
1:1 (n=1)?
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
________________________________
From: Jonathon Pendlum <[email protected]>
Sent: Friday, May 6, 2016 12:31 PM
To: Swanson, Craig
Subject: Re: Wish list suggestions for future tutorials
Hey Craig,
Sounds like you want more tutorials. Now that the knowledge base is live, I
planned on adding that kind of content. Of course, with the 2 other projects I
am working simultaneously, it won't be easy. :-)
Martin is working on getting FPGA only or what we are calling "streamer-less"
flow graphs working. He has had some success internally, but we don't have a
set deadline for releasing the work.
Jonathon
On Thu, May 5, 2016 at 3:25 PM, Swanson, Craig
<[email protected]<mailto:[email protected]>> wrote:
Jonathon,
Maybe these could be topics to cover at the breakout sessions for the upcoming
conference in Boulder:
1. ?Tutorial on how to understand, use, and modify the system verilog
testbenches you created. Examples might include increasing or the changing the
number of packets. I am not an expert in System Verilog, but I have tried to
increase the number of packets and modifying the data (maybe with a file
generated by file source) with only limited success. Also how to add file i/o
to the testbench.
2. Tying the data produced by gnuradio file source and file sync into the
data generated by rfnoc simulations and real time running on an SDR. How to
generate test vectors in gnu radio file source and file sync and interfacing it
with the system verilog testbench in the lib/rfnoc/noc_block_tb subdirectories.
How to verify or correlate the data since there will be quantization issues.
3. How do write "noc" code (I cannot remember the name) that allows uhd to
control the registers in rfnoc. I have followed Martin's explanation but he
went over it very fast and briefly. The best example I have been following is
noc_block_moving_avg but that is a medium complexity example. I would like to
see a very simple example.
4. I have had limited success with Chipscope and the E310. It wasn't very
reliable.
Have you gotten RFNoC blocks to run in grc that doesn't involve any uhd blocks?
For example, on the grc might be an RFNoC noc_block_radio source ->
noc_block_moving_avg -> RFNoC noc_block_radio sink
Another alternative might be for you to do some very short online tutorials
through Webex that I could record and post somewhere.
Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156<tel:770.298.9156>
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160506/10ddbe1b/attachment-0001.html>
------------------------------
Message: 9
Date: Fri, 06 May 2016 13:07:04 -0400
From: [email protected]
To: "Swanson, Craig" <[email protected]>
Cc: Jonathon Pendlum <[email protected]>, Martin Braun
<[email protected]>, [email protected]
Subject: Re: [USRP-users] Wish list suggestions for future tutorials
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Keep_one_in_N in RFNoC is vector based, and I've used it with ratios !=
1 in the recent past, to decimate averaged FFT data.
On 2016-05-06 12:39, Swanson, Craig via USRP-users wrote:
> Jonathon and Martin,
>
> Thanks for all the hard work you do and I look forward towards more tutorials
> including the steamer-less flow graphs.
>
> Also, did you get a chance to think about why the keep_one_in_n only works
> for 1:1 (n=1)?
>
> Craig
>
> CRAIG F. SWANSON
> Research Engineer II
>
> _INFORMATION AND COMMUNICATIONS LABORATORY_
> _COMMUNICATIONS, SYSTEMS, AND SPECTRUM DIVISION_
> _Georgia Tech Research Institute_
> Room 560
> 250 14th St NW
>
> _Atlanta, GA 30318_
> _Cell: 770.298.9156_
> http://www.gtri.gatech.edu [2]
>
> -------------------------
>
> FROM: Jonathon Pendlum <[email protected]>
> SENT: Friday, May 6, 2016 12:31 PM
> TO: Swanson, Craig
> SUBJECT: Re: Wish list suggestions for future tutorials
>
> Hey Craig,
>
> Sounds like you want more tutorials. Now that the knowledge base is live, I
> planned on adding that kind of content. Of course, with the 2 other projects
> I am working simultaneously, it won't be easy. :-)
>
> Martin is working on getting FPGA only or what we are calling "streamer-less"
> flow graphs working. He has had some success internally, but we don't have a
> set deadline for releasing the work.
>
> Jonathon
>
> On Thu, May 5, 2016 at 3:25 PM, Swanson, Craig
> <[email protected]> wrote:
>
>> Jonathon,
>>
>> Maybe these could be topics to cover at the breakout sessions for the
>> upcoming conference in Boulder:
>>
>> * ?Tutorial on how to understand, use, and modify the system verilog
>> testbenches you created. Examples might include increasing or the changing
>> the number of packets. I am not an expert in System Verilog, but I have
>> tried to increase the number of packets and modifying the data (maybe with a
>> file generated by file source) with only limited success. Also how to add
>> file i/o to the testbench.
>> * Tying the data produced by gnuradio file source and file sync into the
>> data generated by rfnoc simulations and real time running on an SDR. How to
>> generate test vectors in gnu radio file source and file sync and interfacing
>> it with the system verilog testbench in the lib/rfnoc/noc_block_tb
>> subdirectories. How to verify or correlate the data since there will be
>> quantization issues.
>> * How do write "noc" code (I cannot remember the name) that allows uhd to
>> control the registers in rfnoc. I have followed Martin's explanation but he
>> went over it very fast and briefly. The best example I have been following
>> is noc_block_moving_avg but that is a medium complexity example. I would
>> like to see a very simple example.
>> * I have had limited success with Chipscope and the E310. It wasn't very
>> reliable.
>>
>> Have you gotten RFNoC blocks to run in grc that doesn't involve any uhd
>> blocks? For example, on the grc might be an RFNoC noc_block_radio source ->
>> noc_block_moving_avg -> RFNoC noc_block_radio sink
>>
>> Another alternative might be for you to do some very short online tutorials
>> through Webex that I could record and post somewhere.
>>
>> Craig
>>
>> CRAIG F. SWANSON
>> Research Engineer II
>>
>> _INFORMATION AND COMMUNICATIONS LABORATORY_
>> _COMMUNICATIONS, SYSTEMS, AND SPECTRUM DIVISION_
>> _Georgia Tech Research Institute_
>> Room 560
>> 250 14th St NW
>>
>> _Atlanta, GA 30318_
>> _Cell: 770.298.9156 [1]_
>> http://www.gtri.gatech.edu [2]
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Links:
------
[1] tel:770.298.9156
[2]
https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160506/26c62175/attachment-0001.html>
------------------------------
Message: 10
Date: Fri, 6 May 2016 13:21:01 -0400
From: Zhihong Luo <[email protected]>
To: Zhihong Luo via USRP-users <[email protected]>
Subject: [USRP-users] How to use memory in RFNoC CE
Message-ID:
<CAH4wXLrX4S6CfChSo-c+19ukv+TzCM3pYOiJmDXW8qn3Jcp=k...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I want to store some data in my RFNoC blocks, previously I stored it in
registers for convenience. However, the size now is too large for register
(16 KB), so is there a convenient way I can store it in some memory?
Thanks in advance for any help.
Best regards,
Zhihong
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160506/b3c4a5ae/attachment-0001.html>
------------------------------
Message: 11
Date: Fri, 6 May 2016 13:22:28 -0400
From: Zhihong Luo <[email protected]>
To: Claudio Cicconetti <[email protected]>
Cc: Zhihong Luo via USRP-users <[email protected]>
Subject: Re: [USRP-users] Thunderbolt? 3 on Laptop to 10 Gigabit
Ethernet
Message-ID:
<CAH4wXLrdFDXgZ_V3YAVLTR78cKmYd1=+ejjtt0f_chkkb15...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Claudio,
Thanks a lot for the information!
Zhihong
On Fri, May 6, 2016 at 5:40 AM, Claudio Cicconetti via USRP-users <
[email protected]> wrote:
> Dear Marcus,
> Will try asap (downloading DVD live right now).
>
> If it works I owe you a pint.
>
> Best regards,
> Claudio
>
> On 05/06/2016 10:43 AM, Marcus M?ller wrote:
> > You sparked my own initiative: Went to the sonnettech website, clicked
> > through to the presto 10GE card that's inside the box, got the windows
> > driver, looked at the URL: It's a Myricom Myri10GE !
> > If it works over thunderbird, too, then there should be drivers in the
> > upstream linux kernel since 2.6.something :) ; module name is
> > "myri10ge", iirc.
> >
> >
> > Cheers,
> > Marcus
> >
> > On 06.05.2016 10:32, Claudio Cicconetti wrote:
> >> Dear Marcus,
> >> If it worked, that would make my life soooo much easier.
> >>
> >> Frankly, I didn't even try since I had to install a (Mac OS X only)
> >> driver on the MacBook to make the adapter work.
> >>
> >> Yet, I will give it a try and will keep the list posted on this.
> >>
> >> Best regards,
> >> Claudio
> >>
> >> On 05/06/2016 10:09 AM, Marcus M?ller via USRP-users wrote:
> >>> Out of personal curiosity:
> >>> does that thunderbolt/10GE adapter work under linux, e.g. with the GNU
> >>> Radio Live DVD?
> >>>
> >>> Best regards,
> >>> Marcus
> >>>
> >>> On 06.05.2016 09:10, Claudio Cicconetti via USRP-users wrote:
> >>>> Dear Zhihong
> >>>> I am able to receive at 100 MS/s (i.e., ~3.3 Gb/s over the wire).
> >>>>
> >>>> At that rate I only experience under-runs when the OS runs background
> >>>> jobs (such as re-building indexes of the spotlight or iTunes database)
> >>>> that choke all CPUs and my application as well.
> >>>>
> >>>> I am trying to disable all such background jobs, which is proving more
> >>>> painful than it should reasonably be because of my lack of experience
> >>>> with Mac OS X...
> >>>>
> >>>> Best regards,
> >>>> Claudio
> >>>>
> >>>> On 05/05/2016 06:28 PM, Zhihong Luo wrote:
> >>>>> Hi Claudio,
> >>>>>
> >>>>> Thank you so much for the sharing. Problem is that there seems to be
> no
> >>>>> available adapter for Thunderbolt3 to Thunderbolt 2/1 yet... What's
> the
> >>>>> highest sample rate you can run without having any underrun issues?
> I am
> >>>>> looking for roughly 60 MS/s, if it can work on this rate, I can try
> to use
> >>>>> a laptop with old Thunderbolt port.
> >>>>>
> >>>>> Thanks,
> >>>>> Zhihong
> >>>>>
> >>>>> On Thu, May 5, 2016 at 2:57 AM, Claudio Cicconetti <
> [email protected]>
> >>>>> wrote:
> >>>>>
> >>>>>> Dear Zhihong,
> >>>>>> I have successfully set up a MacBook + X300 connected via 10 GbE.
> >>>>>>
> >>>>>> I used this product:
> >>>>>>
> >>>>>> http://www.sonnettech.com/product/echoexpresssel_10gbeadapter.html
> >>>>>>
> >>>>>> to adapt Thunderbolt to 10 GbE. It worked out-of-the-box.
> >>>>>>
> >>>>>> The only (major!) issue I have now is that the host cannot keep my
> >>>>>> desired sampling rate (92.16 Msamples/s) without buffer underruns.
> Since
> >>>>>> the CPU is far from being overloaded, I suspect it might have
> something
> >>>>>> to do with interrupts and how the OS handles them.
> >>>>>>
> >>>>>> If anyone has experience or guidelines on how to optimize
> host-to-radio
> >>>>>> communication on Mac OS X I would appreciate it very much if you
> could
> >>>>>> share.
> >>>>>>
> >>>>>> Best regards,
> >>>>>> Claudio
> >>>>>>
> >>>>>> On 05/05/2016 07:24 AM, Zhihong Luo via USRP-users wrote:
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>> I am currently trying to set up 10 Gigabit Ethernet on laptop
> through a
> >>>>>>> Thunderbolt? 3 port. Thunderbolt? 3 supports up to 40Gbps, so
> that I
> >>>>>>> suppose it can be adapted to a 10 Gigabit Ethernet port (or PCI).
> But I
> >>>>>> am
> >>>>>>> not sure how to do it, and I didn't find any material on this yet.
> >>>>>>>
> >>>>>>> Please let me know if you have any suggestions.
> >>>>>>>
> >>>>>>> Thanks for any help,
> >>>>>>> Zhihong
> >>>>>>>
> >>>> _______________________________________________
> >>>> 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/20160506/4492df57/attachment-0001.html>
------------------------------
Message: 12
Date: Fri, 6 May 2016 12:41:38 -0500
From: Jonathon Pendlum <[email protected]>
To: Zhihong Luo <[email protected]>
Cc: Zhihong Luo via USRP-users <[email protected]>
Subject: Re: [USRP-users] How to use memory in RFNoC CE
Message-ID:
<cagdo0ust1tr+i_qyakskkn_f4zxgpzx2ob6+khbs5e2ombs...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Zhihong,
Look at the window rfnoc block. It stores the window coefficients in a
block ram and loads the block ram via the settings bus.
Jonathon
On Fri, May 6, 2016 at 12:21 PM, Zhihong Luo via USRP-users <
[email protected]> wrote:
> Hi all,
>
> I want to store some data in my RFNoC blocks, previously I stored it in
> registers for convenience. However, the size now is too large for register
> (16 KB), so is there a convenient way I can store it in some memory?
>
> Thanks in advance for any help.
>
> Best regards,
> 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/20160506/74ab447f/attachment-0001.html>
------------------------------
Message: 13
Date: Fri, 6 May 2016 11:14:58 -0700
From: Ashish Chaudhari <[email protected]>
To: john liu <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] master clock of X300
Message-ID:
<caozxt+df-akn6mrt454qx_rruz5zqa-32ntp03wxyfkhnvk...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi John,
Support for master clock rates of 120MHz and 184.32MHz is considered
experimental and it does not go though our full validation cycle. We
only guarantee radio performance with a clock rate of 200MHz.
That said, you can ask UHD to try to calibrate its FPGA interfaces to
work with a custom master clock rate. You can do so by specifying the
"self_cal_adc_delay" device argument. Here is an example:
$ uhd_usrp_probe --args="addr=<device IP>,self_cal_adc_delay"
When you specify this additional argument, UHD will run through a
timing calibration sequence during initialization and should print out
status information and the calibration offset to the console. Please
note that this will only work in UHD 3.9.0 or later.
Thanks,
Ashish Chaudhari
Ashish Chaudhari | Senior Software Engineer | Software Defined Radio
Ettus Research, A National Instruments Company
[email protected]
On Thu, May 5, 2016 at 8:15 PM, john liu via USRP-users
<[email protected]> wrote:
> Dear all,
> We set master clock of usrp X300 200M or 120M,it is OK.But when
> we set master clock 184.32M,the errors output:
>
> Error: RuntimeError: ADC self-test failed! Ramp checker status:
> {ADC0_I=Good,
> ADC0_Q=Good,ADC1_I=Bit Errors!, ADC1_Q=Bit Errors!}
>
> We had changed UHD version,but the error keep same.
> can you give some davices.
>
> thank you for your help
> best regards
> John
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 14
Date: Fri, 6 May 2016 14:49:53 -0400
From: Serge Malo <[email protected]>
To: Zhihong Luo <[email protected]>
Cc: Claudio Cicconetti <[email protected]>, Zhihong Luo via
USRP-users <[email protected]>
Subject: Re: [USRP-users] Thunderbolt? 3 on Laptop to 10 Gigabit
Ethernet
Message-ID:
<CAOhu+FNmi9Sro-HDkPwaXkyJbk8HoK-P9fJiUFNt9LKa=ma...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
We have been using the Promise Technologies SanLink2 successfully under
MacOS, Windows and Linux Ubuntu (Macbook and Asus ROG laptops). Its a
Thunderbol2 to 10GbE converter.
http://www.promise.com/Products/SANLink/SANLink2
However, newer laptops come with Thunderbolt3 (via a USB Type C connector),
and we have not found any solution yet to connect Thunderbolt3 to a X300.
StartTech should have a Thunderbolt3 to Thnderbolt2 converter in June (
https://www.startech.com/Cables/thunderbolt-3-cables/thunderbolt-3-usb-c-thunderbolt-adapter~TBT3TBTADAP
)
But we would prefer to find a direct Thunderbolt3 to 10GbE SFP+ converter.
If by any chance anyone finds such adapter, I'll be happy to buy/try one!
Regards,
Serge
On 6 May 2016 at 13:22, Zhihong Luo via USRP-users <
[email protected]> wrote:
> Claudio,
>
> Thanks a lot for the information!
>
> Zhihong
>
> On Fri, May 6, 2016 at 5:40 AM, Claudio Cicconetti via USRP-users <
> [email protected]> wrote:
>
>> Dear Marcus,
>> Will try asap (downloading DVD live right now).
>>
>> If it works I owe you a pint.
>>
>> Best regards,
>> Claudio
>>
>> On 05/06/2016 10:43 AM, Marcus M?ller wrote:
>> > You sparked my own initiative: Went to the sonnettech website, clicked
>> > through to the presto 10GE card that's inside the box, got the windows
>> > driver, looked at the URL: It's a Myricom Myri10GE !
>> > If it works over thunderbird, too, then there should be drivers in the
>> > upstream linux kernel since 2.6.something :) ; module name is
>> > "myri10ge", iirc.
>> >
>> >
>> > Cheers,
>> > Marcus
>> >
>> > On 06.05.2016 10:32, Claudio Cicconetti wrote:
>> >> Dear Marcus,
>> >> If it worked, that would make my life soooo much easier.
>> >>
>> >> Frankly, I didn't even try since I had to install a (Mac OS X only)
>> >> driver on the MacBook to make the adapter work.
>> >>
>> >> Yet, I will give it a try and will keep the list posted on this.
>> >>
>> >> Best regards,
>> >> Claudio
>> >>
>> >> On 05/06/2016 10:09 AM, Marcus M?ller via USRP-users wrote:
>> >>> Out of personal curiosity:
>> >>> does that thunderbolt/10GE adapter work under linux, e.g. with the GNU
>> >>> Radio Live DVD?
>> >>>
>> >>> Best regards,
>> >>> Marcus
>> >>>
>> >>> On 06.05.2016 09:10, Claudio Cicconetti via USRP-users wrote:
>> >>>> Dear Zhihong
>> >>>> I am able to receive at 100 MS/s (i.e., ~3.3 Gb/s over the wire).
>> >>>>
>> >>>> At that rate I only experience under-runs when the OS runs background
>> >>>> jobs (such as re-building indexes of the spotlight or iTunes
>> database)
>> >>>> that choke all CPUs and my application as well.
>> >>>>
>> >>>> I am trying to disable all such background jobs, which is proving
>> more
>> >>>> painful than it should reasonably be because of my lack of experience
>> >>>> with Mac OS X...
>> >>>>
>> >>>> Best regards,
>> >>>> Claudio
>> >>>>
>> >>>> On 05/05/2016 06:28 PM, Zhihong Luo wrote:
>> >>>>> Hi Claudio,
>> >>>>>
>> >>>>> Thank you so much for the sharing. Problem is that there seems to
>> be no
>> >>>>> available adapter for Thunderbolt3 to Thunderbolt 2/1 yet... What's
>> the
>> >>>>> highest sample rate you can run without having any underrun issues?
>> I am
>> >>>>> looking for roughly 60 MS/s, if it can work on this rate, I can try
>> to use
>> >>>>> a laptop with old Thunderbolt port.
>> >>>>>
>> >>>>> Thanks,
>> >>>>> Zhihong
>> >>>>>
>> >>>>> On Thu, May 5, 2016 at 2:57 AM, Claudio Cicconetti <
>> [email protected]>
>> >>>>> wrote:
>> >>>>>
>> >>>>>> Dear Zhihong,
>> >>>>>> I have successfully set up a MacBook + X300 connected via 10 GbE.
>> >>>>>>
>> >>>>>> I used this product:
>> >>>>>>
>> >>>>>> http://www.sonnettech.com/product/echoexpresssel_10gbeadapter.html
>> >>>>>>
>> >>>>>> to adapt Thunderbolt to 10 GbE. It worked out-of-the-box.
>> >>>>>>
>> >>>>>> The only (major!) issue I have now is that the host cannot keep my
>> >>>>>> desired sampling rate (92.16 Msamples/s) without buffer underruns.
>> Since
>> >>>>>> the CPU is far from being overloaded, I suspect it might have
>> something
>> >>>>>> to do with interrupts and how the OS handles them.
>> >>>>>>
>> >>>>>> If anyone has experience or guidelines on how to optimize
>> host-to-radio
>> >>>>>> communication on Mac OS X I would appreciate it very much if you
>> could
>> >>>>>> share.
>> >>>>>>
>> >>>>>> Best regards,
>> >>>>>> Claudio
>> >>>>>>
>> >>>>>> On 05/05/2016 07:24 AM, Zhihong Luo via USRP-users wrote:
>> >>>>>>> Hi all,
>> >>>>>>>
>> >>>>>>> I am currently trying to set up 10 Gigabit Ethernet on laptop
>> through a
>> >>>>>>> Thunderbolt? 3 port. Thunderbolt? 3 supports up to 40Gbps, so
>> that I
>> >>>>>>> suppose it can be adapted to a 10 Gigabit Ethernet port (or PCI).
>> But I
>> >>>>>> am
>> >>>>>>> not sure how to do it, and I didn't find any material on this yet.
>> >>>>>>>
>> >>>>>>> Please let me know if you have any suggestions.
>> >>>>>>>
>> >>>>>>> Thanks for any help,
>> >>>>>>> Zhihong
>> >>>>>>>
>> >>>> _______________________________________________
>> >>>> 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
>>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
--
*Serge Malo *
CDO & Co-founder, Skydel Solutions
Cell: 1-514-294-4017
www.skydelsolutions.com
Twitter: @skydelsol <https://twitter.com/skydelsol>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160506/de20ab68/attachment-0001.html>
------------------------------
Message: 15
Date: Fri, 6 May 2016 14:55:09 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>, Martin
Braun <[email protected]>
Subject: Re: [USRP-users] RFNoC: RuntimeError: On node 0/CostasLoop_0,
output port 0 is already connected
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
> This is a different error, it comes from multi_usrp. Are you changing
about the subdev specs or something like that?
Nope. All I did was try to make the fix that Sylvain pointed to, that
//seemed// to work for him. It changed my error from the one I started
this thread with, to the one in that last email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160506/d2d00ecf/attachment-0001.html>
------------------------------
Message: 16
Date: Fri, 6 May 2016 21:23:00 +0200
From: Sylvain Munaut <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC: RuntimeError: On node 0/CostasLoop_0,
output port 0 is already connected
Message-ID:
<CAHL+j09uFoRj1wGci4f=+56cKty5j=3zcn2ksy+b12qjrvw...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
>> Not sure if it's the "right" fix, but that seemed to have helped for me.
>
> Sylvain, Were you able to verify that this solved all of your issues
> (potentially indirectly, I know)?
I didn't solve _all_ my issues, but at least the app starts and
doesn't throw any startup error.
Now my issue is that the fpga locks up pretty quickly (some data goes
through but not much).
But that's probably a bug in my FPGA code, I actually probably just
found it (using wrong src SID in the CHDR headers), but I'll be able
to confirm that once synthesis is done.
Cheers,
Sylvain
------------------------------
Message: 17
Date: Fri, 6 May 2016 12:51:18 -0700
From: James Wagner <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] X310 RFNOC FFT block issue
Message-ID:
<CA+USoOKe-+h7fw5GD4+3k06=kvw2wz2xxndlxwf0d6dqem3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
I am trying to get code that works with the E310 to run on the X310. I have
the E310 off the network right now and am running the code locally( I
assume network mode still does not work with RFNOC). for the X310 I am
running it over an Ethernet connection. I check the mailing list and found
that the poke32 error can often be fixed by increasing the size of the
socket buffer and after doing this that error stopped. now i just don't get
anything out of the block. if i run my own code i get zero samples back
when i call the recv method for the streamer. when I run a GRC flowgraph it
gives me an error message "timeout on chan 0".
just to clarify this code operates correctly on the E310, and I am able to
get samples from the X310 (I was demodulating live FM stations to confirm).
the issue is when I attempt to use the FFT block on the X310 I seem to be
getting no data out.
On Fri, May 6, 2016 at 9:31 AM, Martin Braun via USRP-users <
[email protected]> wrote:
> On 05/05/2016 09:14 AM, James Wagner wrote:
> > well I partially resolved this one. in the C++ code a line got commented
> > out that connects the Radio to the FFT block. I have not dug too deep
> > into the issue_stream command but I am guessing it tries to issue a
> > corresponding command to the radio and when it did not find the radio it
> > tried to issue it to the FFT block.
>
> Yes, that would happen.
>
> >
> > but this really only showed that the warning
> >
> > issue_stream_cmd() not implemented for 0/FFT_0
> >
> > is unrelated to the problem.
> >
> > it turns out that if i run this code directly on the E310 it works. I
> > also found that there are two failure modes depending on the
> > configuration. when pass data directly to both sides of the FPGA there
> > is simply no output from the FPGA and the streamer delivers 0
> > packets. however if I connect the input of the FFT to the radio two
> > error messages are produced
> >
> > EnviromentError: IOError x300 fw communication failure # 3
> > EnviroemntError: IOError x300 fw poke32 - reply timed out
> >
> > this is consistent across both my own code and GNURadio.
>
> ...those errors come from an X-series though. And you said this is on an
> E310? Are you maybe discovering the wrong device on the network?
>
> M
>
>
> >
> >
> >
> >
> > On Mon, May 2, 2016 at 2:01 PM, James Wagner <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> > something like
> > std::string stream_arguments = "";
> > uhd::stream_args_t stream_args(cpu_format,wire_format);
> > stream_args.args = stream_arguments;
> > uhd::rx_streamer::sptr rx_stream =
> > usrp->get_rx_stream(stream_args);
> > uhd::stream_cmd_t
> > stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
> > stream_cmd.num_samps = 100000;
> > stream_cmd.stream_now = true;
> > stream_cmd.time_spec = uhd::time_spec_t();
> > rx_stream->issue_stream_cmd(stream_cmd);
> >
> > while( some tests)
> > {
> > num_rx_samps = rx_stream->recv(&buff.front(),
> > buff.size()/2, md, 3.0, true);
> > if(num_rx_samps)
> > {
> > std::cout << "got samples\n";
> > num_fails = 0;
> > }
> >
> >
> >
> > }
> >
> >
> > On Mon, May 2, 2016 at 1:16 PM, Martin Braun via USRP-users
> > <[email protected] <mailto:[email protected]>>
> wrote:
> >
> > How does your C++ code look like? It looks like you're calling
> > issue_stream_cmd() on the actual FFT block, which you shouldn't
> > be doing
> > -- you'd only call that on a radio, or you streamers.
> >
> > Cheers,
> > m
> >
> > On 05/02/2016 10:23 AM, James Wagner via USRP-users wrote:
> > > I am currently working with RFNOC on the X310 after doing some
> > work on
> > > the E310 and I seem to be having an issue getting the FFT
> > block to work.
> > > I have tried the block in both GNURadio and with C++ code which
> > > previously worked with the E310. in GNURadio Chan 0 timeouts
> > immediately
> > > and no data seems to pass through. when i run my C++ code i
> get a
> > > warning saying
> > >
> > > UHD warning:
> > > issue_stream_cmd() not implemented for 0/FFT_0
> > >
> > > and the recv method for the streamer never returns a non-zero
> > value.
> > >
> > >
> > >
> > > additional information
> > > Ubuntu 14.0.4
> > > UHD_003.010.rfnoc-300-g74d178b5
> > >
> > >
> > > _______________________________________________
> > > 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] <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/20160506/905d16f8/attachment-0001.html>
------------------------------
Message: 18
Date: Fri, 6 May 2016 14:16:45 -0700
From: Patrick Sathyanathan <[email protected]>
To: Michael West <[email protected]>
Cc: Ian Buckley <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] B210: 20db difference between RX2 antenna on
A:A and A:B
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Thanks, Michael.
--Patrick
Date: Thu, 5 May 2016 21:13:03 -0700
Subject: Re: [USRP-users] B210: 20db difference between RX2 antenna on A:A and
A:B
From: [email protected]
To: [email protected]
CC: [email protected]; [email protected]
Yes, those should be fine.
On Thu, May 5, 2016 at 7:55 PM, Patrick Sathyanathan <[email protected]> wrote:
Yes, I can see that from the schematic. The reason I asked for part no. is that
if I search at DigiKey for ceramic 220pf capacitor with "Applications" set to
"RF, Microwave, High Frequency" it only shows 0603 and larger sizes. The 0402
devices are classified as "General purpose" or others. Will these be OK ?
Thanks,
--Patrick
Date: Thu, 5 May 2016 18:24:01 -0700
Subject: Re: [USRP-users] B210: 20db difference between RX2 antenna on A:A and
A:B
From: [email protected]
To: [email protected]
CC: [email protected]; [email protected]
They are all 0402.
C826 / C852 = 470 pF
C832 / C855 = 220 pF
C814 / C849 = 470 pF
C810 / C847 = 220 pF
C833 / C856 = 470 pF
C829 / C854 = 470 pF
C819 / C851 = 470 pF
C812 / C848 = 470 pF
Regards,
Michael
On Thu, May 5, 2016 at 5:05 PM, Patrick Sathyanathan <[email protected]> wrote:
Thanks for the picture, Michael. That helps a lot. In my attempt to desolder
the switch with my hot air gun I blew off a couple of the capacitors. I have
them but since they are 2 different values I don't know which is which. That is
why I need to replace them with new ones.
--Patrick
Date: Thu, 5 May 2016 16:08:25 -0700
Subject: Re: [USRP-users] B210: 20db difference between RX2 antenna on A:A and
A:B
From: [email protected]
To: [email protected]
CC: [email protected]; [email protected]
Hi Patrick,
No need to buy any parts. It should be good enough to just rotate the existing
capacitors so they connect to the bypass traces instead of connecting to the
traces that goes to the RF switches.
In the picture below (A side shown), the red arrows point to the capacitors to
rotate and the green arrows point to the bypass traces.
Regards,
Michael
On Thu, May 5, 2016 at 3:47 PM, Patrick Sathyanathan <[email protected]> wrote:
Thanks for clarifying, Ian.
--Patrick
Date: Wed, 4 May 2016 23:31:14 -0700
Subject: Re: [USRP-users] B210: 20db difference between RX2 antenna on A:A and
A:B
From: [email protected]
To: [email protected]
CC: [email protected]; [email protected]
Also, C851/C848/... are labeled as "DNP" in the schematic. What does this mean ?
DNP = Do Not Populate. It's an annotation for the standard board assembly
configuration.
On Wed, May 4, 2016 at 11:01 PM, Michael West via USRP-users
<[email protected]> wrote:
Hi Patrick,
If you look at the board, you can see the bypass traces and the capacitors that
need to be rotated to bypass the switches.
C826 rotates 90 degrees to become C852
C832 rotates 90 degrees to become C855
C814 rotates 90 degrees to become C849
C810 rotates 90 degrees to become C847
C833 rotates 90 degrees to become C856
C829 rotates 90 degrees to become C854
C819 rotates 90 degrees to become C851
C812 rotates 90 degrees to become C848
Regards,Michael
On Wed, May 4, 2016 at 5:08 PM, Patrick Sathyanathan <[email protected]> wrote:
Shouldn't both A and B be symmetric ? Your lists below do not match for A and B.
Assuming B is correct:
C814/C810 on B:TX match C826/C832 on A:TX
C851/C812 on B:RX match C854/C833 on A:RX
Assuming A is correct:
C852/C855 on A:TX match C849/C847 on B:TX
C854/C856 on A:RX match C848/C851 on B:RX
Also, C851/C848/... are labeled as "DNP" in the schematic. What does this mean ?
Thanks,
--Patrick
Date: Wed, 4 May 2016 16:14:14 -0700
Subject: Re: [USRP-users] B210: 20db difference between RX2 antenna on A:A and
A:B
From: [email protected]
To: [email protected]
CC: [email protected]; [email protected]
Small correction. There is no need to remove C834 or C809. Just move the
other capacitors to the respective bypass paths.
Regards,
Michael
On Wed, May 4, 2016 at 4:01 PM, Michael West <[email protected]> wrote:
There is no need to remove the RF switches to bypass them. There are already
bypass traces on the board.
On the A side:
1) Remove C834
2) Move C852 and C855 to the bypass path for TX
3) Move C854 and C856 to the bypass path for RX
On the B side:
1) Remove C809
2) Move C814 and C810 to the bypass path for TX
3) Move C851 and C812 to the bypass path for RX
Regards,
Michael
On Wed, May 4, 2016 at 3:40 PM, Patrick Sathyanathan via USRP-users
<[email protected]> wrote:
Thanks, Ralph. That's an excellent idea. I don't need a combined RX and TX path
either so I will just bridge it. Now if only I could get the switch off the
board...
--Patrick
From: [email protected]
To: [email protected]; [email protected]
Subject: RE: [USRP-users] B210: 20db difference between RX2 antenna on A:A and
A:B
Date: Wed, 4 May 2016 15:25:42 +0200
Hi,
I had it replaced once by a professional, and when it blew again, I just
removed it with a hot air gun and bridged it. For my use case I anyway need
separated RX and TX paths.
Ralph.
From: Patrick Sathyanathan [mailto:[email protected]]
Sent: Wednesday, May 4, 2016 10:19 AM
To: Ralph A. Schmid, dk5ras; [email protected]
Subject: RE: [USRP-users] B210: 20db difference between RX2 antenna on A:A and
A:B
Hi Ralph,
I see the same problem with the TX/RX antenna on A:B. So is this a symptom of
both the switches on A:B getting damaged ?
Also, I tried using my hot air gun to desolder the switch but have been
unsuccessful so far. All I managed to do was blow off some of the neighboring
SMD capacitors. It appears that melting the solder on the ground pad below the
chip is not easy.
How did you replace the switches ?
Thanks,
--Patrick
> From: [email protected]
> To: [email protected]; [email protected]
> Subject: RE: [USRP-users] B210: 20db difference between RX2 antenna on A:A
> and A:B
> Date: Wed, 6 Apr 2016 11:29:11 +0200
>
> The TX/RX switch is very sensitive to ESD :( I already killed two of them
> and don't know why...
>
> Ralph.
>
> >-----Original Message-----
> >From: USRP-users [mailto:[email protected]] On Behalf Of
> >Patrick Sathyanathan via USRP-users
> >Sent: Wednesday, April 6, 2016 11:22
> >To: [email protected]
> >Subject: [USRP-users] B210: 20db difference between RX2 antenna on A:A and
> >A:B
> >
> >Hi,
> >
> >I have been using my B210 for about a year now with GNUradio and a scanner
> >software that I wrote using UHD and other hardware libraries. Initially I
> used
> >cheap Nagoya telescopic antennas for both receive channels. When I ran
> uhd_fft
> >to observe a known local signal (I think a local HDTV channel) the spectrum
> was
> >more or less identical if I used the same parameters. Then I purchased a
> super M
> >ultra base antenna (25MHz-6GHz from mapantenna.com) which is a physically
> >larger wide band discone antenna and connected it to subdev A:B. For a
> while
> >uhd_fft and my own scanner software showed much higher signal strengths
> with
> >this. However, a few weeks earlier it started reporting lower signal
> strength even
> >for known local signals. And when I connected the Nagoya to A:B and ran
> uhd_fft
> >for the local TV signal it shows a spectrum whose shape looks correct but
> is 20db
> >lower than A:A for the same parameters.
> >
> >Could some transmission have overloaded the A:B receive with the larger
> >antenna and damaged some component ? If so what could be damaged and how
> >can I get it fixed ?
> >
> >Thanks for any help,
> >
> >--Patrick
> >
> >
> >_______________________________________________
> >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/20160506/6ab86caa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 136390 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160506/6ab86caa/attachment-0001.png>
------------------------------
Message: 19
Date: Sat, 7 May 2016 11:14:00 +0800
From: liangyong <[email protected]>
To: usrp-users <[email protected]>, usrp-users
<[email protected]>, usrp-users
<[email protected]>, usrp-users <[email protected]>
Subject: [USRP-users] questions about usrp b210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
hi all
I have one question about usrp b210.
Generally usrp b210 get time reference from gps if there is an OCXO exists.
then,usrp generate the local oscillator (LO) frequency from gps.
In addition, there is a 1pps signal derived from the incoming GPS signal to
synchronize.
Now ,usrp b210 is connectted to PC via usb3.0,I want to know how could PC get
time reference.
Is this relate to vita timestamp ?
looking forward to your reply,thanks.
Best Regard
liangyong
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160507/f624d4d2/attachment-0001.html>
------------------------------
Message: 20
Date: Sat, 7 May 2016 15:19:27 +0000
From: "Swanson, Craig" <[email protected]>
To: Jonathon Pendlum <[email protected]>, Martin Braun
<[email protected]>
Cc: "[email protected]" <[email protected]>, "Myers,
David" <[email protected]>
Subject: [USRP-users] gr-ettus will not build
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Jonathon and Martin,
I am not sure what I am doing wrong here, but I just tried compiling the latest
gr-ettus from the repo:
craig@craig-VirtualBox:~$ git clone
https://github.com/EttusResearch/gr-ettus.git
Cloning into 'gr-ettus'...
remote: Counting objects: 924, done.
remote: Total 924 (delta 0), reused 0 (delta 0), pack-reused 924
Receiving objects: 100% (924/924), 322.54 KiB | 0 bytes/s, done.
Resolving deltas: 100% (632/632), done.
Checking connectivity... done.
craig@craig-VirtualBox:~$ cd gr-ettus/
craig@craig-VirtualBox:~/gr-ettus (master)$ mkdir build
craig@craig-VirtualBox:~/gr-ettus (master)$ cd build
craig@craig-VirtualBox:~/gr-ettus/build (master)$ cmake ../
-- The CXX compiler identification is GNU 4.8.4
-- The C compiler identification is GNU 4.8.4
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Build type not specified: defaulting to release.
-- Boost version: 1.54.0
-- Found the following Boost libraries:
-- filesystem
-- system
-- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
-- Found UHD: /usr/local/lib/libuhd.so
CMake Error at CMakeLists.txt:113 (message):
RFNoC not found.
?Craig
Craig F. Swanson
Research Engineer II
Information and Communications Laboratory
Communications, Systems, and Spectrum Division
Georgia Tech Research Institute
Room 560
250 14th St NW
Atlanta, GA 30318
Cell: 770.298.9156
http://www.gtri.gatech.edu<https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160507/591bf98c/attachment-0001.html>
------------------------------
Message: 21
Date: Sat, 7 May 2016 17:25:47 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] gr-ettus will not build
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Craig,
what does
uhd_config_info --version --enabled-components
say?
Best regards,
Marcus
On 07.05.2016 17:19, Swanson, Craig via USRP-users wrote:
>
> Jonathon and Martin,
>
> I am not sure what I am doing wrong here, but I just tried compiling
> the latest gr-ettus from the repo:
>
>
> craig@craig-VirtualBox:~$ git clone
> https://github.com/EttusResearch/gr-ettus.git
> Cloning into 'gr-ettus'...
> remote: Counting objects: 924, done.
> remote: Total 924 (delta 0), reused 0 (delta 0), pack-reused 924
> Receiving objects: 100% (924/924), 322.54 KiB | 0 bytes/s, done.
> Resolving deltas: 100% (632/632), done.
> Checking connectivity... done.
> craig@craig-VirtualBox:~$ cd gr-ettus/
> craig@craig-VirtualBox:~/gr-ettus (master)$ mkdir build
> craig@craig-VirtualBox:~/gr-ettus (master)$ cd build
> craig@craig-VirtualBox:~/gr-ettus/build (master)$ cmake ../
> -- The CXX compiler identification is GNU 4.8.4
> -- The C compiler identification is GNU 4.8.4
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Check for working C compiler: /usr/bin/cc
> -- Check for working C compiler: /usr/bin/cc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Build type not specified: defaulting to release.
> -- Boost version: 1.54.0
> -- Found the following Boost libraries:
> -- filesystem
> -- system
> -- Found PkgConfig: /usr/bin/pkg-config (found version "0.26")
> -- Found UHD: /usr/local/lib/libuhd.so
> CMake Error at CMakeLists.txt:113 (message):
> RFNoC not found.
>
> ?Craig
>
>
>
> *Craig F. Swanson*
> */Research Engineer II
> /*
> */Information and Communications Laboratory/*
> */Communications, Systems, and Spectrum Division/*
> /Georgia Tech Research Institute/
> /Room 560
> 250 14th St NW
> /
> /Atlanta, GA 30318/
> /Cell: 770.298.9156/
> http://www.gtri.gatech.edu
> <https://mail.gtri.gatech.edu/owa/redir.aspx?C=c20925f2f0af4dd29329ddf0701ecfff&URL=http%3a%2f%2fwww.gtri.gatech.edu%2f>
>
>
>
>
> _______________________________________________
> 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/20160507/e17a064f/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 69, Issue 7
*****************************************
