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. B200mini Rx-to-Tx-to-Rx observation (Steven Knudsen)
2. More B205 FPGA Acceleration Questions (Austin Anderson)
3. Re: E310 and RFNoC performance (Martin Braun)
4. Isolation between TX/RX and RX2 on B210 (Sebastian M. Richter)
5. Re: Isolation between TX/RX and RX2 on B210 ([email protected])
6. Re: RFNoC Installation Problems (devin kelly)
7. Re: RFNoC Installation Problems (devin kelly)
----------------------------------------------------------------------
Message: 1
Date: Tue, 28 Jun 2016 10:57:38 -0600
From: Steven Knudsen <[email protected]>
To: USRP-users <[email protected]>
Subject: [USRP-users] B200mini Rx-to-Tx-to-Rx observation
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi All,
There is no pressing question here, but rather I am wondering if the following
matches other people?s expectations and experience.
I have a TDMA-based GR design with B200minis. Time is sync?d to GPS time and
packets are scheduled and delineated using tx_time and SOB/EOB tags.
The attached scope snapshots show the 1 PPS edge and a packet scheduled to
transmit at that time. The following observations seem obvious, but you be the
judge.
The (SOB-mediated?) Rx-to-Tx transient exists and is kind of high. It may be
that I should put a couple of zero-valued samples up front, so I will try that
soon.
However, it appears that the EOB Tx-to-Rx transition is delayed by about 10 us
past the last sample, and still results in a transient. This may not bode well
for reducing the Tx transient.
I am confident the transient is delayed as I calculated exactly how long my
?packet? needs, which is 134.4 us
It appears that it takes about 80 us to reach full transmit power. Again,
zero-padding or extending my sync sequence at the front can mitigate that.
Any and all comments are welcome. This behaviour is, for my particular project,
not a problem, but I suspect would be for someone needing to meet a spectrum
mask.
Thanks for your time and consideration,
steven
Steven Knudsen, Ph.D., P.Eng.
www. techconficio.ca
www.linkedin.com/in/knudstevenknudsen
Der entscheidende Augenblick der menschlichen Entwicklung ist immerw?hrend.
Darum sind die revolution?ren geistigen Bewegungen, welche alles Fr?here f?r
nichtig erkl?ren, im Recht, denn es ist noch nichts geschehen. - Franz Kafka
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160628/85d78221/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rx_to_tx_to_rx.bmp
Type: image/bmp
Size: 308278 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160628/85d78221/attachment-0002.bmp>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160628/85d78221/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rx_to_tx_to_rx_persist.bmp
Type: image/bmp
Size: 308278 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160628/85d78221/attachment-0003.bmp>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160628/85d78221/attachment-0005.html>
------------------------------
Message: 2
Date: Tue, 28 Jun 2016 11:02:14 -0600
From: Austin Anderson <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] More B205 FPGA Acceleration Questions
Message-ID:
<CAF30z8d6aZr9GwkMotEZRqGbkk4EnTnZKnMGgz8ky7csSPMG=a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi All,
I have a couple follow up questions about using the FPGA on the B205. I'm
planning on replacing the DUC/DDC with my own processing cores and using
the user setting registers for configuration/control.
1. I understand how to turn on the user registers and what values I'd need
to write where to do what I want. What I'm unclear on is how to access this
from the host software. I can see in:
uhd/host/lib/usrb/b200/b200_impl.cpp
where peek/poke calls exist that I can use. I've been working with the
example at:
uhd/host/examples/rx_samples_to_file.cpp
If I add a new method to the b200_impl class, is there a straightforward
way to call that from the usrp object created in that example? Is adding a
new method the recommended approach?
2. The most basic processing I'd like to do is a fixed point FFT. I'd like
to synch up the framing of the FFT in the FPGA fabric with the framing of
the data on the host side. The FFT's framing can be synch'd up by pulsing a
reset signal. Does the host-side pulse a reset to the FPGA fabric to start
a data transfer? If that's the case, syncing the framing should be pretty
easy.
Thanks,
-Austin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160628/e4ee6eff/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 28 Jun 2016 10:44:17 -0700
From: Martin Braun <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] E310 and RFNoC performance
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Ulrika,
let me summarize this thread: If you want any kind of performance on the
E310, RFNoC is your best bet since the ARM core isn't really designed
for high-speed DSP algorithms. RFNoC doesn't auto-offload blocks to the
FPGA, but it makes it really simple to do that yourself. The majority of
tasks (if you were to design a new FPGA image from scratch) involve
non-DSP related tasks, such as getting the data transports set up etc.
RFNoC lets you simply take your DSP algorithm and put it into an RFNoC
block, which then handles all the housekeeping for you, as well as
simple integration into your software tools.
I know you've guys have done USRP-based development both in software and
FPGA for a while; the E310 and RFNoC workflows are a bit different than
the N210 workflow, though. I recommend taking a look at the videos we've
compiled at the bottom of https://kb.ettus.com/RFNoC.
Cheers,
Martin
On 06/28/2016 08:30 AM, Sylvain Munaut via USRP-users wrote:
> 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
>
> _______________________________________________ USRP-users mailing
> list [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 4
Date: Tue, 28 Jun 2016 17:51:27 +0000
From: "Sebastian M. Richter" <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Isolation between TX/RX and RX2 on B210
Message-ID:
<blupr03mb1380891dc28994b4b5439f2d90...@blupr03mb1380.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I am trying to get more information about the components U801, U805, U807,
U810, U814. From my perspective, they are switches and I am mainly interested
in their isolation. It is important to me to get an information about the
isolation between the RF ports RX2 and TX/RX of one channel. Does anybody has
more information about the switches or the TX/RX-RX2 isolation?
Best,
Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160628/edd34c50/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 28 Jun 2016 14:00:55 -0400
From: [email protected]
To: "Sebastian M. Richter" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Isolation between TX/RX and RX2 on B210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
http://www.skyworksinc.com/uploads/documents/SKY13317_373LF_200914K.pdf
That's for one of the switches used.
The schematics for B2xx are at:
http://files.ettus.com/schematics/b200/
In general, getting better than 40dB isolation on a single RF card
without shielded sub-assemblies is next to impossible.
On 2016-06-28 13:51, Sebastian M. Richter via USRP-users wrote:
> Hello,
>
> I am trying to get more information about the components U801, U805, U807,
> U810, U814. From my perspective, they are switches and I am mainly interested
> in their isolation. It is important to me to get an information about the
> isolation between the RF ports RX2 and TX/RX of one channel. Does anybody has
> more information about the switches or the TX/RX-RX2 isolation?
>
> Best,
>
> Sebastian
> _______________________________________________
> 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/166c95a7/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 28 Jun 2016 14:01:04 -0400
From: devin kelly <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC Installation Problems
Message-ID:
<caanlyub7s4dzcalsr5qhsg0h7u2bcebo7vmwjkopnet77en...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Martin,
Thanks for the help. I switched to rfnoc-radio-redo but I'm having
problems building the branch for the UHD.
This is how I set it up:
$ cd uhd
$ git checkout -b rfnoc-radio-redo origin/rfnoc-radio-redo
$ mkdir -p host/build; cd host/build
$ cmake -DCMAKE_INSTALL_PREFIX=${INSTALL_DIR} -DENABLE_E300=ON ../
$ make
...
[ 52%] Building CXX object
lib/CMakeFiles/uhd.dir/usrp/e300/e300_global_regs.cpp.o
[ 52%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/e300/e300_spi.cpp.o
[ 52%] Building CXX object
lib/CMakeFiles/uhd.dir/usrp/e300/e300_sensor_manager.cpp.o
/local_disk/gr_3.7.9.2_rfnoc_src/uhd/host/lib/usrp/e300/e300_spi.cpp: In
member function ?virtual uint32_t
uhd::usrp::e300::spidev_impl::transact_spi(int, const uhd::spi_config_t&,
uint32_t, size_t, bool)?:
/local_disk/gr_3.7.9.2_rfnoc_src/uhd/host/lib/usrp/e300/e300_spi.cpp:96:12:
error: ?struct spi_ioc_transfer? has no member named ?tx_nbits?
tr.tx_nbits = 1;
^
/local_disk/gr_3.7.9.2_rfnoc_src/uhd/host/lib/usrp/e300/e300_spi.cpp:97:12:
error: ?struct spi_ioc_transfer? has no member named ?rx_nbits?
tr.rx_nbits = 1;
^
make[2]: *** [lib/CMakeFiles/uhd.dir/usrp/e300/e300_spi.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2
make: *** [all] Error 2
It looks like this struct is just missing tx_nbits and rx_nbits but I
suspect the solution is more than the adding the two fields.
As far as I know I'm on the most recent commit (from 8 June):
$ git show
commit eb3036f6ddec6c81882b625fe76d778882eabab5
Is there something else I'm doing wrong?
Devin
On Mon, Jun 27, 2016 at 3:02 PM, Yin, Charles - 0665 - MITLL via USRP-users
<[email protected]> wrote:
> 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]> 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 (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 (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 (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 (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]]
> *Sent:* Wednesday, June 22, 2016 12:17 PM
> *To:* Yin, Charles - 0665 - MITLL
> *Cc:* [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]> 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]
> 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/20160628/55c72577/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 28 Jun 2016 14:09:34 -0400
From: devin kelly <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoC Installation Problems
Message-ID:
<caanlyuy_bpqqtghof3+8z+xjvehj28ogrg_-zfdxevxxfoc...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Actually, I just realized that this is happening because I'm on a very old
kernel (3.10.0-327.13.1.el7.x86_64). I'll try a more recent kernel.
Devin
On Tue, Jun 28, 2016 at 2:01 PM, devin kelly <[email protected]> wrote:
> Hi Martin,
>
> Thanks for the help. I switched to rfnoc-radio-redo but I'm having
> problems building the branch for the UHD.
>
> This is how I set it up:
>
> $ cd uhd
> $ git checkout -b rfnoc-radio-redo origin/rfnoc-radio-redo
> $ mkdir -p host/build; cd host/build
> $ cmake -DCMAKE_INSTALL_PREFIX=${INSTALL_DIR} -DENABLE_E300=ON ../
> $ make
> ...
> [ 52%] Building CXX object
> lib/CMakeFiles/uhd.dir/usrp/e300/e300_global_regs.cpp.o
> [ 52%] Building CXX object lib/CMakeFiles/uhd.dir/usrp/e300/e300_spi.cpp.o
> [ 52%] Building CXX object
> lib/CMakeFiles/uhd.dir/usrp/e300/e300_sensor_manager.cpp.o
> /local_disk/gr_3.7.9.2_rfnoc_src/uhd/host/lib/usrp/e300/e300_spi.cpp: In
> member function ?virtual uint32_t
> uhd::usrp::e300::spidev_impl::transact_spi(int, const uhd::spi_config_t&,
> uint32_t, size_t, bool)?:
> /local_disk/gr_3.7.9.2_rfnoc_src/uhd/host/lib/usrp/e300/e300_spi.cpp:96:12:
> error: ?struct spi_ioc_transfer? has no member named ?tx_nbits?
> tr.tx_nbits = 1;
> ^
> /local_disk/gr_3.7.9.2_rfnoc_src/uhd/host/lib/usrp/e300/e300_spi.cpp:97:12:
> error: ?struct spi_ioc_transfer? has no member named ?rx_nbits?
> tr.rx_nbits = 1;
> ^
> make[2]: *** [lib/CMakeFiles/uhd.dir/usrp/e300/e300_spi.cpp.o] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[1]: *** [lib/CMakeFiles/uhd.dir/all] Error 2
> make: *** [all] Error 2
>
> It looks like this struct is just missing tx_nbits and rx_nbits but I
> suspect the solution is more than the adding the two fields.
>
> As far as I know I'm on the most recent commit (from 8 June):
>
> $ git show
> commit eb3036f6ddec6c81882b625fe76d778882eabab5
>
> Is there something else I'm doing wrong?
>
> Devin
>
>
> On Mon, Jun 27, 2016 at 3:02 PM, Yin, Charles - 0665 - MITLL via
> USRP-users <[email protected]> wrote:
>
>> 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]> 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 (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 (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 (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 (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]]
>> *Sent:* Wednesday, June 22, 2016 12:17 PM
>> *To:* Yin, Charles - 0665 - MITLL
>> *Cc:* [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]> 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]
>> 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/20160628/04b48ff9/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 70, Issue 30
******************************************
