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: Compiling UHD against Boost 1.64 (Michael Dickens)
2. rfnocmodtool "global name 'sys' is not defined" (Jason Matusiak)
3. [GRCon17] Updates, Approaching Deadlines (Ben Hilburn)
4. Re: rfnocmodtool "global name 'sys' is not defined"
(Nicolas Cuervo)
5. Re: Can I write my own HDL code on B210 or the other kind of
USRPs without using GNU radio? (Adam Bacon)
6. RFNoc on E310 hangs on uhd_usrp_probe (Erik Malone)
7. Re: RFNoc on E310 hangs on uhd_usrp_probe (Nicolas Cuervo)
8. uhd_image_builder using wrong directory (Jason Matusiak)
9. Re: uhd_image_builder using wrong directory (Nicolas Cuervo)
10. Re: uhd_image_builder using wrong directory (Jason Matusiak)
11. Re: uhd_image_builder using wrong directory (Nicolas Cuervo)
12. E310 Rfnoc clocking guidelines/ performance issues (Samuel Prager)
13. About the speed of the received signal of "file sink", what
factors affect it? (Bob)
14. Making NI USRP 2943R work with GNU Radio (Ammar Mahmood)
15. Re: Using B210 TX/RX in TDD mode (Sumit Kumar)
16. Re: Using B210 TX/RX in TDD mode (Sumit Kumar)
17. Re: Using B210 TX/RX in TDD mode (Sumit Kumar)
18. Re: Making NI USRP 2943R work with GNU Radio (Neel Pandeya)
19. Re: uhd_image_builder using wrong directory (Jason Matusiak)
20. Re: About the speed of the received signal of "file sink",
what factors affect it? (Marcus M?ller)
21. Re: uhd_image_builder using wrong directory (Nicolas Cuervo)
22. E310 Cross-Compiled UHD Error - key "product" not found
(Jane Abad Jaume)
----------------------------------------------------------------------
Message: 1
Date: Wed, 17 May 2017 12:18:01 -0400
From: Michael Dickens <[email protected]>
To: Daryl Lee <[email protected]>, [email protected]
Subject: Re: [USRP-users] Compiling UHD against Boost 1.64
Message-ID:
<1495037881.3777123.979798656.33efa...@webmail.messagingengine.com>
Content-Type: text/plain; charset="utf-8"
Hi Daryl - You're not alone. Boost 1.64.0 moved
serialization::make_array from <boost/serialization/array.hpp> into
<boost/serialization/array_wrapper.hpp>, and then didn't include the
latter in the former. I have NOT tried modifying UHD code that uses this
to include the latter -before- the former; that might work. The other
option is to just ban this version of Boost, since it doesn't work out
of the box. Boost 1.63.0 works nicely out of the box in my testing. Hope
this helps! - MLD
On Wed, May 17, 2017, at 11:49 AM, Daryl Lee via USRP-users wrote:
> I'm trying to compile UHD against Boost 1.64 and running into the
> following error:>
> [ 17%] Building CXX object
> lib/CMakeFiles/uhd.dir/cal/power_container_impl.cpp.o> In file included from
> /home/daryl/Dropbox/Bluecom/ZynqPorts/boost/boo-
> st_1_64_0/boost/numeric/ublas/vector.hpp:21:0,> from
> /home/daryl/Dropbox/Bluecom/ZynqPorts/boost/boo-
> st_1_64_0/boost/numeric/ublas/matrix.hpp:18,>
> from /home/daryl/Dropbox/Bluecom/ZynqPorts/uhd4/uhd/-
> host/lib/cal/interpolation.ipp:24,> from
> /home/daryl/Dropbox/Bluecom/ZynqPorts/uhd4/uhd/-
> host/lib/cal/power_container_impl.hpp:21,>
> from /home/daryl/Dropbox/Bluecom/ZynqPorts/uhd4/uhd/-
> host/lib/cal/power_container_impl.cpp:18:>
> /home/daryl/Dropbox/Bluecom/ZynqPorts/boost/boost_1_64_0/boost/numeri-
> c/ublas/storage.hpp: In member function 'void
> boost::numeric::ublas::unbounded_array<T, ALLOC>::serialize(Archive&,
> unsigned int)':>
> /home/daryl/Dropbox/Bluecom/ZynqPorts/boost/boost_1_64_0/boost/numeri-
> c/ublas/storage.hpp:299:18: error: 'make_array' is not a member of
> 'boost::serialization'> ar & serialization::make_array(data_, s);
> Am I the only one with this problem? What is the best version of
> Boost to use for the current version of UHD?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170517/81379f7e/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 17 May 2017 13:12:01 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] rfnocmodtool "global name 'sys' is not defined"
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
I was trying to add a new block to my RFNoC OOT module by running:
rfnocmodtool add freqShift
But I get the error:
[INFO] [UHD] linux; GNU C++ version 4.8.4; Boost_105400;
UHD_4.0.0.rfnoc-devel-348-g2c2e1a99
RFNoC module name identified: multiaperture
Traceback (most recent call last):
File "/home/jmat/rfnoc/bin/rfnocmodtool", line 27, in <module>
main()
File "/home/jmat/rfnoc/bin/rfnocmodtool", line 22, in main
print(err, file=sys.stderr)
NameError: global name 'sys' is not defined
If I add "import sys" to the top of /home/jmat/rfnoc/bin/rfnocmodtool,
everything is happy again...
------------------------------
Message: 3
Date: Wed, 17 May 2017 13:37:45 -0400
From: Ben Hilburn <[email protected]>
To: GNURadio Discussion List <[email protected]>
Cc: USRP-Users <[email protected]>
Subject: [USRP-users] [GRCon17] Updates, Approaching Deadlines
Message-ID:
<CAJH_qMHY1=wlwrqupy_mz+dtf3rjxry5rveaqliedtbgxd3...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hey all -
Some updates about GRCon17:
*Presentation Deadline*
As a reminder, the deadline for submitting your presentation abstract
(talk, tutorial, or poster) is in *2 weeks*, Thursday 1 June. Check out the
website for more info, and please let us know if you have any questions!
https://www.gnuradio.org/grcon-2017/submit/
*Paper Submission Opens*
Paper submission will open on EDAS on Thursday 1 June, and closes on
Saturday 1 July. Acceptance will be on a rolling basis. For more details,
please see the website: https://www.gnuradio.org/grcon-2017/submit/
*Registration*
Remember that the deadline for Early Bird Registration is *Thursday 1 June*,
in just two weeks! Don't forget that there is discounted registration
available for students (https://www.gnuradio.org/grcon-2017/students/).
To register for the conference, head to Eventbrite:
https://grcon17.eventbrite.com/
To book your hotel rooms, use this link for our negotiated rate:
http://bahiahotel.com/groups/GRCon17/
*Sponsors*
We've added four new sponsors since the last update to the list! We are
very happy to announce the following sponsors for GRCon17:
*simpleXecutive - Diamond Sponsor*
simpleXecutive Methodology?s patented modeling tools simulate hardware and
software performance on embedded systems, prior to writing any code. We
enable software engineers, architects and designers to deliver
sophisticated real-time systems that meet requirements, at lower costs, on
schedule and with greatly reduced risk. We encourage systematically testing
and tuning overall system design until optimal performance is achieved. We
applied our methodology and tools to the ATSC Flow Graph as part of our
DARPA contract and worked with Corgan Labs. We improved performance by over
20% without changing any of the application code or data and will share
details during our presentation.
*Epiq Solutions - Platinum Sponsor*
Epiq Solutions is a company focused on developing state of the art software
defined radio platforms and sensors that push the limits of small form
factor, integration and low power consumption. These products are used by
customers around the world in multiple business sectors, including
commercial, research and security/defense applications. In addition to
radio platform expertise, Epiq Solutions specializes in developing
integrated RF sensing products and signal processing applications that run
on these platforms. These applications leverage decades of experience in
the commercial wireless industry, enabling unique capabilities that support
2G/3G/4G cellular as well as other commercial wireless communications
standards.
*CyberRadio Solutions - Platinum Sponsor*
CyberRadio?s mission is to deliver rugged hardware solutions that combine
wideband RF tuners with embedded FPGA-based signal processing and standard
network data interfaces for worldwide connectivity. CyberRadio Solutions
GNURadio modules provide seamless open-source software development on all
CyberRadio products. The addition of GNURadio modules enable the CyberRadio
Solutions product line to support SDR applications. For More information on
our GNU Radio Modules please visit us at www.cyberradiosolutions.com
*Johns Hopkins Applied Physics Laboratory - Platinum Sponsor*
The Johns Hopkins University Applied Physics Laboratory has provided
solutions to national security and scientific challenges with engineering,
systems integration, research and development, and analysis for more than
70 years. APL is our nation?s largest University Affiliated Research
Center, with approximately 5,000 staff members and 600 ongoing sponsored
research projects. Our scientists, engineers and analysts serve as trusted
advisors and technical experts to the government, ensuring the reliability
of complex technologies that safeguard our nation?s security and advance
the frontiers of space. We also maintain independent research and
development programs that pioneer and explore emerging technologies and
concepts to address future national priorities.
Cheers,
The GRCon17 Organizing Committee
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170517/e6e7258b/attachment-0001.html>
------------------------------
Message: 4
Date: Wed, 17 May 2017 19:51:35 +0200
From: Nicolas Cuervo <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] rfnocmodtool "global name 'sys' is not
defined"
Message-ID:
<CAOuPCvjrdMNCSGz--vmV-Y975aNJiK62ZF8aH6=vbhushjo...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Jason,
I think you are right! Thanks for the catch! I will push a patch for this.
Cheers,
-Nicolas
On Wed, May 17, 2017 at 7:12 PM, Jason Matusiak via USRP-users <
[email protected]> wrote:
> I was trying to add a new block to my RFNoC OOT module by running:
> rfnocmodtool add freqShift
>
> But I get the error:
> [INFO] [UHD] linux; GNU C++ version 4.8.4; Boost_105400;
> UHD_4.0.0.rfnoc-devel-348-g2c2e1a99
> RFNoC module name identified: multiaperture
> Traceback (most recent call last):
> File "/home/jmat/rfnoc/bin/rfnocmodtool", line 27, in <module>
> main()
> File "/home/jmat/rfnoc/bin/rfnocmodtool", line 22, in main
> print(err, file=sys.stderr)
> NameError: global name 'sys' is not defined
>
>
> If I add "import sys" to the top of /home/jmat/rfnoc/bin/rfnocmodtool,
> everything is happy again...
>
> _______________________________________________
> 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/20170517/95a991f0/attachment-0001.html>
------------------------------
Message: 5
Date: Wed, 17 May 2017 17:56:13 +0000
From: Adam Bacon <[email protected]>
To: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Can I write my own HDL code on B210 or the
other kind of USRPs without using GNU radio?
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi Ali,
As Marcus et al. stated, unless you are skilled with FPGA development, this is
probably not the path you want to take. If you do have this experience, then
these platforms can be a good platform to build on and you should be able to do
so without UHD and GNU Radio (although these are great tools!). A couple of
years ago my company was looking for a prototype platform with a suitable RF
Frontend on which to build a DVB-S2X satellite modem. We ended up selecting the
Ettus X310 because it was able to hit bandwidths higher than other boards built
on the AD9361 IC and it had a decent sized FPGA. If you are curious and want
more details, see:
https://www.ettus.com/blog/2015/06/aha-demonstrates-complete-dvb-s2x-modem-in-sdr-platform
https://www.linkedin.com/pulse/dvb-s2x-modem-from-ettus-x310-sdr-platform-juan-d-deaton-ph-d-
Best Regards,
Adam Bacon
AHA Products Group
Comtech EF Data Corp
www.aha.com
From: Marcus M?ller [mailto:[email protected]]
Sent: Wednesday, May 17, 2017 1:05 AM
To: [email protected]
Subject: Re: [USRP-users] Can I write my own HDL code on B210 or the other kind
of USRPs without using GNU radio?
Hi Ali,
Aside from the E-series USRPs, all USRPs are designed to be controlled by a
computer running UHD.
So, the general answer to "can I use the USRP without UHD" is no. "Can I use it
without a PC?": Also, No (you can substitute a server, single-board-computer,
... as you see fit, though, given that computing platform can run UHD and has
enough power to process the samples).
Notice that of course you can just throw away all of our firmware and FPGA
image to make things work differently, but the digital design of a USRP is
about as cost- and time-intense as the analog part, so it's highly unlikely you
would be successful at re-inventing how a USRP works based on our hardware.
FPGA development, by all means, is hard, when comparing it to writing software
for a PC-style computer. So, if you're a beginner at DSP/SDR and digital
design, I'd very strongly recommend not trying to do that.
>From my experience (I get a lot of email from customers): From the (especially
>students') projects having descriptions that sound like
> I want to implement this and that in the FPGA of a USRP, but I don't have an
> approach how to do that, at all
there's a 95% chance that no, you should not implement this on the FPGA -
there's no necessity to do so instead of implementing it in software, and doing
it in software is far easier, cheaper, faster, better to debug, easier to hand
on to the next person working on the same project and maintainable.
Best regards,
Marcus
On 17.05.2017 06:29, Ali Khanjani via USRP-users wrote:
Hi every one, I want to use the USRP boards because they have front end RF unit
embedded on it's own, and it has a moderate processor but I don't know that
without using GNU radio or UHD can I program it independently through ISE
program and use these boards without the need of PC or not?
please help me.
thanks for your attention.
_______________________________________________
USRP-users mailing list
[email protected]<mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
________________________________
NOTICE TO RECIPIENT: This email, including attachments, may contain information
which is confidential, proprietary, attorney-client privileged and/or
controlled under U.S. export laws and regulations and may be restricted from
disclosure by applicable State and Federal law. Nothing in this email shall
create any legal binding agreement between the parties unless expressly stated
herein and provided by an authorized representative of Comtech
Telecommunications Corp. or its subsidiaries. If you are not the intended
recipient of this message, be advised that any dissemination, distribution, or
use of the contents of this message is strictly prohibited. If you received
this message in error, please notify us immediately by return email and
permanently delete all copies of the original email and any attached
documentation from any computer or other media.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170517/869809ca/attachment-0001.html>
------------------------------
Message: 6
Date: Wed, 17 May 2017 11:00:11 -0700
From: Erik Malone <[email protected]>
To: [email protected]
Subject: [USRP-users] RFNoc on E310 hangs on uhd_usrp_probe
Message-ID:
<cajtcrc2u8+2nuegpf1ik-f84+ctjpkquelaaum2mbth3crq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi,
I'm attempting to get RFNoC build working on an SG1 E310. So far I've gone
through running the pybombs
<https://kb.ettus.com/Software_Development_on_the_E310_and_E312> setup on a
host Linux running Ubuntu 16.04. The image on the E310 is e3xx-release-4.
I've setup sshfs on the E310 to point to the /prefix/usr space on the host,
and used uhd_images_downloader to download the FPGA image (
uhd-images_4.0.0.rfnoc-devel-238-g39a41476.zip
<http://files.ettus.com/binaries/images/uhd-images_4.0.0.rfnoc-devel-238-g39a41476.zip>
).
Unfortunately, when I attempt to run uhd_usrp_probe it hangs.
Here's the output I do receive:
[INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700;
UHD_4.0.0.rfnoc-devel-348-g2c2e1a99
[INFO] [E300] Loading FPGA image:
/home/root/usr/usr/share/uhd/images/usrp_e310_fpga.bit...
[INFO] [E300] FPGA image loaded
[INFO] [E300] Initializing core control (global registers)...
[INFO] [E300] Performing register loopback test...
[INFO] [E300] Register loopback test passed
Any help would be appreciated.
Thank you,
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170517/b55383d1/attachment-0001.html>
------------------------------
Message: 7
Date: Wed, 17 May 2017 20:16:12 +0200
From: Nicolas Cuervo <[email protected]>
To: Erik Malone <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] RFNoc on E310 hangs on uhd_usrp_probe
Message-ID:
<CAOuPCvgkdQUNBGbC3LZu4OdxZh4UFmp=cnxtjx-1znigf2a...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Erik,
This is a known issue and we are working on it. I will report back to you
as soon as this is fixed. Sorry for the inconvenience.
- Nicolas
On Wed, May 17, 2017 at 8:00 PM, Erik Malone via USRP-users <
[email protected]> wrote:
> Hi,
>
> I'm attempting to get RFNoC build working on an SG1 E310. So far I've gone
> through running the pybombs
> <https://kb.ettus.com/Software_Development_on_the_E310_and_E312> setup on
> a host Linux running Ubuntu 16.04. The image on the E310 is
> e3xx-release-4. I've setup sshfs on the E310 to point to the /prefix/usr
> space on the host, and used uhd_images_downloader to download the FPGA
> image (uhd-images_4.0.0.rfnoc-devel-238-g39a41476.zip
> <http://files.ettus.com/binaries/images/uhd-images_4.0.0.rfnoc-devel-238-g39a41476.zip>
> ).
>
> Unfortunately, when I attempt to run uhd_usrp_probe it hangs.
>
> Here's the output I do receive:
>
> [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700;
> UHD_4.0.0.rfnoc-devel-348-g2c2e1a99
> [INFO] [E300] Loading FPGA image: /home/root/usr/usr/share/uhd/
> images/usrp_e310_fpga.bit...
> [INFO] [E300] FPGA image loaded
> [INFO] [E300] Initializing core control (global registers)...
>
> [INFO] [E300] Performing register loopback test...
> [INFO] [E300] Register loopback test passed
>
>
> Any help would be appreciated.
>
> Thank you,
>
>
>
> _______________________________________________
> 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/20170517/5d1185e8/attachment-0001.html>
------------------------------
Message: 8
Date: Wed, 17 May 2017 15:42:36 -0400
From: Jason Matusiak <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] uhd_image_builder using wrong directory
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
I moved a directory instead of blowing it away and created a new ~/rfnoc
directory. So now I have ~/rfnoc and ~/rfnoc_bu2. Yet, when I go into
rfnoc and run uhd_image_builder_gui.py and add my new RFNoC OOT modules,
I get the following error:
./uhd_image_builder.py cpremoval freqShift axi_fifo_loopback fft -d x310
-t X310_RFNOC_HG
--Using the following blocks to generate image:
* cpremoval
* freqShift
* axi_fifo_loopback
* fft
Adding CE instantiation file for 'X310_RFNOC_HG'
changing temporarily working directory to
/home/jmat/rfnoc_bu2/src/uhd-fpga/usrp3/tools/scripts/../../top/x300
Setting up a 64-bit FPGA build environment for the USRP-X3x0...
- Vivado: Found (/opt/Xilinx/Vivado/2015.4/bin)
- Vivado HLS: Found (/opt/Xilinx/Vivado_HLS/2015.4/bin)
Environment successfully initialized.
make -f Makefile.x300.inc bin NAME=X310_RFNOC_HG ARCH=kintex7
PART_ID=xc7k410t/ffg900/-2 BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1
SFP1_10GBE=1 RFNOC=1 X310=1 EXTRA_DEFS="BUILD_1G=1 BUILD_10G=1
SFP0_1GBE=1 SFP1_10GBE=1 RFNOC=1 X310=1"
make[1]: Entering directory
`/home/jmat/rfnoc_bu2/src/uhd-fpga/usrp3/top/x300'
/home/jmat/rfnoc_bu2/src/uhd-fpga/usrp3/top/x300/Makefile.srcs:14: ***
missing separator. Stop.
make[1]: Leaving directory
`/home/jmat/rfnoc_bu2/src/uhd-fpga/usrp3/top/x300'
make: *** [X310_RFNOC_HG] Error 2
Any idea why it is somehow going to that old backup directory?....
------------------------------
Message: 9
Date: Wed, 17 May 2017 22:21:47 +0200
From: Nicolas Cuervo <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] uhd_image_builder using wrong directory
Message-ID:
<caoupcvigwdx5nndg0a4atzlgrkqb9vnpxg+47wrvtfkm7dt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Jason,
Please allow me to ask for clarification: So your question regards that you
are running the image builder from
"~/*rfnoc/*srcr/uhd-fpga/usrp3/tools/scripts"
but the script is apparently running in "*~**/rfnoc_bu2/*src/uhd-f
pga/usrp3/tools/scripts/"?
-N
On Wed, May 17, 2017 at 9:42 PM, Jason Matusiak via USRP-users <
[email protected]> wrote:
> I moved a directory instead of blowing it away and created a new ~/rfnoc
> directory. So now I have ~/rfnoc and ~/rfnoc_bu2. Yet, when I go into
> rfnoc and run uhd_image_builder_gui.py and add my new RFNoC OOT modules, I
> get the following error:
>
> ./uhd_image_builder.py cpremoval freqShift axi_fifo_loopback fft -d x310
> -t X310_RFNOC_HG
> --Using the following blocks to generate image:
> * cpremoval
> * freqShift
> * axi_fifo_loopback
> * fft
> Adding CE instantiation file for 'X310_RFNOC_HG'
> changing temporarily working directory to /home/jmat/rfnoc_bu2/src/uhd-f
> pga/usrp3/tools/scripts/../../top/x300
> Setting up a 64-bit FPGA build environment for the USRP-X3x0...
> - Vivado: Found (/opt/Xilinx/Vivado/2015.4/bin)
> - Vivado HLS: Found (/opt/Xilinx/Vivado_HLS/2015.4/bin)
>
> Environment successfully initialized.
> make -f Makefile.x300.inc bin NAME=X310_RFNOC_HG ARCH=kintex7
> PART_ID=xc7k410t/ffg900/-2 BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1
> RFNOC=1 X310=1 EXTRA_DEFS="BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1
> RFNOC=1 X310=1"
> make[1]: Entering directory `/home/jmat/rfnoc_bu2/src/uhd-
> fpga/usrp3/top/x300'
> /home/jmat/rfnoc_bu2/src/uhd-fpga/usrp3/top/x300/Makefile.srcs:14: ***
> missing separator. Stop.
> make[1]: Leaving directory `/home/jmat/rfnoc_bu2/src/uhd-
> fpga/usrp3/top/x300'
> make: *** [X310_RFNOC_HG] Error 2
>
> Any idea why it is somehow going to that old backup directory?....
>
> _______________________________________________
> 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/20170517/a889db1b/attachment-0001.html>
------------------------------
Message: 10
Date: Wed, 17 May 2017 17:35:01 -0400
From: Jason Matusiak <[email protected]>
To: Nicolas Cuervo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] uhd_image_builder using wrong directory
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Yep. I don't get it.
-------- Original message --------
From: Nicolas Cuervo <[email protected]>
Date: 5/17/17 4:21 PM (GMT-05:00)
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] uhd_image_builder using wrong directory
Hello Jason,
Please allow me to ask for clarification: So your question regards that you are
running the image builder from "~/rfnoc/srcr/uhd-fpga/usrp3/tools/scripts" but
the script is apparently running in
"~/rfnoc_bu2/src/uhd-fpga/usrp3/tools/scripts/"?
-N
On Wed, May 17, 2017 at 9:42 PM, Jason Matusiak via USRP-users
<[email protected]> wrote:
I moved a directory instead of blowing it away and created a new ~/rfnoc
directory.? So now I have ~/rfnoc and ~/rfnoc_bu2.? Yet, when I go into rfnoc
and run uhd_image_builder_gui.py and add my new RFNoC OOT modules, I get the
following error:
./uhd_image_builder.py cpremoval freqShift axi_fifo_loopback fft -d x310 -t
X310_RFNOC_HG
--Using the following blocks to generate image:
? ? * cpremoval
? ? * freqShift
? ? * axi_fifo_loopback
? ? * fft
Adding CE instantiation file for 'X310_RFNOC_HG'
changing temporarily working directory to
/home/jmat/rfnoc_bu2/src/uhd-fpga/usrp3/tools/scripts/../../top/x300
Setting up a 64-bit FPGA build environment for the USRP-X3x0...
- Vivado: Found (/opt/Xilinx/Vivado/2015.4/bin)
- Vivado HLS: Found (/opt/Xilinx/Vivado_HLS/2015.4/bin)
Environment successfully initialized.
make -f Makefile.x300.inc bin NAME=X310_RFNOC_HG ARCH=kintex7
PART_ID=xc7k410t/ffg900/-2 BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1?
RFNOC=1 X310=1 EXTRA_DEFS="BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1?
RFNOC=1 X310=1"
make[1]: Entering directory `/home/jmat/rfnoc_bu2/src/uhd-fpga/usrp3/top/x300'
/home/jmat/rfnoc_bu2/src/uhd-fpga/usrp3/top/x300/Makefile.srcs:14: *** missing
separator.? Stop.
make[1]: Leaving directory `/home/jmat/rfnoc_bu2/src/uhd-fpga/usrp3/top/x300'
make: *** [X310_RFNOC_HG] Error 2
Any idea why it is somehow going to that old backup directory?....
_______________________________________________
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/20170517/552f9ea8/attachment-0001.html>
------------------------------
Message: 11
Date: Wed, 17 May 2017 23:53:19 +0200
From: Nicolas Cuervo <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] uhd_image_builder using wrong directory
Message-ID:
<CAOuPCviMGeCJ_NWGoiCZseeV086P7seKoMaPZ9-tM0NUBLk=u...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hmm, this is completely odd.
basically the working directory, as you can see in the code, is taken
relative to the location of the script that is currently running. While
being in the directory that contains the script (which from your
information I assume it is "~/*rfnoc/*srcr/uhd-fpga/usrp3/tools/scripts"),
you can check the path in the terminal by running the same method that is
used in the code as follows:
$ python -c "import os ; print
os.path.dirname(os.path.realpath('./uhd_image_builder.py'))"
which will, basically, return the same
"~/rfnoc/srcr/uhd-fpga/usrp3/tools/scripts". If this is an issue, then we
definitely have to look further. Could you please tell me which commit are
you running?
-N
On Wed, May 17, 2017 at 11:35 PM, Jason Matusiak <
[email protected]> wrote:
> Yep. I don't get it.
>
>
> -------- Original message --------
> From: Nicolas Cuervo <[email protected]>
> Date: 5/17/17 4:21 PM (GMT-05:00)
> To: Jason Matusiak <[email protected]>
> Cc: "[email protected]" <[email protected]>
> Subject: Re: [USRP-users] uhd_image_builder using wrong directory
>
> Hello Jason,
>
> Please allow me to ask for clarification: So your question regards that
> you are running the image builder from
> "~/*rfnoc/*srcr/uhd-fpga/usrp3/tools/scripts"
> but the script is apparently running in "*~**/rfnoc_bu2/*src/uhd-fpga/
> usrp3/tools/scripts/"?
>
> -N
>
> On Wed, May 17, 2017 at 9:42 PM, Jason Matusiak via USRP-users <
> [email protected]> wrote:
>
>> I moved a directory instead of blowing it away and created a new ~/rfnoc
>> directory. So now I have ~/rfnoc and ~/rfnoc_bu2. Yet, when I go into
>> rfnoc and run uhd_image_builder_gui.py and add my new RFNoC OOT modules, I
>> get the following error:
>>
>> ./uhd_image_builder.py cpremoval freqShift axi_fifo_loopback fft -d x310
>> -t X310_RFNOC_HG
>> --Using the following blocks to generate image:
>> * cpremoval
>> * freqShift
>> * axi_fifo_loopback
>> * fft
>> Adding CE instantiation file for 'X310_RFNOC_HG'
>> changing temporarily working directory to /home/jmat/rfnoc_bu2/src/uhd-f
>> pga/usrp3/tools/scripts/../../top/x300
>> Setting up a 64-bit FPGA build environment for the USRP-X3x0...
>> - Vivado: Found (/opt/Xilinx/Vivado/2015.4/bin)
>> - Vivado HLS: Found (/opt/Xilinx/Vivado_HLS/2015.4/bin)
>>
>> Environment successfully initialized.
>> make -f Makefile.x300.inc bin NAME=X310_RFNOC_HG ARCH=kintex7
>> PART_ID=xc7k410t/ffg900/-2 BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1
>> RFNOC=1 X310=1 EXTRA_DEFS="BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1
>> RFNOC=1 X310=1"
>> make[1]: Entering directory `/home/jmat/rfnoc_bu2/src/uhd-
>> fpga/usrp3/top/x300'
>> /home/jmat/rfnoc_bu2/src/uhd-fpga/usrp3/top/x300/Makefile.srcs:14: ***
>> missing separator. Stop.
>> make[1]: Leaving directory `/home/jmat/rfnoc_bu2/src/uhd-
>> fpga/usrp3/top/x300'
>> make: *** [X310_RFNOC_HG] Error 2
>>
>> Any idea why it is somehow going to that old backup directory?....
>>
>> _______________________________________________
>> 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/20170517/fe5f1677/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 17 May 2017 19:26:04 -0700
From: Samuel Prager <[email protected]>
To: Ryan Marlow via USRP-users <[email protected]>
Subject: [USRP-users] E310 Rfnoc clocking guidelines/ performance
issues
Message-ID: <3c830729-e8b2-41f3-9190-2ddf9aa2200b@Spark>
Content-Type: text/plain; charset="utf-8"
Hello,
I have just begun developing an rfnoc based application for the E310/E312 and I
am running into a few performance issues. I have been using an X300 for a while
now but am new to the E310 and would really appreciate some pointers on
performance limits, configuration, etc.
I have built a custom fpga image with my noc block (originally developed for
and tested on the X300) and have loaded that as well as my custom build of uhd
onto the E312 using the method described in ?Software Development on the E310
and E312.? My noc block is a pulsed arbitrary waveform generator (AWG) and is
connected as:
AWG -> Radio TX -> Channel (30 dB attenuator, loopback) -> Radio RX -> Host
Radio Setup:
rate = 61.44e6
radio_ctrl->set_rate(rate);
radio_ctrl->set_rx_frequency(6e8, 0);
radio_ctrl->set_tx_frequency(6e8, 0);
The idea is to stream 4096 rx samples at the highest rate possible and then
wait a little while before sending another pulse.
Issue 1)
When I run the application, rfnoc appears to initialize correctly and I can
sr_read sr_write. However, after receiving one pulse (4096 samples), I begin to
see errors similar to:
Error: EnvironmentError: IOError: 0/Radio_0 user_reg_read64() failed:
EnvironmentError: IOError: [0/Radio_0] sr_read64() failed: EnvironmentError:
IOError: Block ctrl (CE_00_Port_10) packet parse error - EnvironmentError:
IOError: Expected packet index: 0 Received index: 890
If I do not read/write any FPGA registers before sending another pulse, I see
timeouts after a few thousand samples have been received.
I have tried changing the rate (as low as 1 MHz) and increasing the wait time
between pulses ? neither has any effect. After the first pulse, the usrp starts
to freeze up. I have also tried adding a FIFO block between the Radio RX and
host with no improvement.
Issue 2)
The data I am receiving in the analog loopback configuration is essentially
junk. However, if I set the ?loopback? register in the radio_core (SR_LOOPBACK
= 132), I receive the exact samples that are being send by the AWG with the
correct time coherence, etc. So the tx samples going out of the radio_core
appear to be correct.
Questions:
Are there additional uhd calls needed to setup the E310 RF frontend beyond what
is necessary for the X300?
I am sort of scratching my head here because I have been using noc_block on the
X300 successfully for a while and the E310 fpga image I built met timing, etc.
Are there any obvious culprits for this sort of behavior? My noc_block uses a
timekeeper (and the sync_in and pps signals on the X300). On the E310, however
there is no sync_in signal and the pps generation is different. Could this be
the source of the issues that I am seeing?
What is the proper way to set the gpsdo as the time and clock source for a
device3 based usrp? Is there anything analogous to what is used for multi_usrp
in the sync_to_gps.cpp example?
And lastly, is it possible to use a dma_fifo block directly on the E310? Or
does custom firmware have to be written in order to use the dram memory on
board?
Any guidance on these issues would be greatly appreciated.
For reference I have included the output of my test application:
linux; GNU C++ version 4.9.2; Boost_105700; UHD_4.0.0.rfnoc-devel-761-g0b0fab9b
Creating the usrp device with:
fpga=/usr/share/uhd/images/usrp_e310_fpga_rfnoc.bit...
-- Loading FPGA image: /usr/share/uhd/images/usrp_e310_fpga_rfnoc.bit... done
-- Detecting internal GPSDO .... found
-- Initializing core control (global registers)...
-- Performing register loopback test... pass
-- Initializing AD9361 using hard SPI core...OK
-- [RFNOC] ------- Block Setup -----------
-- [E300] Setting up dest map for host ep 0 to be stream 0
-- Setting up NoC-Shell Control for port #0 (SID: 00:00>02:10)...OK
-- Port 16: Found NoC-Block with ID 12AD100000000000.
-- Reading XML file: /home/root/usr/usr/share/uhd/rfnoc/blocks/radio_e3xx.xml
-- [E300] Setting up dest map for host ep 1 to be stream 1
-- Setting up NoC-Shell Control for port #1 (SID: 00:01>02:11)...OK
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /home/root/usr/usr/share/uhd/rfnoc/blocks/radio_e3xx.xml
-- [RFNoC Factory] Using controller key 'E3XXRadio' and block name 'Radio'
-- block_ctrl_base()
-- Reading XML file: /home/root/usr/usr/share/uhd/rfnoc/blocks/radio_e3xx.xml
-- Found valid blockdef
-- NOC ID: 0x12AD100000000000 Block ID: 0/Radio_0
-- [0/Radio_0] block_ctrl_base::clear()
-- [0/Radio_0] node_ctrl_base::clear()
-- [0/Radio_0] block_ctrl_base::_clear()
-- [0/Radio_0] block_ctrl_base::_clear()
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/0: type = 'sc16'
pkt_size = '0' vlen = '0'
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/in/1: type = 'sc16'
pkt_size = '0' vlen = '0'
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/0: type =
'sc16' pkt_size = '0' vlen = '0'
-- [0/Radio_0] Adding port definition at xbar/Radio_0/ports/out/1: type =
'sc16' pkt_size = '0' vlen = '0'
-- [RFNoC Radio] Performing register loopback test... pass
-- [RFNoC Radio] Performing register loopback test... pass
-- [0/Radio_0] radio_ctrl_impl::_update_spp(): Requested spp: 364
-- [0/Radio_0] radio_ctrl_impl::_update_spp(): Setting spp to: 364
-- [0/Radio_0] e3xx_radio_ctrl_impl::ctor()
-- Setting time source to internal
-- [0/Radio_0] e3xx_radio_ctrl_impl::_update_gpio_state()
-- [0/Radio_0] Creating internal GPIOs...
-- [0/Radio_0] Setting tick rate...
-- [RFNOC] ------- Block Setup -----------
-- [E300] Setting up dest map for host ep 2 to be stream 2
-- Setting up NoC-Shell Control for port #0 (SID: 00:02>02:20)...OK
-- Port 32: Found NoC-Block with ID F1F0000000000000.
-- Reading XML file: /home/root/usr/usr/share/uhd/rfnoc/blocks/fifo.xml
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /home/root/usr/usr/share/uhd/rfnoc/blocks/fifo.xml
-- [RFNoC Factory] Using controller key 'Block' and block name 'FIFO'
-- block_ctrl_base()
-- Reading XML file: /home/root/usr/usr/share/uhd/rfnoc/blocks/fifo.xml
-- Found valid blockdef
-- NOC ID: 0xF1F0000000000000 Block ID: 0/FIFO_0
-- [0/FIFO_0] block_ctrl_base::clear()
-- [0/FIFO_0] node_ctrl_base::clear()
-- [0/FIFO_0] block_ctrl_base::_clear()
-- [0/FIFO_0] Adding port definition at xbar/FIFO_0/ports/in/0: type = ''
pkt_size = '0' vlen = '0'
-- [0/FIFO_0] Adding port definition at xbar/FIFO_0/ports/out/0: type = ''
pkt_size = '0' vlen = '0'
-- [RFNOC] ------- Block Setup -----------
-- [E300] Setting up dest map for host ep 3 to be stream 3
-- Setting up NoC-Shell Control for port #0 (SID: 00:03>02:30)...OK
-- Port 48: Found NoC-Block with ID D053000000000000.
-- Reading XML file: /home/root/usr/usr/share/uhd/rfnoc/blocks/window.xml
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /home/root/usr/usr/share/uhd/rfnoc/blocks/window.xml
-- [RFNoC Factory] Using controller key 'Window' and block name 'Window'
-- block_ctrl_base()
-- Reading XML file: /home/root/usr/usr/share/uhd/rfnoc/blocks/window.xml
-- Found valid blockdef
-- NOC ID: 0xD053000000000000 Block ID: 0/Window_0
-- [0/Window_0] block_ctrl_base::clear()
-- [0/Window_0] node_ctrl_base::clear()
-- [0/Window_0] block_ctrl_base::_clear()
-- [0/Window_0] Adding port definition at xbar/Window_0/ports/in/0: type =
'sc16' pkt_size = '%vlen' vlen = '$spp'
-- [0/Window_0] Adding port definition at xbar/Window_0/ports/out/0: type =
'sc16' pkt_size = '%vlen' vlen = '$spp'
-- window_block::window_block() max_len ==4096
-- [0/Window_0] window_block::set_window()
-- [RFNOC] ------- Block Setup -----------
-- [E300] Setting up dest map for host ep 4 to be stream 4
-- Setting up NoC-Shell Control for port #0 (SID: 00:04>02:40)...OK
-- Port 64: Found NoC-Block with ID FF70000000000000.
-- Reading XML file: /home/root/usr/usr/share/uhd/rfnoc/blocks/fft.xml
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /home/root/usr/usr/share/uhd/rfnoc/blocks/fft.xml
-- [RFNoC Factory] Using controller key 'Block' and block name 'FFT'
-- block_ctrl_base()
-- Reading XML file: /home/root/usr/usr/share/uhd/rfnoc/blocks/fft.xml
-- Found valid blockdef
-- NOC ID: 0xFF70000000000000 Block ID: 0/FFT_0
-- [0/FFT_0] block_ctrl_base::clear()
-- [0/FFT_0] node_ctrl_base::clear()
-- [0/FFT_0] block_ctrl_base::_clear()
-- [0/FFT_0] Adding port definition at xbar/FFT_0/ports/in/0: type = 'sc16'
pkt_size = '%vlen' vlen = '$spp'
-- [0/FFT_0] Adding port definition at xbar/FFT_0/ports/out/0: type = '$otype'
pkt_size = '%vlen' vlen = '$spp'
-- [NocScript] Executing and asserting code: GE($spp, 16) AND LE($spp, 4096)
AND IS_PWR_OF_2($spp)
-- [NocScript] Executing and asserting code: SR_WRITE("FFT_SIZE_LOG2",
LOG2($spp)) AND SR_WRITE("AXIS_CONFIG_BUS", ADD(873472, LOG2($spp)))
-- [NocScript] Executing SR_WRITE()
-- [0/FFT_0] sr_write(FFT_SIZE_LOG2, 00000008) ==>
-- [NocScript] Executing SR_WRITE()
-- [0/FFT_0] sr_write(AXIS_CONFIG_BUS, 000D5408) ==>
-- [NocScript] Executing and asserting code: SR_WRITE("AXIS_CONFIG_BUS",
ADD($ctrl_word, LOG2($spp)))
-- [NocScript] Executing SR_WRITE()
-- [0/FFT_0] sr_write(AXIS_CONFIG_BUS, 000D5408) ==>
-- [NocScript] Executing and asserting code: EQUAL($otype, "sc16")
-- [NocScript] Executing and asserting code:
-- IF(NOT(EQUAL($reset, 0)), SR_WRITE("FFT_RESET", 1) AND SR_WRITE("FFT_RESET",
0))
--
-- [NocScript] Executing SR_WRITE()
-- [0/FFT_0] sr_write(FFT_RESET, 00000001) ==>
-- [NocScript] Executing SR_WRITE()
-- [0/FFT_0] sr_write(FFT_RESET, 00000000) ==>
-- [NocScript] Executing and asserting code: EQUAL($magnitude_out, "COMPLEX")
OR EQUAL($magnitude_out, "MAGNITUDE") OR EQUAL($magnitude_out,
"MAGNITUDE_SQUARED")
-- [NocScript] Executing and asserting code:
-- IF(EQUAL($magnitude_out, "COMPLEX"), SR_WRITE("MAGNITUDE_OUT", 0)) OR
-- IF(EQUAL($magnitude_out, "MAGNITUDE"), SR_WRITE("MAGNITUDE_OUT", 1)) OR
-- IF(EQUAL($magnitude_out, "MAGNITUDE_SQUARED"), SR_WRITE("MAGNITUDE_OUT", 2))
--
-- [NocScript] Executing SR_WRITE()
-- [0/FFT_0] sr_write(MAGNITUDE_OUT, 00000000) ==>
-- [RFNOC] ------- Block Setup -----------
-- [E300] Setting up dest map for host ep 5 to be stream 5
-- Setting up NoC-Shell Control for port #0 (SID: 00:05>02:50)...OK
-- Port 80: Found NoC-Block with ID DFA0000000000000.
-- Reading XML file: /home/root/usr/usr/share/uhd/rfnoc/blocks/wavegen.xml
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /home/root/usr/usr/share/uhd/rfnoc/blocks/wavegen.xml
-- [RFNoC Factory] Using controller key 'wavegen' and block name 'wavegen'
-- block_ctrl_base()
-- Reading XML file: /home/root/usr/usr/share/uhd/rfnoc/blocks/wavegen.xml
-- Found valid blockdef
-- NOC ID: 0xDFA0000000000000 Block ID: 0/wavegen_0
-- [0/wavegen_0] block_ctrl_base::clear()
-- [0/wavegen_0] node_ctrl_base::clear()
-- [0/wavegen_0] block_ctrl_base::_clear()
-- [0/wavegen_0] Adding port definition at xbar/wavegen_0/ports/in/0: type = ''
pkt_size = '0' vlen = '0'
-- [0/wavegen_0] Adding port definition at xbar/wavegen_0/ports/out/0: type =
'sc16' pkt_size = '0' vlen = '0'
-- [RFNOC] ------- Block Setup -----------
-- [E300] Setting up dest map for host ep 6 to be stream 6
-- Setting up NoC-Shell Control for port #0 (SID: 00:06>02:60)...OK
-- Port 96: Found NoC-Block with ID F1F0000000000000.
-- Reading XML file: /home/root/usr/usr/share/uhd/rfnoc/blocks/fifo.xml
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /home/root/usr/usr/share/uhd/rfnoc/blocks/fifo.xml
-- [RFNoC Factory] Using controller key 'Block' and block name 'FIFO'
-- block_ctrl_base()
-- Reading XML file: /home/root/usr/usr/share/uhd/rfnoc/blocks/fifo.xml
-- Found valid blockdef
-- NOC ID: 0xF1F0000000000000 Block ID: 0/FIFO_1
-- [0/FIFO_1] block_ctrl_base::clear()
-- [0/FIFO_1] node_ctrl_base::clear()
-- [0/FIFO_1] block_ctrl_base::_clear()
-- [0/FIFO_1] Adding port definition at xbar/FIFO_1/ports/in/0: type = ''
pkt_size = '0' vlen = '0'
-- [0/FIFO_1] Adding port definition at xbar/FIFO_1/ports/out/0: type = ''
pkt_size = '0' vlen = '0'
-- [RFNOC] ------- Block Setup -----------
-- [E300] Setting up dest map for host ep 7 to be stream 7
-- Setting up NoC-Shell Control for port #0 (SID: 00:07>02:70)...OK
-- Port 112: Found NoC-Block with ID F112000000000000.
-- Reading XML file: /home/root/usr/usr/share/uhd/rfnoc/blocks/fir.xml
-- [RFNoC Factory] block_ctrl_base::make()
-- Reading XML file: /home/root/usr/usr/share/uhd/rfnoc/blocks/fir.xml
-- [RFNoC Factory] Using controller key 'FIR' and block name 'FIR'
-- block_ctrl_base()
-- Reading XML file: /home/root/usr/usr/share/uhd/rfnoc/blocks/fir.xml
-- Found valid blockdef
-- NOC ID: 0xF112000000000000 Block ID: 0/FIR_0
-- [0/FIR_0] block_ctrl_base::clear()
-- [0/FIR_0] node_ctrl_base::clear()
-- [0/FIR_0] block_ctrl_base::_clear()
-- [0/FIR_0] Adding port definition at xbar/FIR_0/ports/in/0: type = 'sc16'
pkt_size = '0' vlen = '0'
-- [0/FIR_0] Adding port definition at xbar/FIR_0/ports/out/0: type = 'sc16'
pkt_size = '0' vlen = '0'
-- fir_block::fir_block() n_taps ==41
-- [0/FIR_0] fir_block::set_taps()
-- Initializing Radio Block...
-- Performing CODEC loopback test... pass
-- Performing CODEC loopback test... pass
-- [0/Radio_0] e3xx_radio_ctrl_impl::_update_enables()
-- [0/Radio_0] e3xx_radio_ctrl_impl::_update_gpio_state()
-- Asking for clock rate 16 MHz
-- Actually got clock rate 16 MHz
-- Performing timer loopback test... pass
-- [0/Radio_0] e3xx_radio_ctrl_impl::_update_enables()
-- [0/Radio_0] e3xx_radio_ctrl_impl::_update_gpio_state()
-- end of e300_impl()
Setting RX Rate: 16.000000 Msps...
-- Asking for clock rate 16 MHz
-- Actually got clock rate 16 MHz
-- Performing timer loopback test... pass
-- [0/Radio_0] e3xx_radio_ctrl_impl::_update_enables()
-- [0/Radio_0] e3xx_radio_ctrl_impl::_update_gpio_state()
Actual RX Rate: 16.000000 Msps...
Setting RX Freq: 600.000000 MHz...
Actual RX Freq: 600.000000 MHz...
Actual TX Freq: 600.000000 MHz...
Setting RX Gain: 0.000000 dB...
Actual RX Gain: 0.000000 dB...
Setting TX Gain: 0.000000 dB...
Actual TX Gain: 0.000000 dB...
-- [0/Radio_0] radio_ctrl_impl::my_set_loopback_reg() 0 0
-- [0/Radio_0] block_ctrl_base::clear()
-- [0/Radio_0] node_ctrl_base::clear()
-- [0/Radio_0] block_ctrl_base::_clear()
-- [0/Radio_0] block_ctrl_base::_clear()
-- [0/FIFO_0] block_ctrl_base::clear()
-- [0/FIFO_0] node_ctrl_base::clear()
-- [0/FIFO_0] block_ctrl_base::_clear()
-- [0/Window_0] block_ctrl_base::clear()
-- [0/Window_0] node_ctrl_base::clear()
-- [0/Window_0] block_ctrl_base::_clear()
-- [0/FFT_0] block_ctrl_base::clear()
-- [0/FFT_0] node_ctrl_base::clear()
-- [0/FFT_0] block_ctrl_base::_clear()
-- [0/wavegen_0] block_ctrl_base::clear()
-- [0/wavegen_0] node_ctrl_base::clear()
-- [0/wavegen_0] block_ctrl_base::_clear()
-- [0/FIFO_1] block_ctrl_base::clear()
-- [0/FIFO_1] node_ctrl_base::clear()
-- [0/FIFO_1] block_ctrl_base::_clear()
-- [0/FIR_0] block_ctrl_base::clear()
-- [0/FIR_0] node_ctrl_base::clear()
-- [0/FIR_0] block_ctrl_base::_clear()
+-------------+ +-----------+ +----------+ +------+
| 0/wavegen_0 |==>| 0/Radio_0 |==>| 0/FIFO_0 |==>| HOST |
+-------------+ +-----------+ +----------+ +------+
Setting AWG Policy to Manual for Setup...
-- [0/wavegen_0] wavegen_block::set_policy_manual()
-- [0/wavegen_0] wavegen_block::set_policy_fwd_time()
-- [0/wavegen_0] wavegen_block::set_policy_no_cmd()
AWG Policy set to: UNKNOWN:3 DEFAULT MANUAL
-- [0/wavegen_0] wavegen_block::set_ctrl_word()
Src Ctrl set to: UNKNOWN:0 DEFAULT CHIRP
-- [0/wavegen_0] wavegen_block::set_chirp_counter()
-- [0/wavegen_0] wavegen_block::set_chirp_tuning_coef()
-- [0/wavegen_0] wavegen_block::set_chirp_freq_offset()
Checking Uploaded Waveform Length
Uploaded Waveform Length set to: 3840
-- [0/wavegen_0] wavegen_block::set_num_adc_samples()
-- [0/wavegen_0] wavegen_block::set_prf_count()
AWG PRF set to: 32000000(2 sec)
Connecting blocks...
-- [tx_graph] Connecting 0/wavegen_0:0 --> 0/Radio_0:0
-- [0/wavegen_0] source_block_ctrl_base::set_destination() 2.80>2.16
-- [0/wavegen_0] Setting SID: 2.80>2.16
-- Assuming max packet size for 0/wavegen_0
-- [0/wavegen_0] source_block_ctrl_base::configure_flow_control_out()
buf_size_pkts==8
-- [0/Radio_0] sink_block_ctrl_base::configure_flow_control_in(cycles=0,
packets=2)
-- [rx_graph] Connecting 0/Radio_0:0 --> 0/FIFO_0:0
-- [0/Radio_0] source_block_ctrl_base::set_destination() 2.16>2.32
-- [0/Radio_0] Setting SID: 2.16>2.32
-- Assuming max packet size for 0/Radio_0
-- [0/Radio_0] source_block_ctrl_base::configure_flow_control_out()
buf_size_pkts==2
-- [0/FIFO_0] sink_block_ctrl_base::configure_flow_control_in(cycles=0,
packets=1)
-- Samples per packet: 364
-- Using streamer args: block_id=FIFO_0,spp=364
-- [RX Streamer] chan 0 connecting to 0/FIFO_0
-- [RX Streamer] creating rx stream max_recv_window=32
-- [E300] Setting up dest map for host ep 8 to be stream 8
-- [RX Streamer] data_sid = 00:08>02:20 actual recv_buff_size = 131072
-- [0/FIFO_0] source_block_ctrl_base::set_destination() 0.0>0.8
-- [0/FIFO_0] Setting SID: 2.32>0.8
-- [RX Streamer] resp_out_dst_sid == 8
-- [RX Streamer] Number of upstream radio nodes: 1
-- [RX Streamer] spp == 364
-- [RX Streamer] Flow Control Window (minus one) = 31, Flow Control Handler
Window = 6
-- [0/FIFO_0] source_block_ctrl_base::configure_flow_control_out()
buf_size_pkts==31
-- [RX Terminator 0] rx_stream_terminator::set_rx_streamer() 1
-- [0/FIFO_0] source_node_ctrl::set_rx_streamer() 0 -> 1
-- [0/Radio_0] radio_ctrl_impl::set_rx_streamer() 0 -> 1
-- [0/Radio_0] e3xx_radio_ctrl_impl::_update_enables()
-- [0/Radio_0] e3xx_radio_ctrl_impl::_update_gpio_state()
-- [Device3] updating RX streamer to RX Terminator 0
-- New tick_rate == 1.6e+07 New samp_rate == 1.6e+07 New scaling == 3.05185e-05
-- [0/wavegen_0] wavegen_block::set_waveform()
Waveform Sent: 3584 samples
-- [0/wavegen_0] wavegen_block::set_ctrl_word()
-- [0/Radio_0] radio_ctrl_impl::my_set_loopback_reg() 0 1
Issuing start stream cmd
-- [0/wavegen_0] wavegen_block::send_pulse(ticks)
-- [0/FIFO_0] source_block_ctrl_base::issue_stream_cmd()
-- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() 0 d
[initRxStream()] timed pulse sent with ticks: 2170117
Done
Received 3840/3840 samples in 0.000017 seconds
225.882353 Msps
Issuing start stream cmd
Error: EnvironmentError: IOError: 0/Radio_0 user_reg_read64() failed:
EnvironmentError: IOError: [0/Radio_0] sr_read64() failed: EnvironmentError:
IOError: Block ctrl (CE_00_Port_10) packet parse error - EnvironmentError:
IOError: Expected packet index: 0 Received index: 882
Thank you,
Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170517/1d5f18be/attachment-0001.html>
------------------------------
Message: 13
Date: Thu, 18 May 2017 16:02:32 +0800 (CST)
From: Bob <[email protected]>
To: [email protected]
Subject: [USRP-users] About the speed of the received signal of "file
sink", what factors affect it?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="gbk"
Hello,
Fig.1
fig.2
Under the same experimental conditions, Figure 1 can get a complete signal, but
Figure 2 can only get a part. For example, the signal sent by the 200 MB,
Figure 1 obtained data is 200 MB, and Figure 2 only 10 MB or so, why is this?
Figure 2 has more modules than the fig.1, whether the processing speed of these
modules affect the speed of the received signal of "file sink", if we want to
receive as many signals, how to do it?
In GNU Radio, we build a system, firstly, we save the signal in a file, at the
same time, read the data from the same file to process, you can do so? If it
can, which block can be achieved?
Thank you very much for your answers. I am looking forward to your reply as
soon as possible and as detailed as possible.
Thanks!
Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170518/660166e8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ??1.png
Type: image/png
Size: 69949 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170518/660166e8/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ??2.png
Type: image/png
Size: 122404 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170518/660166e8/attachment-0003.png>
------------------------------
Message: 14
Date: Thu, 18 May 2017 13:51:50 +0500
From: Ammar Mahmood <[email protected]>
To: [email protected]
Subject: [USRP-users] Making NI USRP 2943R work with GNU Radio
Message-ID:
<CAOZxRwgYr0Gv3ernJskFHM_=me4d--k=XdT2ZgFw_e3c=-v...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
I want to make NI USRP 2943R work with GNU Radio Companion. Can anybody
guide me regarding the appropriate images required in order to achieve this
task?
-Ammar
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170518/fa060496/attachment-0001.html>
------------------------------
Message: 15
Date: Thu, 18 May 2017 11:00:49 +0200
From: Sumit Kumar <[email protected]>
To: "Gilad Beeri (ApolloShield)" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Using B210 TX/RX in TDD mode
Message-ID:
<caoextctrh4pwbcktdhc6_f56vq5wf6cbnwohrrhjmwtwulu...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Yes this is precisely what I want but the link discussion is dead it seems !
On Tue, May 9, 2017 at 3:14 PM, Gilad Beeri (ApolloShield) <
[email protected]> wrote:
> I think that the recent post http://lists.ettus.com/
> pipermail/usrp-users_lists.ettus.com/2017-May/024831.html
> references what you're asking about
>
> On Tue, May 9, 2017 at 1:34 PM Sumit Kumar via USRP-users <
> [email protected]> wrote:
>
>>
>> Hi,
>>
>> Are there examples/ discussion where I can see TX/RX port is used in a
>> TDD fashion.
>>
>> I want to pause my 802.11 receiver thread on some condition, transmit the
>> acknowledgment frame and then wake up the receiver thread again. And I want
>> to do this using single antenna port i.e. TX/RX.
>>
>> Is there some internal switch which is required to be controlled for this
>> ?
>>
>> Regards
>> --
>> --
>> Sumit kumar
>> Doctoral Student, UPMC
>> Eurecom, BIOT
>> France
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
--
--
Sumit kumar
Doctoral Student, UPMC
Eurecom, BIOT
France
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170518/24379ae4/attachment-0001.html>
------------------------------
Message: 16
Date: Thu, 18 May 2017 11:01:50 +0200
From: Sumit Kumar <[email protected]>
To: Michael West <[email protected]>
Cc: "Gilad Beeri (ApolloShield)" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] Using B210 TX/RX in TDD mode
Message-ID:
<caoextcqug55vksv-ma54wm1s9j06nu49dnq5wb7s2umxyq7...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Do we have any code snippet or example which hints on how to do this.
Sumit
On Tue, May 16, 2017 at 8:39 PM, Michael West <[email protected]>
wrote:
> Hi Sumit,
>
> The best approach is to do continuous receive and transmit just when you
> want. The RF switch prioritizes TX over RX. Using time_specs in the
> metadata, you can just discard the RX samples received during the TX.
>
> Regards,
> Michael
>
> On Tue, May 9, 2017 at 6:14 AM, Gilad Beeri (ApolloShield) via USRP-users
> <[email protected]> wrote:
>
>> I think that the recent post http://lists.ettus.com/pi
>> permail/usrp-users_lists.ettus.com/2017-May/024831.html
>> references what you're asking about
>>
>> On Tue, May 9, 2017 at 1:34 PM Sumit Kumar via USRP-users <
>> [email protected]> wrote:
>>
>>>
>>> Hi,
>>>
>>> Are there examples/ discussion where I can see TX/RX port is used in a
>>> TDD fashion.
>>>
>>> I want to pause my 802.11 receiver thread on some condition, transmit
>>> the acknowledgment frame and then wake up the receiver thread again. And I
>>> want to do this using single antenna port i.e. TX/RX.
>>>
>>> Is there some internal switch which is required to be controlled for
>>> this ?
>>>
>>> Regards
>>> --
>>> --
>>> Sumit kumar
>>> Doctoral Student, UPMC
>>> Eurecom, BIOT
>>> France
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
--
--
Sumit kumar
Doctoral Student, UPMC
Eurecom, BIOT
France
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170518/acee53a7/attachment-0001.html>
------------------------------
Message: 17
Date: Thu, 18 May 2017 11:17:18 +0200
From: Sumit Kumar <[email protected]>
To: Michael West <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Using B210 TX/RX in TDD mode
Message-ID:
<caoextcrtknhtwpuhg+0_9ns6z_bq72oomaaqs47aev+8jre...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Michael,
I have to do exactly what you said i.e. continuous receive (802.11g packets
reception) and occasional transmits (send the ACK when CRC passes).
Regards
Sumit
On Tue, May 16, 2017 at 8:39 PM, Michael West <[email protected]>
wrote:
> Hi Sumit,
>
> The best approach is to do continuous receive and transmit just when you
> want. The RF switch prioritizes TX over RX. Using time_specs in the
> metadata, you can just discard the RX samples received during the TX.
>
> Regards,
> Michael
>
> On Tue, May 9, 2017 at 6:14 AM, Gilad Beeri (ApolloShield) via USRP-users
> <[email protected]> wrote:
>
>> I think that the recent post http://lists.ettus.com/pi
>> permail/usrp-users_lists.ettus.com/2017-May/024831.html
>> references what you're asking about
>>
>> On Tue, May 9, 2017 at 1:34 PM Sumit Kumar via USRP-users <
>> [email protected]> wrote:
>>
>>>
>>> Hi,
>>>
>>> Are there examples/ discussion where I can see TX/RX port is used in a
>>> TDD fashion.
>>>
>>> I want to pause my 802.11 receiver thread on some condition, transmit
>>> the acknowledgment frame and then wake up the receiver thread again. And I
>>> want to do this using single antenna port i.e. TX/RX.
>>>
>>> Is there some internal switch which is required to be controlled for
>>> this ?
>>>
>>> Regards
>>> --
>>> --
>>> Sumit kumar
>>> Doctoral Student, UPMC
>>> Eurecom, BIOT
>>> France
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
--
--
Sumit kumar
Doctoral Student, UPMC
Eurecom, BIOT
France
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170518/6ce0d4fb/attachment-0001.html>
------------------------------
Message: 18
Date: Thu, 18 May 2017 05:40:21 -0700
From: Neel Pandeya <[email protected]>
To: Ammar Mahmood <[email protected]>
Cc: usrp-users <[email protected]>
Subject: Re: [USRP-users] Making NI USRP 2943R work with GNU Radio
Message-ID:
<CACaXmv_VMYEYgRKMLPVGWOXq1NKZ13D+wW=vu9A=csran-p...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hello Ammar:
You will first need to set up the toolchain on the host (see the link
below), and then download the FPGA images by running the
"uhd_images_downloader" utility, and then flash the FPGA image onto the
USRP using the "usrp_x3xx_fpga_burner" utility. Once that's done, try
running "uhd_find_devices" and "uhd_usrp_probe" to verify that the host can
communicate with the radio.
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux
Please let me know if you have any further questions.
--?Neel Pandeya
On 18 May 2017 at 01:51, Ammar Mahmood via USRP-users <
[email protected]> wrote:
> Hi all,
>
> I want to make NI USRP 2943R work with GNU Radio Companion. Can anybody
> guide me regarding the appropriate images required in order to achieve this
> task?
>
>
> -Ammar
>
> _______________________________________________
> 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/20170518/e06a1ebd/attachment-0001.html>
------------------------------
Message: 19
Date: Thu, 18 May 2017 09:04:11 -0400
From: Jason Matusiak <[email protected]>
To: Nicolas Cuervo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] uhd_image_builder using wrong directory
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Nicolas,
Agreed (on it being completely odd)! I ran the command and it is
running right. I am not sure what I've done now, but I can't even get
the gui to open anymore. I think I am having a python issue, but I am
not sure how I got out of whack. When I try to run the GUI this
morning, it gives me a lot of errors like:
Widget::paintEngine: Should no longer be called
QPainter::begin: Paint device returned engine == 0, type: 1
QWidget::paintEngine: Should no longer be called
QPainter::begin: Paint device returned engine == 0, type: 1
QWidget::paintEngine: Should no longer be called
QPainter::begin: Paint device returned engine == 0, type: 1
QWidget::paintEngine: Should no longer be called
QPainter::begin: Paint device returned engine == 0, type: 1
QWidget::paintEngine: Should no longer be called
QPainter::begin: Paint device returned engine == 0, type: 1
QPainter::pen: Painter not active
QPainter::setPen: Painter not active
QPainter::setPen: Painter not active
QWidget::paintEngine: Should no longer be called
QPainter::begin: Paint device returned engine == 0, type: 1
QPainter::pen: Painter not active
QPainter::setPen: Painter not active
QPainter::setPen: Painter not active
QWidget::paintEngine: Should no longer be called
QPainter::begin: Paint device returned engine == 0, type: 1
I believe I got down this path because the GUI started complaining about
QT5 at some point, which means that the switch to Py3 occured I guess.
I can't tell where things are out of whack now.
uhd-fpga is git commit 74d14 on the rfnoc-devel branch.
Thanks!!!
On 05/17/2017 05:53 PM, Nicolas Cuervo wrote:
> Hmm, this is completely odd.
>
> basically the working directory, as you can see in the code, is taken
> relative to the location of the script that is currently running.
> While being in the directory that contains the script (which from your
> information I assume it is
> "~/*rfnoc/*srcr/uhd-fpga/usrp3/tools/scripts"), you can check the
> path in the terminal by running the same method that is used in the
> code as follows:
>
> $ python -c "import os ; print
> os.path.dirname(os.path.realpath('./uhd_image_builder.py'))"
>
> which will, basically, return the same
> "~/rfnoc/srcr/uhd-fpga/usrp3/tools/scripts". If this is an issue, then
> we definitely have to look further. Could you please tell me which
> commit are you running?
>
> -N
>
> On Wed, May 17, 2017 at 11:35 PM, Jason Matusiak
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> Yep. I don't get it.
>
>
> -------- Original message --------
> From: Nicolas Cuervo <[email protected]
> <mailto:[email protected]>>
> Date: 5/17/17 4:21 PM (GMT-05:00)
> To: Jason Matusiak <[email protected]
> <mailto:[email protected]>>
> Cc: "[email protected]
> <mailto:[email protected]>" <[email protected]
> <mailto:[email protected]>>
> Subject: Re: [USRP-users] uhd_image_builder using wrong directory
>
> Hello Jason,
>
> Please allow me to ask for clarification: So your question regards
> that you are running the image builder from
> "~/*rfnoc/*srcr/uhd-fpga/usrp3/tools/scripts" but the script is
> apparently running in
> "*~**/rfnoc_bu2/*src/uhd-fpga/usrp3/tools/scripts/"?
>
> -N
>
> On Wed, May 17, 2017 at 9:42 PM, Jason Matusiak via USRP-users
> <[email protected] <mailto:[email protected]>>
> wrote:
>
> I moved a directory instead of blowing it away and created a
> new ~/rfnoc directory. So now I have ~/rfnoc and
> ~/rfnoc_bu2. Yet, when I go into rfnoc and run
> uhd_image_builder_gui.py and add my new RFNoC OOT modules, I
> get the following error:
>
> ./uhd_image_builder.py cpremoval freqShift axi_fifo_loopback
> fft -d x310 -t X310_RFNOC_HG
> --Using the following blocks to generate image:
> * cpremoval
> * freqShift
> * axi_fifo_loopback
> * fft
> Adding CE instantiation file for 'X310_RFNOC_HG'
> changing temporarily working directory to
> /home/jmat/rfnoc_bu2/src/uhd-fpga/usrp3/tools/scripts/../../top/x300
> Setting up a 64-bit FPGA build environment for the USRP-X3x0...
> - Vivado: Found (/opt/Xilinx/Vivado/2015.4/bin)
> - Vivado HLS: Found (/opt/Xilinx/Vivado_HLS/2015.4/bin)
>
> Environment successfully initialized.
> make -f Makefile.x300.inc bin NAME=X310_RFNOC_HG ARCH=kintex7
> PART_ID=xc7k410t/ffg900/-2 BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1
> SFP1_10GBE=1 RFNOC=1 X310=1 EXTRA_DEFS="BUILD_1G=1 BUILD_10G=1
> SFP0_1GBE=1 SFP1_10GBE=1 RFNOC=1 X310=1"
> make[1]: Entering directory
> `/home/jmat/rfnoc_bu2/src/uhd-fpga/usrp3/top/x300'
> /home/jmat/rfnoc_bu2/src/uhd-fpga/usrp3/top/x300/Makefile.srcs:14:
> *** missing separator. Stop.
> make[1]: Leaving directory
> `/home/jmat/rfnoc_bu2/src/uhd-fpga/usrp3/top/x300'
> make: *** [X310_RFNOC_HG] Error 2
>
> Any idea why it is somehow going to that old backup directory?....
>
> _______________________________________________
> USRP-users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> <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/20170518/7b98e3e7/attachment-0001.html>
------------------------------
Message: 20
Date: Thu, 18 May 2017 15:25:55 +0200
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] About the speed of the received signal of
"file sink", what factors affect it?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Bob,
have you watched the console output? Do "O" appear there?
Also, what USRP? 100kS/s is really, really slow, and most USRPs *do not*
support that rate.
Your second flow grph has a lot more blocks in it, and some of them
aren't known to me, so nobody but the author of these blocks, or you,
investigating their behaviour, can tell you what they do, and whether
they stop the flow graph early.
Best regards,
Marcus
On 18.05.2017 10:02, Bob via USRP-users wrote:
>
>
> Hello,
> Fig.1
> fig.2
> Under the same experimental conditions, Figure 1 can get a complete
> signal, but Figure 2 can only get a part. For example, the signal sent
> by the 200 MB, Figure 1 obtained data is 200 MB, and Figure 2 only 10
> MB or so, why is this?
> Figure 2 has more modules than the fig.1, whether the processing speed
> of these modules affect the speed of the received signal of "file
> sink", if we want to receive as many signals, how to do it?
> In GNU Radio, we build a system, firstly, we save the signal in a
> file, at the same time, read the data from the same file to process,
> you can do so? If it can, which block can be achieved?
>
> Thank you very much for your answers. I am looking forward to your
> reply as soon as possible and as detailed as possible.
> Thanks!
>
> Bob
>
>
>
>
>
>
>
> _______________________________________________
> 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/20170518/05b8f1b4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 69949 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170518/05b8f1b4/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 122404 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170518/05b8f1b4/attachment-0003.png>
------------------------------
Message: 21
Date: Thu, 18 May 2017 15:55:52 +0200
From: Nicolas Cuervo <[email protected]>
To: Jason Matusiak <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] uhd_image_builder using wrong directory
Message-ID:
<CAOuPCvj0XMz=cfju3ptsh2r_ftr_zht1hyzf7+ckd9ibtkj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
(On the run I miss clicked and didn't respond to the list, sorry about
that. Resending:)
Hello Jason,
I'll have to give a deeper look on the path-call. It seems that you are
running a recent commit. We did changed the GUI to Pyqt5 as a preparation
for python3 (so you have to install Pyqt5). However, after installing this,
the GUI should work for Python2 and 3 as well.
-N
On Thu, May 18, 2017 at 3:04 PM, Jason Matusiak <
[email protected]> wrote:
> Nicolas,
>
> Agreed (on it being completely odd)! I ran the command and it is running
> right. I am not sure what I've done now, but I can't even get the gui to
> open anymore. I think I am having a python issue, but I am not sure how I
> got out of whack. When I try to run the GUI this morning, it gives me a
> lot of errors like:
> Widget::paintEngine: Should no longer be called
> QPainter::begin: Paint device returned engine == 0, type: 1
> QWidget::paintEngine: Should no longer be called
> QPainter::begin: Paint device returned engine == 0, type: 1
> QWidget::paintEngine: Should no longer be called
> QPainter::begin: Paint device returned engine == 0, type: 1
> QWidget::paintEngine: Should no longer be called
> QPainter::begin: Paint device returned engine == 0, type: 1
> QWidget::paintEngine: Should no longer be called
> QPainter::begin: Paint device returned engine == 0, type: 1
> QPainter::pen: Painter not active
> QPainter::setPen: Painter not active
> QPainter::setPen: Painter not active
> QWidget::paintEngine: Should no longer be called
> QPainter::begin: Paint device returned engine == 0, type: 1
> QPainter::pen: Painter not active
> QPainter::setPen: Painter not active
> QPainter::setPen: Painter not active
> QWidget::paintEngine: Should no longer be called
> QPainter::begin: Paint device returned engine == 0, type: 1
>
> I believe I got down this path because the GUI started complaining about
> QT5 at some point, which means that the switch to Py3 occured I guess. I
> can't tell where things are out of whack now.
>
> uhd-fpga is git commit 74d14 on the rfnoc-devel branch.
>
> Thanks!!!
>
>
> On 05/17/2017 05:53 PM, Nicolas Cuervo wrote:
>
> Hmm, this is completely odd.
>
> basically the working directory, as you can see in the code, is taken
> relative to the location of the script that is currently running. While
> being in the directory that contains the script (which from your
> information I assume it is "~/*rfnoc/*srcr/uhd-fpga/usrp3/tools/scripts"),
> you can check the path in the terminal by running the same method that is
> used in the code as follows:
>
> $ python -c "import os ; print os.path.dirname(os.path.
> realpath('./uhd_image_builder.py'))"
>
> which will, basically, return the same
> "~/rfnoc/srcr/uhd-fpga/usrp3/tools/scripts".
> If this is an issue, then we definitely have to look further. Could you
> please tell me which commit are you running?
>
> -N
>
> On Wed, May 17, 2017 at 11:35 PM, Jason Matusiak <
> [email protected]> wrote:
>
>> Yep. I don't get it.
>>
>>
>> -------- Original message --------
>> From: Nicolas Cuervo <[email protected]>
>> Date: 5/17/17 4:21 PM (GMT-05:00)
>> To: Jason Matusiak <[email protected]>
>> Cc: "[email protected]" <[email protected]>
>> Subject: Re: [USRP-users] uhd_image_builder using wrong directory
>>
>> Hello Jason,
>>
>> Please allow me to ask for clarification: So your question regards that
>> you are running the image builder from
>> "~/*rfnoc/*srcr/uhd-fpga/usrp3/tools/scripts"
>> but the script is apparently running in "*~**/rfnoc_bu2/*src/uhd-f
>> pga/usrp3/tools/scripts/"?
>>
>> -N
>>
>> On Wed, May 17, 2017 at 9:42 PM, Jason Matusiak via USRP-users <
>> [email protected]> wrote:
>>
>>> I moved a directory instead of blowing it away and created a new ~/rfnoc
>>> directory. So now I have ~/rfnoc and ~/rfnoc_bu2. Yet, when I go into
>>> rfnoc and run uhd_image_builder_gui.py and add my new RFNoC OOT modules, I
>>> get the following error:
>>>
>>> ./uhd_image_builder.py cpremoval freqShift axi_fifo_loopback fft -d x310
>>> -t X310_RFNOC_HG
>>> --Using the following blocks to generate image:
>>> * cpremoval
>>> * freqShift
>>> * axi_fifo_loopback
>>> * fft
>>> Adding CE instantiation file for 'X310_RFNOC_HG'
>>> changing temporarily working directory to /home/jmat/rfnoc_bu2/src/uhd-f
>>> pga/usrp3/tools/scripts/../../top/x300
>>> Setting up a 64-bit FPGA build environment for the USRP-X3x0...
>>> - Vivado: Found (/opt/Xilinx/Vivado/2015.4/bin)
>>> - Vivado HLS: Found (/opt/Xilinx/Vivado_HLS/2015.4/bin)
>>>
>>> Environment successfully initialized.
>>> make -f Makefile.x300.inc bin NAME=X310_RFNOC_HG ARCH=kintex7
>>> PART_ID=xc7k410t/ffg900/-2 BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1
>>> RFNOC=1 X310=1 EXTRA_DEFS="BUILD_1G=1 BUILD_10G=1 SFP0_1GBE=1 SFP1_10GBE=1
>>> RFNOC=1 X310=1"
>>> make[1]: Entering directory `/home/jmat/rfnoc_bu2/src/uhd-
>>> fpga/usrp3/top/x300'
>>> /home/jmat/rfnoc_bu2/src/uhd-fpga/usrp3/top/x300/Makefile.srcs:14: ***
>>> missing separator. Stop.
>>> make[1]: Leaving directory `/home/jmat/rfnoc_bu2/src/uhd-
>>> fpga/usrp3/top/x300'
>>> make: *** [X310_RFNOC_HG] Error 2
>>>
>>> Any idea why it is somehow going to that old backup directory?....
>>>
>>> _______________________________________________
>>> 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/20170518/83df97ac/attachment-0001.html>
------------------------------
Message: 22
Date: Thu, 18 May 2017 09:57:49 +0000
From: Jane Abad Jaume <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] E310 Cross-Compiled UHD Error - key "product"
not found
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi,
I'm trying to cross-compile the UHD for the E310 in a Ubuntu before
cross-compiling OOT custom blocks.
I've followed the instructions of
https://kb.ettus.com/Software_Development_on_the_E310_and_E312. I've
successfully mounted the prefix into the embedded device and set-up the
enviroment variables with set_env.
But when I run uhd_usrp_probe or any other example, it always returns
Error: LookupError: KeyError: key "product" not found in dict(Ss, Ss).
How can I solve that?
Thanks!
Regards,
Jaume
## COMMANDS
root@ettus-e3xx-sg3:~/usr/usr# cat set_env
LOCALPREFIX=~/usr/usr
export PATH=$LOCALPREFIX/bin:$PATH
export LD_LOAD_LIBRARY=$LOCALPREFIX/lib:$LD_LOAD_LIBRARY
export LD_LIBRARY_PATH=$LOCALPREFIX/lib:$LD_LIBRARY_PATH
export PYTHONPATH=$LOCALPREFIX/lib/python2.7/site-packages:$PYTHONPATH
export PKG_CONFIG_PATH=$LOCALPREFIX/lib/pkgconfig:$PKG_CONFIG_PATH
export
GRC_BLOCKS_PATH=$LOCALPREFIX/share/gnuradio/grc/blocks:$GRC_BLOCKS_PATH
export UHD_RFNOC_DIR=$LOCALPREFIX/share/uhd/rfnoc/
export UHD_IMAGES_DIR=$LOCALPREFIX/share/uhd/images
root@ettus-e3xx-sg3:~/usr/usr/lib/uhd/examples# which uhd_find_devices
/home/root/usr/usr/bin/uhd_find_devices
root@ettus-e3xx-sg3:~/usr/usr/lib/uhd/examples# uhd_find_devices
[INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700;
UHD_4.0.0.rfnoc-devel-316-g24b98579
--------------------------------------------------
-- UHD Device 0
--------------------------------------------------
Device Address:
serial:
name:
node: /dev/axi_fpga
type: e3x0
root@ettus-e3xx-sg3:~/usr/usr/lib/uhd/examples# uhd_usrp_probe
[INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700;
UHD_4.0.0.rfnoc-devel-316-g24b98579
Error: LookupError: KeyError: key "product" not found in dict(Ss, Ss)
## SD IMAGE BUILD VERSION
root@ettus-e3xx-sg3:~# cat /etc/version-image
Timestamp: 201601150121
Release: Release-4
Image: gnuradio-dev-image
root@ettus-e3xx-sg3:~# cat /etc/build
-----------------------
Build Configuration: |
-----------------------
DISTRO = nodistro
DISTRO_VERSION = nodistro.0
-----------------------
Layer Revisions: |
-----------------------
meta = (nobranch):9f339f516ab03d598fae0e536b3a420ea4d8ee1a
e100-bsp =
(detachedfrom40cf300):40cf300296b889df5b8445bf7db457c160220919
e300-bsp =
(detachedfrom40cf300):40cf300296b889df5b8445bf7db457c160220919
common =
(detachedfrom40cf300):40cf300296b889df5b8445bf7db457c160220919
meta-xilinx = (nobranch):13779b9254bab450875a60ed8f21edd0e8876a71
meta-oe = (nobranch):e8a8e0be8e39dbb949bf0f0df90abe1c4e3f6470
meta-networking = (nobranch):e8a8e0be8e39dbb949bf0f0df90abe1c4e3f6470
meta-python = (nobranch):e8a8e0be8e39dbb949bf0f0df90abe1c4e3f6470
meta-filesystems = (nobranch):e8a8e0be8e39dbb949bf0f0df90abe1c4e3f6470
meta-sdr =
(detachedfrom3d06bc0):3d06bc06e874dc3b8db64fc1bf838763f834d193
________________________________
Ce message et toutes les pi?ces jointes (ci-apr?s le "message") sont ?tablis ?
l'intention exclusive de ses destinataires et sont confidentiels. Si vous
recevez ce message par erreur ou s'il ne vous est pas destin?, merci de le
d?truire ainsi que toute copie de votre syst?me et d'en avertir imm?diatement
l'exp?diteur. Toute lecture non autoris?e, toute utilisation de ce message qui
n'est pas conforme ? sa destination, toute diffusion ou toute publication,
totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer
l'int?grit? de ce message ?lectronique susceptible d'alt?ration, l?exp?diteur
(et ses filiales) d?cline(nt) toute responsabilit? au titre de ce message dans
l'hypoth?se o? il aurait ?t? modifi? ou falsifi?.
This message and any attachments (the "message") is intended solely for the
intended recipient(s) and is confidential. If you receive this message in
error, or are not the intended recipient(s), please delete it and any copies
from your systems and immediately notify the sender. Any unauthorized view, use
that does not comply with its purpose, dissemination or disclosure, either
whole or partial, is prohibited. Since the internet cannot guarantee the
integrity of this message which may not be reliable, the sender (and its
subsidiaries) shall not be liable for the message if modified or falsified.
------------------------------
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 81, Issue 18
******************************************
