Re: [USRP-users] AGC overloading ADC Ettus B200 mini

[Tom Bereknyei via USRP-users]

In case it helps, the changes in this commit helped me get AGC working
using RFNoC/GNURadio when I couldn't find the right hooks to do it via the
API.

https://github.com/tomberek/uhd/commit/c491f3e0f44ea457003852883ff742551a57e785#diff-dff9438dbbf09c43d9ccbf24a04e2cb6



On Wed, Mar 28, 2018 at 4:35 PM Julian Arnold via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey,
>
> > Is your signal very narrowband?
>
> Also, keep in mind, that the AGC defaults to the 'slow' mode when enabled.
> This mode is intended for signals like FM broadcast. So if your signal is
> coming in bursts, the AGC won't be able to handle it properly.
>
> Cheers,
> Julian
>
> Marcus D. Leech via USRP-users schrieb am 28.03.2018 22:16:
>
> > On 03/28/2018 01:50 PM, Ahmed Hamza wrote:
> >
> >>
> >> Hi Marcus,
> >>
> >>
> >> Thank you for your prompt response.
> >>
> >>
> >> I can change the TX power, kindly find attached the received  "I"
> channel in case of TX power -25 dbm and -45 dbm. Also, there is about 10 dB
> attenuation before the Ettus RX. As you can see, there are many samples
> that goes to +/- 2048 and I believe that means ADC is overloaded. It is
> mentioned in the reference manual of Ad9364:
> >>
> >> "When the ADC is overloaded, the error between its samples and the
> input signal will cause the ADC to output more samples with values of +4 or
> −4 as it struggles to track the input signal.", is there anything else I
> can try? Note: Disabling AGC and changing gains gives reasonable outputs
> (i.e., amplitude of samples change with changing the applied gain without
> samples going to +/- 2048). But I need to use AGC because I want to have
> "over the air" testing instead of cable testing.
> >>
> >>
> >> Also, I tried to use --args type=b200 but it did not help. Is it
> possible after loading and executing the script top_block_py (i.e., while
> USB port is used to stream I/Q) to send commands for the board to get
> sample rate, carrier freq., gains,?
> >>
> >>
> >> Thanks again,
> >>
> >>
> >> Best Regards,
> >>
> >> Ahmed
> >>
> > You can insert calls to API elements like get_rx_gain, from with a
> flow-graph.  However, for flow-graphs generated by GRC, it's a bit
> tricky--you'll have to
> >   add code after GRC has generated its output.
> >
> > See the section of the Gnu Radio manual here:
> >
> > https://gnuradio.org/doc/doxygen/group__uhd__blk.html <
> https://gnuradio.org/doc/doxygen/group__uhd__blk.html>
> >
> > Is your signal very narrowband?  The hardware AGC will be looking at the
> entire input bandwidth to the ADC, which is large.  Which means that a
> narrowband
> >   signal doesn't really "drive" the AGC very hard, so it gets "pinned"
> at max gain.  This is why hardware AGC is generally not super-useful.
> >
> > There's nothing inherently incompatible between manual, fixed, gain, and
> doing over-the-air tests.  It is typically the case in the DSP world that
> the
> >   DSP flow handles AGC-like functions, because the DSP flow has a MUCH
> better "view" of the intended signal bandwidth than the front-end of
> >   the hardware.
> >
> >
> >> On Wed, Mar 28, 2018 at 12:29 PM, Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com  > wrote:
> >>>
> >>>
> >>> On 03/28/2018 11:32 AM, Ahmed Hamza via USRP-users wrote:
> >>>
> 
>  Hi,
> 
> 
>  I am using Ettus B200 mini, to receive signal at carrier frequency
> 725 MHz and the bandwidth is 6 MHz. The sampling rate is set to 13.28 MHz.
> 
> 
>  I enabled AGC by calling set_rx_agc() from set_gain inside
> /usrp_source_impl.cc.
> 
>  The thing is that I am receiving a signal with a maximum that reach
> +/- 2048 frequently so I believe that the ADC is overloaded. The test is
> using cable so it is supposed that there is no out of band interference.
> 
> 
>  My questions are:
> 
>  1) Do you know what may be causing this behavior and what should I
> try?
> 
>  2) Where can I find the default values that Ettus B200 mini used for
> Ad9364 registers?
> 
>  3) Is there a way to read and/or write values of Ad9364 registers?
> 
>  4) There are some get functions provided by Ettus, could this get
> functions used in run time (I mean after loading the script)? For example,
> if I do, uhd_usrp_probe --string
> /mboards/0/dboards/A/rx_frontends/A/gain/agc/mode/value after loading the
> script
> 
>  I get: linux; GNU C++ version 5.3.1 20151219; Boost_105800;
> UHD_003.009.002-0-unknown
> 
>  Error: LookupError: KeyError: No devices found for ->
> 
>  Empty Device Address
> 
> 
>  Thanks,
> 
> 
>  Best Regards,
> 
>  Ahmed
> 
> 
> >>> Reduce the power of the device that is sending the signal--use
> attenuators if you have to.
> >>>
> >>> uhd_usrp_probe needs a device address: use --args type=b200
> >>>
> >>>
> >>> ___
> >>> USRP-users 

