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: RFNoC Installation Problems (Martin Braun)
2. Re: BER VS SNR (Martin Braun)
3. Re: benchmark_rate problem ([email protected])
4. Re: RFNoC Installation Problems (Yin, Charles - 0665 - MITLL)
5. Re: Creating a custom RFNoC Block (El Ouni, Naceur (IntlAssoc))
6. Re: benchmark_rate problem ([email protected])
7. Cyberspectrum: Software Defined Radio Meetup (Wed 29th Jun)
6:30pm (Balint Seeber)
8. How to use tlast signal in rfnoc block? (Luong Tan Phong)
9. Re: How to use tlast signal in rfnoc block? (Marcus M?ller)
10. E310 and RFNoC performance (Ulrika Uppman)
11. Re: E310 and RFNoC performance (Sylvain Munaut)
12. Re: E310 and RFNoC performance (Ulrika Uppman)
13. Lots of UnderRuns USRP N210 (Filippo Camuglia)
14. Multiple parallel connections to x310 (Tihomir Mescic)
15. Re: Multiple parallel connections to x310 (Marcus M?ller)
16. Re: Lots of UnderRuns USRP N210 (Marcus M?ller)
17. Re: E310 and RFNoC performance (Marcus M?ller)
18. Re: Multiple parallel connections to x310 (Tihomir Mescic)
19. Remote access to running GNU Radio application's USRP objects
(was Re: Multiple parallel connections to x310) (Marcus M?ller)
20. Re: E310 and RFNoC performance (Sylvain Munaut)
----------------------------------------------------------------------
Message: 1
Date: Mon, 27 Jun 2016 10:15:22 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] RFNoC Installation Problems
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 06/27/2016 07:12 AM, devin kelly via USRP-users wrote:
> This is for the E310 - Charles and I are working on this together. I've
> run into a separate problem when compiling gr-ettus (sorry, I'm not in a
> state where I can post the problem but will do that as soon as I can.)
> I have a few questions:
>
> 1) Which branch should we be using radio-redo or rfnoc-devel?
Both are in usable states, but the former has more features and will be
merged into the latter soon. All things identical, I strongly suggest
you use rfnoc-radio-redo.
> 2) Can you complete the instructions below for the gr-ettus module:
>
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312
>
> All the sections before gr-ettus have worked really well for me.
We'll do that, but you can use PyBOMBS to set up the entire development
environment. Setting up gr-ettus by hand correctly for cross-compiling
can be cumbersome.
> 3) Are there instructions anywhere that will tell me how to build my own
> RFNOC FPGA images? We have access to Vivado and all that - I just don't
> have any experience with FPGAs.
Instructions to build images in general are shipped with the manual (we
have the 3.9.4 manual here:
http://files.ettus.com/manual/md_usrp3_build_instructions.html, but your
local branch will have a version of this page that matches your local
requirements).
To choose RFNoC blocks, modify the rfnoc_ce_auto_inst_e310.v file.
Cheers,
Martin
>
> Thanks for the help!
> Devin
>
> On Fri, Jun 24, 2016 at 1:44 PM, Martin Braun via USRP-users
> <[email protected] <mailto:[email protected]>> wrote:
>
> And are you crosscompiling, or native compiling (e.g. for X310)?
>
> M
>
> On 06/24/2016 07:28 AM, Jonathon Pendlum via USRP-users wrote:
> > Hi Charles,
> >
> > Can you provide the cmake command you are using for your build?
> >
> >
> >
> > Jonathon
> >
> > On Thu, Jun 23, 2016 at 6:07 AM, Yin, Charles - 0665 - MITLL via
> > USRP-users <[email protected]
> <mailto:[email protected]>
> > <mailto:[email protected]
> <mailto:[email protected]>>> wrote:
> >
> > Neel,____
> >
> > __ __
> >
> > Thank you very much. I had allocated 16GB of RAM for my VM
> > originally, but Martin recommended me to increase my swap space to
> > 32GB, and that fixed the problem. I am, running into another
> > problem when trying to build GR-Ettus. I am using the devel branch
> > of https://github.com/ettusresearch/gr-ettus and I am get the
> > following error message when running cmake:____
> >
> > __ __
> >
> > CMake Error at
> >
> /local_disk/e310_gr_3.7.9.2/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake:4
> > (string):____
> >
> > string sub-command REGEX, mode MATCH needs at least 5 arguments
> > total to____
> >
> > command.____
> >
> > Call Stack (most recent call first):____
> >
> > build/CMakeFiles/2.8.12.2/CMakeSystem.cmake:6
> <http://2.8.12.2/CMakeSystem.cmake:6>
> > <http://2.8.12.2/CMakeSystem.cmake:6> (include)____
> >
> > CMakeLists.txt:24 (project)____
> >
> > __ __
> >
> > __ __
> >
> > CMake Error at
> >
> /local_disk/e310_gr_3.7.9.2/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake:5
> > (string):____
> >
> > string sub-command REGEX, mode REPLACE needs at least 6 arguments
> > total to____
> >
> > command.____
> >
> > Call Stack (most recent call first):____
> >
> > build/CMakeFiles/2.8.12.2/CMakeSystem.cmake:6
> <http://2.8.12.2/CMakeSystem.cmake:6>
> > <http://2.8.12.2/CMakeSystem.cmake:6> (include)____
> >
> > CMakeLists.txt:24 (project)____
> >
> > __ __
> >
> > __ __
> >
> > -- 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++____
> >
> > CMake Error at
> >
> /local_disk/e310_gr_3.7.9.2/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake:4
> > (string):____
> >
> > string sub-command REGEX, mode MATCH needs at least 5 arguments
> > total to____
> >
> > command.____
> >
> > Call Stack (most recent call first):____
> >
> >
> >
>
> /local_disk/e310_gr_3.7.9.2/src/gr-ettus/build/CMakeFiles/2.8.12.2/CMakeSystem.cmake:6
> <http://2.8.12.2/CMakeSystem.cmake:6>
> > <http://2.8.12.2/CMakeSystem.cmake:6> (include)____
> >
> > CMakeLists.txt:2 (PROJECT)____
> >
> > __ __
> >
> > __ __
> >
> > CMake Error at
> >
> /local_disk/e310_gr_3.7.9.2/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake:5
> > (string):____
> >
> > string sub-command REGEX, mode REPLACE needs at least 6 arguments
> > total to____
> >
> > command.____
> >
> > Call Stack (most recent call first):____
> >
> >
> >
>
> /local_disk/e310_gr_3.7.9.2/src/gr-ettus/build/CMakeFiles/2.8.12.2/CMakeSystem.cmake:6
> <http://2.8.12.2/CMakeSystem.cmake:6>
> > <http://2.8.12.2/CMakeSystem.cmake:6> (include)____
> >
> > CMakeLists.txt:2 (PROJECT)____
> >
> > __ __
> >
> > __ __
> >
> > CMake Error: Internal CMake error, TryCompile configure of cmake
> > failed____
> >
> > -- Check for working CXX compiler: /usr/bin/c++ -- broken____
> >
> > CMake Error at
> > /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:54
> > (message):____
> >
> > The C++ compiler "/usr/bin/c++" is not able to compile a simple
> > test____
> >
> > program.____
> >
> > __ __
> >
> > It fails with the following output:____
> >
> > __ __
> >
> > ____
> >
> > __ __
> >
> > ____
> >
> > __ __
> >
> > CMake will not be able to correctly generate this project.____
> >
> > Call Stack (most recent call first):____
> >
> > CMakeLists.txt:24 (project)____
> >
> > __ __
> >
> > __ __
> >
> > -- Configuring incomplete, errors occurred!____
> >
> > See also
> >
>
> "/local_disk/e310_gr_3.7.9.2/src/gr-ettus/build/CMakeFiles/CMakeOutput.log".____
> >
> > See also
> >
>
> "/local_disk/e310_gr_3.7.9.2/src/gr-ettus/build/CMakeFiles/CMakeError.log".____
> >
> > __ __
> >
> > __ __
> >
> > __ __
> >
> > I?m guessing it?s another really small problem that I am missing
> > again. Please let me know if you think of anything. Thanks!____
> >
> > __ __
> >
> > Charles____
> >
> > __ __
> >
> > __ __
> >
> > *From:*Neel Pandeya [mailto:[email protected]
> <mailto:[email protected]>
> > <mailto:[email protected] <mailto:[email protected]>>]
> > *Sent:* Wednesday, June 22, 2016 12:17 PM
> > *To:* Yin, Charles - 0665 - MITLL
> > *Cc:* [email protected]
> <mailto:[email protected]>
> > <mailto:[email protected]
> <mailto:[email protected]>>; Chibane, Cherif - 0665 - MITLL
> > *Subject:* Re: [USRP-users] RFNoC Installation Problems____
> >
> > __ __
> >
> > Hello Charles:____
> >
> > It looks like you're running in a Virtual Machine, and it's run out
> > of memory. See the line in the output:____
> >
> > virtual memory exhausted: Cannot allocate memory____
> >
> > Try increasing the memory for the VM to 4 GB, and re-building.____
> >
> > Please let us know if you're able to make any further
> progress.____
> >
> > __ __
> >
> > --Neel Pandeya
> >
> > ____
> >
> > __ __
> >
> > On 21 June 2016 at 13:24, Yin, Charles - 0665 - MITLL via USRP-users
> > <[email protected]
> <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> > wrote:____
> >
> > Hi Neel and Jonathon,____
> >
> > ____
> >
> > I am having problems building RFNoC with GNU Radio. I am using GNU
> > Radio Version 3.9.7.2 on Ubuntu 14.04. You mentioned to check for
> > the swig package, and I can confirm that it is there. The error
> > from the build process is as follows:____
> >
> > ____
> >
> > Linking CXX executable test-gr-blocks____
> >
> > [ 67%] Built target test-gr-blocks____
> >
> > Scanning dependencies of target _blocks_swig3____
> >
> > [ 67%] Building CXX object
> >
>
> gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/blocks_swig3PYTHON_wrap.cxx.o____
> >
> > {standard input}: Assembler messages:____
> >
> > {standard input}:380989: Warning: end of file not at end of a line;
> > newline inserted____
> >
> > {standard input}:381666: Error: invalid operands (*UND* and
> > .ARM.extab sections) for `-'____
> >
> > {standard input}:381669: Error: invalid operands (*UND* and
> > .ARM.extab sections) for `-'____
> >
> > arm-oe-linux-gnueabi-g++: internal compiler error: Killed (program
> > cc1plus)____
> >
> > Please submit a full bug report,____
> >
> > with preprocessed source if appropriate.____
> >
> > See <http://gcc.gnu.org/bugs.html> for instructions.____
> >
> > make[2]: ***
> >
>
> [gr-blocks/swig/CMakeFiles/_blocks_swig2.dir/blocks_swig2PYTHON_wrap.cxx.o]
> > Error 4____
> >
> > make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig2.dir/all] Error
> > 2____
> >
> > make[1]: *** Waiting for unfinished jobs....____
> >
> > virtual memory exhausted: Cannot allocate memory____
> >
> > {standard input}: Assembler messages:____
> >
> > {standard input}:1273004: Warning: end of file not at end of a line;
> > newline inserted____
> >
> > {standard input}:1274439: Error: unknown pseudo-op: `.'____
> >
> > make[2]: ***
> >
>
> [gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/blocks_swig0PYTHON_wrap.cxx.o]
> > Error 1____
> >
> > make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/all] Error
> > 2____
> >
> > {standard input}: Error: open CFI at the end of file; missing
> > .cfi_endproc directive____
> >
> > arm-oe-linux-gnueabi-g++: internal compiler error: Killed (program
> > cc1plus)____
> >
> > Please submit a full bug report,____
> >
> > with preprocessed source if appropriate.____
> >
> > See <http://gcc.gnu.org/bugs.html> for instructions.____
> >
> > make[2]: ***
> >
>
> [gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/blocks_swig3PYTHON_wrap.cxx.o]
> > Error 4____
> >
> > make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/all] Error
> > 2____
> >
> > Linking CXX shared module _blocks_swig1.so____
> >
> > [ 67%] Built target _blocks_swig1____
> >
> > make: *** [all] Error 2____
> >
> > ____
> >
> > ____
> >
> > ____
> >
> > I?m not entirely sure what I am missing. Please let me know if you
> > find anything. Thanks!____
> >
> > ____
> >
> > Charles Yin____
> >
> > ____
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected] <mailto:[email protected]>
> <mailto:[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]>
> <mailto:[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] <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: 2
Date: Mon, 27 Jun 2016 10:19:20 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] BER VS SNR
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
I'm not sure what you mean by "the bench marking option", but you can
certainly do this.
In GNU Radio, there's gr-digital/examples/berawgn.py which is a basic
example. However, it is a simulation, assumes perfect synchronization,
and all that.
If you want to use USRPs, you'll need to figure out a good way to know
the Eb/N0 at the receiver, and remember you'll be including all the
components of a digital receiver chain (equalizer, synchronizer) which
will all affect your results.
The discuss-gnuradio is probably a better place to discuss this (if you
are planning to use GNU Radio).
Cheers,
M
On 06/26/2016 09:00 PM, Prativadi Bhayankaram, Narasimha Anirudh
Srinivas (UMKC-Student) via USRP-users wrote:
> Hello folks ,I have been using the USRP for my research project. My
> main aim is to find trade off between BER and distance for different
> modulation schemes. i just wanted to know is there anyway we can do the
> snr vs ber simulation using the bench marking option ?
>
>
> Regards,
>
> Anirudh.
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 3
Date: Mon, 27 Jun 2016 17:21:12 +0000
From: "[email protected]" <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] benchmark_rate problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Thanks Marcus,
Here is the relevant lspci output
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express
Gigabit Ethernet controller
Flags: bus master, fast devsel, latency 0, IRQ 44
I/O ports at e000 [size=256]
Memory at f7b00000 (64-bit, non-prefetchable) [size=4K]
Expansion ROM at dfb00000 [disabled] [size=128K]
Capabilities: <access denied>
Kernel driver in use: r8169
As mentioned, it can run for days under simple_ra at 5 MSPS but at
any rate, even 1 MSPS, it fails the benchmark_rx portion - but only
after (not during) it has finished the streaming which sounds like s/w
to me.
Slainte,
John
On 27/06/16 14:12, [email protected] wrote:
>
> That's a bit odd.
>
> What specific manufacturer/part-number ethernet controller do you have?
>
> You can use 'lspci -v' to see details of the various controllers on
> your PCI bus, including your ethernet controller.
>
> On 2016-06-27 03:29, john.shields--- via USRP-users wrote:
>
>> Hi,
>> Have N200 (w/gpsdo and SBX) on it's own GigE controller card and
>> it works fine using simple_ra etc. at sample rate of 5e6.
>>
>> When I give the following command to benchmark_rate:
>>
>> benchmark_rate --rx_rate 1e6 --args="addr=192.168.10.2"
>> --duration 10
>>
>> I get:
>>
>> linux; GNU C++ version 4.8.4; Boost_105400;
>> UHD_003.010.git-216-gb1c2d4bb
>>
>>
>> Creating the usrp device with: addr=192.168.10.2...
>> -- Opening a USRP2/N-Series device...
>> -- Current recv frame size: 1472 bytes
>> -- Current send frame size: 1472 bytes
>> -- Detecting internal GPSDO.... Found an internal GPSDO
>> -- Setting references to the internal GPSDO
>> Using Device: Single USRP:
>> Device: USRP2 / N-Series Device
>> Mboard 0: N200r4
>> RX Channel: 0
>> RX DSP: 0
>> RX Dboard: A
>> RX Subdev: SBXv3 RX
>> TX Channel: 0
>> TX DSP: 0
>> TX Dboard: A
>> TX Subdev: SBXv3 TX
>>
>> Setting device timestamp to 0...
>> Testing receive rate 1.000000 Msps on 1 channels
>>
>> and things go quiet for the 'duration' i.e. 10 seconds and then:
>>
>> Receiver error: Unknown error code: 0x10
>> Unexpected error on recv, continuing...
>>
>> repeated forever (it seems)
>>
>> I can get benchmark_rate to work with a USRP/tvrx on USB so think the
>> software is good.
>> I wonder(ed) if the GPSDO is causing some issue but varying the --ref
>> and --pps parameters doesn't appear to alter the outcome :(
>>
>> Any advice on what I am doing wrong?
>>
>> Kind Regards,
>>
>> John
>>
>>
>>
>>
>> _______________________________________________
>> 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/20160627/7f891f11/attachment-0001.html>
------------------------------
Message: 4
Date: Mon, 27 Jun 2016 19:02:38 +0000
From: "Yin, Charles - 0665 - MITLL" <[email protected]>
To: Jonathon Pendlum <[email protected]>
Cc: "Kelly, Devin - 0665 - MITLL" <[email protected]>, Neel
Pandeya <[email protected]>, "Chibane, Cherif - 0665 - MITLL"
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] RFNoC Installation Problems
Message-ID:
<13657fc12b4974458e83264543702551062...@lle2k10-mbx02.mitll.ad.local>
Content-Type: text/plain; charset="utf-8"
Jonathan,
I am using the radio-redo branch of https://github.com/ettusresearch/gr-ettus.
The cmake command is as follows:
cmake -Wno-dev
-DCMAKE_TOOLCHAIN_FILE='${GR_ROOT_PATH}/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake'
-DCMAKE_INSTALL_PREFIX='/usr' -DENABLE_DOXYGEN=OFF
-DUHD_LIBRARIES='$GR_INSTALL_PATH/usr/lib'
-DUHD_INCLUDE_DIRS='$GR_INSTALL_PATH/usr/include'
-DUHD_DIR=$GR_INSTALL_PATH/usr/lib/cmake/uhd' ../
The toolchain file is the following:
https://raw.githubusercontent.com/gnuradio/gnuradio/master/cmake/Toolchains/oe-sdk_cross.cmake
Thanks,
Charles
From: Jonathon Pendlum [mailto:[email protected]]
Sent: Friday, June 24, 2016 10:28 AM
To: Yin, Charles - 0665 - MITLL
Cc: Neel Pandeya; Chibane, Cherif - 0665 - MITLL; [email protected]
Subject: Re: [USRP-users] RFNoC Installation Problems
Hi Charles,
Can you provide the cmake command you are using for your build?
Jonathon
On Thu, Jun 23, 2016 at 6:07 AM, Yin, Charles - 0665 - MITLL via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Neel,
Thank you very much. I had allocated 16GB of RAM for my VM originally, but
Martin recommended me to increase my swap space to 32GB, and that fixed the
problem. I am, running into another problem when trying to build GR-Ettus. I
am using the devel branch of https://github.com/ettusresearch/gr-ettus and I
am get the following error message when running cmake:
CMake Error at
/local_disk/e310_gr_3.7.9.2/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake:4
(string):
string sub-command REGEX, mode MATCH needs at least 5 arguments total to
command.
Call Stack (most recent call first):
build/CMakeFiles/2.8.12.2/CMakeSystem.cmake:6<http://2.8.12.2/CMakeSystem.cmake:6>
(include)
CMakeLists.txt:24 (project)
CMake Error at
/local_disk/e310_gr_3.7.9.2/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake:5
(string):
string sub-command REGEX, mode REPLACE needs at least 6 arguments total to
command.
Call Stack (most recent call first):
build/CMakeFiles/2.8.12.2/CMakeSystem.cmake:6<http://2.8.12.2/CMakeSystem.cmake:6>
(include)
CMakeLists.txt:24 (project)
-- 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++
CMake Error at
/local_disk/e310_gr_3.7.9.2/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake:4
(string):
string sub-command REGEX, mode MATCH needs at least 5 arguments total to
command.
Call Stack (most recent call first):
/local_disk/e310_gr_3.7.9.2/src/gr-ettus/build/CMakeFiles/2.8.12.2/CMakeSystem.cmake:6<http://2.8.12.2/CMakeSystem.cmake:6>
(include)
CMakeLists.txt:2 (PROJECT)
CMake Error at
/local_disk/e310_gr_3.7.9.2/src/gnuradio/cmake/Toolchains/oe-sdk_cross.cmake:5
(string):
string sub-command REGEX, mode REPLACE needs at least 6 arguments total to
command.
Call Stack (most recent call first):
/local_disk/e310_gr_3.7.9.2/src/gr-ettus/build/CMakeFiles/2.8.12.2/CMakeSystem.cmake:6<http://2.8.12.2/CMakeSystem.cmake:6>
(include)
CMakeLists.txt:2 (PROJECT)
CMake Error: Internal CMake error, TryCompile configure of cmake failed
-- Check for working CXX compiler: /usr/bin/c++ -- broken
CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:54
(message):
The C++ compiler "/usr/bin/c++" is not able to compile a simple test
program.
It fails with the following output:
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:24 (project)
-- Configuring incomplete, errors occurred!
See also
"/local_disk/e310_gr_3.7.9.2/src/gr-ettus/build/CMakeFiles/CMakeOutput.log".
See also
"/local_disk/e310_gr_3.7.9.2/src/gr-ettus/build/CMakeFiles/CMakeError.log".
I?m guessing it?s another really small problem that I am missing again. Please
let me know if you think of anything. Thanks!
Charles
From: Neel Pandeya
[mailto:[email protected]<mailto:[email protected]>]
Sent: Wednesday, June 22, 2016 12:17 PM
To: Yin, Charles - 0665 - MITLL
Cc: [email protected]<mailto:[email protected]>; Chibane,
Cherif - 0665 - MITLL
Subject: Re: [USRP-users] RFNoC Installation Problems
Hello Charles:
It looks like you're running in a Virtual Machine, and it's run out of memory.
See the line in the output:
virtual memory exhausted: Cannot allocate memory
Try increasing the memory for the VM to 4 GB, and re-building.
Please let us know if you're able to make any further progress.
--Neel Pandeya
On 21 June 2016 at 13:24, Yin, Charles - 0665 - MITLL via USRP-users
<[email protected]<mailto:[email protected]>> wrote:
Hi Neel and Jonathon,
I am having problems building RFNoC with GNU Radio. I am using GNU Radio
Version 3.9.7.2 on Ubuntu 14.04. You mentioned to check for the swig package,
and I can confirm that it is there. The error from the build process is as
follows:
Linking CXX executable test-gr-blocks
[ 67%] Built target test-gr-blocks
Scanning dependencies of target _blocks_swig3
[ 67%] Building CXX object
gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/blocks_swig3PYTHON_wrap.cxx.o
{standard input}: Assembler messages:
{standard input}:380989: Warning: end of file not at end of a line; newline
inserted
{standard input}:381666: Error: invalid operands (*UND* and .ARM.extab
sections) for `-'
{standard input}:381669: Error: invalid operands (*UND* and .ARM.extab
sections) for `-'
arm-oe-linux-gnueabi-g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: ***
[gr-blocks/swig/CMakeFiles/_blocks_swig2.dir/blocks_swig2PYTHON_wrap.cxx.o]
Error 4
make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig2.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....
virtual memory exhausted: Cannot allocate memory
{standard input}: Assembler messages:
{standard input}:1273004: Warning: end of file not at end of a line; newline
inserted
{standard input}:1274439: Error: unknown pseudo-op: `.'
make[2]: ***
[gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/blocks_swig0PYTHON_wrap.cxx.o]
Error 1
make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig0.dir/all] Error 2
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc
directive
arm-oe-linux-gnueabi-g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[2]: ***
[gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/blocks_swig3PYTHON_wrap.cxx.o]
Error 4
make[1]: *** [gr-blocks/swig/CMakeFiles/_blocks_swig3.dir/all] Error 2
Linking CXX shared module _blocks_swig1.so
[ 67%] Built target _blocks_swig1
make: *** [all] Error 2
I?m not entirely sure what I am missing. Please let me know if you find
anything. Thanks!
Charles Yin
_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160627/804fba77/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 27 Jun 2016 19:08:15 +0000
From: "El Ouni, Naceur (IntlAssoc)" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Creating a custom RFNoC Block
Message-ID:
<sn1pr09mb0925e8496e9837bfbf96f0c09e...@sn1pr09mb0925.namprd09.prod.outlook.com>
Content-Type: text/plain; charset="us-ascii"
Hi Martin,
> I think I'm missing something -- how are you expecting the $display() command
> to display? Do you have some debugging setup? Is there some kind of
> chipscope/ILA involved?
Could you direct me to an example using chipscope/ILA or any resource on the
matter because I am only following the RFNOC tutorial file and the source code
itself.
Following a Xilinx Tutorial of Vivado ILA, I have to instantiate an ILA IP and
plug it in the design.
I am doing this for the first time so help is much appreciated. I don't know if
I should use the monitor type AXI, since RFNOC is based on AXI standard.
[cid:[email protected]]
Next after the IP is generated, how to integrate it in the design ? Is there an
RFNOC Vivado sample project that has debug features to follow ? I am going in
the right direction ?
[cid:[email protected]]
> Is data flowing through your blocks? What's happening?
Re the data flow: I am not following what's happening in between the blocks.
(How to monitor that ?).
I generated an all-ones 256 vectors file in matlab that I use in this flowgraph
and
I am looking at the bin_aggr output (at file sink) expecting a file of vectors
of 5s instead of ones: 50 bins of value 5 each and 3 vectors on each side of 0
value.
> Can you give us more info on your failure modes?
When reading the file in Matlab (or even Hexdump in Linux) I get a file of all
zeros.
[cid:[email protected]]
Thanks and Regards,
Naceur El Ouni
NIST - Wireless Networks Division (673)
100 Bureau Dr. Building 222-A218
Gaithersburg, MD 20899
(301) 975-3353
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160627/eb9d0440/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 55543 bytes
Desc: image001.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160627/eb9d0440/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 62766 bytes
Desc: image003.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160627/eb9d0440/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 20496 bytes
Desc: image004.jpg
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160627/eb9d0440/attachment-0005.jpg>
------------------------------
Message: 6
Date: Tue, 28 Jun 2016 06:19:08 +0000
From: "[email protected]" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] benchmark_rate problem
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"
Hi Marcus,
In addition, I have established that the GPSDO option
does not cause the problem and also have confirmed that replacing the
SBX with a TVRX2 also does not fix the issue.
So we have benchmark_rate (rx_rate) working on USRP
with TVRX2 but not working on N200 with TVRX2.
Slainte,
John
On 27/06/16 17:21, john.shields--- via USRP-users wrote:
> Thanks Marcus,
> Here is the relevant lspci output
>
> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)
> Subsystem: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI
> Express Gigabit Ethernet controller
> Flags: bus master, fast devsel, latency 0, IRQ 44
> I/O ports at e000 [size=256]
> Memory at f7b00000 (64-bit, non-prefetchable) [size=4K]
> Expansion ROM at dfb00000 [disabled] [size=128K]
> Capabilities: <access denied>
> Kernel driver in use: r8169
>
> As mentioned, it can run for days under simple_ra at 5 MSPS but at
> any rate, even 1 MSPS, it fails the benchmark_rx portion - but only
> after (not during) it has finished the streaming which sounds like s/w
> to me.
>
> Slainte,
>
> John
>
>
> On 27/06/16 14:12, [email protected] wrote:
>>
>> That's a bit odd.
>>
>> What specific manufacturer/part-number ethernet controller do you have?
>>
>> You can use 'lspci -v' to see details of the various controllers on
>> your PCI bus, including your ethernet controller.
>>
>> On 2016-06-27 03:29, john.shields--- via USRP-users wrote:
>>
>>> Hi,
>>> Have N200 (w/gpsdo and SBX) on it's own GigE controller card and
>>> it works fine using simple_ra etc. at sample rate of 5e6.
>>>
>>> When I give the following command to benchmark_rate:
>>>
>>> benchmark_rate --rx_rate 1e6 --args="addr=192.168.10.2"
>>> --duration 10
>>>
>>> I get:
>>>
>>> linux; GNU C++ version 4.8.4; Boost_105400;
>>> UHD_003.010.git-216-gb1c2d4bb
>>>
>>>
>>> Creating the usrp device with: addr=192.168.10.2...
>>> -- Opening a USRP2/N-Series device...
>>> -- Current recv frame size: 1472 bytes
>>> -- Current send frame size: 1472 bytes
>>> -- Detecting internal GPSDO.... Found an internal GPSDO
>>> -- Setting references to the internal GPSDO
>>> Using Device: Single USRP:
>>> Device: USRP2 / N-Series Device
>>> Mboard 0: N200r4
>>> RX Channel: 0
>>> RX DSP: 0
>>> RX Dboard: A
>>> RX Subdev: SBXv3 RX
>>> TX Channel: 0
>>> TX DSP: 0
>>> TX Dboard: A
>>> TX Subdev: SBXv3 TX
>>>
>>> Setting device timestamp to 0...
>>> Testing receive rate 1.000000 Msps on 1 channels
>>>
>>> and things go quiet for the 'duration' i.e. 10 seconds and then:
>>>
>>> Receiver error: Unknown error code: 0x10
>>> Unexpected error on recv, continuing...
>>>
>>> repeated forever (it seems)
>>>
>>> I can get benchmark_rate to work with a USRP/tvrx on USB so think
>>> the software is good.
>>> I wonder(ed) if the GPSDO is causing some issue but varying the
>>> --ref and --pps parameters doesn't appear to alter the outcome :(
>>>
>>> Any advice on what I am doing wrong?
>>>
>>> Kind Regards,
>>>
>>> John
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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/20160628/e76a2c7f/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 28 Jun 2016 00:21:47 -0700
From: Balint Seeber <[email protected]>
To: [email protected], [email protected]
Subject: [USRP-users] Cyberspectrum: Software Defined Radio Meetup
(Wed 29th Jun) 6:30pm
Message-ID:
<cad39kuxekwpgjioow-cgqlhfce5b3oghqkgq2t9zsadn2ro...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Dear all,
We're back! Announcing the sixteenth Cyberspectrum meetup in San Francisco!
Come along at 6:30 PM for a 7 PM sharp kickoff in the Hackatorium. For
those unable to attend the event in person, you can live stream it here:
https://www.youtube.com/watch?v=mgbepw3G-uo
There's also IRC: #cyberspectrum on Freenode.
Full details, including the speaker lineup/topics, are here:
*http://www.meetup.com/Cyberspectrum/events/228537098/
<http://www.meetup.com/Cyberspectrum/events/228537098/>* (please RSVP if
you are coming!).
On the agenda this time:
- "Understanding the LTE Physical Layer" with Sandor Szilvasi
<https://twitter.com/sszilvasi>
- "GNU Radio Tutorial Part 2: Receiving FM and RDS" with Neel Pandeya
- "Interactive Install & Setup-fest" with the group
Don't forget all our videos are here:
https://www.youtube.com/playlist?list=PLPmwwVknVIiXGzKhtimTMjhcyppeRRsnE
...and materials here: http://www.meetup.com/Cyberspectrum/about/
For updates before, and photos during the event:
https://twitter.com/spenchdotnet
Please support Cyberspectrum by submitting a talk, or spreading the word
about us!
We have a chapter up and running in Melbourne, Australia now:
http://www.meetup.com/Cyberspectrum-Melbourne/
If you would like to learn more about setting one up, please get in touch.
(Anyone on the US East Coast?)
We have some very exciting plans for the coming months, including more
great talks, and special meetups planned to occur in different locations
coinciding with some big & upcoming conferences. More to come...
If you're not familiar with Cyberspectrum: "The Bay Area SDR Meetup will
serve as a forum to exchange knowledge and ideas related to Software
Defined Radio (the software and hardware), and generally aim to get people
excited about all the applications that can be realised with the
technology. At each meetup, attendees will have the opportunity to present
their work/ideas to the group. Engineers, enthusiasts, hobbyists and people
of all experience levels are welcome, no matter what your software/hardware
background."
As always, if you would like to present at a future event about a project
you're working on, or something interesting you've discovered, please get
in touch!
Stay tuned and hope to see you there,
Balint
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160628/d48c4791/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 28 Jun 2016 17:09:24 +0700
From: Luong Tan Phong <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] How to use tlast signal in rfnoc block?
Message-ID:
<CAA8YXsrixc7mWPEOPDYDViPPf1F1S_Wx=HNjSX8faaJmHEt=l...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi List,
I'm writing a CE block for signal processing with input samplerate is fixed
(e.g 100 Msps) and ouput rate is depending on user's realtime setting - as
a signal abitrary resampler.
I've set s_axis_data_tlast equal '0' or '1' but it don't work.
Could you help me, please?
Thanks in advance.
Phong
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160628/78478328/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 28 Jun 2016 12:24:31 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] How to use tlast signal in rfnoc block?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
You'll need to use the chdr header rewriter to modify the output packet
length; see keep_one_in_n for an example.
Cheers,
Marcus
On 28.06.2016 12:09, Luong Tan Phong via USRP-users wrote:
> Hi List,
>
> I'm writing a CE block for signal processing with input samplerate is
> fixed (e.g 100 Msps) and ouput rate is depending on user's realtime
> setting - as a signal abitrary resampler.
> I've set s_axis_data_tlast equal '0' or '1' but it don't work.
>
> Could you help me, please?
>
> Thanks in advance.
>
> Phong
>
>
> _______________________________________________
> 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/20160628/bed15957/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 28 Jun 2016 11:17:25 +0000
From: Ulrika Uppman <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] E310 and RFNoC performance
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi,
I've tried to figure out what performance to expect from the E310 running
Gnuradio on the Zynq ARM processor. I'm hoping that someone on this list might
have some experience and tips to share.
We would like to be able to run some stuff on the box standalone, and since the
processing power of the ARM core is limited, it seems like a good idea to use
RFNoC. However, just trying it out with a radio source at rate 2MS/s followed
by a couple of RFNoC blocks and an UDP sink results in more than 125% cpu load
(of 200%, since there are 2 cores). Running with higher data rate gives
"timeout on chan 0" (or "overrun on chan 0" with samplerate > 6MS/s while not
using UDP). Is this performance expected from the E310, or am I missing
something? (I am currently running the alpha fido-rfnoc-test sdimage
(gnuradio-demo) build that has gnuradio 3.7.8 and uhd 003.010.rfnoc-0-unknown.)
Reading about performance with the RFNoC, it seems that most of you guys use
the X310. How big is the difference between these two platforms, in terms of
both hardware and performance?
While I'm at it I have another question regarding the network mode in the E310;
what is the reason for network transport not being supported for the data flow
(i.e. only AXI transport supported)? I guess sending the data into an UDP sink
is still feasible, but control and gui possibilities are reduced. Are there any
fundamental showstoppers in the design, or is it just not implemented?
/Ulrika
------------------------------
Message: 11
Date: Tue, 28 Jun 2016 14:29:08 +0200
From: Sylvain Munaut <[email protected]>
To: Ulrika Uppman <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 and RFNoC performance
Message-ID:
<CAHL+j0_=oo89owdzyybabynuravqc9aynwpy5vq+kmfwi8x...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
> We would like to be able to run some stuff on the box standalone, and since
> the processing power of the ARM core is limited, it seems like a good idea to
> use RFNoC. However, just trying it out with a radio source at rate 2MS/s
> followed by a couple of RFNoC blocks and an UDP sink results in more than
> 125% cpu load (of 200%, since there are 2 cores). Running with higher data
> rate gives "timeout on chan 0" (or "overrun on chan 0" with samplerate >
> 6MS/s while not using UDP). Is this performance expected from the E310, or am
> I missing something? (I am currently running the alpha fido-rfnoc-test
> sdimage (gnuradio-demo) build that has gnuradio 3.7.8 and uhd
> 003.010.rfnoc-0-unknown.)
You realize that to actually use RFNoC you need to code your own
algorithm into RFNoC blocs ... if you just use RFNoC branch to just
feed the ARM, you gained nothing.
> Reading about performance with the RFNoC, it seems that most of you guys use
> the X310. How big is the difference between these two platforms, in terms of
> both hardware and performance?
The X310 is a huge FPGA and using Kintex fabric vs, the E310 which is
a Zynq 7020 which is not that large and using the Artix fabric. The
RFNoC blocks in the E310 are also clocked slower by default in the
E310, but it's
However if your RFNoC block fits in the FPGA and meets timing during
synthesis and you clock them at the same frequency, the actual
performance will be identical.
The performance of the host CPU and of whatever you run there will be
hugely different ... the ARM in there really can't do much at all.
> While I'm at it I have another question regarding the network mode in the
> E310; what is the reason for network transport not being supported for the
> data flow (i.e. only AXI transport supported)? I guess sending the data into
> an UDP sink is still feasible, but control and gui possibilities are reduced.
> Are there any fundamental showstoppers in the design, or is it just not
> implemented?
By the "only AXI transport supported", I assume you mean support
network as a native transport in RFNoC on the E310.
Well I don't see any fundamental technical showstoppers if you're
given unlimited time and resources to develop it ... (of course some
might consider that a showstopper)
The two options are :
- Make the packets go through the host : This is purely software
stuff ... of course performance would be pretty poor, pretty much like
the current network mode in the non-rfnoc version (i.e. usable for
debug / testing only)
- Direct from fpga to network : This could be pretty fast and
efficient ... however it also requires cooperation between userspace,
the kernel, the network driver, uhd, the fpga fabric and the ethernet
hard ip .... that would be a _massive_ amount of work !
Cheers,
Sylvain
------------------------------
Message: 12
Date: Tue, 28 Jun 2016 13:22:25 +0000
From: Ulrika Uppman <[email protected]>
To: Sylvain Munaut <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 and RFNoC performance
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hello Sylvain,
>From your reply you say that "the ARM in there really can't do much at all"
>and that
> You realize that to actually use RFNoC you need to code your own algorithm
> into RFNoC blocs ... if you just use RFNoC branch to just feed the ARM, you
> gained nothing.
>
Well, yes I assumed that the intention of RFNoC was the ability to use FPGA
acceleration on the computationally heavy parts of your signal processing
flowgraphs. From what you tell me, it sounds more like that part is the whole
thing. If you implement the whole design in a NoC-block, what is gained from
this, using UHD and the RFNoC framework, compared to just implementing the
whole design in the FPGA from scratch?
> -----Original Message-----
>
> Hi,
>
> > We would like to be able to run some stuff on the box standalone, and
> > since the processing power of the ARM core is limited, it seems like a
> > good idea to use RFNoC. However, just trying it out with a radio
> > source at rate 2MS/s followed by a couple of RFNoC blocks and an UDP
> > sink results in more than 125% cpu load (of 200%, since there are 2
> > cores). Running with higher data rate gives "timeout on chan 0" (or
> > "overrun on chan 0" with samplerate > 6MS/s while not using UDP). Is
> > this performance expected from the E310, or am I missing something? (I
> > am currently running the alpha fido-rfnoc-test sdimage (gnuradio-demo)
> > build that has gnuradio 3.7.8 and uhd 003.010.rfnoc-0-unknown.)
>
> You realize that to actually use RFNoC you need to code your own algorithm
> into RFNoC blocs ... if you just use RFNoC branch to just feed the ARM, you
> gained nothing.
>
>
> > Reading about performance with the RFNoC, it seems that most of you
> guys use the X310. How big is the difference between these two platforms,
> in terms of both hardware and performance?
>
> The X310 is a huge FPGA and using Kintex fabric vs, the E310 which is a Zynq
> 7020 which is not that large and using the Artix fabric. The RFNoC blocks in
> the E310 are also clocked slower by default in the E310, but it's However if
> your RFNoC block fits in the FPGA and meets timing during synthesis and you
> clock them at the same frequency, the actual performance will be identical.
>
> The performance of the host CPU and of whatever you run there will be
> hugely different ... the ARM in there really can't do much at all.
>
>
> > While I'm at it I have another question regarding the network mode in the
> E310; what is the reason for network transport not being supported for the
> data flow (i.e. only AXI transport supported)? I guess sending the data into
> an UDP sink is still feasible, but control and gui possibilities are reduced.
> Are
> there any fundamental showstoppers in the design, or is it just not
> implemented?
>
> By the "only AXI transport supported", I assume you mean support network
> as a native transport in RFNoC on the E310.
>
> Well I don't see any fundamental technical showstoppers if you're given
> unlimited time and resources to develop it ... (of course some might consider
> that a showstopper)
>
> The two options are :
> - Make the packets go through the host : This is purely software stuff ... of
> course performance would be pretty poor, pretty much like the current
> network mode in the non-rfnoc version (i.e. usable for debug / testing only)
> - Direct from fpga to network : This could be pretty fast and efficient ...
> however it also requires cooperation between userspace, the kernel, the
> network driver, uhd, the fpga fabric and the ethernet hard ip .... that would
> be a _massive_ amount of work !
>
>
> Cheers,
>
> Sylvain
------------------------------
Message: 13
Date: Tue, 28 Jun 2016 15:23:39 +0200
From: Filippo Camuglia <[email protected]>
To: [email protected]
Subject: [USRP-users] Lots of UnderRuns USRP N210
Message-ID:
<camo_yxelh+puixzat2rlu6ayjze4xzk+nsqcazdgss3dwbu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I'm using an USRP N210 with GnuRadio, but seems that the UHD blocks don't
work in fact when I try to play a trace I get a lot of Underrun and
gnuradio freezes.
I don't know if this can be a problem related to my USRP or if it depends
from wrong settings on my laptop.
Have you ever faced something similar to that?
Thanks in advance,
Regards,
Filippo
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160628/bf4b41d8/attachment-0001.html>
------------------------------
Message: 14
Date: Tue, 28 Jun 2016 15:33:45 +0200 (CEST)
From: Tihomir Mescic <[email protected]>
To: [email protected]
Subject: [USRP-users] Multiple parallel connections to x310
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8
Hi everyone,
I am using GNU radio to read and process data from the Ettus x310. What I would
like to do now, is to be able to access the device (using the UHD C API) from
another process *while* GNU radio is using it. I know that this is not possible
out of the box, but I am interested is a workaround? What about using the
second Ethernet port (I am currently only using the first Ethernet port)?
Tihomir Mescic
Visit us on Toulouse Space Show 2016 at booth E35
------------------------------
Message: 15
Date: Tue, 28 Jun 2016 16:28:40 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Multiple parallel connections to x310
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hello Tihomir,
no, USRP access is inherently exclusive, because there's no safe way to
concurrently access the ressources on the X310.
What you can (probably should) do is write a minimal server that runs
within the GNU Radio application and gives remote access to the USRP
functionality you want.
Could you elaborate on what you need to do while GNU Radio is streaming
samples from/to the USRP?
Best regards,
Marcus
On 28.06.2016 15:33, Tihomir Mescic via USRP-users wrote:
> Hi everyone,
>
> I am using GNU radio to read and process data from the Ettus x310. What I
> would like to do now, is to be able to access the device (using the UHD C
> API) from another process *while* GNU radio is using it. I know that this is
> not possible out of the box, but I am interested is a workaround? What about
> using the second Ethernet port (I am currently only using the first Ethernet
> port)?
>
> Tihomir Mescic
> Visit us on Toulouse Space Show 2016 at booth E35
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 16
Date: Tue, 28 Jun 2016 16:30:15 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Lots of UnderRuns USRP N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Under what conditions do you get underruns?
These are really just what their name suggests: The USRP indicates that
it hasn't gotten the samples when it needed to send them ? its buffers
ran empty. The typical cause for this is simply that the PC is too slow
to produce the samples in real-time. What kind of application are you
building? What's the sampling rate?
Best regards,
Marcus
On 28.06.2016 15:23, Filippo Camuglia via USRP-users wrote:
> Hi,
>
> I'm using an USRP N210 with GnuRadio, but seems that the UHD blocks
> don't work in fact when I try to play a trace I get a lot of Underrun
> and gnuradio freezes.
> I don't know if this can be a problem related to my USRP or if it
> depends from wrong settings on my laptop.
> Have you ever faced something similar to that?
>
> Thanks in advance,
> Regards,
> Filippo
>
>
> _______________________________________________
> 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/20160628/7eec985d/attachment-0001.html>
------------------------------
Message: 17
Date: Tue, 28 Jun 2016 16:31:24 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] E310 and RFNoC performance
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Well, implementing the whole control of the E310 radio hardware from
scratch is probably worth multiple manmonths in FPGA and AD9361 expert
work time. I wouldn't recommend doing it.
Best regards,
Marcus
On 28.06.2016 15:22, Ulrika Uppman via USRP-users wrote:
> Hello Sylvain,
> From your reply you say that "the ARM in there really can't do much at all"
> and that
>
>> You realize that to actually use RFNoC you need to code your own algorithm
>> into RFNoC blocs ... if you just use RFNoC branch to just feed the ARM, you
>> gained nothing.
>>
> Well, yes I assumed that the intention of RFNoC was the ability to use FPGA
> acceleration on the computationally heavy parts of your signal processing
> flowgraphs. From what you tell me, it sounds more like that part is the whole
> thing. If you implement the whole design in a NoC-block, what is gained from
> this, using UHD and the RFNoC framework, compared to just implementing the
> whole design in the FPGA from scratch?
>
>> -----Original Message-----
>>
>> Hi,
>>
>>> We would like to be able to run some stuff on the box standalone, and
>>> since the processing power of the ARM core is limited, it seems like a
>>> good idea to use RFNoC. However, just trying it out with a radio
>>> source at rate 2MS/s followed by a couple of RFNoC blocks and an UDP
>>> sink results in more than 125% cpu load (of 200%, since there are 2
>>> cores). Running with higher data rate gives "timeout on chan 0" (or
>>> "overrun on chan 0" with samplerate > 6MS/s while not using UDP). Is
>>> this performance expected from the E310, or am I missing something? (I
>>> am currently running the alpha fido-rfnoc-test sdimage (gnuradio-demo)
>>> build that has gnuradio 3.7.8 and uhd 003.010.rfnoc-0-unknown.)
>> You realize that to actually use RFNoC you need to code your own algorithm
>> into RFNoC blocs ... if you just use RFNoC branch to just feed the ARM, you
>> gained nothing.
>>
>>
>>> Reading about performance with the RFNoC, it seems that most of you
>> guys use the X310. How big is the difference between these two platforms,
>> in terms of both hardware and performance?
>>
>> The X310 is a huge FPGA and using Kintex fabric vs, the E310 which is a Zynq
>> 7020 which is not that large and using the Artix fabric. The RFNoC blocks in
>> the E310 are also clocked slower by default in the E310, but it's However if
>> your RFNoC block fits in the FPGA and meets timing during synthesis and you
>> clock them at the same frequency, the actual performance will be identical.
>>
>> The performance of the host CPU and of whatever you run there will be
>> hugely different ... the ARM in there really can't do much at all.
>>
>>
>>> While I'm at it I have another question regarding the network mode in the
>> E310; what is the reason for network transport not being supported for the
>> data flow (i.e. only AXI transport supported)? I guess sending the data into
>> an UDP sink is still feasible, but control and gui possibilities are
>> reduced. Are
>> there any fundamental showstoppers in the design, or is it just not
>> implemented?
>>
>> By the "only AXI transport supported", I assume you mean support network
>> as a native transport in RFNoC on the E310.
>>
>> Well I don't see any fundamental technical showstoppers if you're given
>> unlimited time and resources to develop it ... (of course some might consider
>> that a showstopper)
>>
>> The two options are :
>> - Make the packets go through the host : This is purely software stuff ...
>> of
>> course performance would be pretty poor, pretty much like the current
>> network mode in the non-rfnoc version (i.e. usable for debug / testing only)
>> - Direct from fpga to network : This could be pretty fast and efficient ...
>> however it also requires cooperation between userspace, the kernel, the
>> network driver, uhd, the fpga fabric and the ethernet hard ip .... that would
>> be a _massive_ amount of work !
>>
>>
>> Cheers,
>>
>> Sylvain
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 18
Date: Tue, 28 Jun 2016 16:40:04 +0200 (CEST)
From: Tihomir Mescic <[email protected]>
To: Marcus M?ller <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Multiple parallel connections to x310
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Thanks for the advice. Do you maybe have a link to an example of how would one
create a server withing GNU radio?
As for the use case, I want to create a service that would expose parameters of
the the device during processing (something similar to SNMP) so that I can
display them to the user during processing (GNU radio would be running headless
in the background).
Tihomir Me??i?
Senior Software Engineer
Amphinicy Technologies
Nothing is Impossible.?
Zagreb Office
Trg Nikole Subica Zrinskog 15 | HR-10000 Zagreb | Croatia
T +385 1 6407 831 | M +385 95 8745 900 | F +385 1 485 2824
W amphinicy.com
From: "usrp-users" <[email protected]>
To: "usrp-users" <[email protected]>
Sent: Tuesday, June 28, 2016 4:28:40 PM
Subject: Re: [USRP-users] Multiple parallel connections to x310
Hello Tihomir,
no, USRP access is inherently exclusive, because there's no safe way to
concurrently access the ressources on the X310.
What you can (probably should) do is write a minimal server that runs
within the GNU Radio application and gives remote access to the USRP
functionality you want.
Could you elaborate on what you need to do while GNU Radio is streaming
samples from/to the USRP?
Best regards,
Marcus
On 28.06.2016 15:33, Tihomir Mescic via USRP-users wrote:
> Hi everyone,
>
> I am using GNU radio to read and process data from the Ettus x310. What I
> would like to do now, is to be able to access the device (using the UHD C
> API) from another process *while* GNU radio is using it. I know that this is
> not possible out of the box, but I am interested is a workaround? What about
> using the second Ethernet port (I am currently only using the first Ethernet
> port)?
>
> Tihomir Mescic
> Visit us on Toulouse Space Show 2016 at booth E35
>
>
> _______________________________________________
> 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
Visit us on Toulouse Space Show 2016 at booth E35
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160628/e6e676aa/attachment-0001.html>
------------------------------
Message: 19
Date: Tue, 28 Jun 2016 17:11:16 +0200
From: Marcus M?ller <[email protected]>
To: Tihomir Mescic <[email protected]>,
"[email protected]" <[email protected]>, GNURadio
Discussion List <[email protected]>
Subject: [USRP-users] Remote access to running GNU Radio application's
USRP objects (was Re: Multiple parallel connections to x310)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
What kind of parameters would that be? Most of the "value keeping" for
things like gain, frequency... are done purely inside the UHD host-side
driver, so notifying your GUI of whatever action your GNU Radio flow
graph does would probably do the trick just as well!
I'm including the discuss-gnuradio list here; I think the discussion is
going to go more into a GNU Radio-specific area; feel free to follow up
on whatever mailing list *you* deem more approporiate
Going through things in my head, there's two to three options:
1. The web service kind of thing: XMLRPC. I think there should be an
example within GNU Radio. Together with a function probe, this might
be totally sufficient for your use case. I remember Balint Seeber
has hacked together a quick restaurant pager highjacking GUI [1]
using XMLRPC
2. The most universal way of doing this is probably going through the
controlport RPC facility that GNU Radio has ? you should be able to
add RPC variables for whatever you want to monitor. Downside: I
think this is not a python thing yet, so you'd have to meddle with
GNU Radio C++ source code. Out of the box, I think gr-uhd supports
sample rate (and not much else). Others on the discuss-gnuradio
mailing list might be better informed than me.
3. Notification based updating of the GUI: Make your GUI listen to
ZeroMQ packets. Whenever you change something on the USRP sink or
source, send a message to a ZeroMQ message sink ? for examples, you
could implement your GUIs all as ZeroMQ subscriber sockets. All the
GUIs would then subscribe to one ZeroMQ PUB Message sink, getting
notified when your application sends a message to that. On the GUI's
side, use GNU Radio's PMT library (available in both C++ and Python,
but should be easily wrappable to C ABI, and hence, available pretty
much everywhere?) to decode the messages.
Best regards,
Marcus
[1] https://www.youtube.com/watch?v=x3UUazj0tkg
? I'm not even sure why GR doesn't do that. The whole PMT tree feels
like it's old-school C style with its whole "pmt_t pmt_operation(pmt_t,
parameters);" API, but as far as I can tell, that is not exported as a C
API.
On 28.06.2016 16:40, Tihomir Mescic wrote:
> Thanks for the advice. Do you maybe have a link to an example of how
> would one create a server withing GNU radio?
>
> As for the use case, I want to create a service that would expose
> parameters of the the device during processing (something similar to
> SNMP) so that I can display them to the user during processing (GNU
> radio would be running headless in the background).
>
>
> *Tihomir Me??i?
> *Senior Software Engineer
>
> Amphinicy Technologies
> Nothing is Impossible.?
>
> Zagreb Office
> Trg Nikole Subica Zrinskog 15 | HR-10000 Zagreb | Croatia
> T +385 1 6407 831 <callto:+385%201%206407%20831> | M +385 95 8745 900
> <callto:+385%2095%208745%20900> | F +385 1 485 2824
> <callto:+385%201%20485%202824>
> W amphinicy.com
>
>
> ------------------------------------------------------------------------
> *From: *"usrp-users" <[email protected]>
> *To: *"usrp-users" <[email protected]>
> *Sent: *Tuesday, June 28, 2016 4:28:40 PM
> *Subject: *Re: [USRP-users] Multiple parallel connections to x310
>
> Hello Tihomir,
>
> no, USRP access is inherently exclusive, because there's no safe way to
> concurrently access the ressources on the X310.
>
> What you can (probably should) do is write a minimal server that runs
> within the GNU Radio application and gives remote access to the USRP
> functionality you want.
>
> Could you elaborate on what you need to do while GNU Radio is streaming
> samples from/to the USRP?
>
>
> Best regards,
>
> Marcus
>
>
> On 28.06.2016 15:33, Tihomir Mescic via USRP-users wrote:
> > Hi everyone,
> >
> > I am using GNU radio to read and process data from the Ettus x310.
> What I would like to do now, is to be able to access the device (using
> the UHD C API) from another process *while* GNU radio is using it. I
> know that this is not possible out of the box, but I am interested is
> a workaround? What about using the second Ethernet port (I am
> currently only using the first Ethernet port)?
> >
> > Tihomir Mescic
> > Visit us on Toulouse Space Show 2016 at booth E35
> >
> >
> > _______________________________________________
> > 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
>
> Visit Amphinicy Technologies on Toulouse Space show 2016 - booth E35
> Visit us on Toulouse Space Show 2016 ? booth E35
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160628/3b8e4742/attachment-0001.html>
------------------------------
Message: 20
Date: Tue, 28 Jun 2016 17:30:21 +0200
From: Sylvain Munaut <[email protected]>
To: Ulrika Uppman <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] E310 and RFNoC performance
Message-ID:
<CAHL+j0-_capt1rZBBdsyvnUaAqr2AD83XXEeWfV5aG0k1B=g...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
>> You realize that to actually use RFNoC you need to code your own algorithm
>> into RFNoC blocs ... if you just use RFNoC branch to just feed the ARM, you
>> gained nothing.
>>
>
> Well, yes I assumed that the intention of RFNoC was the ability to use FPGA
> acceleration on the computationally heavy parts of your signal processing
> flowgraphs. From what you tell me, it sounds more like that part is the whole
> thing. If you implement the whole design in a NoC-block, what is gained from
> this, using UHD and the RFNoC framework, compared to just implementing the
> whole design in the FPGA from scratch?
What you gain ? Well same thing as using any other framework : time ...
The radio interfacing and control as well as data exchange with the
host is handled conveniently for you.
And :
- It doesn't have to be a single block, the point here is to make
re-usable blocks you can combine dynamically
- It doesn't have to do _everything_ but anything that's high rate,
one example would be to only send to the host demodulated bits for
instance and let the host handle the "protocol" layer above that.
Cheers,
Sylvain
------------------------------
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 70, Issue 29
******************************************