Re: [USRP-users] Poor Tx/Rx Isolation on B205

[Tom Bereknyei via USRP-users]

What would the equivalent of this be for the e310?


On Tue, Feb 13, 2018 at 16:23 Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 02/13/2018 03:30 AM, Dominik Eyerly via USRP-users wrote:
>
> Hello,
>
> I've noticed that the isolation between the Tx/Rx and the Rx2 port is
> quite poor at the upper frequencies ~22dB at 5.9GHz. Could you explain if
> this is to be expected? Would it be possible to know which switch you are
> using? Any way to improve the isolation?
>
>
> cheers,
> Dominik
> --
>
>
> The schematics for B20xmini are here:
>
> http://files.ettus.com/schematics/b200mini/
>
> How are you measuring isolation?  Are both ports terminated in 50ohms?
>
> You could remove C23, which would improve isolation a bit further, but
> you'd be stuck with only EVER using RX2 for receive, and this would of
> course
>   void your warranty.
>
>
>
>
> --
>
> i.A. Dominik Eyerly
> Head of RF Software
>
> Tel:  +49 (0) 351 7958019 233
> Fax: +49 (0) 351 7958019 232
> Email:   d.eye...@konrad-technologies.de
> *Konrad GmbH — Fritz-Reichle-Ring 12 — D-78315 
> Radolfzell*www.konrad-technologies.dewww.abexstandard.org
> *Support Telefon: +49 (0) 7732 9815 100*supp...@konrad-technologies.de[image: 
> sig]
> Geschäftsleitung: Michael Konrad
> Handelsregisternr: HRB 550593 in Freiburg
> Ust-Id-Nr. DE 206693267
>
> VERTRAULICHKEITS-INFORMATION: Dieses e-Mail und alle anhängenden Dokumente, 
> enthalten Informationen der Konrad GmbH und sind nur für die adressierte 
> Person bestimmt. Diese können vertraulich und/oder von Veröffentlichungen 
> ausgenommen sein. Das Kopieren und die Weitergabe an nicht autorisierte 
> Dritte sind verboten. Für Zuwiderhandlungen können Sie haftbar gemacht 
> werden. Falls Sie nicht der Empfänger sind, benachrichtigen Sie den Absender 
> bitte umgehend. Danke
>
> CONFIDENTIALITY NOTICE: This e-mail and any documents which may accompany it, 
> contains information from Konrad GmbH, which is intended only for the use of 
> the individual or entity to which it is addressed, and which may contain 
> information that is privileged, confidential, and/or otherwise exempt from 
> disclosure under applicable law. If the reader of this message is not the 
> intended recipient, any disclosure, dissemination, distribution, copying or 
> other use of this communication or its substance is prohibited. If you have 
> received this communication in error, please contact us immediately. Thank 
> you.
>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-- 
Maj Tom Bereknyei
Defense Digital Service
t...@dds.mil
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Reading and displaying RFNoC registers within gnuradio companion

[Tom Bereknyei via USRP-users]

I've not hooked it up to a GUI, but using the RFNoC blocks set_register and
get_register functions in Python seem to work very well. Making this show
up in companion would be just a matter of either passing those values as
data or a PMT to whatever graphical element you wish.

On Tue, Dec 19, 2017 at 2:58 PM Andrew Thommesen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
>
> The RFNoC gain block tutorial shows hows to write to an RFNoC register
> from a gnuradio companion flowgraph. Are there any examples of how to read
> an RFNoC register and display the value within gnuradio companion. Is a
> dedicated gnuradio sink block required to display the value, or can it
> simply be displayed within the RFNoC block within gnuradio?
>
>
> Thanks,
>
>
> Andy
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-- 
Maj Tom Bereknyei
Defense Digital Service
t...@dds.mil
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] set_processor_affinity for python block

[Tom Bereknyei via USRP-users]

Try something like this:

self._gateway_block__gateway.set_processor_affinity([0])


On Thu, Oct 26, 2017 at 22:11 john liu via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
> Does anyone know how to solve this problem?
>
> best regards
> John
>
> On Wed, Oct 25, 2017 at 10:43 AM, john liu 
> wrote:
>
>> Dear all,
>> We write a python block based gr-sync,everything ok,but which can
>> not set_processor_affinity.error as below:
>> object has no attribute 'set_processor_affinity'
>> So we need other special settings?
>>
>> best regards
>> John
>>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-- 
Maj Tom Bereknyei
Defense Digital Service
t...@dds.mil
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Fast synthesis of SDR's FPGA

[Tom Bereknyei via USRP-users]

You can edit the TCL build script with the appropriate Xilinx commands to
do incremental place and route. I apologize, it's been a few months since I
looked into this and can't recall exactly where and what command it was.
But it did help by cutting a few minutes off, not a lot.

On Fri, Oct 13, 2017 at 20:08 Shoorveer Singh via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Neel,
>
> Sorry about the mistake.
>
> Actually I am trying to implement FFT in the Ettus RX-TX Path. Building
> the code along with the FFT takes much more time as expected.
> Is there a way to specify  incremental place and route in Xilinx? I am
> hoping that this time can be reduced for small changes in the code, so that
> when rebuilding, I can use the old build files.
>
>
> --
> Thanks and Regards
> Shoor
>
> From: Neel Pandeya 
> Date: Friday, October 13, 2017 at 4:47 PM
>
> To: Shoorveer Singh 
> Cc: usrp-users 
> Subject: Re: [USRP-users] Fast synthesis of SDR's FPGA
>
> Hello Shoor:
>
> Please keep the conversation on the mailing list.
>
> A build time of 20 minutes for the B200mini FPGA is entirely normal. I'm
> not sure how much you would be able to reduce that. Again, try the build on
> a system with a higher clock speed and at least 8 GB memory. Our Xilinx ISE
> workflow does not have an incremental build process, and because Xilinx has
> ended development and support for ISE (Xilinx has deprecated ISE), we do
> not have any plans to add this capability.
>
> Please let me know if you have any further questions.
>
> --Neel Pandeya
>
>
>
> On 13 October 2017 at 10:43, Shoorveer Singh 
> wrote:
>
>> Hi Neel,
>>
>> I am using USRP B200mini. Even without any modification to the code, it
>> take around 20 minutes to build.
>>
>> Is there a way we can speed up the process so that if I do a small
>> modification to the code, it takes less time? Like incrementally builds?
>>
>>
>> —
>> Thanks and Regards
>> Shoor
>>
>> From: Neel Pandeya 
>> Date: Friday, October 13, 2017 at 10:28 AM
>> To: Shoorveer Singh 
>> Cc: usrp-users 
>> Subject: Re: [USRP-users] Fast synthesis of SDR's FPGA
>>
>> Hello Shoor:
>>
>> How long is your Xilinx ISE build taking? Which USRP device are you using?
>>
>> The primary thing would be to use a CPU with a higher clock speed. More
>> memory helps too, as the build process is memory-intensive, but only up to
>> a point. For the B200/B210 FPGA, a system with 8 GB memory should suffice.
>>
>> Xilinx ISE won't really take advantage of multiple cores, so using a CPU
>> with lots of cores won't help much.
>>
>> --​Neel Pandeya
>>
>>
>>
>>
>> ​​
>> On 13 October 2017 at 09:34, Shoorveer Singh via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi,
>>>
>>> I am trying to modify the Ettus’s FPGA code and build the new code to
>>> get the bit file. But it takes a very long time for every build to be done.
>>> I am using Xilinx ISE for this work.
>>> Is there any way I can get it to work faster?
>>>
>>>
>>>
>>> --
>>> Thanks and Regards
>>> Shoor
>>>
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-- 
Maj Tom Bereknyei
Defense Digital Service
t...@dds.mil
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] OFDM Broken

[Tom Bereknyei via USRP-users]

I ran into a similar issue. We ended up rebuilding portions of OFDM. We are
working to release, but trying to figure out some critical bugs first.

I'm sure there are many in a similar position. If we pool together, would
the groups you represent be willing to fund RFNoC developers to solidify
the OFDM block-set?
On Mon, Oct 2, 2017 at 15:51 Francisco Alberto Kindelan-Espinosa via
USRP-users  wrote:

> Hello,
>
> I'm trying to get something from RFNoC OFDM working but have had no luck.
>
> In the rfnoc-devel branch, the schmidl_cox block cannot be built without
> errors and the .v doesn't appear to be complete.
>
> Using the ofdm-branches (gr-ettus, uhd, uhd-fpga), the schmidl_cox can be
> built but runs with errors.
>
> Is there a plan to get OFDM working?  I want to help the effort but don't
> know where to begin.  Did OFDM ever work correctly (or close to correctly)
> at some point?  If so, can someone point me to the right revisions of
> gr-ettus, uhd, and uhd-fpga?
>
> Thanks,
> Frank
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-- 
Maj Tom Bereknyei
Defense Digital Service
t...@dds.mil
(571) 225-1630‬
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Error building OOT RFNOC Module with dependencies

[Tom Bereknyei via USRP-users]

John, will this be open source? We are also looking at modifying the SIGGEN
to add functionality. From the name it seems you are transmitting on two
channels. We would need more, but the concept seems similar.
On Wed, Sep 27, 2017 at 18:10 John Medrano via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> We have modified sig_gen module to create an OOT module and we are
> attempting to build image. But we receive an error while trying to build
> the test bench.
>
> sig_gen relies on modules cadd, cordic_rotater, and axi_clip_complex. As
> seen below, it is unable to find these modules while building test bench.
>
> These files all exist with FPGA_SOURCE and are part of the original
> sig_gen module.
>
> Please advise.
>
> INFO: [VRFC 10-311] analyzing module glbl
> INFO: [USF-XSim-3] XSim::Elaborate design
> INFO: [USF-XSim-61] Executing 'ELABORATE' step in
> '/home/joseavila/Documents/gnuradio_source/rfnoc-siggen2ch/rfnoc/testbenches/noc_block_twochannelsiggen_tb/xsim_proj/xsim_proj.sim/sim_1/behav'
> Vivado Simulator 2015.4
> Copyright 1986-1999, 2001-2015 Xilinx, Inc. All Rights Reserved.
> Running: /opt/Xilinx/Vivado/2015.4/bin/unwrapped/lnx64.o/xelab -wto
> b9f75645c2494d95a76a86ec25333ddc --debug all --relax --mt 8 -d
> WORKING_DIR=/home/joseavila/Documents/gnuradio_source/rfnoc-siggen2ch/rfnoc/testbenches/noc_block_twochannelsiggen_tb
> -L work -L unisims_ver -L unimacro_ver -L secureip --snapshot
> noc_block_twochannelsiggen_tb_behav work.noc_block_twochannelsiggen_tb
> work.glbl -log elaborate.log -timescale 1ns/1ns
> Using 8 slave threads.
> Starting static elaboration
> ERROR: [VRFC 10-2063] Module  not found while processing
> module instance 
> [/usr/src/gnuradio_source/fpga/usrp3/lib/rfnoc/sine_tone.v:63]
> ERROR: [VRFC 10-2063] Module  not found while processing module
> instance 
> [/home/joseavila/Documents/gnuradio_source/rfnoc-siggen2ch/rfnoc/fpga-src/noc_block_twochannelsiggen.v:255]
> ERROR: [VRFC 10-2063] Module  not found while processing
> module instance 
> [/home/joseavila/Documents/gnuradio_source/rfnoc-siggen2ch/rfnoc/fpga-src/noc_block_twochannelsiggen.v:265]
> ERROR: [XSIM 43-3322] Static elaboration of top level Verilog design
> unit(s) in library work failed.
> INFO: [USF-XSim-99] Step results log
> file:'/home/joseavila/Documents/gnuradio_source/rfnoc-siggen2ch/rfnoc/testbenches/noc_block_twochannelsiggen_tb/xsim_proj/xsim_proj.sim/sim_1/behav/elaborate.log'
> ERROR: [USF-XSim-62] 'elaborate' step failed with error(s). Please check
> the Tcl console output or
> '/home/joseavila/Documents/gnuradio_source/rfnoc-siggen2ch/rfnoc/testbenches/noc_block_twochannelsiggen_tb/xsim_proj/xsim_proj.sim/sim_1/behav/elaborate.log'
> file for more information.
> # if [string equal $vivado_mode "batch"] {
> # puts "BUILDER: Closing project"
> # close_project
> # } else {
> # puts "BUILDER: In GUI mode. Leaving project open."
> # }
> BUILDER: Closing project
> ** Webtalk v2015.4 (64-bit)
>    SW Build 1412921 on Wed Nov 18 09:44:32 MST 2015
>    IP Build 1412160 on Tue Nov 17 13:47:24 MST 2015
> ** Copyright 1986-2015 Xilinx, Inc. All Rights Reserved.
>
> source
> /home/joseavila/Documents/gnuradio_source/rfnoc-siggen2ch/rfnoc/testbenches/noc_block_twochannelsiggen_tb/xsim_proj/xsim_proj.hw/webtalk/labtool_webtalk.tcl
> -notrace
> INFO: [Common 17-206] Exiting Webtalk at Wed Sep 27 15:09:04 2017...
> INFO: [Common 17-206] Exiting Vivado at Wed Sep 27 15:09:04 2017...
> Built target noc_block_twochannelsiggen_tb
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-- 
Maj Tom Bereknyei
Defense Digital Service
t...@dds.mil
(571) 225-1630‬
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Siggen not working in E310

[Tom Bereknyei via USRP-users]

My experiments with SIGGEN on the E310 were similar. At the moment my
workaround is to just send noise or burst samples from the CPU exactly when
needed. I would be interested in a way to use siggen. I am also working on
a siggen-like block which will hop frequencies. I am interested in any
design considerations, thoughts, or advice on the design of the block. If
it can be general enough it can be pushed to upstream.

On Mon, Sep 25, 2017 at 18:04 John Medrano via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> I have been working on getting Siggen working under E310. I built RFNOC
> image with siggen for E310. I have been able to use that image to generate
> a signal from RFNOC_SIGGEN -> HOST, but when I try to rung RFNOC_SIGGEN ->
> RFNOC_DUC -> RFNOC_RADIO I received an error. The error I received goes
> away if I start with siggen enable = FALSE.
>
> See below, the script was modified to enable siggen after 2 seconds, and
> again it does not complain, but I get absolutely no output.
>
> Following are script and original error that I receive.
>
> Please advise,
> John
>
> #!/usr/bin/env python2
> # -*- coding: utf-8 -*-
> ##
> # GNU Radio Python Flow Graph
> # Title: Rfnoc Sin Radio E310
> # Generated: Thu Sep 21 14:12:08 2017
> ##
>
> from gnuradio import eng_notation
> from gnuradio import gr
> from gnuradio import uhd
> from gnuradio.eng_option import eng_option
> from gnuradio.filter import firdes
> from optparse import OptionParser
> import ettus
>
>
> class RFNoc_Sin_Radio_e310(gr.top_block):
>
> def __init__(self):
> gr.top_block.__init__(self, "Rfnoc Sin Radio E310")
>
> ##
> # Variables
> ##
> self.samp_rate = samp_rate = 2e6
> self.device3 = variable_uhd_device3_0 =
> ettus.device3(uhd.device_addr_t( ",".join(('type=e3x0',
> "fpga=/home/root/rfnoc/usr/share
> /uhd/images/usrp_e310_fpga_RFNOC_sg3.bit")) ))
> self.up_rate = up_rate = 12e6
> self.gain = gain = 0.5
> self.freq = freq = samp_rate/10
> self.enable = enable = False
> self.ampl_q = ampl_q = 1
> self.ampl_i = ampl_i = 1
>
> ##
> # Blocks
> ##
> self.uhd_rfnoc_streamer_siggen_0 = ettus.rfnoc_generic(
> self.device3,
> uhd.stream_args( # TX Stream Args
> cpu_format="fc32", # TODO: This must be made an option
> otw_format="sc16",
> args="",
> ),
> uhd.stream_args( # RX Stream Args
> cpu_format="fc32", # TODO: This must be made an option
> otw_format="sc16",
> args="",
> ),
> "SigGen", -1, -1,
> )
> self.uhd_rfnoc_streamer_siggen_0.set_arg("spp",  364)
> self.uhd_rfnoc_streamer_siggen_0.set_arg("frequency",
> ((2*freq)/samp_rate))
> self.uhd_rfnoc_streamer_siggen_0.set_arg("waveform", "SINE_WAVE")
> self.uhd_rfnoc_streamer_siggen_0.set_arg("gain", gain)
> self.uhd_rfnoc_streamer_siggen_0.set_arg("enable", enable)
> self.uhd_rfnoc_streamer_siggen_0.set_arg("amplitude_i",
> complex(ampl_i , ampl_q).real)
> self.uhd_rfnoc_streamer_siggen_0.set_arg("amplitude_q",
> complex(ampl_i , ampl_q).imag)
>
> self.uhd_rfnoc_streamer_radio_0 = ettus.rfnoc_radio(
> self.device3,
> uhd.stream_args( # Tx Stream Args
> cpu_format="fc32",
> otw_format="sc16",
> args='',
> ),
> uhd.stream_args( # Rx Stream Args
> cpu_format="fc32",
> otw_format="sc16",
> args="", # empty
> ),
> 0, -1
> )
> self.uhd_rfnoc_streamer_radio_0.set_rate(up_rate)
> for i in xrange(1):
> self.uhd_rfnoc_streamer_radio_0.set_tx_freq(1.0e9, i)
> self.uhd_rfnoc_streamer_radio_0.set_tx_gain(20, i)
> self.uhd_rfnoc_streamer_radio_0.set_tx_dc_offset(True, i)
>
> self.uhd_rfnoc_streamer_radio_0.set_tx_antenna("TX/RX", 0)
>
> self.uhd_rfnoc_streamer_fifo_0 = ettus.rfnoc_generic(
> self.device3,
> uhd.stream_args( # TX Stream Args
> cpu_format="fc32",
> otw_format="sc16",
> args="gr_vlen={0},{1}".format(1, "" if 1 == 1 else
> "spp={0}".format(1)),
> ),
> uhd.stream_args( # RX Stream Args
> cpu_format="fc32",
> otw_format="sc16",
> args="gr_vlen={0},{1}".format(1, "" if 1 == 1 else
> "spp={0}".format(1)),
> ),
> "FIFO", -1, -1,
>  

Re: [USRP-users] E310 "subdev spec" equivalent in RFNoC?

[Tom Bereknyei via USRP-users]

EJ,

I went through that same sequence of attempts and never got a solution
other than using TX/RX and RX2 on the same A channel.

On Thu, Sep 21, 2017 at 14:05 EJ Kreinar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I'm trying to specify exactly which channel to record from an RFNoC
> flowgraph on the E310, but I cant seem to get this to work
>
> Typically, in non-RFNoC applications, or in the "legacy_compat" mode, you
> can use the following options:
>
> uhd_rx_cfile -r  -f  -A TX/RX --spec=A:A
> recording.c32
> uhd_rx_cfile -r  -f  -A RX2 --spec=A:A
> recording.c32
> uhd_rx_cfile -r  -f  -A TX/RX --spec=A:B
> recording.c32
> uhd_rx_cfile -r  -f  -A RX2 --spec=A:B
> recording.c32
>
> And each option, in turn, records data from a different receive port on
> the E310.
>
>
> But, I cant figure out the correct combination to get the rfnoc_radio
> software to support recording on channel B. A few things I've tried:
>
> 1. Changing the rfnoc_radio dropdown to "Radio Select = B". This errors
> like this:
>
> Traceback (most recent call last):
>   File "/home/root/test_rx.py", line 138, in 
> main()
>   File "/home/root/test_rx.py", line 127, in main
> tb = top_block_cls(args=options.args, freq=options.freq,
> gain=options.gain, rate=options.rate)
>   File "/home/root/test_rx.py", line 52, in __init__
> 1, -1
>   File "/usr/lib/python2.7/site-packages/ettus/ettus_swig.py", line 1980,
> in make
> return _ettus_swig.rfnoc_radio_make(*args, **kwargs)
> RuntimeError: Cannot find a block for ID: Radio_1
> -- Loading FPGA image: /boot/system_top.bit... done
>
>
> 2. Adding a FIFO to the FPGA on the second channel, and "dropping" the
> samples from the first channel.
> [image: Inline image 1]
>
> But this fails like so:
>
> -- [0/FIFO_0] source_node_ctrl::set_rx_streamer() 0 -> 1
> -- [0/Radio_0] radio_ctrl_impl::set_rx_streamer() 1 -> 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 == 25  New samp_rate == 25 New scaling ==
> 3.05185e-05
> -- [0/FIFO_0] source_block_ctrl_base::issue_stream_cmd()
> -- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() 0 a
> -- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() called on inactive
> channel. Skipping.
> timeout on chan 0
> timeout on chan 0
>
> And no data is recorded.
>
> 3. I also tried (foolishly) manually editing the generated python to
> connect the File Sink to port 1 of the rfnoc_radio, rather than port 0.
>
> I used this flowgraph:
> [image: Inline image 3]
> And then I manually changed the following lines:
>
> self.connect((self.uhd_rfnoc_streamer_radio_0, 0),
> (self.blocks_file_sink_0_0, 0))
> =becomes==>
> self.connect((self.uhd_rfnoc_streamer_radio_0, 1),
> (self.blocks_file_sink_0_0, 0))
>
> I was hopeful that port 1 actually existed and was initialized correctly
> in UHD, but alas, port 1 clearly does not exist for me to attach the file
> sink to:
>
> Traceback (most recent call last):
>   File "/home/root/test_rx.py", line 138, in 
> main()
>   File "/home/root/test_rx.py", line 128, in main
> tb.start()
>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", line
> 109, in start
> top_block_start_unlocked(self._impl, max_noutput_items)
>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/runtime_swig.py",
> line 3671, in top_block_start_unlocked
> return _runtime_swig.top_block_start_unlocked(*args, **kwargs)
> RuntimeError: rfnoc_radio(1): missing connection from output port 0
> -- Loading FPGA image: /boot/system_top.bit... done
>
>
> I cant seem to figure this out.. Any suggestions?? Am I missing something
> obvious, or is RFNoC missing this support?
>
> (by the way, I am admittedly still behind on my UHD version. So perhaps
> there's updates that resolve this issue recently?)
>
> Thanks!
> EJ
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-- 
Maj Tom Bereknyei
Defense Digital Service
t...@dds.mil
(571) 225-1630‬
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Porting from x86 to armv7 (Ettus E310) - performance issues

[Tom Bereknyei via USRP-users]

We ran into a similar issue. Big things that helped us was to move high
rate dsp calculations to RFNoC.

I've also had luck with volk_profile. It seems to help with some workloads.
On Wed, Sep 6, 2017 at 16:53 Philip Balister via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 09/06/2017 04:38 PM, Marcus Müller via USRP-users wrote:
> > Hi Mr Hamilton,
> >
> > So, what you'd want to optimize first depends on what needs the most
> > optimization. Your x86 program might be a good place to start looking
> > into what the bottleneck is. If you're running Linux on your x86, I can
> > heartily recommend `perf`, which is a tool that lets you display live,
> > record and analyze the points in your code where the program spends most
> > time.
>
> "perf top" gives results pretty quickly.
>
> It also sounds like you aren't using both cpu's to the full extent.
> Maybe there is just one block doing all the work?
>
> Also, looking at using rfnoc to do high rate functions to reduce
> calculations that need doing on the arm is a good plan.
>
> Philip
>
> >
> > In general, modern x86 have way larger memory bandwidth and larger CPU
> > caches, so that alone can become critical, but also things like more
> > capable SIMD instructions and less hardware-handling overhead.
> >
> > I don't know whether this helped you much, but I hope it's a start,
> > best regards,
> >
> > Marcus Müller
> >
> > On 09/06/2017 10:06 PM, S Hamilton via USRP-users wrote:
> >> We're moving an application that we had running on pc hardware with
> >> the Ettus B210, to the embedded arm E310.  On the pc side we were at
> >> 80% idle cpu when running (intel i5-4570).  With armv7 we're down to
> >> 30% idle, with one of the cores @100% so it's not keeping up.
> >> Are there any arm specific optimizations that are recommended or
> gotchas.
> >> We are using the release4 version of the SDK and firmware.
> >>
> >> We'd also like to use the complex_to_mag_approx RFNOC block.  Is there
> >> any sample code around to look at.
> >>
> >> Thanks,
> >>
> >>
> >> ___
> >> USRP-users mailing list
> >> USRP-users@lists.ettus.com
> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
> >
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-- 
Maj Tom Bereknyei
Defense Digital Service
t...@dds.mil
(571) 225-1630‬
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC user registers and related APIs

[Tom Bereknyei via USRP-users]

Dario,

I've been working on a similar requirement. how strict are your timing
needs? For prototyping we were able to get microsecond timing with just a
scheduler implemented in python on an E310. The other major limitation
right now is that RFnoc does not implement the UHD tagging of samples on
the receiving side or to schedule the transmission on the transmit side. I
would love to see that functionality implemented in someway but tags are
only a GNUradio concept not in RFNOC.

A good start is to utilize the timing information in the headers, but
ideally you would just edit the existing radio blocks to make them more
useful in general.
On Tue, Aug 22, 2017 at 15:57 Dario Pennisi via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Jonathon,
> Thank you for your feedback. There's one more thing I am missing. I need
> to implement closed loop frequency hopping in the sense that my rfnoc block
> demodulates a signal, provides demodulated data to host along with
> timestamp and host needs to send a timed command to another block that will
> emit its answer packet. It is my understanding that it is possible to set
> registers at a given timestamp so this should do it.
> What I am wondering is if there is a clean way to receive data from FPGA
> with minimal latency so that timed registers programming can be set within
> a short time. At the moment I am implementing a great block that gets data
> from a port and sends commands to a message port connected to the rfnoc
> block which then sends timed commands.
> Initially was thinking it would make sense to intercept data directly from
> the rfnoc block c code but could not figure out a way to do that.
> Can you please provide some insight and eventually pointers on how to do
> this?
>
> Thanks,
>
> Dario
>
>
>
> On Tue, Aug 22, 2017 at 7:26 PM +0200, "Jonathon Pendlum" <
> jonathon.pend...@ettus.com> wrote:
>
> Hi Dario,
>>
>> Yes, the deep dive is a bit outdated, but most of the core concepts are
>> still valid. Originally, next_dst was derived from a register in the user
>> register address space (usually register 128). However, that was wasteful
>> of user registers, so that signal was pulled into Noc Shell and set as part
>> of the Noc Shell register address space. I would suggest not using the
>> configuration buses on AXI Wrapper, but instead to use axi_setting_reg if
>> you want a register with an AXI stream interface.
>>
>> The settings bus / readback bus concept has existed in USRPs before
>> RFNoC. We avoided redesigning those buses so we could easily include
>> pre-RFNoC code (such as the radio core) into RFNoC. We do have a redesign
>> of that bus on our RFNoC roadmap to make it more consistent.
>>
>> Jonathon
>>
>> On Tue, Aug 22, 2017 at 3:56 AM, Dario Pennisi via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi,
>>>
>>> I have some doubts on the interfaces available on noc shell and axi
>>> wrapper.
>>>
>>> Based on the deep dive slides noc shell provides 3 bidirectional busses:
>>>
>>>- Command & response
>>>
>>> Looking at the noc_shell code this should be indicated as control
>>> source. This bus seems to be able to send commands to other blocks. Is the
>>> command sink really usable to have a block send commands to other blocks?
>>>
>>>- Data packets
>>>
>>> This should just contain sample data in and out of the block
>>>
>>>- Settings bus
>>>
>>> This should be what noc shell code calls control sink and is basically
>>> an axi bus that is used to read and write registers.
>>>
>>>
>>>
>>> In axi_wrapper the settings bus is decoded to allow sending axi
>>> streaming packets to each configured busses through registers 129 and 130.
>>> This basically allows sending packets of configuration data to each
>>> configured bus over the AXI configuration busses. It is used in window
>>> block to send window data
>>>
>>>
>>>
>>> Axi wrapper also allows looping timestamp data or vice substituting it
>>> with user generated data.
>>>
>>>
>>>
>>> One thing I don’t understand is for example that in the rfnoc getting
>>> started web page the gain sample uses register 128 which according to the
>>> deep dive ppt is supposed to be reserved for axi wrapper next destination,
>>> whereas the noc_shell_regs.v seems to indicate SR_NEXT_DST_SID is 6… it
>>> seems to me deep dive ppt is outdated and settings registers from 128 on
>>> can be feely used as long as they aren’t used for configuration busses…
>>> correct?
>>>
>>>
>>>
>>> Another thing I think I understood is that the settings register space
>>> can be used for both reads and writes and provides a 32 bit data bus and
>>> has only 128 addresses left for user application of which 2*channels are
>>> used for configuration busses. This address space is separate from the user
>>> readback which provide another 256 x 64 bit possible readback registers
>>> which are completely separate from the settings register space.. while it
>>> makes sense it’s not totally clear why an additional