[USRP-users] UHD 4.0 RFNoC migration questions

[Nick Foster via USRP-users]

Just had a few q's regarding RFNoC in UHD 4.0 as I migrate my applications
to it.


   1. In the style of a tedious conference Q session, this is more of a
   comment than a question: I noticed NoCScript is dead: great! But it sure
   would be nice if there were something which filled the role of obviating
   the need for explicit block controllers for simple blocks.
   2. I noticed both the "registers" sections of the YAML definitions are
   unused in stock UHD blocks and unlooked-for in rfnoc_blocktool's
   templating process. I also noticed a lot of _regs.vh
   register definition files in the RFNoC Verilog blocks included in UHD,
   which look suspiciously like autogenerated boilerplate. Seems like
   something which would be reasonably straightforward (I say, having not done
   it myself) to implement in rfnoc_blocktool. What am I missing?
   3. I'm a little unclear on the difference between the rfnoc_chdr clock
   and ce_clk. Some block definitions just use one, some use both. I'm
   assuming the rfnoc_chdr clock is equivalent to the old bus_clk. Is the
   lack of a ce_clk in the block definition just to avoid having to route
   ce_clk to logic which doesn't require it? Is ce_clk decoupled entirely
   from radio_clk now on X310?
   4. Is there a plan to integrate rfnoc_modtool and rfnoc_blocktool? At
   least within the same repository? The overlapping functionality between
   them is confusing. It would be a huge reduction in boilerplate madness if a
   single YAML block definition could result in both Verilog blocks and
   coordinated C++ block controllers being generated.

Thanks for all the work on this: UHD 4.0 looks like a major improvement.

Nick
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC: How can I use the GPS time?

[Nick Foster via USRP-users]

Maybe if you provide a more detailed description of what you're trying to
accomplish, we can help direct you toward a path to get there. Do you just
want to get a timestamp into your UHD application? Do you require a
timestamp for the custom logic in your RFNoC block on the FPGA?

On Mon, Nov 16, 2020 at 10:26 PM George Smith via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear community,
>
> I use an RFNoC block and I would like to use it in combination with the
> GPS time functionallity on a N310.
> My aim is to create and write out a GPS precise timestamp - in the first
> step only once but maybe later more regularly.
> Until Inow I have a RFNoC block, where I put the controlling stuff (of the
> main task) inside *test1_block_ctrl_impl.cpp *which is called by
> *test1_impl.cc*
> My idea is to put the GPS time function inside *test1_block_ctrl_impl.cpp*
> / *test1_impl.cc *as well. In my opinion it is not necessary to create a
> completelty new self-written RFNoC block since it is a small function.
>
> In the following I describe two different approaches how I try to achieve
> my goal, but I would like to use the easiest one.
> Mainly I try to use the integrated GPSDO function
> So if you know a better solution, don't hesitate to post it. :)
>
>
> 
>
> *(1)*
>
> Initially; I thought I could use code of the *sync_to_gps.cpp *in the
> examples folder of uhd, but I realized that therefore an instance of an
> *usrp* object is created.
>
> *uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(args);*
>
> Since I use a RFNoC block, previously a "*rfnoc*" object is constructed.
> (I dont know the exact name and where it is created). So, I have two
> instances which want to access at the same resource (board) at the same
> time. This is obviously not functioning.
> So when I run it in gnuradio I got the following error:
>
> *[ERROR] [RPC] Someone tried to claim this device again*
>
> In order to avoid this problem I would like to apply the needed methods
> for using the GPS time functionallity at the *rfnoc *object (so I do not
> need to create an object *usrp *).
> In the *sync_to_gps.cpp *example the following methods are used:
>
> *set_clock_source*
> *set_time_source*
> *get_mboard_sensor_names*
> *get_mboard_sensor*
> *set_time_next_pps*
> *get_time_last_pps*
>
> So my question is, where in the RFNoC framework is an instance of the *rfnoc
> *object created, so I can apply these methods to it.
>
> *Another thing:*
> If I start the built program *sync_to_gps*, I get after the
> initialization, a *seg fault *error. I think, it is because I use an
> RFNoC block.
> Is it true, and where is the core dump stored?
>
> *(2)*
>
> During my research, I noticed that there is an *RFNoC: Radio block. *Looking
> at the source code I see interesting methods in it:
>
> set_clock_source
> set_time_next_pps
> get_time_last_pps
>
> but not (*set_time_source, get_mboard_sensor_names, get_mboard_sensor *)
>
> So it seems to me that a GPS time function is not integrated in the 
> *rfnoc_radio_impl
> *class*.*
> This astonishes me, because I would assume that the RFNoC framework could
> perform at least the same tasks as an usual USRP (radio) one.
> I think about using (copying) the missing methods in the *rfnoc_radio_impl
> *class. Are there any problems doing this or why they have not been
> implemented so far?
> If I implement it, how can I recompile the block in order to get an
> updated *RFNoC: Radio* block.
>
>
> 
>
> Used software:
> I use GNURadio 3.7.14.0, UHD 3.15 with Python 2.7.
> Hardware:
> N310
>
> Thanks for the help :)
>
> Kind regards
>
> George
>
>
>
> ___
> 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

Re: [USRP-users] X310 RFNoC Basic Transmit Signal Source Flowgraph Not Working

[Nick Foster via USRP-users]

RFNoC Radio runs at a constant 200Msps. Use DUC parameters: input rate
1Msps, output rate 200Msps. Use Radio parameter: Sampling Rate 200Msps.

I don't know why you're getting a gain error. What daughterboard are you
using?

In addition, you probably don't need the DMA FIFO for this FG.

Nick

On Thu, Jul 23, 2020 at 11:34 AM Hodges, Jeff via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Has anyone been able to transmit with RFNoC Radio using the standard FPGA
> image from UHD.3.15.LTS?
>
>
> I have a clean installation and ran SigGen --> RFNoC: DmaFIFO --> RFNoC:
> DUC --> RFNoC: Radio
>
>
> Most basic flow graph ever. It does not work. I get a run-time error.
>
>
> Traceback (most recent call last):
>   File "/home/nvd/Documents/top_block.py", line 169, in 
> main()
>   File "/home/nvd/Documents/top_block.py", line 157, in main
> tb = top_block_cls()
>   File "/home/nvd/Documents/top_block.py", line 84, in __init__
> self.uhd_rfnoc_streamer_radio_0.set_tx_gain(0, 0)
>   File "/usr/local/lib/python2.7/dist-packages/ettus/ettus_swig.py", line
> 3235, in set_tx_gain
> return _ettus_swig.rfnoc_radio_sptr_set_tx_gain(self, gain, chan)
> RuntimeError: _Map_base::at
>
>
>
> Jeff
> --
> *From:* USRP-users  on behalf of
> Hodges, Jeff via USRP-users 
> *Sent:* Wednesday, July 22, 2020 8:49:05 PM
> *To:* usrp-users@lists.ettus.com
> *Subject:* [USRP-users] X310 RFNoC Basic Transmit Signal Source Flowgraph
> Not Working
>
>
> I get a set_tx_gain error running a basic signal generator through RFNoC
> Radio:
>
> Signal Source -> DMA FIFO -> DUC -> Radio  (See image below)
>
>
> This is equivalent to:
> Signal Source --> USRP Sink(Works fine)
>
>
> https://kb.ettus.com/File:dma_fifo_v02.png
>
>
> 
>
> Traceback (most recent call last):
>   File "/home/nvd/Documents/top_block.py", line 169, in 
> main()
>   File "/home/nvd/Documents/top_block.py", line 157, in main
> tb = top_block_cls()
>   File "/home/nvd/Documents/top_block.py", line 84, in __init__
> self.uhd_rfnoc_streamer_radio_0.set_tx_gain(0, 0)
>   File "/usr/local/lib/python2.7/dist-packages/ettus/ettus_swig.py", line
> 3235, in set_tx_gain
> return _ettus_swig.rfnoc_radio_sptr_set_tx_gain(self, gain, chan)
> RuntimeError: _Map_base::at
>
>
> I am using 3.15.LTS.
>
>
> Any ideas?
>
>
> Thanks,
>
>
> Jeff
>
> ___
> 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

Re: [USRP-users] Precise Time Synchronization In B200/N210

[Nick Foster via USRP-users]

The change in time of arrival with B200s is due to phase ambiguity. Do you
have a 10MHz reference shared between your devices as well?

Don't know why N210 has that off-by-one timestamp. I'm guessing that
there's an extra flop in the logic for the PPS timing chain somewhere -- as
in, the clock starts ticking on the first tick after PPS comes in. I've
made that error about half a million times, myself.

Nick

On Fri, Jun 12, 2020 at 2:23 PM Aaron Smith via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello all,
>
> I have two separate, but related, questions.
>
> I am trying to trigger an RF transmission every second, and I am receiving
> the transmission with a receiver that has very precise time stamps. I am
> driving the receiver with the same 1 PPS source as the B200 and N210. For
> my simple test, I want the time of arrival at the receiver to register at 1
> PPS + propagation delay of the RF coax cable + the USRP front end delay. In
> all cases I am running UHD 3.15.LTS
>
> With the N210 I can achieve this. However when I call
>
> usrp->set_time_next_pps(uhd::time_spec_t(0.0));
>
> and poll the last pps time, I see that it is consistently 20 ns before a
> second. That is, the pps shows at:
>
> 99980 ns
> 199980 ns
> 299980 ns
>
> If I call usrp->set_time_next_pps(uhd::time_spec_t(20.0e-9)); then the 1
> PPS registers on the second. It's almost like the clock is biased by 20 ns.
> I have observed this across 3 different N210s. What could be causing this?
>
> With the B200, every time I destroy and recreate the uhd::usrp::multi_usrp
> there is a random change in the time of arrival at the receiver that
> appears to be uniformly distributed between 0 and 1/master_clock_rate. Is
> this expected? The Ettus website says "All functions that directly interact
> with the AD93xx (tuning, gain change, etc) are subject to the scheduling of
> the AD93xx. The determinism of these operations are not guaranteed. "
>
> Is this what I am experiencing?
>
> Thank you for the help!
>
> ___
> 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

Re: [USRP-users] How to debug timed commands on FPGA side?

[Nick Foster via USRP-users]

I agree that Gnuradio sometimes introduces unpredictable and
non-reproducible latencies, which can be especially problematic when
dealing with timing-sensitive hardware close to the metal. Setting UHD
buffer size is one thing, but Gnuradio can hang onto data in sometimes
opaque ways, with sometimes opaque interactions (at least, to me!) with the
host OS's scheduler. These issues are ordinarily not a problem because you
can just increase send buffer size until you never see underruns due to
buffer starvation, but this solution only works for systems which a) have
backpressure, and b) are not latency-sensitive.

This isn't a particularly helpful suggestion, I realize, but when faced
with these problems in the past I have reimplemented my systems in C++,
interfaced directly to UHD, generally with favorable results. It is much
easier to guarantee timing when you have full control of the system.

Nick

On Fri, Jun 12, 2020 at 8:45 AM Lukas Haase via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Chintan,
>
> That's a good thought.
>
> What concerns me is that whether timed commands are executed properly
> seems to depend on second and third level parameters such as the way in
> which I connect blocks in gnuradio.
> This is problematic because even if I figure out the max. rate with the
> scope, once I add another block, things may behave differently.
>
> I think the reason that this depends on how blocks are connected in
> gnuradio are buffers. In other words, how fast and how much data UHD
> receives at once.
> All my data arrives on time, just timed commands are sometimes late (the
> cause and conditions are unclear).
>
> There must be a way to control this properly in UHD. The link speed is way
> fast enough (10Gbe and I use 20Msps).
>
> Thanks,
> Lukas
>
>
>
>
> Gesendet: Freitag, 12. Juni 2020 um 07:04 Uhr
> Von: "Chintan Patel" 
> An: "Lukas Haase" 
> Betreff: Re: [USRP-users] How to debug timed commands on FPGA side?
>
> Lukas,
>
> I may have missed some salient points of this thread, but here's a
> thought. Could you just alternate between sending two timed commands -
> transmit freq A and transmit freq B. Hook up the output to a scope (spec an
> may not react fast enough). Once you have the setup that you can "see"
> whether a command has been processed or not by looking at the scope, you
> can characterize the reliable ingest rate of the timed command,
> empirically?
>
> If using a scope is not feasible, if you have another SDR, you can use the
> SDR to capture data (instead of scope) to see whether all TX tune commands
> were processed correctly.
>
> A thought.
>
> Chintan
>
> On Thu, Jun 11, 2020 at 4:47 PM Lukas Haase via USRP-users <
> usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com]> wrote:Hi
> Marcus,
>
> Can we quantify this in the following way?
>
> If I send timed commands every 2ms and sampling rate is 5MS/s, that's
> 1 samples per command or 5 for the command queue (assuming a depth
> of 5).
>
> Can we say the timed commands will guaranteed to be executed on time if we
> never buffer more than 5 samples (=20 bytes) on the host?
>
> Can this be tuned somehow? I tried setting send_buff_size [1] to a small
> value (send_buff_size=1 etc.) but that didn't seem to make any
> difference.
>
> Thanks,
> Lukas
>
>
> [1]
> https://files.ettus.com/manual/page_transport.html[https://files.ettus.com/manual/page_transport.html]
>
>
>
> > Gesendet: Donnerstag, 11. Juni 2020 um 16:32 Uhr
> > Von: "Marcus D Leech"  patchvonbr...@gmail.com]>
> > An: "Lukas Haase" mailto:lukasha...@gmx.at]>
> > Cc: "USRP-userslists.ettus.com[http://USRP-userslists.ettus.com]; <
> usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com]>
> > Betreff: Re: [USRP-users] How to debug timed commands on FPGA side?
> >
> > So one of the things That can happen is that your command packets will
> have to wait For a much-larger data packet. The link is shared.
> >
> > I’d timed commands are scheduled “tight” this can happen.
> >
> > Sent from my iPhone
> >
> > > On Jun 11, 2020, at 3:34 PM, Lukas Haase  lukasha...@gmx.at]> wrote:
> > >
> > > Hi Marcus,
> > >
> > >>> On 06/10/2020 09:00 PM, Lukas Haase via USRP-users wrote:
> > >>> [...]
> > >>> For example, what is the fastest rate I can issue timed commands
> > >>> (ignoring settling times etc) on a X310 over 10Gbe?
> > >> This is actually an ambiguous question.  Do you mean "what is the
> > >> smallest scheduling interval for the commands that will be executed
> > >> in the future?" or "how fast can I issue commands that will
> > >> ultimately be scheduled at a later time?"  In the former, that
> > >> depends on the exact nature of the commands, since they end up
> > >> actually being executed by, for example, an SPI or I2C endpoint,
> > >> which operates very very much slower than a 10GiGe interface.  In the
> > >> latter, my guess is that the FPGA can swallow commands and place them
> > >> on the queue pretty-much as fast as you can 

Re: [USRP-users] RFNoC Build Error? Or Something Else?

[Nick Foster via USRP-users]

You're using the wrong version of Vivado. You need to use Vivado 2017.4.

On Mon, Mar 16, 2020 at 12:38 PM Jeff S via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi, All.
>
> I am trying to start down the path of RFNoC development, and I am
> following the steps outlined on the following page:
>
> https://kb.ettus.com/Getting_Started_with_RFNoC_Development
>
>
> I have already ran into a problem, and I'm not quite sure where to go with
> it.  I'm not sure if I have missed a step somewhere in my installation, or
> if something else is wrong.  I am hoping someone can point me in the
> correct direction.
>
> Here's what I have:
>
> $ uhd_config_info --version
> UHD 4.0.0.rfnoc-devel-702-geec24d7b
>
> $ ./uhd_image_builder.py window fft -d x310 -t X310_RFNOC_HG -m 5 
> --fill-with-fifos
> --Using the following blocks to generate image:
> * window
> * fft
> Adding CE instantiation file for 'X310_RFNOC_HG'
> changing temporarily working directory to 
> /home/user/offline/src/fpga/usrp3/tools/scripts/../../top/x300
> Setting up a 64-bit FPGA build environment for the USRP-X3x0...
> - Vivado: Found (/tools/Xilinx/Vivado/2019.2/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  TOP_MODULE=x300 EXTRA_DEFS="BUILD_1G=1 BUILD_10G=1 
> SFP0_1GBE=1 SFP1_10GBE=1  RFNOC=1 X310=1 "
> make[1]: Entering directory '/home/user/offline/src/fpga/usrp3/top/x300'
> BUILDER: Checking tools...
> * GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)
> * Python 2.7.17
> * Vivado v2019.2.1 (64-bit)
> 
> BUILDER: Building IP ten_gig_eth_pcs_pma
> 
> BUILDER: Staging IP in build directory...
> BUILDER: Reserving IP location: 
> /home/user/offline/src/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma
> BUILDER: Retargeting IP to part kintex7/xc7k410t/ffg900/-2...
> BUILDER: Building IP...*[00:00:00] Executing command: vivado -mode batch 
> -source /home/user/offline/src/fpga/usrp3/tools/scripts/viv_generate_ip.tcl 
> -log ten_gig_eth_pcs_pma.log -nojournal*WARNING: [IP_Flow 19-2162] IP 
> 'ten_gig_eth_pcs_pma' is locked:CRITICAL WARNING: [filemgmt 20-1366] Unable 
> to reset target(s) for the following file is locked: 
> /home/user/offline/src/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma.xciCRITICAL
>  WARNING: [filemgmt 20-1365] Unable to generate target(s) for the following 
> file is locked: 
> /home/user/offline/src/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma.xci
> [00:00:13] Current task: Initialization +++ Current Phase: Starting
> [00:00:13] Current task: Initialization +++ Current Phase: 
> Finished*[00:00:13] Executing Tcl: synth_design -top ten_gig_eth_pcs_pma 
> -part xc7k410tffg900-2 -mode out_of_context*[00:00:13] Starting Synthesis 
> CommandWARNING: [Vivado_Tcl 4-391] The following IPs are missing output 
> products for Synthesis target. These output products could be required for 
> synthesis, please generate the output products using the generate_target or 
> synth_ip command before running synth_design.WARNING: [IP_Flow 19-2162] IP 
> 'ten_gig_eth_pcs_pma' is locked:*ERROR: [Designutils 20-414] HRTInvokeSpec : 
> No Verilog or VHDL sources specified**ERROR: [Common 17-53] User Exception: 
> No open design. Please open an elaborated, synthesized or implemented design 
> before executing this command.**ERROR: [Common 17-53] User Exception: No open 
> design. Please open an elaborated, synthesized or implemented design before 
> executing this command.**ERROR: [Common 17-53] User Exception: No open 
> design. Please open an elaborated, synthesized or implemented design before 
> executing this command.**ERROR: [Common 17-53] User Exception: No open 
> design. Please open an elaborated, synthesized or implemented design before 
> executing this command.**ERROR: [Common 17-53] User Exception: No open 
> design. Please open an elaborated, synthesized or implemented design before 
> executing this command.**ERROR: [Common 17-53] User Exception: No open 
> design. Please open an elaborated, synthesized or implemented design before 
> executing this command.*CRITICAL WARNING: [IP_Flow 19-4739] Writing 
> uncustomized BOM file 
> '/home/user/offline/src/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma.xml'CRITICAL
>  WARNING: [IP_Flow 19-4739] Writing uncustomized BOM file 
> '/home/user/offline/src/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma.xml'CRITICAL
>  WARNING: [IP_Flow 19-4739] Writing uncustomized BOM file 
> '/home/user/offline/src/fpga/usrp3/top/x300/build-ip/xc7k410tffg900-2/ten_gig_eth_pcs_pma/ten_gig_eth_pcs_pma.xml'CRITICAL
>  WARNING: [IP_Flow 19-4739] 

Re: [USRP-users] Can underflows in any way be bad for hardware in the long term?

[Nick Foster via USRP-users]

Nothing in the USRP will be damaged. It's up to you to ensure that your
subsequent RF chain will handle it. There are a few, rare configurations
which come to mind where it would be a Bad Thing to suddenly pulse power on
a millisecond timescale with extremely high bandwidth.

   1. Using your USRP to drive a linear accelerator (don't laugh, it's been
   done)
   2. Using your USRP to drive an extremely high power tube-based AM
   transmitter
   3. Using your USRP to drive an amplifier which is not unconditionally
   stable

Outside of these you're probably fine.

Nick

On Tue, Mar 3, 2020 at 3:21 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 03/03/2020 06:16 PM, Sam Reiter via USRP-users wrote:
>
> Hey Francisco,
>
> Interesting question. I remember reading this when it was initially
> posted, giving it some thought, and promptly forgetting to respond. It's a
> question that is difficult to give a "yes" or "no" to. Similar to
> statistics, I think the answer to this question only comes by disproving
> the null hypothesis that "no part of the signal chain is damaged with an
> underflow". If you can't prove that damage will occur, then you're probably
> in the clear, but you also can't be positive that the null hypothesis is
> true. That being said, I don't think underflows are bad for the hardware in
> any way.
>
> An underflow is typically caused when a bottleneck on the host side
> prevents data from filling USRP buffers quickly enough to be pushed through
> the DAC at the requested rate. As I see it, the only place in the signal
> chain that *might* exhibit unexpected behavior in the face of samples not
> being present would be at the DAC (don't ask me why, but that would be my
> best guess). The way UHD operates, the DAC and ADC are initialized and
> running as soon as the streamer objects in UHD are initialized, and they
> sit there processing nothing (similar to an underflow state) until a TX
> stream command from the host tells the USRP radio core to release it's
> queued samples to the converter(s).
>
> Maybe that was all nonsense. In any case, I wouldn't worry about radio
> damage, I'd worry about fixing your underflows :)
>
> Best,
>
> Sam Reiter
>
> I'd have to agree with Sam here.
>
> An underflow on the TX will just mean that whatever the DAC last saw will
> be presented to the analog interface during the underflow period.
>   Which means perhaps a few microseconds of no level change coming out of
> the DAC.   Not a problem at all, as far as I know.
>
> The main thing is to optimize your code/computer-hardware to prevent them.
>
>
> ___
> 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

Re: [USRP-users] Device Recovery N210: JTAG programmer

[Nick Foster via USRP-users]

Sumit,

Any JTAG programmer which is compatible with Xilinx iMPACT should work
fine. I can recommend the solutions from Digilent (HS2, HS3) or Xilinx
(Platform USB II).

Nick

On Fri, Feb 28, 2020 at 2:19 AM Sumit Kumar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> I have 3 bricked N210 to be recovered. I was following the post
> https://kb.ettus.com/N200/N210_Device_Recovery
>
> It says JTAG programmer and in the picture I can see the model no. is
> DLC9G.
>
> I found something on Amazon which has the same model number but does not
> looks the same. Can anyone confirm if this is correct.
>
> https://www.amazon.fr/Plate-Forme-Compatible-lautolaveuse-programmable-XILINX/dp/B07Y7PBBGQ/ref=sr_1_1?__mk_fr_FR=%C3%85M%C3%85%C5%BD%C3%95%C3%91=DLC9G=1582884943=8-1
>
>
> Regards
> --
> --
> Sumit kumar
> Postdoc
> SnT, Luxembourg
>
>
> ___
> 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] Block parameters in NOC block testbenches

[Nick Foster via USRP-users]

Hi all,

I'm wondering if there's any good way to instantiate blocks in testbenches
with testbench-defined block parameters. The macro `RFNOC_ADD_BLOCK takes
care of defining all the NOC bus interfaces, but there's no place to define
block parameters.

Say I have a NOC block which takes a parameter N_TAPS. How can I
instantiate the block in the testbench with a testbench-defined N_TAPS
parameter without setting it as the default in the block's module?

Nick
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Vivado IP locked issue

[Nick Foster via USRP-users]

/home/kossler/nd_overhaul/uhd_nd/rfnoc/testbenches/noc_block_txarb_tb/build-ip/

Wipe that whole directory and try it again. If you want to be selective and
save some time you can wipe only the axi_mem_64k directory.

On Thu, Feb 20, 2020 at 6:13 PM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> I am having a problem with a Block Memory Generator IP that is working
> with 2017.4 but is giving me issues with 2018.3. I have tried to upgrade
> the IP as well as re-creating the IP from scratch in 2018.3, but I still
> get the same failure (see below).  I have attached the IP created from
> scratch in 2018.3.  Any suggestions?  I am not very experienced with FPGA
> development in general or Vivado specifically, so it is likely that I am
> missing something obvious.
>
> By the way, I am using the webpack (free) version of Vivado and attempting
> to build for the E310.
>
> Rob
>
>
> kossler@kossler-ThinkPad-P51:~/nd_overhaul/uhd_nd/rfnoc/testbenches/noc_block_txarb_tb$
> make xsim
> BUILDER: Checking tools...
> * GNU bash, version 4.4.20(1)-release (x86_64-pc-linux-gnu)
> * Python 2.7.17
> * Vivado v2018.3 (64-bit)
> 
> BUILDER: Building IP axi_mem_64k
> 
> BUILDER: Staging IP in build directory...
> BUILDER: Reserving IP location:
> /home/kossler/nd_overhaul/uhd_nd/rfnoc/testbenches/noc_block_txarb_tb/build-ip/xc7z020clg484-3/axi_mem_64k
> BUILDER: Retargeting IP to part kintex7/xc7z020/clg484/-3...
> BUILDER: Building IP...
> [00:00:00] Executing command: vivado -mode batch -source
> /home/kossler/uhd/UHD-3.15/uhd/fpga-src/usrp3/tools/scripts/viv_generate_ip.tcl
> -log axi_mem_64k.log -nojournal
> WARNING: [IP_Flow 19-2162] IP 'axi_mem_64k' is locked:
> CRITICAL WARNING: [filemgmt 20-1366] Unable to reset target(s) for the
> following file is locked:
> /home/kossler/nd_overhaul/uhd_nd/rfnoc/testbenches/noc_block_txarb_tb/build-ip/xc7z020clg484-3/axi_mem_64k/axi_mem_64k.xci
> CRITICAL WARNING: [filemgmt 20-1365] Unable to generate target(s) for the
> following file is locked:
> /home/kossler/nd_overhaul/uhd_nd/rfnoc/testbenches/noc_block_txarb_tb/build-ip/xc7z020clg484-3/axi_mem_64k/axi_mem_64k.xci
> ___
> 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

Re: [USRP-users] noc_block_addsub_tb.sv - number of samples/packets.

[Nick Foster via USRP-users]

The NOC bus is 64 bits wide. This means each item in the testbench data
array is 2 samples {16i, 16q, 16i, 16q}. The testbench is failing because
you're reading past the end of the input data array.

On Sat, Feb 8, 2020 at 5:04 AM Andrew Payne via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> I'm running and slightly modifying the simulation testbench for the
> RFNOC addsub module.  I've noticed that the for loop in test case 4
> goes to SPP/2 - that upper limit is what I'm modifying to learn how
> packets work in the NOC shell.  So it passes as a stock testbench, and
> after modifying it to run to SPP (256), the entire test case 4 fails,
> with every return from the noc block being "x" (undriven as I
> understand it).  Why does the test fail when I increase the upper
> limit of tests?
>
> Thanks,
> Andrew
>
> ___
> 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

Re: [USRP-users] USRP filter delay

[Nick Foster via USRP-users]

You will also have latency introduced by the ADCs themselves, as well as
baseband analog filters if applicable. If you need very accurate
calibration of arrival time, it is best to generate an accurately timed
calibration signal using a GPS reference. You could continue to use your
TX/RX loopback test, adding an oscilloscope to measure the time between the
PPS rising edge and the RF output to determine TX latency.

On Sun, Feb 2, 2020, 1:41 AM YENDstudio . via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> I want to know the actual timestamp of TX and RX signals at the RF
> antenna. For this I have add/subtract the group delay introduced by digital
> filters in the TX and the RX paths from the UHD timestamp. Through loopback
> test, I am able to calculate the aggregate delay, but cannot know the TX
> delay and the RX delay separately. The UHD driver has APIs to get the list
> of filters used in the signal paths. But my calculated values do not match
> with the loopback delay I measured. Could someone help me with this? I am
> using USRPB200 set with 30.72 MHz master clock rate and 1.92 MHz sampling
> rate.
>
> Regards!
>
>
> ___
> 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

Re: [USRP-users] Receiving IO Block Error when Using RFNoC Split Stream

[Nick Foster via USRP-users]

I also haven't tested to see if this is a gr-ettus limitation or a UHD
limitation.

On Thu, Nov 14, 2019 at 3:04 PM Nick Foster  wrote:

> You can't have heterogenous output destinations on RFNoC blocks -- i.e.,
> you can't send one output to the host and one output to another RFNoC block.
>
> I'm not sure why this limitation exists as there is no architectural
> reason I can see.
>
> Nick
>
> On Thu, Nov 14, 2019 at 12:35 PM Jonathan Lockhart 
> wrote:
>
>> Greetings EJ,
>>
>> So went and dug out the E312 b/c I couldn't wait and unfortunately that
>> didn't resolve the issue I was experiencing. I cherry picked the new
>> split_stream block, I am using the same flow graph as provided before, but
>> when it goes to run on the E312 I get the following error.
>>
>> Traceback (most recent call last):
>>   File "rfnoc_fosphor_radio_network_usrp.py", line 281, in 
>> main()
>>   File "rfnoc_fosphor_radio_network_usrp.py", line 271, in main
>> tb.start()
>>   File
>> "/home/root/localinstall/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
>> "/home/root/localinstall/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: uhd_rfnoc_SplitStream(9): missing connection from output
>> port 0
>>
>> Looks like something is missing from the split stream. I assume it needs
>> to be fixed in the verilog.
>>
>> I attached a screenshot of the new, cleaned up GNU radio file. I had to
>> remove a FIFO and switch to using a throttle b/c I wasn't able to get it
>> all to fit in the bit file.
>>
>> Regards,
>> Jon
>>
>> On Wed, Nov 13, 2019 at 10:46 AM Jonathan Lockhart 
>> wrote:
>>
>>> Greetings EJ,
>>>
>>> Thanks for the info. I haven't had time to grab the new block as my dev
>>> box is packed for moving this weekend. I will get it downloaded and try it
>>> as soon as I can.
>>>
>>> Regards,
>>> Jon
>>>
>>> On Sat, Nov 9, 2019 at 9:48 AM EJ Kreinar  wrote:
>>>
 Hi there,

 Just want to chime in since I recently went through the upgrade process
 to UHD-3.14...

 Can you confirm you're using uhd-3.14? If so, this is actually a split
 stream fpga bug caused by the commit Jon referred to, not the "not enough
 bandwidth" problem.

 Fortunately, rather than referring the old commit, the bug seems to
 have been fixed in October on the master branch: https://
 github.com/EttusResearch/fpga/commit/1102779f49d44c9e8b88ce7251d203eb62ae26c9
 (but not yet ported onto 3.14)

 I just cherry-picked 1102779f onto my UHD-3.14 and it cleaned it up for
 me.

 I assume this will eventually make it to the UHD-3.14 branch? But if
 not the cherry pick works fine

 EJ


 On Fri, Nov 8, 2019, 2:43 PM Jonathan Lockhart via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Jonathon,
>
> I will give that a try and see if it works.
>
>
> Nick,
>
> If the revert on Split_Stream fails, I will try switching from ce_clk
> to bus_clk and give that a try.
>
>
> Regards,
> Jon
>
> On Fri, Nov 8, 2019 at 1:52 PM Nick Foster 
> wrote:
>
>> Jonathon (Pendlum), correct me if I'm wrong, but I think this is the
>> usual split-stream-demands-more-bandwidth-than-RFNoC-bus-allows problem.
>>
>> Jonathan (Lockhart), if I'm right, then in your
>> rfnoc_ce_auto_inst_e310.v, if you change the ce_clk/ce_rst in the
>> noc_block_split_stream instantiation to bus_clk/bus_rst, this may fix the
>> problem.
>>
>> Nick
>>
>> On Fri, Nov 8, 2019 at 10:20 AM Jonathon Pendlum <
>> jonathon.pend...@ettus.com> wrote:
>>
>>> Hi Jon,
>>>
>>> Can you try reverting commit e39334fe on the fpga repo and
>>> rebuilding your bitstream? Let me know if that makes a difference or 
>>> not.
>>>
>>> Jonathon
>>>
>>> On Sat, Nov 9, 2019 at 12:13 AM Jonathan Lockhart via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Greetings Nick,

 Here is the screenshot of my GR flow graph, though it shouldn't
 matter as the Split_Stream RFNoC Block I believe is a failure of the 
 python
 or Verilog but the solutions in the link I sent in my previous email 
 did
 not resolve the issue.

 [image: Screenshot from 2019-11-08 10-06-50.png]

 Regards,
 Jon

 On Thu, Nov 7, 2019 at 5:33 PM Nick Foster 
 wrote:

> Can you be more specific about what your flowgraph looks like?
>
> On Thu, Nov 7, 2019 at 2:22 PM Jonathan Lockhart via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Greetings,
>>
>> I 

Re: [USRP-users] Receiving IO Block Error when Using RFNoC Split Stream

[Nick Foster via USRP-users]

You can't have heterogenous output destinations on RFNoC blocks -- i.e.,
you can't send one output to the host and one output to another RFNoC block.

I'm not sure why this limitation exists as there is no architectural reason
I can see.

Nick

On Thu, Nov 14, 2019 at 12:35 PM Jonathan Lockhart 
wrote:

> Greetings EJ,
>
> So went and dug out the E312 b/c I couldn't wait and unfortunately that
> didn't resolve the issue I was experiencing. I cherry picked the new
> split_stream block, I am using the same flow graph as provided before, but
> when it goes to run on the E312 I get the following error.
>
> Traceback (most recent call last):
>   File "rfnoc_fosphor_radio_network_usrp.py", line 281, in 
> main()
>   File "rfnoc_fosphor_radio_network_usrp.py", line 271, in main
> tb.start()
>   File
> "/home/root/localinstall/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
> "/home/root/localinstall/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: uhd_rfnoc_SplitStream(9): missing connection from output
> port 0
>
> Looks like something is missing from the split stream. I assume it needs
> to be fixed in the verilog.
>
> I attached a screenshot of the new, cleaned up GNU radio file. I had to
> remove a FIFO and switch to using a throttle b/c I wasn't able to get it
> all to fit in the bit file.
>
> Regards,
> Jon
>
> On Wed, Nov 13, 2019 at 10:46 AM Jonathan Lockhart 
> wrote:
>
>> Greetings EJ,
>>
>> Thanks for the info. I haven't had time to grab the new block as my dev
>> box is packed for moving this weekend. I will get it downloaded and try it
>> as soon as I can.
>>
>> Regards,
>> Jon
>>
>> On Sat, Nov 9, 2019 at 9:48 AM EJ Kreinar  wrote:
>>
>>> Hi there,
>>>
>>> Just want to chime in since I recently went through the upgrade process
>>> to UHD-3.14...
>>>
>>> Can you confirm you're using uhd-3.14? If so, this is actually a split
>>> stream fpga bug caused by the commit Jon referred to, not the "not enough
>>> bandwidth" problem.
>>>
>>> Fortunately, rather than referring the old commit, the bug seems to have
>>> been fixed in October on the master branch: https://
>>> github.com/EttusResearch/fpga/commit/1102779f49d44c9e8b88ce7251d203eb62ae26c9
>>> (but not yet ported onto 3.14)
>>>
>>> I just cherry-picked 1102779f onto my UHD-3.14 and it cleaned it up for
>>> me.
>>>
>>> I assume this will eventually make it to the UHD-3.14 branch? But if not
>>> the cherry pick works fine
>>>
>>> EJ
>>>
>>>
>>> On Fri, Nov 8, 2019, 2:43 PM Jonathan Lockhart via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Jonathon,

 I will give that a try and see if it works.


 Nick,

 If the revert on Split_Stream fails, I will try switching from ce_clk
 to bus_clk and give that a try.


 Regards,
 Jon

 On Fri, Nov 8, 2019 at 1:52 PM Nick Foster 
 wrote:

> Jonathon (Pendlum), correct me if I'm wrong, but I think this is the
> usual split-stream-demands-more-bandwidth-than-RFNoC-bus-allows problem.
>
> Jonathan (Lockhart), if I'm right, then in your
> rfnoc_ce_auto_inst_e310.v, if you change the ce_clk/ce_rst in the
> noc_block_split_stream instantiation to bus_clk/bus_rst, this may fix the
> problem.
>
> Nick
>
> On Fri, Nov 8, 2019 at 10:20 AM Jonathon Pendlum <
> jonathon.pend...@ettus.com> wrote:
>
>> Hi Jon,
>>
>> Can you try reverting commit e39334fe on the fpga repo and rebuilding
>> your bitstream? Let me know if that makes a difference or not.
>>
>> Jonathon
>>
>> On Sat, Nov 9, 2019 at 12:13 AM Jonathan Lockhart via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Greetings Nick,
>>>
>>> Here is the screenshot of my GR flow graph, though it shouldn't
>>> matter as the Split_Stream RFNoC Block I believe is a failure of the 
>>> python
>>> or Verilog but the solutions in the link I sent in my previous email did
>>> not resolve the issue.
>>>
>>> [image: Screenshot from 2019-11-08 10-06-50.png]
>>>
>>> Regards,
>>> Jon
>>>
>>> On Thu, Nov 7, 2019 at 5:33 PM Nick Foster 
>>> wrote:
>>>
 Can you be more specific about what your flowgraph looks like?

 On Thu, Nov 7, 2019 at 2:22 PM Jonathan Lockhart via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Greetings,
>
> I was wondering if anyone had encountered the following error and
> had a way to fix it?
>
> [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700;
> UHD_3.14.1.HEAD-0-g0347a6d8
> [INFO] [E300] Loading FPGA image:
> /home/root/localinstall/e300.bit...
> 

Re: [USRP-users] Receiving IO Block Error when Using RFNoC Split Stream

[Nick Foster via USRP-users]

Can you be more specific about what your flowgraph looks like?

On Thu, Nov 7, 2019 at 2:22 PM Jonathan Lockhart via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Greetings,
>
> I was wondering if anyone had encountered the following error and had a
> way to fix it?
>
> [INFO] [UHD] linux; GNU C++ version 4.9.2; Boost_105700;
> UHD_3.14.1.HEAD-0-g0347a6d8
> [INFO] [E300] Loading FPGA image: /home/root/localinstall/e300.bit...
> [INFO] [E300] FPGA image loaded
> [INFO] [E300] Detecting internal GPS
>  [INFO] [E300] GPSDO found
> [INFO] [E300] Initializing core control (global registers)...
>
> [INFO] [E300] Performing register loopback test...
> [INFO] [E300] Register loopback test passed
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1000)
> [WARNING] [RFNOC] Can't find a block controller for key SplitStream, using
> default block controller!
> [INFO] [0/SplitStream_0] Initializing block control (NOC ID:
> 0x5757)
> [ERROR] [UHD] Exception caught in safe-call.
>   in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with
> uhd::endianness_t _endianness = (uhd::endianness_t)1u]
>   at /home/jon/rfnoc_3.14.1.1/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:52
> this->send_cmd_pkt(0, 0, true); -> EnvironmentError: IOError: Block ctrl
> (CE_01_Port_21) no response packet - AssertionError: bool(buff)
>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
> [with uhd::endianness_t _endianness = (uhd::endianness_t)1u; uint64_t =
> long long unsigned int]
>   at /home/jon/rfnoc_3.14.1.1/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:142
>
> Traceback (most recent call last):
>   File "rfnoc_fosphor_network_usrp.py", line 283, in 
> main()
>   File "rfnoc_fosphor_network_usrp.py", line 272, in main
> tb = top_block_cls(fft_size=options.fft_size,
> fpga_path=options.fpga_path, freq=options.freq, gain=options.gain,
> host_ip_addr=options.host_ip_addr, samp_rate=options.samp_rate,
> tdecay=options.tdecay, trise=options.trise)
>   File "rfnoc_fosphor_network_usrp.py", line 43, in __init__
> self.device3 = variable_uhd_device3_0 =
> ettus.device3(uhd.device_addr_t( ",".join(('type=e3x0',
> "master_clock_rate=%d,fpga=%s" % (samp_rate,fpga_path))) ))
>   File
> "/home/root/localinstall/usr/lib/python2.7/site-packages/ettus/ettus_swig.py",
> line 1307, in make
> return _ettus_swig.device3_make(*args, **kwargs)
> RuntimeError: EnvironmentError: IOError: [0/SplitStream_0] sr_read64()
> failed: EnvironmentError: IOError: Block ctrl (CE_01_Port_21) no response
> packet - AssertionError: bool(buff)
>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
> [with uhd::endianness_t _endianness = (uhd::endianness_t)1u; uint64_t =
> long long unsigned int]
>   at /home/jon/rfnoc_3.14.1.1/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:142
>
> This is only occurring when I use the split stream block in RFNoC. I have
> tried the fixes in [1] but unfortunately they have not helped. Also, fix 1,
> I can't seem to before b/c I am missing the file
> rfnoc_ce_auto_inst_.v  as shown from the output when attempting a
> "find" command in Ubuntu.
>
> find: ‘rfnoc_ce_auto_inst_e310.v’: No such file or directory
>
> I ran it on both ~/* and /* with no luck.
>
> Regards,
> Jon Lockhart
>
> [1] https://kb.ettus.com/RFNoC#Why_do_I_have_a_command_timeout_error.3F
>
> ___
> 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

Re: [USRP-users] Controlling an X310 from embedded devices

[Nick Foster via USRP-users]

You should have no trouble running UHD on an ARM architecture. The Ettus
E300 series radios are ARM devices. UHD does a huge amount of
initialization and configuration for the X310, and in any case the X310
doesn't use VRT in any real capacity. You won't realistically be able to
divorce the X310 from UHD.

Your biggest headache on an embedded machine will be keeping up with high
data rates, and waiting for UHD to compile in the first place. =)

Nick

On Wed, Oct 23, 2019 at 4:59 PM Muri, Richard - 1002 - MITLL via USRP-users
 wrote:

> Hello,
>
>
>
> I’m looking into controlling an X310 from an embedded device. I wanted to
> probe the users list before I bury myself into a rabbit hole.
>
>
>
> Is it possible to control a USRP directly from an FPGA? I noticed that UHD
> use VRT as the transport protocol (
> http://files.ettus.com/manual/page_rtp.html). If I have an FPGA that
> speaks VRT over Ethernet or Aurora can I control a USRP, and are there
> examples/documentation of controlling a USRP without running an instance of
> UHD? In my use case I need to send timed transmit commands and data
> packets, and timed receive commands and receive data packets.
>
>
>
> In the case that running without UHD is a headache I don’t want to brave,
> are there examples of running UHD on ARM cores?
>
>
>
> Any insight is appreciated.
>
>
>
> Thanks,
>
> Richard
>
>
>
>
> ___
> 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

Re: [USRP-users] Addsub HLS Block Error

[Nick Foster via USRP-users]

Yes, I've used it, no custom block controller required. Attached are XML
and GRC descriptors.

On Sat, Sep 7, 2019 at 11:22 AM d.des  wrote:

> I wonder if you have successfully used this block with grc or if you
> were just using it with uhd. When I try to use the 2-input, 1-output
> block in grc I get: "RuntimeError: Invalid stream args." this looks
> like same issue as
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-August/057702.html
> and the solution at that time seemed to be to keep the second port so
> as not to confuse the streamer.
>
> In case I'm doing something dumb in the xml, here are the files I
> created for uhd and grc:
>
> 
> 
> 
>   addonly
>   addonly
>   
> 41253002
>   
>   
> 
>   in0
> 
> 
>   in1
> 
> 
>   out
> 
>   
> 
>
>
>
> 
> 
>   RFNoC: addonly
>   dave_addonly
>   import ettus
>   ettus.rfnoc_generic(
> self.device3,
> uhd.stream_args( \# TX Stream Args
> cpu_format="$type", \# TODO: This must be made an option
> otw_format="sc16",
> channels=(0,1),
> args="align=1",
> ),
> uhd.stream_args( \# RX Stream Args
> cpu_format="$type",
> otw_format="sc16",
> channels=(0,1),
> args="align=1",
> ),
> "addonly", $block_index, $device_index,
> )
>
>   
> Host Data Type
> type
> enum
> 
>   Complex float32
>   fc32
>   type:fc32
> 
> 
>   Complex int16
>   sc16
>   type:sc16
> 
>   
>
>   
> dcovariance Select
> block_index
> -1
> int
> #if int($block_index())  0 then 'part' else
> 'none'#
> RFNoC Config
>   
>   
> Device Select
> device_index
> -1
> int
> #if int($device_index())  0 then 'part' else
> 'none'#
> RFNoC Config
>   
>
>   
> FPGA Module Name
> fpga_module_name
> noc_block_dcovariance
> string
> all
> RFNoC Config
>   
>
>   
> in
> $type.type
> rfnoc
> 2
>   
>
>   
> out
> $type.type
> rfnoc
>   
> 
>
>
> The messages just before the error are:
> [DEBUG] [DEVICE3] Port 0x20: Found NoC-Block with ID 41253002.
> [DEBUG] [RFNOC] Reading XML file
> /home/root/localinstall/usr/share/uhd/rfnoc/blocks/addonly.xml for NOC
> ID 0x41253002
> [DEBUG] [E300] [E300] Setting up dest map for host ep 35 to be stream 3
>
> [TRACE] [RFNOC] [RFNoC Factory] block_ctrl_base::make()
> [DEBUG] [RFNOC] Reading XML file
> /home/root/localinstall/usr/share/uhd/rfnoc/blocks/addonly.xml for NOC
> ID 0x41253002
> [WARNING] [RFNOC] Can't find a block controller for key addonly, using
> default block controller!
> [TRACE] [RFNOC] [RFNoC Factory] Using controller key 'Block' and block
> name 'addonly'
> [DEBUG] [RFNOC] Reading XML file
> /home/root/localinstall/usr/share/uhd/rfnoc/blocks/addonly.xml for NOC
> ID 0x41253002
> [INFO] [0/dcorrelate_0] Initializing block control (NOC ID:
> 0x41253002)
> [DEBUG] [0/dcorrelate_0] Checking compat number for FPGA component
> `noc_shell': Expecting 5.1, actual: 5.1.
> [TRACE] [0/addonly_0] Adding port definition at
> xbar/dcorrelate_0/ports/in/0: type = '' pkt_size = '0' vlen = '0'
> [TRACE] [0/addonly_0] Adding port definition at
> xbar/dcorrelate_0/ports/in/1: type = '' pkt_size = '0' vlen = '0'
> [TRACE] [0/addonly_0] Adding port definition at
> xbar/addonly_0/ports/out/0: type = '' pkt_size = '0' vlen = '0'
> [DEBUG] [E300] [E300] Setting up dest map for host ep 36 to be stream 4
>
> :
> 
> :
> [DEBUG] [E300] Actually got clock rate 10 MHz
>
> [DEBUG] [CORES] Performing timer loopback test...
> [DEBUG] [CORES] Timer loopback test passed.
> [TRACE] [RFNOC] e3xx_radio_ctrl_impl::_update_enables()
>
> [TRACE] [RFNOC] e3xx_radio_ctrl_impl::_update_gpio_state()
>
> Traceback (most recent call last):
>   File "./dave_addonly_usrp.py", line 169, in 
> main()
>   File "./dave_addonly_usrp.py", line 158, in main
> tb = top_block_cls()
>   File "./dave_addonly_usrp.py", line 94, in __init__
> "addonly", -1, -1,
>   File "/home/root/localinstall/usr/lib/python2.7/site-
> packages/ettus/ettus_swig.py", line 3270, in make
> return _ettus_swig.rfnoc_generic_make(*args, **kwargs)
> RuntimeError: Invalid stream args.
>
> It never gets to the part where it attempts to connect ports together.
>
>
> The line in the Python launcher that generates the error is:
>
> self.dave_addonly_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",
> channels=(0,1),
> args="align=1",
> ),
> uhd.stream_args( # RX Stream Args
> cpu_format="fc32",
> otw_format="sc16",
> channels=(0,1),
> args="align=1",
> ),
> "addonly", -1, -1,
> )
>
>
> Maybe 

Re: [USRP-users] Addsub HLS Block Error

[Nick Foster via USRP-users]

Here's a modified add-only block. You'll have to make a matching .xml
descriptor and GRC block (if you're using gr-ettus).

Probably it would be a super useful thing to have an add/sub block, instead
of an addsub block. A register-controlled mux to select which operation you
want. I'll think about adding that to the Theseus Cores project.

Nick

On Fri, Sep 6, 2019 at 3:18 PM d.des via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Nick-
> Could you share the tricks to remove one of the output ports? I don't
> I'm having similar issues with my modified addsub block and don't have
> enough room on the e310 fpga for extra fifos. It's not obvious from the
> noc_block_addsub code, the use of splitstream and dummy variables is
> very confusing.
>
> Tnx,
> Dave (and I'm sure many others, based on threads I've seen in searches)
>
> 
> From: Nick Foster 
> Sent: Tuesday, September 3, 2019 11:45:46 PM
> To: Quadri,Adnan 
> Cc: usrp-users at lists.ettus.com 
> Subject: Re: [USRP-users] Addsub HLS Block Error
>
> That shouldn't be. Even if you connect both outputs to the host?
>
> I admit I got fed up with it in my own application (don't want both
> streams going into the host) and just modified the addsub block to be
> an add-only block.
>
> On Tue, Sep 3, 2019 at 8:43 PM Quadri,Adnan  louisville.edu> wrote:
> I tried connecting one Signal Source block to both the inputs of addsub
> block. It still throws the same error.
>
> Adnan
> 
> From: Nick Foster mailto:bistromath at
> gmail.com>>
> Sent: Tuesday, September 3, 2019 11:40:05 PM
> To: Quadri,Adnan mailto:adnan.quadri at
> louisville.edu>>
> Cc: usrp-users at lists.ettus.com
> mailto:usrp-users at lists.ettus.com>>
> Subject: Re: [USRP-users] Addsub HLS Block Error
>
> Oh, I see. You have separate sources connected to the same addsub
> block. It's telling you that you need to use timed stream commands to
> start the stream, or else you will see undefined behavior. Personally I
> think that error should be demoted to a warning -- anyone from Ettus
> want to chime in?
>
> On Tue, Sep 3, 2019 at 3:53 PM Quadri,Adnan  louisville.edu> wrote:
> Hello,
>
> Thank you for your prompt response. I have connected both the addsub
> output to two QT Gui Sink but I still get the same error. I have the
> Copy block in the middle as well.
>
> I am attaching a screenshot of my flowgraph. I tried with different
> USRP sources/Signal Sources as well. But it is the same error.
>
> Thanks,
> Adnan
>
> 
> From: Nick Foster mailto:bistromath at
> gmail.com>>
> Sent: Tuesday, September 3, 2019 3:57 PM
> To: Quadri,Adnan mailto:adnan.quadri at
> louisville.edu>>
> Cc: usrp-users at lists.ettus.com
> mailto:usrp-users at lists.ettus.com>>
> Subject: Re: [USRP-users] Addsub HLS Block Error
>
> I ran into this the other day and it's independent of the HLS component
> of the addsub block (since the interface is identical). You need to
> connect both outputs of the addsub block to something, even a null
> sink. I'm pretty sure this wasn't the intended behavior and also pretty
> sure that it wasn't like this last time I checked (which was more than
> a year ago), so maybe it should be filed as a bug.
>
> Nick
>
> On Tue, Sep 3, 2019 at 1:48 PM Quadri,Adnan via USRP-users  at lists.ettus.com> wrote:
> Hello,
>
> We are trying to run the RFNoC addsub HLS block.
>
> I was able to build the FPGA Image and made sure in the noc_block
> verilog code to point to the HLS implementation for addsub block on
> RFNoC as opposed to the verilog/VHDL implementation.
>
> But when we run the example Flowgraph with two signal source as input
> to the two inputs for addsub block on GRC, we get the following error -
>
> ERROR:
> thread[thread-per-block[4]: ]:
> RuntimeError: Invalid recv stream command - stream now on multiple
> channels in a single streamer will fail to time align.
>
> Does this have anything to do with the C++ code for HLS implementation
> or is it a problem at UHD level?
>
> Thanks,
> Adnan
> ___
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com<
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com=DwMFaQ=OAG1LQNACBDguGvBeNj18Swhr9TMTjS-x4O_KuapPgY=JoNl3b2Pn0MHhs668QvjpcSGl6s3MEmtJLBypH6x02U=XH0fqWeFmcl-P0_Y01iOhbHXEKDsJDUBaImT_nfh0t4=_hsJH03rqnDSUZXWGyx31-8I7HJLsU5_S5hs-j5_WRw=
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20190904/3138375d/attachment.html
> >
>
>
> 

Re: [USRP-users] Addsub HLS Block Error

[Nick Foster via USRP-users]

That shouldn't be. Even if you connect both outputs to the host?

I admit I got fed up with it in my own application (don't want both streams
going into the host) and just modified the addsub block to be an add-only
block.

On Tue, Sep 3, 2019 at 8:43 PM Quadri,Adnan 
wrote:

> I tried connecting one Signal Source block to both the inputs of addsub
> block. It still throws the same error.
>
> Adnan
> --
> *From:* Nick Foster 
> *Sent:* Tuesday, September 3, 2019 11:40:05 PM
> *To:* Quadri,Adnan 
> *Cc:* usrp-users@lists.ettus.com 
> *Subject:* Re: [USRP-users] Addsub HLS Block Error
>
> Oh, I see. You have separate sources connected to the same addsub block.
> It's telling you that you need to use timed stream commands to start the
> stream, or else you will see undefined behavior. Personally I think that
> error should be demoted to a warning -- anyone from Ettus want to chime in?
>
> On Tue, Sep 3, 2019 at 3:53 PM Quadri,Adnan 
> wrote:
>
>> Hello,
>>
>> Thank you for your prompt response. I have connected both the addsub
>> output to two QT Gui Sink but I still get the same error. I have the Copy
>> block in the middle as well.
>>
>> I am attaching a screenshot of my flowgraph. I tried with different USRP
>> sources/Signal Sources as well. But it is the same error.
>>
>> Thanks,
>> Adnan
>>
>> --
>> *From:* Nick Foster 
>> *Sent:* Tuesday, September 3, 2019 3:57 PM
>> *To:* Quadri,Adnan 
>> *Cc:* usrp-users@lists.ettus.com 
>> *Subject:* Re: [USRP-users] Addsub HLS Block Error
>>
>> I ran into this the other day and it's independent of the HLS component
>> of the addsub block (since the interface is identical). You need to connect
>> both outputs of the addsub block to something, even a null sink. I'm pretty
>> sure this wasn't the intended behavior and also pretty sure that it wasn't
>> like this last time I checked (which was more than a year ago), so maybe it
>> should be filed as a bug.
>>
>> Nick
>>
>> On Tue, Sep 3, 2019 at 1:48 PM Quadri,Adnan via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>> Hello,
>>
>> We are trying to run the RFNoC addsub HLS block.
>>
>> I was able to build the FPGA Image and made sure in the noc_block verilog
>> code to point to the HLS implementation for addsub block on RFNoC as
>> opposed to the verilog/VHDL implementation.
>>
>> But when we run the example Flowgraph with two signal source as input to
>> the two inputs for addsub block on GRC, we get the following error -
>>
>> ERROR:
>> thread[thread-per-block[4]: ]: RuntimeError:
>> Invalid recv stream command - stream now on multiple channels in a single
>> streamer will fail to time align.
>>
>> Does this have anything to do with the C++ code for HLS implementation or
>> is it a problem at UHD level?
>>
>> Thanks,
>> Adnan
>> ___
>> 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

Re: [USRP-users] Addsub HLS Block Error

[Nick Foster via USRP-users]

Oh, I see. You have separate sources connected to the same addsub block.
It's telling you that you need to use timed stream commands to start the
stream, or else you will see undefined behavior. Personally I think that
error should be demoted to a warning -- anyone from Ettus want to chime in?

On Tue, Sep 3, 2019 at 3:53 PM Quadri,Adnan 
wrote:

> Hello,
>
> Thank you for your prompt response. I have connected both the addsub
> output to two QT Gui Sink but I still get the same error. I have the Copy
> block in the middle as well.
>
> I am attaching a screenshot of my flowgraph. I tried with different USRP
> sources/Signal Sources as well. But it is the same error.
>
> Thanks,
> Adnan
>
> --
> *From:* Nick Foster 
> *Sent:* Tuesday, September 3, 2019 3:57 PM
> *To:* Quadri,Adnan 
> *Cc:* usrp-users@lists.ettus.com 
> *Subject:* Re: [USRP-users] Addsub HLS Block Error
>
> I ran into this the other day and it's independent of the HLS component of
> the addsub block (since the interface is identical). You need to connect
> both outputs of the addsub block to something, even a null sink. I'm pretty
> sure this wasn't the intended behavior and also pretty sure that it wasn't
> like this last time I checked (which was more than a year ago), so maybe it
> should be filed as a bug.
>
> Nick
>
> On Tue, Sep 3, 2019 at 1:48 PM Quadri,Adnan via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hello,
>
> We are trying to run the RFNoC addsub HLS block.
>
> I was able to build the FPGA Image and made sure in the noc_block verilog
> code to point to the HLS implementation for addsub block on RFNoC as
> opposed to the verilog/VHDL implementation.
>
> But when we run the example Flowgraph with two signal source as input to
> the two inputs for addsub block on GRC, we get the following error -
>
> ERROR:
> thread[thread-per-block[4]: ]: RuntimeError:
> Invalid recv stream command - stream now on multiple channels in a single
> streamer will fail to time align.
>
> Does this have anything to do with the C++ code for HLS implementation or
> is it a problem at UHD level?
>
> Thanks,
> Adnan
> ___
> 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

Re: [USRP-users] Addsub HLS Block Error

[Nick Foster via USRP-users]

I ran into this the other day and it's independent of the HLS component of
the addsub block (since the interface is identical). You need to connect
both outputs of the addsub block to something, even a null sink. I'm pretty
sure this wasn't the intended behavior and also pretty sure that it wasn't
like this last time I checked (which was more than a year ago), so maybe it
should be filed as a bug.

Nick

On Tue, Sep 3, 2019 at 1:48 PM Quadri,Adnan via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> We are trying to run the RFNoC addsub HLS block.
>
> I was able to build the FPGA Image and made sure in the noc_block verilog
> code to point to the HLS implementation for addsub block on RFNoC as
> opposed to the verilog/VHDL implementation.
>
> But when we run the example Flowgraph with two signal source as input to
> the two inputs for addsub block on GRC, we get the following error -
>
> ERROR:
> thread[thread-per-block[4]: ]: RuntimeError:
> Invalid recv stream command - stream now on multiple channels in a single
> streamer will fail to time align.
>
> Does this have anything to do with the C++ code for HLS implementation or
> is it a problem at UHD level?
>
> Thanks,
> Adnan
> ___
> 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

Re: [USRP-users] RFNoC Polyphase Channelizer updates

[Nick Foster via USRP-users]

Last ditch, does your application permit aliasing? I.e., do you need to be
able to receive all four channels simultaneously? It would be
computationally cheap to sample at 5Msps and alias to 1Msps, then filter in
the CPU. You'd have to rotate two of the carriers down to baseband but the
sample rate would be ~20kHz at that point, easily done.

Nick

On Thu, Aug 8, 2019 at 11:55 AM Royce Connerley 
wrote:

> Nick:
>
> That was my first approach, but I can’t even fit two DDCs in the E310 FPGA.
>
> Royce
>
> On Aug 8, 2019, at 1:36 PM, Nick Foster  wrote:
>
> Nevermind, I just saw you're doing it in an E310. Reading is fundamental.
>
> You might consider splitting the problem into a pair of DDCs instead.
>
> Nick
>
> On Thu, Aug 8, 2019 at 11:35 AM Nick Foster  wrote:
>
>> Royce,
>>
>> Is there a reason you absolutely need it to be done in RFNoC? This is
>> only 5MHz of bandwidth, and any commodity PC should be able to handle
>> channelizing it in software.
>>
>> Nick
>>
>> On Thu, Aug 8, 2019 at 11:19 AM Royce Connerley via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> EJ:
>>>
>>> I’m currently wanting to receive a total of four channels that are 12.5
>>> kHz wide.  The channels are not equally spaced.
>>>
>>> F2 = F1 + 1 MHz
>>> F3 = F1 + 3.99375 MHz
>>> F4 = F3 + 1 MHz
>>>
>>> For this type of system, I typically have a number of channel pairs
>>> (repeater output and input separated by 1 MHz) that I need to monitor.
>>>
>>> Royce
>>>
>>> On Aug 8, 2019, at 8:51 AM, EJ Kreinar  wrote:
>>>
>>> Hi Royce,
>>>
>>> Can you walk me through your use case real quick?
>>>
>>> - How many channels?
>>> - How wide is each channel?
>>> - Are the channels equally spaced?
>>>
>>> The polyphase channelizer in theseus-cores currently has a static number
>>> of "max channels" that get instantiated which is not insignificant.
>>> We've discussed exposing a build-time parameter that could scale down the
>>> max number of channels to save some resources, but 1) that hasn't been
>>> implemented yet and 2) I'm not totally confident it would fit in the e310
>>> anyway.
>>>
>>> But lets think through your scenario and we can discuss where we'd need
>>> the channelizer to go for it to work... for example, you probably also need
>>> the FPGA-based channel downselection in the channelizer -- the E310 wont be
>>> able to return all channels in real time! Or, we could consider other
>>> approaches -- the DDC channelizer in theseus-cores might be workable if you
>>> have just small number of channels and you need arbitrary spacing/channel
>>> widths.
>>>
>>> EJ
>>>
>>> On Thu, Aug 8, 2019, 8:52 AM Royce Connerley 
>>> wrote:
>>>
 EJ:

 I want to pick a few narrowband channels scattered over about 5 MHz.  I
 would like to be able to use your channelizer in an E310.  Do you think it
 could fit in the E310’s FPGA?  When I run uhd_image_builder with just the
 channelizer and a FIFO, I’m seeing the following errors:

 ERROR: [Place 30-640] Place Check : This design requires more
 RAMB36/FIFO cells than are available in the target device. This design
 requires 324 of such cell types but only 140 compatible sites are available
 in the target device. Please analyze your synthesis results and constraints
 to ensure the design is mapped to Xilinx primitives as expected. If so,
 please consider targeting a larger device.
 ERROR: [Place 30-640] Place Check : This design requires more RAMB18
 and RAMB36/FIFO cells than are available in the target device. This design
 requires 703 of such cell types but only 280 compatible sites are available
 in the target device. Please analyze your synthesis results and constraints
 to ensure the design is mapped to Xilinx primitives as expected. If so,
 please consider targeting a larger device.
 ERROR: [Place 30-640] Place Check : This design requires more RAMB36E1
 cells than are available in the target device. This design requires 324 of
 such cell types but only 140 compatible sites are available in the target
 device. Please analyze your synthesis results and constraints to ensure the
 design is mapped to Xilinx primitives as expected. If so, please consider
 targeting a larger device.

 Royce Connerley

 On Jul 24, 2019, at 6:34 PM, EJ Kreinar  wrote:

 Hi Royce,

 Phil and I have been working on the channelizer in the theseus-cores
 repo here: gitlab.com/theseus-cores/theseus-cores

 The master branch has a (potentially) working channelizer, at least
 according to my recent tests on the x310, as long as the network interface
 supports the desired output rate.

 There's also an fpga solution for channel downselection in a branch
 that Phil put together. The ball is in my court to turn the crank and merge
 to master with supporting software, but I haven't gotten much of a chance
 recently.

 If you're interested in 

Re: [USRP-users] RFNoC Polyphase Channelizer updates

[Nick Foster via USRP-users]

Nevermind, I just saw you're doing it in an E310. Reading is fundamental.

You might consider splitting the problem into a pair of DDCs instead.

Nick

On Thu, Aug 8, 2019 at 11:35 AM Nick Foster  wrote:

> Royce,
>
> Is there a reason you absolutely need it to be done in RFNoC? This is only
> 5MHz of bandwidth, and any commodity PC should be able to handle
> channelizing it in software.
>
> Nick
>
> On Thu, Aug 8, 2019 at 11:19 AM Royce Connerley via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> EJ:
>>
>> I’m currently wanting to receive a total of four channels that are 12.5
>> kHz wide.  The channels are not equally spaced.
>>
>> F2 = F1 + 1 MHz
>> F3 = F1 + 3.99375 MHz
>> F4 = F3 + 1 MHz
>>
>> For this type of system, I typically have a number of channel pairs
>> (repeater output and input separated by 1 MHz) that I need to monitor.
>>
>> Royce
>>
>> On Aug 8, 2019, at 8:51 AM, EJ Kreinar  wrote:
>>
>> Hi Royce,
>>
>> Can you walk me through your use case real quick?
>>
>> - How many channels?
>> - How wide is each channel?
>> - Are the channels equally spaced?
>>
>> The polyphase channelizer in theseus-cores currently has a static number
>> of "max channels" that get instantiated which is not insignificant.
>> We've discussed exposing a build-time parameter that could scale down the
>> max number of channels to save some resources, but 1) that hasn't been
>> implemented yet and 2) I'm not totally confident it would fit in the e310
>> anyway.
>>
>> But lets think through your scenario and we can discuss where we'd need
>> the channelizer to go for it to work... for example, you probably also need
>> the FPGA-based channel downselection in the channelizer -- the E310 wont be
>> able to return all channels in real time! Or, we could consider other
>> approaches -- the DDC channelizer in theseus-cores might be workable if you
>> have just small number of channels and you need arbitrary spacing/channel
>> widths.
>>
>> EJ
>>
>> On Thu, Aug 8, 2019, 8:52 AM Royce Connerley 
>> wrote:
>>
>>> EJ:
>>>
>>> I want to pick a few narrowband channels scattered over about 5 MHz.  I
>>> would like to be able to use your channelizer in an E310.  Do you think it
>>> could fit in the E310’s FPGA?  When I run uhd_image_builder with just the
>>> channelizer and a FIFO, I’m seeing the following errors:
>>>
>>> ERROR: [Place 30-640] Place Check : This design requires more
>>> RAMB36/FIFO cells than are available in the target device. This design
>>> requires 324 of such cell types but only 140 compatible sites are available
>>> in the target device. Please analyze your synthesis results and constraints
>>> to ensure the design is mapped to Xilinx primitives as expected. If so,
>>> please consider targeting a larger device.
>>> ERROR: [Place 30-640] Place Check : This design requires more RAMB18 and
>>> RAMB36/FIFO cells than are available in the target device. This design
>>> requires 703 of such cell types but only 280 compatible sites are available
>>> in the target device. Please analyze your synthesis results and constraints
>>> to ensure the design is mapped to Xilinx primitives as expected. If so,
>>> please consider targeting a larger device.
>>> ERROR: [Place 30-640] Place Check : This design requires more RAMB36E1
>>> cells than are available in the target device. This design requires 324 of
>>> such cell types but only 140 compatible sites are available in the target
>>> device. Please analyze your synthesis results and constraints to ensure the
>>> design is mapped to Xilinx primitives as expected. If so, please consider
>>> targeting a larger device.
>>>
>>> Royce Connerley
>>>
>>> On Jul 24, 2019, at 6:34 PM, EJ Kreinar  wrote:
>>>
>>> Hi Royce,
>>>
>>> Phil and I have been working on the channelizer in the theseus-cores
>>> repo here: gitlab.com/theseus-cores/theseus-cores
>>>
>>> The master branch has a (potentially) working channelizer, at least
>>> according to my recent tests on the x310, as long as the network interface
>>> supports the desired output rate.
>>>
>>> There's also an fpga solution for channel downselection in a branch that
>>> Phil put together. The ball is in my court to turn the crank and merge to
>>> master with supporting software, but I haven't gotten much of a chance
>>> recently.
>>>
>>> If you're interested in testing we could definitely use some more people
>>> to give it a shot :D Let me know if you need a sample bitstream or if you
>>> can build one yourself.
>>>
>>> EJ
>>>
>>> On Wed, Jul 24, 2019, 4:39 PM Royce Connerley via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 At the 2018 GRCon, EJ Kreinar spoke about improvements to the RFNoC
 polyphase channelizer.  Has there been any activity on this?

 Royce Connerley
 ___
 USRP-users mailing list
 USRP-users@lists.ettus.com
 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

>>>
>>>
>> 

Re: [USRP-users] RFNoC Polyphase Channelizer updates

[Nick Foster via USRP-users]

Royce,

Is there a reason you absolutely need it to be done in RFNoC? This is only
5MHz of bandwidth, and any commodity PC should be able to handle
channelizing it in software.

Nick

On Thu, Aug 8, 2019 at 11:19 AM Royce Connerley via USRP-users <
usrp-users@lists.ettus.com> wrote:

> EJ:
>
> I’m currently wanting to receive a total of four channels that are 12.5
> kHz wide.  The channels are not equally spaced.
>
> F2 = F1 + 1 MHz
> F3 = F1 + 3.99375 MHz
> F4 = F3 + 1 MHz
>
> For this type of system, I typically have a number of channel pairs
> (repeater output and input separated by 1 MHz) that I need to monitor.
>
> Royce
>
> On Aug 8, 2019, at 8:51 AM, EJ Kreinar  wrote:
>
> Hi Royce,
>
> Can you walk me through your use case real quick?
>
> - How many channels?
> - How wide is each channel?
> - Are the channels equally spaced?
>
> The polyphase channelizer in theseus-cores currently has a static number
> of "max channels" that get instantiated which is not insignificant.
> We've discussed exposing a build-time parameter that could scale down the
> max number of channels to save some resources, but 1) that hasn't been
> implemented yet and 2) I'm not totally confident it would fit in the e310
> anyway.
>
> But lets think through your scenario and we can discuss where we'd need
> the channelizer to go for it to work... for example, you probably also need
> the FPGA-based channel downselection in the channelizer -- the E310 wont be
> able to return all channels in real time! Or, we could consider other
> approaches -- the DDC channelizer in theseus-cores might be workable if you
> have just small number of channels and you need arbitrary spacing/channel
> widths.
>
> EJ
>
> On Thu, Aug 8, 2019, 8:52 AM Royce Connerley 
> wrote:
>
>> EJ:
>>
>> I want to pick a few narrowband channels scattered over about 5 MHz.  I
>> would like to be able to use your channelizer in an E310.  Do you think it
>> could fit in the E310’s FPGA?  When I run uhd_image_builder with just the
>> channelizer and a FIFO, I’m seeing the following errors:
>>
>> ERROR: [Place 30-640] Place Check : This design requires more RAMB36/FIFO
>> cells than are available in the target device. This design requires 324 of
>> such cell types but only 140 compatible sites are available in the target
>> device. Please analyze your synthesis results and constraints to ensure the
>> design is mapped to Xilinx primitives as expected. If so, please consider
>> targeting a larger device.
>> ERROR: [Place 30-640] Place Check : This design requires more RAMB18 and
>> RAMB36/FIFO cells than are available in the target device. This design
>> requires 703 of such cell types but only 280 compatible sites are available
>> in the target device. Please analyze your synthesis results and constraints
>> to ensure the design is mapped to Xilinx primitives as expected. If so,
>> please consider targeting a larger device.
>> ERROR: [Place 30-640] Place Check : This design requires more RAMB36E1
>> cells than are available in the target device. This design requires 324 of
>> such cell types but only 140 compatible sites are available in the target
>> device. Please analyze your synthesis results and constraints to ensure the
>> design is mapped to Xilinx primitives as expected. If so, please consider
>> targeting a larger device.
>>
>> Royce Connerley
>>
>> On Jul 24, 2019, at 6:34 PM, EJ Kreinar  wrote:
>>
>> Hi Royce,
>>
>> Phil and I have been working on the channelizer in the theseus-cores repo
>> here: gitlab.com/theseus-cores/theseus-cores
>>
>> The master branch has a (potentially) working channelizer, at least
>> according to my recent tests on the x310, as long as the network interface
>> supports the desired output rate.
>>
>> There's also an fpga solution for channel downselection in a branch that
>> Phil put together. The ball is in my court to turn the crank and merge to
>> master with supporting software, but I haven't gotten much of a chance
>> recently.
>>
>> If you're interested in testing we could definitely use some more people
>> to give it a shot :D Let me know if you need a sample bitstream or if you
>> can build one yourself.
>>
>> EJ
>>
>> On Wed, Jul 24, 2019, 4:39 PM Royce Connerley via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> At the 2018 GRCon, EJ Kreinar spoke about improvements to the RFNoC
>>> polyphase channelizer.  Has there been any activity on this?
>>>
>>> Royce Connerley
>>> ___
>>> 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

Re: [USRP-users] Delayed samples receiving, X310

[Nick Foster via USRP-users]

This is exactly what the "timed commands" feature is used for. See the
documentation here:

https://files.ettus.com/manual/structuhd_1_1stream__cmd__t.html

On Wed, Aug 7, 2019 at 7:15 AM Cherif Diouf via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello guys,
>
> I have developed a custom RFNoC CE connected to one radio core of the
> X310.
> The core will act as receiver and provide samples to my CE for further
> processing (Antennas-> RX frontend + noc_radio_core -> custom CE).
> However, I would like the radio core to start sampling and providing data only
> after a deterministic and fixed duration t0 consistent with the 5ns time
> counter and likely synchronized to an external PPS used as time reference.
>
> From python, I know I can use the "set_time_next_pps" call to initialize
> the USRP X310 time. But how to tell the radio core to stay in a idle state
> until the time keeper matches my duration t0?
> Can it be done by  software? Or the only option is to use CHDR packets and
> VITA timing?
>
> Best Regards
> Cherif
>
> ___
> 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

Re: [USRP-users] 214 MHz ce_clk vs 200 MHz radio_clk, USRP X310

[Nick Foster via USRP-users]

All synthesized clocks are synchronized to whatever reference is selected.

On Mon, Aug 5, 2019 at 1:03 PM Cherif Diouf  wrote:

> Thanks Nick,
>
>
> That's fine as explanation.  I however need a HW clock synchronized to the
> 10 MHz external reference. I am using some local counters to run timely
> operations. If not using the 200 MHz clock Is it possible to synchronize
> the 214 MHz clock to the 10 MHz external reference.
>
>
> Best Regards
>
> Cherif
>
>
> --
> *From:* Nick Foster 
> *Sent:* Monday, August 5, 2019 6:33:37 PM
> *To:* Cherif Diouf
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] 214 MHz ce_clk vs 200 MHz radio_clk, USRP X310
>
> The radio TX frontend backpressures upstream blocks. You don't have to
> worry about providing samples at the frontend rate. There is no reason to
> use a 200MHz clock in your block.
>
> Remember: if the frontend is operating at 200Msps, then the samples your
> block is producing must assume a 200Msps sample rate. It doesn't matter at
> all that the clock driving your block is 214MHz -- that only means that the
> logic is operating a bit faster.
>
> Nick
>
> On Mon, Aug 5, 2019 at 8:58 AM Cherif Diouf via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>>
>>
>>
>> --
>>
>> Hello guys,
>>
>>
>>
>> I am working with the X310 USRP. I have developed customed RFNoC CEs
>> running at ce_clk which is no more 200 MHz but rather 214 MHz.
>>
>> So my blocks are providing samples to the RF frontends at 214 MSps. Is
>> that right?
>>
>> Then how the operation can be consistent when the sampling rate of the RF
>> frontends is still at 200MSps.
>>
>>
>> Is it possible to synchronize both the 214 MHz and the 200 MHz clocks to
>> the same 10 MHz external reference, or to  use the 200 MHz reference clock
>> as my HW blocks main clock?
>>
>>
>>
>>
>> Best Regards
>>
>> Cherif
>> ___
>> 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

Re: [USRP-users] 214 MHz ce_clk vs 200 MHz radio_clk, USRP X310

[Nick Foster via USRP-users]

The radio TX frontend backpressures upstream blocks. You don't have to
worry about providing samples at the frontend rate. There is no reason to
use a 200MHz clock in your block.

Remember: if the frontend is operating at 200Msps, then the samples your
block is producing must assume a 200Msps sample rate. It doesn't matter at
all that the clock driving your block is 214MHz -- that only means that the
logic is operating a bit faster.

Nick

On Mon, Aug 5, 2019 at 8:58 AM Cherif Diouf via USRP-users <
usrp-users@lists.ettus.com> wrote:

>
>
>
> --
>
> Hello guys,
>
>
>
> I am working with the X310 USRP. I have developed customed RFNoC CEs
> running at ce_clk which is no more 200 MHz but rather 214 MHz.
>
> So my blocks are providing samples to the RF frontends at 214 MSps. Is
> that right?
>
> Then how the operation can be consistent when the sampling rate of the RF
> frontends is still at 200MSps.
>
>
> Is it possible to synchronize both the 214 MHz and the 200 MHz clocks to
> the same 10 MHz external reference, or to  use the 200 MHz reference clock
> as my HW blocks main clock?
>
>
>
>
> Best Regards
>
> Cherif
> ___
> 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

Re: [USRP-users] RFNoC Polyphase Channelizer updates

[Nick Foster via USRP-users]

I'll test! Forgot about this one and now have a very good use case for it.
I'll let you know how it goes.

On Wed, Jul 24, 2019 at 4:35 PM EJ Kreinar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Royce,
>
> Phil and I have been working on the channelizer in the theseus-cores repo
> here: gitlab.com/theseus-cores/theseus-cores
>
> The master branch has a (potentially) working channelizer, at least
> according to my recent tests on the x310, as long as the network interface
> supports the desired output rate.
>
> There's also an fpga solution for channel downselection in a branch that
> Phil put together. The ball is in my court to turn the crank and merge to
> master with supporting software, but I haven't gotten much of a chance
> recently.
>
> If you're interested in testing we could definitely use some more people
> to give it a shot :D Let me know if you need a sample bitstream or if you
> can build one yourself.
>
> EJ
>
> On Wed, Jul 24, 2019, 4:39 PM Royce Connerley via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> At the 2018 GRCon, EJ Kreinar spoke about improvements to the RFNoC
>> polyphase channelizer.  Has there been any activity on this?
>>
>> Royce Connerley
>> ___
>> 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

[USRP-users] Receiving response packets via UHD

[Nick Foster via USRP-users]

Hi all,

I've created an RFNoC block which sends back a response to indicate whether
a transmission successfully occurred or not, via the cmdout interface of
noc_shell. The Verilog is all fine and the testbench works using
pull_resp_pkt() to retrieve the data. I'm wondering how to receive that
same data in my host-side application. Do I need to create an rx streamer
for the block? This block doesn't send any sample data back to the host,
just the command response.

Any examples where I can see this done?

Thanks!
Nick
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Registering Block Controllers to UHD

[Nick Foster via USRP-users]

This thread might be helpful:

https://www.mail-archive.com/usrp-users@lists.ettus.com/msg07959.html

Nick

On Wed, Jun 19, 2019 at 6:35 AM Christian Valledor via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi All,
>
> I'm developing a few custom RFNoC Blocks for a UHD application I'm working
> on, and I've hit a snag getting UHD to work with my block controllers. Note
> that I went the C++ route instead of using nocscript and the default block
> controller to handle some more complex cases.
>
> The only way I have been able to get my application to work is if I move
> my custom controller files into the UHD directory, and re-compile.
> Otherwise it sees my block and XML, but doesn't register a key, and loads
> the default block controller.
>
> Is there another way to get UHD to play nice with my block without
> re-compiling it each time?
>
> thanks,
> -Christian
> ___
> 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

Re: [USRP-users] Waveform Shape Not Accurate

[Nick Foster via USRP-users]

Can you post the flowgraph you're using again? If you changed transmit gain
and amplitude, the result should have changed in amplitude, while the image
you just sent has the fame magnitude the last one did.

On Wed, Jun 19, 2019, 5:03 AM Simona Sibio  wrote:

> Thank you very much.
> I tried to send a signal with this features, but the result is the same
> (IMG_6590).
> I tried with every amplitude and every gain (Screenshot from 2019).
> Before, I thought that it was a problem of reference signal and I changed
> it but the situation is not changed.
>
> Thank you in advance for your help.
>
> Best Regards,
>
> Simona
>
> Il giorno mar 18 giu 2019 alle ore 18:06 Nick Foster 
> ha scritto:
>
>> Turn up the transmit gain on the USRP sink. Start with ~40dB and transmit
>> amplitude 0.3.
>>
>> Nick
>>
>> On Tue, Jun 18, 2019 at 9:40 AM Simona Sibio  wrote:
>>
>>> Thank you for the assistance.
>>> I tried to change the amplitude but the amplitude and frequency are not
>>> accurate in the oscilloscope yet.
>>> If I lower the amplitude, the S/N is lowered then it is worst.
>>>
>>> Best Regards,
>>>
>>> Simona
>>>
>>>
>>> Il giorno mar 18 giu 2019 alle ore 18:33 Nick Foster <
>>> bistrom...@gmail.com> ha scritto:
>>>
 Waveform source amplitude is too high. Turn it down to <0.4.

 On Tue, Jun 18, 2019 at 9:31 AM Simona Sibio via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Hi Michael,
>
> thank you for your interest.
>
> I have two N200 and each one have two daughterboard UBX-40; the
> transmitters are connected by coaxial cable to an oscilloscope
> (Rhode RTO2064) to check the waveform.
> The version of UHD is 3.13.0.
>
> I tried to send a constant signal using the flowgraph (Screenshot from
> 2019-06-18 14-56-57) in attachment on GNU radio Companion 3.7.13.4, and on
> the oscilloscope I saw this "IMG_6586".
> Also, I tried to generate a constant signal in Simulink model
> (16-42-17 & 16-14-04) on Matlab R2019a but, on the oscilloscope, I saw 
> this
> "IMG_6584".
>
> I tried to send a sine signal with the Simulink model in attachment
> (16-46-10) and, on the oscilloscope, I saw this "IMG_6583".
> Also I tried to generate the sine signal with GNU radio (17-08-58) and
> I saw this "IMG_6588".
>
> It is possible to see how the amplitude and frequency change in every
> case, I need to obtain an accurate signal because I have to measure the
> amplitude and phase in a particular point in the circuit.
> And in the previous email, I added that the problem increases when I
> lower the carrier frequency. All these measures were taken with a carrier
> frequency at 3 GHz, but if I change the fc at 1 GHz the shape is worst,
> e.g. IMG_6589.
>
> Thank you in advance.
>
> Best Regards,
>
> Simona
>
>
> Il giorno mar 18 giu 2019 alle ore 15:34 Michael Dickens <
> michael.dick...@ettus.com> ha scritto:
>
>> Hi Simona - Can you please educate us as to a few items?
>>
>> * your setup: you have an N200 + some daughterboard (which one) +
>> some spectrum analyzer (which one), connected ?somehow? -> are you doing
>> actual wireless Tx -> Rx, or do you have a cable hooked up between the 
>> N200
>> & spectrum analyzer?
>>
>> * what waveform you're trying to generate, and what is the actual
>> flowgraph you're using for GNU Radio? how are you generating the waveform
>> in MATLAB?
>>
>> * which version of GNU Radio and UHD are you trying to use?
>>
>> * which version of MATLAB and it's UHD are you trying to use?
>>
>> The above might help someone to diagnose your issue ... without it,
>> we can make some guesses but not much in the way of specifics.
>>
>> Please remember to "reply all", so that others can see your response
>> and be able to chime in to provide help. - MLD
>>
>> On Tue, Jun 18, 2019, at 8:42 AM, Simona Sibio via USRP-users wrote:
>>
>> Dear Sir/Madam,
>>
>> I am Simona Sibio, a student in Heriot Watt University.
>> I am working with USRPs both on Matlab and on Gnuradio, and with both
>> softwares I have the same problem: the shape (generated by
>> N200+daughterboard 10 MHz to 6 GHz) is not accurate, in attacched some
>> photos.
>> At 1 GHz, the shape is worst than when the carrier frequency is 3GHz.
>> It is not possible to measure the amplitude and frequency because,
>> also at 3 GHz, it is not stable.
>> Could you help me?
>>
>> Thank you in advance.
>>
>> Best Regards,
>>
>> Simona
>>
>>
>> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>

___
USRP-users mailing list

Re: [USRP-users] Waveform Shape Not Accurate

[Nick Foster via USRP-users]

Turn up the transmit gain on the USRP sink. Start with ~40dB and transmit
amplitude 0.3.

Nick

On Tue, Jun 18, 2019 at 9:40 AM Simona Sibio  wrote:

> Thank you for the assistance.
> I tried to change the amplitude but the amplitude and frequency are not
> accurate in the oscilloscope yet.
> If I lower the amplitude, the S/N is lowered then it is worst.
>
> Best Regards,
>
> Simona
>
>
> Il giorno mar 18 giu 2019 alle ore 18:33 Nick Foster 
> ha scritto:
>
>> Waveform source amplitude is too high. Turn it down to <0.4.
>>
>> On Tue, Jun 18, 2019 at 9:31 AM Simona Sibio via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi Michael,
>>>
>>> thank you for your interest.
>>>
>>> I have two N200 and each one have two daughterboard UBX-40; the
>>> transmitters are connected by coaxial cable to an oscilloscope
>>> (Rhode RTO2064) to check the waveform.
>>> The version of UHD is 3.13.0.
>>>
>>> I tried to send a constant signal using the flowgraph (Screenshot from
>>> 2019-06-18 14-56-57) in attachment on GNU radio Companion 3.7.13.4, and on
>>> the oscilloscope I saw this "IMG_6586".
>>> Also, I tried to generate a constant signal in Simulink model (16-42-17
>>> & 16-14-04) on Matlab R2019a but, on the oscilloscope, I saw this
>>> "IMG_6584".
>>>
>>> I tried to send a sine signal with the Simulink model in attachment
>>> (16-46-10) and, on the oscilloscope, I saw this "IMG_6583".
>>> Also I tried to generate the sine signal with GNU radio (17-08-58) and I
>>> saw this "IMG_6588".
>>>
>>> It is possible to see how the amplitude and frequency change in every
>>> case, I need to obtain an accurate signal because I have to measure the
>>> amplitude and phase in a particular point in the circuit.
>>> And in the previous email, I added that the problem increases when I
>>> lower the carrier frequency. All these measures were taken with a carrier
>>> frequency at 3 GHz, but if I change the fc at 1 GHz the shape is worst,
>>> e.g. IMG_6589.
>>>
>>> Thank you in advance.
>>>
>>> Best Regards,
>>>
>>> Simona
>>>
>>>
>>> Il giorno mar 18 giu 2019 alle ore 15:34 Michael Dickens <
>>> michael.dick...@ettus.com> ha scritto:
>>>
 Hi Simona - Can you please educate us as to a few items?

 * your setup: you have an N200 + some daughterboard (which one) + some
 spectrum analyzer (which one), connected ?somehow? -> are you doing actual
 wireless Tx -> Rx, or do you have a cable hooked up between the N200 &
 spectrum analyzer?

 * what waveform you're trying to generate, and what is the actual
 flowgraph you're using for GNU Radio? how are you generating the waveform
 in MATLAB?

 * which version of GNU Radio and UHD are you trying to use?

 * which version of MATLAB and it's UHD are you trying to use?

 The above might help someone to diagnose your issue ... without it, we
 can make some guesses but not much in the way of specifics.

 Please remember to "reply all", so that others can see your response
 and be able to chime in to provide help. - MLD

 On Tue, Jun 18, 2019, at 8:42 AM, Simona Sibio via USRP-users wrote:

 Dear Sir/Madam,

 I am Simona Sibio, a student in Heriot Watt University.
 I am working with USRPs both on Matlab and on Gnuradio, and with both
 softwares I have the same problem: the shape (generated by
 N200+daughterboard 10 MHz to 6 GHz) is not accurate, in attacched some
 photos.
 At 1 GHz, the shape is worst than when the carrier frequency is 3GHz.
 It is not possible to measure the amplitude and frequency because, also
 at 3 GHz, it is not stable.
 Could you help me?

 Thank you in advance.

 Best Regards,

 Simona


 ___
>>> 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

Re: [USRP-users] Waveform Shape Not Accurate

[Nick Foster via USRP-users]

Waveform source amplitude is too high. Turn it down to <0.4.

On Tue, Jun 18, 2019 at 9:31 AM Simona Sibio via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Michael,
>
> thank you for your interest.
>
> I have two N200 and each one have two daughterboard UBX-40; the
> transmitters are connected by coaxial cable to an oscilloscope
> (Rhode RTO2064) to check the waveform.
> The version of UHD is 3.13.0.
>
> I tried to send a constant signal using the flowgraph (Screenshot from
> 2019-06-18 14-56-57) in attachment on GNU radio Companion 3.7.13.4, and on
> the oscilloscope I saw this "IMG_6586".
> Also, I tried to generate a constant signal in Simulink model (16-42-17 &
> 16-14-04) on Matlab R2019a but, on the oscilloscope, I saw this "IMG_6584".
>
> I tried to send a sine signal with the Simulink model in attachment
> (16-46-10) and, on the oscilloscope, I saw this "IMG_6583".
> Also I tried to generate the sine signal with GNU radio (17-08-58) and I
> saw this "IMG_6588".
>
> It is possible to see how the amplitude and frequency change in every
> case, I need to obtain an accurate signal because I have to measure the
> amplitude and phase in a particular point in the circuit.
> And in the previous email, I added that the problem increases when I lower
> the carrier frequency. All these measures were taken with a carrier
> frequency at 3 GHz, but if I change the fc at 1 GHz the shape is worst,
> e.g. IMG_6589.
>
> Thank you in advance.
>
> Best Regards,
>
> Simona
>
>
> Il giorno mar 18 giu 2019 alle ore 15:34 Michael Dickens <
> michael.dick...@ettus.com> ha scritto:
>
>> Hi Simona - Can you please educate us as to a few items?
>>
>> * your setup: you have an N200 + some daughterboard (which one) + some
>> spectrum analyzer (which one), connected ?somehow? -> are you doing actual
>> wireless Tx -> Rx, or do you have a cable hooked up between the N200 &
>> spectrum analyzer?
>>
>> * what waveform you're trying to generate, and what is the actual
>> flowgraph you're using for GNU Radio? how are you generating the waveform
>> in MATLAB?
>>
>> * which version of GNU Radio and UHD are you trying to use?
>>
>> * which version of MATLAB and it's UHD are you trying to use?
>>
>> The above might help someone to diagnose your issue ... without it, we
>> can make some guesses but not much in the way of specifics.
>>
>> Please remember to "reply all", so that others can see your response and
>> be able to chime in to provide help. - MLD
>>
>> On Tue, Jun 18, 2019, at 8:42 AM, Simona Sibio via USRP-users wrote:
>>
>> Dear Sir/Madam,
>>
>> I am Simona Sibio, a student in Heriot Watt University.
>> I am working with USRPs both on Matlab and on Gnuradio, and with both
>> softwares I have the same problem: the shape (generated by
>> N200+daughterboard 10 MHz to 6 GHz) is not accurate, in attacched some
>> photos.
>> At 1 GHz, the shape is worst than when the carrier frequency is 3GHz.
>> It is not possible to measure the amplitude and frequency because, also
>> at 3 GHz, it is not stable.
>> Could you help me?
>>
>> Thank you in advance.
>>
>> Best Regards,
>>
>> Simona
>>
>>
>> ___
> 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

Re: [USRP-users] Getting interval between samples

[Nick Foster via USRP-users]

Varban,

The sample rate (interval between samples) is whatever you ask UHD to
provide. If you ask for 10Msps, you will get a stream of samples with a
sample interval of 100ns. The B205mini will configure the master clock rate
(i.e., the clock rate used natively with the AD9364) to an appropriate
value given the sample rate you ask for. The DDC will handle downconverting
from the master clock rate to your desired sample rate. There is no need
under any circumstances to write custom Verilog to measure the clock
interval between samples. There is no need to write custom software of any
kind in order to receive samples from the UHD Source/Sink blocks.

I'm afraid you might be a bit lost in the woods -- is there a specific
reason you need samples directly from the AD9364? What, exactly, are you
trying to do?

Nick

On Sun, Jun 16, 2019 at 11:39 PM Varban Metodiev via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> Recently I have been trying to figure out how to get the sample interval
> (in nanoseconds) on my USRP b205mini device that is coming from the radio
> IC. In regards with this, I would kindly ask you for assistance on the
> following questions:
>
> 1) While browsing the Verilog codes, I found out that a clock of 40MHz DDR
> is used for reading and writing to the AD9364 IC. When the “USRP Sink”
> block in GNU Radio is active, does it constantly poll at 40MHz? My initial
> intention was to write a separate counter block in Verilog to get the
> interval between the samples but if there are no stops/wait event on the
> bus, can I use this as time reference?
>
>
> 2) On the block diagram of the b205mini, it is mentioned that the DDC and
> the DUC are integrated in the FPGA. I have two questions here:
>
> - I couldn’t find them in the top module, so.. where is the exact location?
>
> - Is there some way to read the samples directly from the RF IC, before
> the DDC?
>
>
> 3) About the UHD interface – are there any examples on how to interface my
> own block with my own registers via the USB?
>
>
> Thanks in advance,
> Varban
>
>
> ___
> 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

Re: [USRP-users] X310 master clock rate incorrect?

[Nick Foster via USRP-users]

Yes to both!. That's what led me to believe the rate was wrong. LFRX is DC
coupled, but the arrangement it's in has the next component in the chain
blocking DC.

I tested with gr-ettus/device3 today, and the bug isn't there. So I think
there's something in the legacy driver.

Nick

On Sat, Jun 15, 2019 at 11:03 AM Ian Buckley  wrote:

> Go tune WWV, your friendly Federal signal generator?
> (Also isn’t LFRX DC coupled?)
>
> > On Jun 14, 2019, at 11:43 PM, Nick Foster via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> >
> > Got a weird one here. I'm using an X310 with UHD 3.14.0.0-87-g4e084337,
> with two LFRX daughterboards installed. Legacy interface with gr-uhd, not
> gr-ettus, just testing things in the field. When I tune to 15MHz sample
> rate at 1Msps, I get a resulting stream that looks for all the world like
> it's coming in at 7.5MHz and 500ksps. Because this is a field deployment,
> and because I don't have immediate access to a signal generator, it's a bit
> hard to confirm that. It looks to me (at first blush) like the DDC block is
> getting an incorrect master clock rate, and setting its tick rate
> accordingly. When I set the frequency to 30MHz and the sample rate to
> 2Msps, I get the result I'm expecting.
> >
> > I don't believe I'm seeing the same problem with device3/gr-ettus, but
> I'll test that further today. Anyone seen behavior like this before?
> There's also an unexpected DC offset I haven't seen before, if that helps
> jog anyone's memory. Since it's direct-sampled, not zero-IF, any DC offset
> must be the result of the DSP chain.
> >
> > Nick
> > ___
> > 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

Re: [USRP-users] B210: 1/f noise and LO offset

[Nick Foster via USRP-users]

Did you make sure to select the external reference when creating the UHD
device?

On Tue, Jun 4, 2019, 7:11 AM Erik Heinz via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Thank you for the explanation.
>
> I tried using an external reference clock (HP 58503A). Unexpectedly, this
> made no difference at all. The noise is still exactly the same.
>
>
> Erik Heinz
>
>
> --
> 
> Supracon AG
> Dr. Erik Heinz
> An der Lehmgrube 11
> 07751 Jena
> Tel.: +49 3641 2328-165
> Fax: +49 3641 2328-109
> Internet: http://www.supracon.com
> 
> Handelsregister:  Amtsgericht Gera HRB  208970
> Umsatzsteuer-Id.:  DE 216 111 685
>
> Kaufm. Vorstand:   Matthias Meyer
> Vorsitz Aufsichtsrat:  Prof. Dr. Michael Siegel
>
> --
> *Von:* Torell, Kent L 
> *Gesendet:* Montag, 3. Juni 2019 17:10
> *An:* Erik Heinz
> *Cc:* usrp-users@lists.ettus.com
> *Betreff:* RE: B210: 1/f noise and LO offset
>
>
> The phase noise comes from the B210 LO (RF synthesizer), and is present
> regardess of the frequency offset…you are misled by the log axis of the
> plot.
>
>
>
> The close-in noise can be improved by using a high quality external 10 MHz
> source.  The control loop action of the synthesizer translates the
> reference phase noise to the LO phase noise.  You may have a lab standard
> available; or you could purchase a GPSDO version for the B210 (Ettus part
> 783454-01).
>
>
>
> If this doesn’t meet your needs, you will need to shift the signal lower
> in frequency with an external mixer and a high quality microwave
> synthesizer (e.g. $20K Rhode/Keysight/etc.) that has the phase noise you
> require.   The B210 uses an Analog Devices AD9361 chip, which generates the
> RF local oscillator signal with a high frequency phase locked loop, then
> divides it down to the requested frequency.  5 GHz is at the upper end of
> it’s range, so the division is small and the phase noise will be at it’s
> highest.   Moving down several octaves will improve the phase noise,
> dropping 6 dB for every octave (e.g. 500 MHz would have 20 dB lower phase
> noise than 5 GHz).
>
>
>
> Kent Torell
>
>
>
> *From:* USRP-users  *On Behalf Of *Erik
> Heinz via USRP-users
> *Sent:* Monday, June 3, 2019 3:06 AM
> *To:* usrp-users@lists.ettus.com
> *Subject:* [USRP-users] B210: 1/f noise and LO offset
>
>
>
> Hello everyone,
>
>
>
> preliminary remark: I am an physicist - so please excuse some possible
> knowledge gaps in radio engineering :-).
>
>
>
> I would like to use a B210 to measure the IQ response of superconducting
> resonators at about 5 GHz. This is done by feeding the resonators a signal
> from the transmitter with a frequency near the resonance, amplifying by
> LNAs, coupling to the receiver, demodulating to base band, and recording
> the resulting IQ signal. The signal bandwidth of interest will be small, in
> the kHz range.
>
>
>
> Since noise of the resonators has to be measured as well, I first had a
> look at  the noise of the B210 output without an external signal. The
> result is plotted in figure 1 (vertical axis is scaled to the output range
> of the ADC). It seems, below 100kHz the B210 receiver has strong 1/f
> noise. I would guess this is hardware noise from the mixer. Anyone knows if
> this assumption is correct?
>
>
>
> So I thought it would be a good idea to demodulate not directly to base
> band, but to an IF of may be 100 kHz and do the rest in software. I
> did a quick test using gnu radio, feeding the output of the USRP source and
> a 100 kHz signal to a multiplier. This indeed has the
> desired effect (figure 2, blue curve vs. red curve).
>
> If I understand the concept of the B210 local oscillators correctly, the
> same should be possible directly on the B210, using an LO offset of 100
> kHz. The result, however, is completely different (figure 2, green curve).
>
>
>
> Any ideas why? Thank you.
>
>
>
> Best regards,
>
> Erik
>
>
> ___
> 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

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

[Nick Foster via USRP-users]

Great news! Also great that we have this on record for others with older
hardware they'd like to put to use again.

Nick

On Fri, May 10, 2019 at 4:54 PM Joe Martin via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Holy smoke!  SUCCESS!!  Nick pointed out that there are two switches on
> the N210; S1 and S2 and S1 is a reset, so an upload of FPGA code fails if
> that is held (which I was holding for his suggested test!).  Holding S2
> during iMPACT loading of the .bit image results in the uhd_image_loader
> step being SUCCESSFUL!!  I am so happy to see that!  Uhd_usrp_probe works
> wonderfully.  Finally.  We now can put this little to work doing some tough
> things!
>
> Thank you all SO MUCH for your assistance with reviving this N210.  A
> monumental achievement in my book!   I don’t know what to say except that
> we TOTALLY appreciate you efforts to get us running.  You guys are GREAT!
>
> Very best wishes to you each and every one!
>
> Joe
>
> On May 10, 2019, at 5:30 PM, Joe Martin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Ian and all,
>
> I have been very careful to avoid the pitfalls you detailed.  I began with
> a fresh installation of Ubuntu 18.04 then performed a successful build of
> UHD 3.9.7, then used command:
>
> uhd_images_downloader
>
> to load the appropriate/associated images into the PC.
>
> Then used ISE iMPACT to load the “usrp_n210_r3_fpga.bit” file into the
> FPGA of the N210.  iMPACT reports “PROGRAM SUCCESSFUL”.
>
> Then without power cycling the N210 used the command:
>
> usrp_image_loader —args=“type=usrp2,addr=192.168.10.2,overwrite-safe”
> —fw-path=/usr/local/share/uhd/images/usrp_n210_fw.bin
> —fpga-path=/usr/local/share/uhd/images/usrp_n210_r3_fpga.bin
>
> To load the non-volatile memory of the N210 but I always get the
> “RuntimeError: Received invalid 32 reply from device” error when running
> usrp_image_loader.
>
> I am able to successfully ping 192.168.10.2 but no matter what
> combinations of r2 or r3 .bit file and firmware and fpga image .bin files I
> use the response when invoking the usrp_image_loader is always the same,
> namely “invalid reply 32 from device”.
>
> The command uhd_find_devices returns by reporting it can find a usrp2
> device at address 192.168.10.2, as you would hope.
>
> After trying every conceivable combination of these actions with numerous
> versions of UHD and r2/r3 .bit FPGA files and r2/r3 .bin files on several
> fresh installations of Ubuntu 18.04 and 16.04 the result is always the same
> in that things proceed normally as the various documents concerning
> un-bricking an N210 explains, until the step of using the usrp_image_loader
> is executed, at which point a RuntimeError returns stating that the
> “invalid 32 reply” has occurred.
>
> I was hopeful that careful use of rev3 .bit and .bin files with UHD 3.9.7
> would do the trick but alas that is not the case.
>
> I suspect that you are near the bottom of the list of suggestions for me
> and I do appreciate the time and thinking you have afforded me on this
> issue.  If there is anything remaining to try I’d be most willing to try
> it.
>
> BTW, the suggestion made by someone earlier to try holding the safe button
> down during the loading of the FPGA from iMPACT causes the programming to
> fail (as reported by iMPACT), so that’s apparently not a good thing to do.
> But one can recover from that state by simply by re-programming with the
> safe button not held but the fundamental problem with the uhd_image_loader
> step in the unbricking process always seems to result.
>
> Joe
>
> On May 10, 2019, at 9:31 AM, Ian Buckley  wrote:
>
> Joe,
> To save you time, It may well be worth you trying jumping to the 3) step
> initially and seeing if your current loaded image or safe image is capable
> of being upgraded …it likely is since that protocol is widely compatible
> across UHD variants. The key here I have to emphasize (since you appear to
> have been previously getting stuck with incompatibility between whatever is
> loaded in the USRP and your host UHD installation) is to be sure your new
> UHD installation is the only one on your system, and that you have the
> binary images that are version matched with it…people often get caught out
> by reminants of various UHD versions installed in various system
> directories from different install methods.
> -Ian
>
> On May 10, 2019, at 5:58 AM, Joe Martin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Ian,
>
> Very good, that’s encouraging at least.  Yes, I am familiar with using ISE
> iMPACT to load the FPGA with .bit code and even how to create the .bit from
> the associated .bin file and did try doing that earlier but perhaps not
> identically to your prescribed steps below.  I’ll revisit it.  I
> successfully built UHD 003_009_000 earlier so I can probably also
> successfully build UHD 003_009_007 too.  I’ll do that and give it a go.  I
> am familiar with the documents you mentioned.  Generally things have gone
> 

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

[Nick Foster via USRP-users]

I'm saying that you might try to continue the effort to JTAG load a more
modern FPGA image. It's possible you have to hold down the safe mode button
while loading the image.

On Thu, May 9, 2019, 2:22 PM Joe Martin  wrote:

> Thanks for digging into that for us, Nick.  Interesting.  As the hardware
> change to rev4 occurred around mid 2011 and the earliest UHD version that
> exists on the files.ettus.com/uhd page is Feb 2104, what is the
> likelihood in your opinion that the UHD version will be compatible with the
> rev2/3 hardware from 2011?
>
> So far I’ve not been successful in reviving the 2014 UHD version so I’m
> asking to determine whether continued effort to do so is likely to yield
> anything positive with respect to interfacing with the 2011 hardware.
>
> Joe
>
> On May 9, 2019, at 3:06 PM, Nick Foster  wrote:
>
> So I really dug into the old archives here and literally pulled an old
> hard drive out of a closet, and found a copy of the old hardware repository
> from back in the days when N210 was called "USRP2+". Best that I can tell,
> we only ever released two versions to the public. We might have sold R3
> stickered as R2 -- I don't see anything in the repository that would
> indicate otherwise. Rev 2/3 was sold until around June or July 2011, when
> we moved to rev 4. The only firmware/host code changes I can see between
> any of the versions are that R4 used LVDS clocking to the daughterboard
> where previous versions used CMOS. So I think you should be able to run r3
> firmware on your N210.
>
> That said, the very very old N210s with very very old firmware might not
> have used the same safe/production firmware/fpga image arrangement that we
> later arrived at. The hardware is still fine, but you might be in for a bit
> of a deep dive to get it all running again.
>
> If you have a TTL-serial adapter or a logic analyzer that works as such,
> you can connect to the debug UART header and get printout information from
> the firmware at boot time. Another good idea would be to take a video of
> the front panel LEDs as you apply power -- the boot LED lights give good
> indication of the firmware/FPGA image loading process.
>
> Nick
>
> On Thu, May 9, 2019 at 1:42 PM Joe Martin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Thanks for the info, Marcus.  However, seeing that Jason went through
>> this last year with a couple of N210 he has it would seem unlikely that all
>> three of the N210 are broken.  That being said and considering what you jus
>> said it seems that I should’ve been able to find some version of UHD that
>> will successfully communicate with the firmware and fpga images stored in
>> the unit;  I have not, using UHD versions from 3.9.0 to 3.14.0.
>>
>> I wanted to try with even earlier versions of UHD but am finding trouble
>> in utilizing UHD v3.4.0 (earliest version I could find) as it seems that
>> “prebuilt” v3.4.0 needs only Ubuntu 10.10 or 11.10 which so far I’m not
>> able to successfully install and run.   Seems we’re running out of option
>> on this one so the Deep Space Exploration Society, who I’m trying to help
>> with this, may have to come to grasps with the notion that their N210 is a
>> true brick.
>>
>> Joe
>>
>> On May 9, 2019, at 2:23 PM, Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>> On 05/09/2019 04:18 PM, Joe Martin via USRP-users wrote:
>>
>> Nick, Ian,
>>
>> If this unit happens to be incorrectly labeled as a rev 2 N210 and it is
>> actually a rev 3 N210, is there hope in being able to load rev 3 firmware
>> and fpga images (which I have located previously and tried actually) with
>> some available UHD version?  If so, would you be able to tell me which UHD
>> version(s) might be able to communicate with it?
>>
>> Joe
>>
>> Theoretically, most versions in the last several years should be able to
>> talk to it.  In *general* UHD never drops support for older hardware,
>>   and tries to maintain compatibility.  Now, it is the case that newer
>> features are almost never "back-ported", but basic functionality should
>>   always be there.
>>
>> What this *should* mean is that you should be able to use the firmware
>> tools once the device is in "safe mode" to get yourself to where you
>>   want to be.  If that doesn't work, that may well mean that the hardware
>> is broken, and it's unlikely to be economical to repair.
>>
>>
>> On May 9, 2019, at 2:12 PM, Joe Martin via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>> Okay.  I’ve asserted from the outset that it’s a rev 2, based on the
>> factory label.  Is this N210 a lost cause if it is actually a Rev2 N210?
>>
>> Joe
>>
>> On May 9, 2019, at 2:05 PM, Nick Foster  wrote:
>>
>> Well, it's not a rev 4. It's either 2 or 3 in terms of hardware revision.
>>
>> On Thu, May 9, 2019 at 12:58 PM Joe Martin  wrote:
>>
>>> …able to ping 192.168.10.2 successfully.
>>>
>>> On May 9, 2019, at 1:54 PM, Joe Martin  wrote:
>>>
>>> Ian,
>>>
>>> Yes, I have tried many times 

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

[Nick Foster via USRP-users]

So I really dug into the old archives here and literally pulled an old hard
drive out of a closet, and found a copy of the old hardware repository from
back in the days when N210 was called "USRP2+". Best that I can tell, we
only ever released two versions to the public. We might have sold R3
stickered as R2 -- I don't see anything in the repository that would
indicate otherwise. Rev 2/3 was sold until around June or July 2011, when
we moved to rev 4. The only firmware/host code changes I can see between
any of the versions are that R4 used LVDS clocking to the daughterboard
where previous versions used CMOS. So I think you should be able to run r3
firmware on your N210.

That said, the very very old N210s with very very old firmware might not
have used the same safe/production firmware/fpga image arrangement that we
later arrived at. The hardware is still fine, but you might be in for a bit
of a deep dive to get it all running again.

If you have a TTL-serial adapter or a logic analyzer that works as such,
you can connect to the debug UART header and get printout information from
the firmware at boot time. Another good idea would be to take a video of
the front panel LEDs as you apply power -- the boot LED lights give good
indication of the firmware/FPGA image loading process.

Nick

On Thu, May 9, 2019 at 1:42 PM Joe Martin via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Thanks for the info, Marcus.  However, seeing that Jason went through this
> last year with a couple of N210 he has it would seem unlikely that all
> three of the N210 are broken.  That being said and considering what you jus
> said it seems that I should’ve been able to find some version of UHD that
> will successfully communicate with the firmware and fpga images stored in
> the unit;  I have not, using UHD versions from 3.9.0 to 3.14.0.
>
> I wanted to try with even earlier versions of UHD but am finding trouble
> in utilizing UHD v3.4.0 (earliest version I could find) as it seems that
> “prebuilt” v3.4.0 needs only Ubuntu 10.10 or 11.10 which so far I’m not
> able to successfully install and run.   Seems we’re running out of option
> on this one so the Deep Space Exploration Society, who I’m trying to help
> with this, may have to come to grasps with the notion that their N210 is a
> true brick.
>
> Joe
>
> On May 9, 2019, at 2:23 PM, Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> On 05/09/2019 04:18 PM, Joe Martin via USRP-users wrote:
>
> Nick, Ian,
>
> If this unit happens to be incorrectly labeled as a rev 2 N210 and it is
> actually a rev 3 N210, is there hope in being able to load rev 3 firmware
> and fpga images (which I have located previously and tried actually) with
> some available UHD version?  If so, would you be able to tell me which UHD
> version(s) might be able to communicate with it?
>
> Joe
>
> Theoretically, most versions in the last several years should be able to
> talk to it.  In *general* UHD never drops support for older hardware,
>   and tries to maintain compatibility.  Now, it is the case that newer
> features are almost never "back-ported", but basic functionality should
>   always be there.
>
> What this *should* mean is that you should be able to use the firmware
> tools once the device is in "safe mode" to get yourself to where you
>   want to be.  If that doesn't work, that may well mean that the hardware
> is broken, and it's unlikely to be economical to repair.
>
>
> On May 9, 2019, at 2:12 PM, Joe Martin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Okay.  I’ve asserted from the outset that it’s a rev 2, based on the
> factory label.  Is this N210 a lost cause if it is actually a Rev2 N210?
>
> Joe
>
> On May 9, 2019, at 2:05 PM, Nick Foster  wrote:
>
> Well, it's not a rev 4. It's either 2 or 3 in terms of hardware revision.
>
> On Thu, May 9, 2019 at 12:58 PM Joe Martin  wrote:
>
>> …able to ping 192.168.10.2 successfully.
>>
>> On May 9, 2019, at 1:54 PM, Joe Martin  wrote:
>>
>> Ian,
>>
>> Yes, I have tried many times to boot in safe mode, same result
>> regardless.  Yes, I am able to pin to 192.168.10.2 successfully.
>>
>> Joe
>>
>> On May 9, 2019, at 1:47 PM, Joe Martin via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>> Ian and Nick,
>>
>> Thanks for the assistance.  Attached are dropbox links to two snapshot
>> photos:  1) the factory label on the back of the N210, showing N210 r:2.0
>> and 2) a top side view of the N210.
>>
>> 1) https://www.dropbox.com/s/u92x02rni71kfb3/20190509_133253.jpg?dl=0
>> 2) https://www.dropbox.com/s/1p8ocqf4qcr9ohb/20190509_133800.jpg?dl=0
>>
>> Seems this unit is indeed a rev 2 N210, yes?
>>
>> Joe
>>
>> On May 9, 2019, at 12:40 PM, Nick Foster  wrote:
>>
>> Moreover, the best "tell" is to look at the N210 motherboard. If the SRAM
>> chip is on the top side, it's a rev 2/3. If the SRAM is on the bottom side,
>> it's a rev 4. If you send a picture along of the top of the N210, I can
>> tell you if it's 

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

[Nick Foster via USRP-users]

Well, it's not a rev 4. It's either 2 or 3 in terms of hardware revision.

On Thu, May 9, 2019 at 12:58 PM Joe Martin  wrote:

> …able to ping 192.168.10.2 successfully.
>
> On May 9, 2019, at 1:54 PM, Joe Martin  wrote:
>
> Ian,
>
> Yes, I have tried many times to boot in safe mode, same result
> regardless.  Yes, I am able to pin to 192.168.10.2 successfully.
>
> Joe
>
> On May 9, 2019, at 1:47 PM, Joe Martin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Ian and Nick,
>
> Thanks for the assistance.  Attached are dropbox links to two snapshot
> photos:  1) the factory label on the back of the N210, showing N210 r:2.0
> and 2) a top side view of the N210.
>
> 1) https://www.dropbox.com/s/u92x02rni71kfb3/20190509_133253.jpg?dl=0
> 2) https://www.dropbox.com/s/1p8ocqf4qcr9ohb/20190509_133800.jpg?dl=0
>
> Seems this unit is indeed a rev 2 N210, yes?
>
> Joe
>
> On May 9, 2019, at 12:40 PM, Nick Foster  wrote:
>
> Moreover, the best "tell" is to look at the N210 motherboard. If the SRAM
> chip is on the top side, it's a rev 2/3. If the SRAM is on the bottom side,
> it's a rev 4. If you send a picture along of the top of the N210, I can
> tell you if it's early or late rev.
>
> On Thu, May 9, 2019 at 11:36 AM Ian Buckley via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Joe,
>> So I scratched my head about this a little late last night and looked
>> back through the development repository for the N210 and as far as I can
>> tell there was never customer facing FPGA code for a Rev2 N210. Chatting
>> with Matt this morning he shared my feeling that a Rev2 wasn't sold to
>> customers, so I'm curious if you have a unit that has a factory label that
>> says N210Rev2 or if you have seen "usrp2 rev2.0" on the PCB (which can be
>> missleading).
>>
>> Also have you tried booting into the safe image and verifying that it at
>> least pings on 192.168.10.2?
>>
>> If we can conclusively identify which rev of h/w you have I can probably
>> help further.
>>
>> Ian
>>
>
> ___
> 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

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

[Nick Foster via USRP-users]

Moreover, the best "tell" is to look at the N210 motherboard. If the SRAM
chip is on the top side, it's a rev 2/3. If the SRAM is on the bottom side,
it's a rev 4. If you send a picture along of the top of the N210, I can
tell you if it's early or late rev.

On Thu, May 9, 2019 at 11:36 AM Ian Buckley via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Joe,
> So I scratched my head about this a little late last night and looked back
> through the development repository for the N210 and as far as I can tell
> there was never customer facing FPGA code for a Rev2 N210. Chatting with
> Matt this morning he shared my feeling that a Rev2 wasn't sold to
> customers, so I'm curious if you have a unit that has a factory label that
> says N210Rev2 or if you have seen "usrp2 rev2.0" on the PCB (which can be
> missleading).
>
> Also have you tried booting into the safe image and verifying that it at
> least pings on 192.168.10.2?
>
> If we can conclusively identify which rev of h/w you have I can probably
> help further.
>
> Ian
>
> On Thu, May 9, 2019, 8:05 AM Joe Martin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Argh.  Yes, maybe that’s what I will need to do then.  I’ll try it.
>>
>> Looks like the earliest vintage of UHD that’s available is Feb 2014
>> (v3.4.0), which is about 4 years after the Rev2 N210, I think.  So that UHD
>> version may still be too recent to work with the Rev2 N210.  That’ll be my
>> last attempt before abandoning the thing as you did with yours.
>>
>> Thanks for the comments and help, Jason.  Good luck with your projects!
>>
>> Joe
>>
>> On May 9, 2019, at 8:20 AM, Jason Matusiak 
>> wrote:
>>
>> Maybe try running a VM of a version of Ubuntu that is roughly the vintage
>> of that version of UHD?
>>
>> --
>> *From:* USRP-users  on behalf of Joe
>> Martin via USRP-users 
>> *Sent:* Thursday, May 9, 2019 9:53 AM
>> *To:* Joe Martin
>> *Cc:* usrp-users@lists.ettus.com
>> *Subject:* [USRP-users] Need a little help with running legacy prebuilt
>> UHD versions
>>
>> I need a bit of help to understand how to run legacy prebuilt UHD
>> versions from the files.ettus.com/binaries/uhd repository.
>>
>> I would like to try various UHD versions to try to find a version that
>> will run with an elderly (Rev 2) N210 with unknown firmware/fpga images in
>> it.  After downloading a legacy version, e.g.,
>> uhd_003.004.000-release_Ubuntu-11.10-x86_64.deb, and clicking “install” I
>> am not understanding what I need to do next to actually run the version, as
>> uhd_usrp_probe —version reports the version of UHD that I originally had
>> installed, not the legacy version I intended to install.
>>
>> I am running Ubuntu 18.04, should I expect to be able to run the legacy
>> versions labeled, for example, *_Ubuntu-11.10-x86_64.deb, as in the example
>> above ?
>>
>> Clearly I’m missing something fundamental, and likely simple, in my
>> understanding about how to use these prebuilt older versions.  I have had
>> no problem building, installing, and running UHD versions from source but I
>> have never tried to run a “prebuilt” version before.
>>
>> Joe
>>
>>
>> ___
>> 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

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Nick Foster via USRP-users]

Yes, code loaded over JTAG is gone at next boot. I can't think of an easy
way to figure out what image is loaded other than asking UHD to query it
for FPGA compat number.

On Wed, May 8, 2019 at 1:04 PM Joe Martin  wrote:

> I guess the proper way to ask is “Is there a way to determine what fpga
> .bin file is in the N210?”, since the .bit file that I loaded into the fpga
> is volatile code that disappears upon power cycling to be reloaded from an
> EEPROM or something, yes?
>
> Joe
>
> On May 8, 2019, at 1:55 PM, Joe Martin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hi Nick,
>
> Thanks for the comments.  Is there a way to determine what bit file is
> currently in the N210?  If so, how please?
>
> Joe
>
> On May 8, 2019, at 1:33 PM, Nick Foster  wrote:
>
> I see you got there already! If you're still having trouble, I'll see what
> I can dig up over here.
>
> On Wed, May 8, 2019 at 12:31 PM Nick Foster  wrote:
>
>> You might be best off reverting to a UHD old enough to support the
>> bitfile currently loaded on your N210. You could then bootstrap your N210
>> by using the old UHD to load a newer FPGA image.
>>
>> Otherwise, it's fairly simple to convert the binfiles (which still exist
>> -- usrp_n210_r2_fpga.bin) to bitfiles. You can take the header from
>> usrp_n210_r3_fpga.bit and just stick it onto the front of
>> usrp_n210_r2_fpga.bin, and call the output usrp_n210_r2_fpga.bit. The
>> header is everything up until FF FF FF FF AA 99 55 66.
>>
>> Lastly, the source is all there, so building using ISE should still be
>> possible.
>>
>> Nick
>>
>> On Wed, May 8, 2019 at 9:57 AM Joe Martin via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Wow, okay; that’s disheartening.  Thanks much for the info, Jason.
>>> Nope, the Rev3 bit file doesn’t work; tried it.  I’ll see if the support
>>> email adr can be of use.
>>>
>>> Joe
>>>
>>> On May 8, 2019, at 10:44 AM, Jason Matusiak <
>>> ja...@gardettoengineering.com> wrote:
>>>
>>> Joe, I think you might be SOL.  If you take a look at this thread from
>>> me last year, I had no luck:
>>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
>>>
>>>
>>> Also, when I pinged Ettus directly, here is some info I got back from
>>> them (from two different emails in the thread):
>>> "we've been having some trouble tracking down Rev2 bitfiles, because no
>>> one here was around when that was built. If you're trying to unbrick
>>> them, Rev3 bitfiles might be OK, but I'm not completely sure.
>>>
>>> supp...@ettus.com might know more by know.
>>> really sorry, but those Rev2s are just so old. And all the people from
>>> that era seem to be gone. Sorry, can't help you with those Rev2s."
>>>
>>> --
>>> *From:* USRP-users  on behalf of
>>> Joe Martin via USRP-users 
>>> *Sent:* Wednesday, May 8, 2019 11:55 AM
>>> *To:* Joe Martin via USRP-users
>>> *Subject:* [USRP-users] Bringing an elderly N210 to life by loading
>>> current firmware/fpga images
>>>
>>> I am trying to bring an elderly N210 r2.0 with unknown history to life
>>> by loading current UHD firmware and fpga images from a 1Gigabit ethernet
>>> connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with
>>> UHD 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty.
>>>
>>> Following instructions in “USRP Hardware Driver and USRP Manual: USRP2
>>> and N2x0 Series”:
>>>
>>> My initial action was to load the “usrp_n210_r4_fpga.bit" file into the
>>> N210 xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG programming
>>> cable from a Win7 PC running Xilinx ISE iMPACT, which reported “Program
>>> Succeeded” for the action.  Ethernet LEDs on the N210 are variously lighted
>>> showing activity on the connection port.
>>>
>>> With the N210 connected to the Linux PC 1Gbps ethernet port, issuing the
>>> following commands result in the responses shown in the screenshot image
>>> below:
>>>
>>> 
>>>
>>> My (naive!) interpretation of the above responses is that the FPGA may
>>> not actually have been programmed with the *.bit code even though iMPACT
>>> reported success in programming.  Can someone assist me in understanding
>>> whether my interpretation is correct or not and, most importantly, suggest
>>> what I might try next to bring this N210 to life?
>>>
>>> The “Please run:” suggestion results in the “Received invalid reply 32
>>> from device” error.  It seems no matter what I try the “Received invalid
>>> reply 32 from device” RuntimeError is reported back when I try to load any
>>> new firmware/FPGA images.
>>>
>>> Thanks!
>>>
>>> Joe
>>>
>>>
>>> ___
>>> 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
>
>
>

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Nick Foster via USRP-users]

I see you got there already! If you're still having trouble, I'll see what
I can dig up over here.

On Wed, May 8, 2019 at 12:31 PM Nick Foster  wrote:

> You might be best off reverting to a UHD old enough to support the bitfile
> currently loaded on your N210. You could then bootstrap your N210 by using
> the old UHD to load a newer FPGA image.
>
> Otherwise, it's fairly simple to convert the binfiles (which still exist
> -- usrp_n210_r2_fpga.bin) to bitfiles. You can take the header from
> usrp_n210_r3_fpga.bit and just stick it onto the front of
> usrp_n210_r2_fpga.bin, and call the output usrp_n210_r2_fpga.bit. The
> header is everything up until FF FF FF FF AA 99 55 66.
>
> Lastly, the source is all there, so building using ISE should still be
> possible.
>
> Nick
>
> On Wed, May 8, 2019 at 9:57 AM Joe Martin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Wow, okay; that’s disheartening.  Thanks much for the info, Jason.  Nope,
>> the Rev3 bit file doesn’t work; tried it.  I’ll see if the support email
>> adr can be of use.
>>
>> Joe
>>
>> On May 8, 2019, at 10:44 AM, Jason Matusiak <
>> ja...@gardettoengineering.com> wrote:
>>
>> Joe, I think you might be SOL.  If you take a look at this thread from me
>> last year, I had no luck:
>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
>>
>>
>> Also, when I pinged Ettus directly, here is some info I got back from
>> them (from two different emails in the thread):
>> "we've been having some trouble tracking down Rev2 bitfiles, because no
>> one here was around when that was built. If you're trying to unbrick
>> them, Rev3 bitfiles might be OK, but I'm not completely sure.
>>
>> supp...@ettus.com might know more by know.
>> really sorry, but those Rev2s are just so old. And all the people from
>> that era seem to be gone. Sorry, can't help you with those Rev2s."
>>
>> --
>> *From:* USRP-users  on behalf of Joe
>> Martin via USRP-users 
>> *Sent:* Wednesday, May 8, 2019 11:55 AM
>> *To:* Joe Martin via USRP-users
>> *Subject:* [USRP-users] Bringing an elderly N210 to life by loading
>> current firmware/fpga images
>>
>> I am trying to bring an elderly N210 r2.0 with unknown history to life by
>> loading current UHD firmware and fpga images from a 1Gigabit ethernet
>> connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with
>> UHD 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty.
>>
>> Following instructions in “USRP Hardware Driver and USRP Manual: USRP2
>> and N2x0 Series”:
>>
>> My initial action was to load the “usrp_n210_r4_fpga.bit" file into the
>> N210 xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG programming
>> cable from a Win7 PC running Xilinx ISE iMPACT, which reported “Program
>> Succeeded” for the action.  Ethernet LEDs on the N210 are variously lighted
>> showing activity on the connection port.
>>
>> With the N210 connected to the Linux PC 1Gbps ethernet port, issuing the
>> following commands result in the responses shown in the screenshot image
>> below:
>>
>> 
>>
>> My (naive!) interpretation of the above responses is that the FPGA may
>> not actually have been programmed with the *.bit code even though iMPACT
>> reported success in programming.  Can someone assist me in understanding
>> whether my interpretation is correct or not and, most importantly, suggest
>> what I might try next to bring this N210 to life?
>>
>> The “Please run:” suggestion results in the “Received invalid reply 32
>> from device” error.  It seems no matter what I try the “Received invalid
>> reply 32 from device” RuntimeError is reported back when I try to load any
>> new firmware/FPGA images.
>>
>> Thanks!
>>
>> Joe
>>
>>
>> ___
>> 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

Re: [USRP-users] Bringing an elderly N210 to life by loading current firmware/fpga images

[Nick Foster via USRP-users]

You might be best off reverting to a UHD old enough to support the bitfile
currently loaded on your N210. You could then bootstrap your N210 by using
the old UHD to load a newer FPGA image.

Otherwise, it's fairly simple to convert the binfiles (which still exist --
usrp_n210_r2_fpga.bin) to bitfiles. You can take the header from
usrp_n210_r3_fpga.bit and just stick it onto the front of
usrp_n210_r2_fpga.bin, and call the output usrp_n210_r2_fpga.bit. The
header is everything up until FF FF FF FF AA 99 55 66.

Lastly, the source is all there, so building using ISE should still be
possible.

Nick

On Wed, May 8, 2019 at 9:57 AM Joe Martin via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Wow, okay; that’s disheartening.  Thanks much for the info, Jason.  Nope,
> the Rev3 bit file doesn’t work; tried it.  I’ll see if the support email
> adr can be of use.
>
> Joe
>
> On May 8, 2019, at 10:44 AM, Jason Matusiak 
> wrote:
>
> Joe, I think you might be SOL.  If you take a look at this thread from me
> last year, I had no luck:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-April/056223.html
>
>
> Also, when I pinged Ettus directly, here is some info I got back from them
> (from two different emails in the thread):
> "we've been having some trouble tracking down Rev2 bitfiles, because no
> one here was around when that was built. If you're trying to unbrick
> them, Rev3 bitfiles might be OK, but I'm not completely sure.
>
> supp...@ettus.com might know more by know.
> really sorry, but those Rev2s are just so old. And all the people from
> that era seem to be gone. Sorry, can't help you with those Rev2s."
>
> --
> *From:* USRP-users  on behalf of Joe
> Martin via USRP-users 
> *Sent:* Wednesday, May 8, 2019 11:55 AM
> *To:* Joe Martin via USRP-users
> *Subject:* [USRP-users] Bringing an elderly N210 to life by loading
> current firmware/fpga images
>
> I am trying to bring an elderly N210 r2.0 with unknown history to life by
> loading current UHD firmware and fpga images from a 1Gigabit ethernet
> connection on an AMD 2950X, 3.4GHz, 2TB SSD PC running Ubuntu 18.04 with
> UHD 3.14.0.HEAD-0-gd20a7ae2 software but having difficulty.
>
> Following instructions in “USRP Hardware Driver and USRP Manual: USRP2 and
> N2x0 Series”:
>
> My initial action was to load the “usrp_n210_r4_fpga.bit" file into the
> N210 xc3sd3400a FPGA using a Xilinx Platform Cable USB II JTAG programming
> cable from a Win7 PC running Xilinx ISE iMPACT, which reported “Program
> Succeeded” for the action.  Ethernet LEDs on the N210 are variously lighted
> showing activity on the connection port.
>
> With the N210 connected to the Linux PC 1Gbps ethernet port, issuing the
> following commands result in the responses shown in the screenshot image
> below:
>
> 
>
> My (naive!) interpretation of the above responses is that the FPGA may not
> actually have been programmed with the *.bit code even though iMPACT
> reported success in programming.  Can someone assist me in understanding
> whether my interpretation is correct or not and, most importantly, suggest
> what I might try next to bring this N210 to life?
>
> The “Please run:” suggestion results in the “Received invalid reply 32
> from device” error.  It seems no matter what I try the “Received invalid
> reply 32 from device” RuntimeError is reported back when I try to load any
> new firmware/FPGA images.
>
> Thanks!
>
> Joe
>
>
> ___
> 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

Re: [USRP-users] X310 RFNoC transmission issues

[Nick Foster via USRP-users]

Have you simulated your RFNoC CEs with Verilog testbenches?

On Wed, May 8, 2019 at 8:12 AM zluudg via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello!
>
> I'm having some issues while trying to transmit a signal using the
> RFNoC: Radio block in Gnuradio. My block diagram is:
>
>
>  Signal Source (constant) -> RFNoC: DmaFIFO -> RFNoC: Radio (in
> TX mode).
>
>
> I run the block diagram by calling "python top_block.py" from the
> command line and I'm not getting any errors while it's running .
> However, I'm unable to quit it properly without having to close the
> terminal window and power-cycle the USRP. When connecting the USRP to a
> spectrum analyzer I see no signal whatsoever (I expect to see a peak at
> 2.4 GHz).
>
>
> Removing the DmaFIFO does not seem to make any difference. My FPGA image
> is a custom image with some of my CEs, but it was built smoothly using
> the "uhd_image_builder.py" script. I've also experienced similar
> problems while having a RFNoC: DUC between the DmaFIFO and the Radio
> block, also with a custom FPGA image. With the stock FPGA image I was
> able to get a signal with more or less the same Gnuradio block diagram.
>
>
> Why am I not seeing any output with my custom FPGA images? All
> suggestions appreciated.
>
>
> I'll happily provide more info if needed, so don't hesitate to ask. For
> know, I'll just provide the basics:
>
>
>  OS: Ubuntu 18.04
>
>  uhd: rfnoc-devel, eec24d7b0
>
>  gnuradio: maint-3.7, c6c575309
>
>  gr-ettus: master, a909447
>
>
> Thanks in advance!
>
> //
>
> Leon
>
>
> ___
> 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

Re: [USRP-users] RFNOC GPIO Remapping

[Nick Foster via USRP-users]

Have you defined that GPIO as an output in the mask register?

On Fri, Apr 26, 2019 at 9:01 AM Chatterjee, Pratik via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Jonathan,
>
> I have a question regarding fpga and rfnoc. I am trying to set a 1'bit
> value on one of the registers in my noc_block and send the value out the
> remapped gpio pins. I haven't been able to see the value on my gpio pin.
> Although declaring the register in the custom gpio file I do see the
> output. Appreciate any insights as to why such a thing is happening.
>
> Thanks,
> Pratik
>
> --
> *From:* Chatterjee, Pratik
> *Sent:* Sunday, February 3, 2019 9:31 PM
> *To:* Jonathon Pendlum
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] RFNOC GPIO Remapping
>
> Thank you Jonathon for your help. I had modified some sections of the file
> x300_db_fe_core.v which was causing the error. I was able to compile an
> unmodified image without error.
> --
> *From:* Jonathon Pendlum 
> *Sent:* Saturday, February 2, 2019 7:02 PM
> *To:* Chatterjee, Pratik
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] RFNOC GPIO Remapping
>
> Hi Pratik,
>
> That error generally means that the RFNoC block did not response to a
> command packet. That happens when the block is not correctly connected to
> the crossbar or the clocks are not connected. In this case it is the Radio
> Core RFNoC block, which by default is correctly connected unless modified.
> Did you make any modifications to the Radio Core RFNoC block I/O, either in
> the source file or the instantiation in x300_core.v?
>
> Also as a sanity check, are you able to build an unmodified image that
> works without that error?
>
> Jonathon
>
> On Sat, Feb 2, 2019 at 3:10 AM Chatterjee, Pratik via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hello,
>
> I am using an X310 and I need to monitor a signal out of GPIO from my
> custom block. Going through the archives I prefer the option to disconnect
> the fp_gpio lines from the radio core to my custom block. So I snapped the
> fp_gpio lines going in gpio_attr to a custom module in db_control to
> observe the signal. The image compiled fine. But when I probe the device, I
> get the following error
>
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.14.0.HEAD-110-g6af6ac32
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Radio 1x clock: 200 MHz
> [INFO] [GPS] No GPSDO found
> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> 0xF1F0D000)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1315 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1309 MB/s)
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001)
> terminate called after throwing an instance of 'uhd::io_error'
>   what():  EnvironmentError: IOError: [0/Radio_0] sr_write() failed:
> EnvironmentError: IOError: Block ctrl (CE_01_Port_40) no response packet -
> AssertionError: bool(buff)
>   in uint64_t ctrl_iface_impl<_endianness>::wait_for_ack(bool, double)
> [with uhd::endianness_t _endianness = (uhd::endianness_t)0u; uint64_t =
> long unsigned int]
>   at /home/delta3/rfnoc3/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:155
>
> Is there something more than just disconnecting the lines. Any help will
> be appreciated. Thank you,
>
> Pratik
>
> ___
> 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

Re: [USRP-users] How to insert an EOB for rfnoc transmission?

[Nick Foster via USRP-users]

I don't know what your block does, so I don't know which to recommend. The
rfnoc-modtool testbench example is fine, as are most of the existing
testbenches in usrp3/lib/rfnoc.

Ignore the error you're having now, spend some time setting up a testbench.
I promise it will save you time in the end.

On Wed, Apr 24, 2019 at 8:06 AM Xingjian Chen  wrote:

> Dear Nick,
>
> Thank you for the quick reply. I assigned eob, has_time, payload_length,
> src_sid, next_dst_sid, future_vita_time in another module. There is some
> logic to define when and how to change those values. Sorry for the
> confusion.
>
> I haven't simulated this. Could you think of a relevant testbench example
> I can start with? Thank you.
>
> --
> *From:* Nick Foster 
> *Sent:* Wednesday, April 24, 2019 10:39:42 AM
> *To:* Xingjian Chen
> *Cc:* USRP-users@lists.ettus.com; usrp-users-boun...@lists.ettus.com
> *Subject:* Re: [USRP-users] How to insert an EOB for rfnoc transmission?
>
> Also, just to be clear, I usually see "no response packet" when I've
> messed up something in the CHDR. Looking more closely, you're using vita
> time set to "future_vita_time", but I don't see where that's assigned,
> either. Similarly for has_time and payload_length.
>
> Have you simulated this? It is very unwise to go straight to FPGA before
> simulating in a testbench. RFNoC comes with very good testbench examples.
>
> On Wed, Apr 24, 2019 at 7:37 AM Nick Foster  wrote:
>
>> Are you assigning a value for eob? You declare it, but I don't see where
>> you assign it.
>>
>> On Wed, Apr 24, 2019 at 7:15 AM Xingjian Chen via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi Guys,
>>> Good morning. I am wondering how to insert an EOB in Verilog code to the
>>> radio.  What I have tried is cvita_hdr_modify as below. I think just change
>>> EOB bit should put the tx radio into the idle state. However, when the
>>> EOB changed, my E312 returned an error as below.  There is a register I
>>> used for updating coefficients in FPGA, but it should not be related to
>>> EOB. Thank you.
>>>
>>>   wire [63:0] future_vita_time ;
>>>   wire eob;
>>>   wire has_time;
>>>   cvita_hdr_modify cvita_hdr_modify_data (
>>>.header_in(m_axis_data_tuser),
>>>.header_out(s_axis_data_tuser),
>>>.use_pkt_type(1'b0), .pkt_type(),
>>>.use_has_time(1'b1), .has_time(has_time),
>>>.use_eob(1'b1), .eob(eob),
>>>.use_seqnum(1'b0), .seqnum(),
>>>.use_length(1'b1), .length(payload_length),
>>>.use_src_sid(1'b1), .src_sid(src_sid),
>>>.use_dst_sid(1'b1), .dst_sid(next_dst_sid),
>>>.use_vita_time(1'b1), .vita_time(future_vita_time));
>>>
>>> Returned Error:
>>> sr_write() failed: EnvironmentError: IOError: Block ctrl (CE_01_Port_20)
>>> no response packet
>>> ___
>>> 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

Re: [USRP-users] How to insert an EOB for rfnoc transmission?

[Nick Foster via USRP-users]

Also, just to be clear, I usually see "no response packet" when I've messed
up something in the CHDR. Looking more closely, you're using vita time set
to "future_vita_time", but I don't see where that's assigned, either.
Similarly for has_time and payload_length.

Have you simulated this? It is very unwise to go straight to FPGA before
simulating in a testbench. RFNoC comes with very good testbench examples.

On Wed, Apr 24, 2019 at 7:37 AM Nick Foster  wrote:

> Are you assigning a value for eob? You declare it, but I don't see where
> you assign it.
>
> On Wed, Apr 24, 2019 at 7:15 AM Xingjian Chen via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi Guys,
>> Good morning. I am wondering how to insert an EOB in Verilog code to the
>> radio.  What I have tried is cvita_hdr_modify as below. I think just change
>> EOB bit should put the tx radio into the idle state. However, when the
>> EOB changed, my E312 returned an error as below.  There is a register I
>> used for updating coefficients in FPGA, but it should not be related to
>> EOB. Thank you.
>>
>>   wire [63:0] future_vita_time ;
>>   wire eob;
>>   wire has_time;
>>   cvita_hdr_modify cvita_hdr_modify_data (
>>.header_in(m_axis_data_tuser),
>>.header_out(s_axis_data_tuser),
>>.use_pkt_type(1'b0), .pkt_type(),
>>.use_has_time(1'b1), .has_time(has_time),
>>.use_eob(1'b1), .eob(eob),
>>.use_seqnum(1'b0), .seqnum(),
>>.use_length(1'b1), .length(payload_length),
>>.use_src_sid(1'b1), .src_sid(src_sid),
>>.use_dst_sid(1'b1), .dst_sid(next_dst_sid),
>>.use_vita_time(1'b1), .vita_time(future_vita_time));
>>
>> Returned Error:
>> sr_write() failed: EnvironmentError: IOError: Block ctrl (CE_01_Port_20)
>> no response packet
>> ___
>> 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

Re: [USRP-users] How to insert an EOB for rfnoc transmission?

[Nick Foster via USRP-users]

Are you assigning a value for eob? You declare it, but I don't see where
you assign it.

On Wed, Apr 24, 2019 at 7:15 AM Xingjian Chen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Guys,
> Good morning. I am wondering how to insert an EOB in Verilog code to the
> radio.  What I have tried is cvita_hdr_modify as below. I think just change
> EOB bit should put the tx radio into the idle state. However, when the
> EOB changed, my E312 returned an error as below.  There is a register I
> used for updating coefficients in FPGA, but it should not be related to
> EOB. Thank you.
>
>   wire [63:0] future_vita_time ;
>   wire eob;
>   wire has_time;
>   cvita_hdr_modify cvita_hdr_modify_data (
>.header_in(m_axis_data_tuser),
>.header_out(s_axis_data_tuser),
>.use_pkt_type(1'b0), .pkt_type(),
>.use_has_time(1'b1), .has_time(has_time),
>.use_eob(1'b1), .eob(eob),
>.use_seqnum(1'b0), .seqnum(),
>.use_length(1'b1), .length(payload_length),
>.use_src_sid(1'b1), .src_sid(src_sid),
>.use_dst_sid(1'b1), .dst_sid(next_dst_sid),
>.use_vita_time(1'b1), .vita_time(future_vita_time));
>
> Returned Error:
> sr_write() failed: EnvironmentError: IOError: Block ctrl (CE_01_Port_20)
> no response packet
> ___
> 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

Re: [USRP-users] how to properly use static libuhd?

[Nick Foster via USRP-users]

I suspect the same solution I gave a couple weeks ago will work here:

set(MY_LIB_OPT -Wl,--whole-archive libuhd -Wl,--no-whole-archive)
target_link_libraries(myapp ${MY_LIB_OPT} <...the rest of your libs...>)

On Wed, Apr 17, 2019 at 3:02 AM Paolo Palana via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi to all the mailing list.
>
> I've a question about the correct way to use a static version of libuhd
> (namely libuhd.a)
>
> For experimental reason I need a way to build an executable of mine that
> "embed" a specific version of libuhd. I enabled (throutg
> -DENABLE_STATIC_LIBS=ON) the compilation of the static library and I get
> the libuhd.a file.
>
> After that I modified my CMakeLists.txt to link against libuhd.a. The
> compilation and link process goes smooth. So far so good.
>
> The problem arise when I execute the program. No radio (x310 in my case)
> is found. I traced the problem.
>
> The shared version of libuhd (libuhd.so) has a init function (that
> should be register_x300_device, defined in x300_impl.cpp). that is
> called before main  This function is no longer called when I compile
> using libuhd.a, may be because there is no the dynamic loader involved.
>
> The question is. Can I call it from my code? And if yes how? I tried
> different ways, but no success.
>
> Thank you for your attention.
>
> My version is 003-010-003-000.
>
> Paolo
>
>
>
> ___
> 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

Re: [USRP-users] (no subject)

[Nick Foster via USRP-users]

Just wanted to follow up on this, because I thought of something in the
shower this morning.

If you compile your block controller as a shared library and you want your
block to be initialized/used with the default UHD apps, you can use
LD_PRELOAD to ensure the block registration happens at runtime. For
instance:

$ LD_PRELOAD=/usr/local/lib/librfnoc-clabs.so uhd_usrp_probe
--args=addr=192.168.10.2

...if your RFNoC controller is registered inside that .so, it will be
loaded and registered for uhd_usrp_probe.

Just a helpful trick if you want to (for instance) use rfnoc_rx_to_file to
test your block, since it has the option to specify a custom block to
insert between the radio and the host.

Nick

On Tue, Apr 9, 2019 at 10:51 AM John Medrano 
wrote:

> Thank you.
>
> Using:
>
> set(RFNOC_MYMOD_LIB_OPT -Wl,--whole-archive rfnoc-mylib
> -Wl,--no-whole-archive)
> target_link_libraries(rfnoc_myapp ${RFNOC_MYMOD_LIB_OPT} <...the rest of
> your libs...>)
>
> We are able to use our controller.
>
> On Mon, Apr 8, 2019 at 11:52 AM Nick Foster  wrote:
>
>> OK, I looked further into it. UHD registers out-of-tree block controllers
>> using the UHD_RFNOC_BLOCK_REGISTER macro, which under the hood creates a
>> static function and a fixture which calls it before main(). Problem is,
>> when linking your out-of-tree executable, the linker sees that the static
>> fixture is never explicitly called from your program, and it optimizes it
>> out. So your block is never getting registered.
>>
>> There's a number of ways to fix it. I don't know how UHD does it
>> internally. If you are linking your library statically, you can do
>> something like the following in the CMakeLists.txt for the application (not
>> the library):
>>
>> set(RFNOC_MYMOD_LIB_OPT -Wl,--whole-archive rfnoc-mylib
>> -Wl,--no-whole-archive)
>> target_link_libraries(rfnoc_myapp ${RFNOC_MYMOD_LIB_OPT} <...the rest of
>> your libs...>)
>>
>> Using --whole-archive will force the linker to include all the contents
>> of your custom static lib in the application. This includes the static
>> constructor.
>>
>> If you're linking dynamically, this may or may not be a problem for you.
>> If it is, you can do something like
>> set_target_properties(rfnoc_myapp PROPERTIES LINK_WHAT_YOU_USE TRUE)
>>
>> ...which sets the -Wl,--no-as-needed linker flag, indicating to the
>> linker that it should include dynamic libraries that aren't explicitly
>> called. This isn't a great solution as it can result in linking to
>> libraries which really aren't used.
>>
>> You can debug this approach by calling the UHD_STATIC_BLOCK macro in your
>> library and just having it print something to stdout. If you don't see the
>> print in your application, it's not linking static objects correctly.
>>
>> Nick
>>
>> On Mon, Apr 8, 2019 at 8:24 AM John Medrano 
>> wrote:
>>
>>> Hello,
>>>
>>> We have verified that library is being linked.
>>>
>>> When we run  nm  | grep 
>>>
>>> We see the following:
>>> 00030310 W _ZNK3uhd7device314get_block_ctrlINS_5rfnoc19>> name>_block_ctrlEEEN5boost10shared_ptrIT_EERKNS2_10block_id_tE
>>> 0023d6e0 V _ZTIN3uhd5rfnoc19_block_ctrlE
>>> 00034b00 V _ZTSN3uhd5rfnoc19_ctrlE
>>>
>>> We continue to get same error.
>>>
>>> We have several blocks and we tried with all of them with same result.
>>>
>>>
>>> On Wed, Mar 27, 2019 at 4:36 PM Nick Foster 
>>> wrote:
>>>
 Make very sure that your program is actually linking in the library
 correctly. Linkers are weird and their interaction with build systems is
 often unpredictable and sometimes perverse. Find the symbols in the
 compiled library with nm and see that they aren't undefined. Use make
 VERBOSE=1 to see the library actually being used.

 Nick

 On Wed, Mar 27, 2019 at 2:55 PM John Medrano 
 wrote:

> Thank you for the response.
>
> I have added to CMakeList.txt:
>
> find_library(SLADEW_LIB gnuradio-SLADEW)
> if(NOT SLADEW_LIB)
>   message(FATAL_ERROR "SLADEW library not found")
> endif()
>
> add later I add:
>
> target_link_libraries(rfnoc_freqmod ${UHD_LIBRARIES}
> ${Boost_LIBRARIES} ${SLADEW_LIB})
>
> It compiles fine but I still get same messages on start up.
>
> Please advise:
> John
>
>
> On Wed, Mar 27, 2019 at 3:00 PM Nick Foster 
> wrote:
>
>> Your program needs to be linked against the library which your custom
>> block controller is compiled into, if in fact your block is using a 
>> custom
>> block controller.
>>
>> uhd_usrp_probe and the other UHD utilities aren't linked against the
>> custom library. This isn't generally a problem since the utilities and
>> examples don't make use of your custom block.
>>
>> Nick
>>
>> On Wed, Mar 27, 2019, 1:26 PM John Medrano via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello,
>>>
>>> We have a custom RFNOC block that we 

Re: [USRP-users] RFNoC RX -> TX loopback

[Nick Foster via USRP-users]

Should still work just fine. I'm using the same approach with a UHD version
from within the last few months.

On Thu, Apr 11, 2019 at 8:00 AM Ryan Marlow via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey Jason,
> That post seemed to be exactly what I was looking for.
> Thanks!
> Ryan
>
> On Thu, Apr 11, 2019 at 10:55 AM Jason Matusiak <
> ja...@gardettoengineering.com> wrote:
>
>> I haven't tried it yet, but have you looked at this blog post (I
>> //think// it is still relevant today)?
>> https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
>>
>>
>> --
>> *From:* USRP-users  on behalf of
>> Ryan Marlow via USRP-users 
>> *Sent:* Thursday, April 11, 2019 10:51 AM
>> *To:* USRP-users@lists.ettus.com
>> *Subject:* [USRP-users] RFNoC RX -> TX loopback
>>
>> Hello all,
>> Quick question on a RX -> TX loopback application. Say I have a rfnoc
>> graph that has been connected as Radio RX -> processing block -> Radio TX
>> so there is no data samples streaming to/from the host. Can I just issue
>> the "start streaming" command to the Radio block itself or do I need to use
>> a
>> uhd::rx_streamer to issue the command? Is there any other gotcha that I
>> am overlooking?
>> Thanks,
>> Ryan
>> --
>> Ryan L. Marlow
>> R L Marlow Consulting LLC
>> rlmarlow.com
>>
>
>
> --
> Ryan L. Marlow
> R L Marlow Consulting LLC
> rlmarlow.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

Re: [USRP-users] (no subject)

[Nick Foster via USRP-users]

OK, I looked further into it. UHD registers out-of-tree block controllers
using the UHD_RFNOC_BLOCK_REGISTER macro, which under the hood creates a
static function and a fixture which calls it before main(). Problem is,
when linking your out-of-tree executable, the linker sees that the static
fixture is never explicitly called from your program, and it optimizes it
out. So your block is never getting registered.

There's a number of ways to fix it. I don't know how UHD does it
internally. If you are linking your library statically, you can do
something like the following in the CMakeLists.txt for the application (not
the library):

set(RFNOC_MYMOD_LIB_OPT -Wl,--whole-archive rfnoc-mylib
-Wl,--no-whole-archive)
target_link_libraries(rfnoc_myapp ${RFNOC_MYMOD_LIB_OPT} <...the rest of
your libs...>)

Using --whole-archive will force the linker to include all the contents of
your custom static lib in the application. This includes the static
constructor.

If you're linking dynamically, this may or may not be a problem for you. If
it is, you can do something like
set_target_properties(rfnoc_myapp PROPERTIES LINK_WHAT_YOU_USE TRUE)

...which sets the -Wl,--no-as-needed linker flag, indicating to the linker
that it should include dynamic libraries that aren't explicitly called.
This isn't a great solution as it can result in linking to libraries which
really aren't used.

You can debug this approach by calling the UHD_STATIC_BLOCK macro in your
library and just having it print something to stdout. If you don't see the
print in your application, it's not linking static objects correctly.

Nick

On Mon, Apr 8, 2019 at 8:24 AM John Medrano 
wrote:

> Hello,
>
> We have verified that library is being linked.
>
> When we run  nm  | grep 
>
> We see the following:
> 00030310 W _ZNK3uhd7device314get_block_ctrlINS_5rfnoc19 name>_block_ctrlEEEN5boost10shared_ptrIT_EERKNS2_10block_id_tE
> 0023d6e0 V _ZTIN3uhd5rfnoc19_block_ctrlE
> 00034b00 V _ZTSN3uhd5rfnoc19_ctrlE
>
> We continue to get same error.
>
> We have several blocks and we tried with all of them with same result.
>
>
> On Wed, Mar 27, 2019 at 4:36 PM Nick Foster  wrote:
>
>> Make very sure that your program is actually linking in the library
>> correctly. Linkers are weird and their interaction with build systems is
>> often unpredictable and sometimes perverse. Find the symbols in the
>> compiled library with nm and see that they aren't undefined. Use make
>> VERBOSE=1 to see the library actually being used.
>>
>> Nick
>>
>> On Wed, Mar 27, 2019 at 2:55 PM John Medrano 
>> wrote:
>>
>>> Thank you for the response.
>>>
>>> I have added to CMakeList.txt:
>>>
>>> find_library(SLADEW_LIB gnuradio-SLADEW)
>>> if(NOT SLADEW_LIB)
>>>   message(FATAL_ERROR "SLADEW library not found")
>>> endif()
>>>
>>> add later I add:
>>>
>>> target_link_libraries(rfnoc_freqmod ${UHD_LIBRARIES} ${Boost_LIBRARIES}
>>> ${SLADEW_LIB})
>>>
>>> It compiles fine but I still get same messages on start up.
>>>
>>> Please advise:
>>> John
>>>
>>>
>>> On Wed, Mar 27, 2019 at 3:00 PM Nick Foster 
>>> wrote:
>>>
 Your program needs to be linked against the library which your custom
 block controller is compiled into, if in fact your block is using a custom
 block controller.

 uhd_usrp_probe and the other UHD utilities aren't linked against the
 custom library. This isn't generally a problem since the utilities and
 examples don't make use of your custom block.

 Nick

 On Wed, Mar 27, 2019, 1:26 PM John Medrano via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Hello,
>
> We have a custom RFNOC block that we have created. When we using
> GNURadio/Python everything works fine. When follow the examples in
> uhd/host/examples and generate an executable using C++, we get an error on
> execution.
>
> We noticed that on start up the python program has no issue locating
> controllers for all our custom blocks (FreqMod):
>
> 2019-Mar-27 13:52:50.824938,0x7f36d447c740,log.cpp:460,2,UHD,linux;
> GNU C++ version 7.3.0; Boost_106501; UHD_3.14.0.0-220-g97935b15
> 2019-Mar-27
> 13:52:50.947109,0x7f36d447c740,x300_impl.cpp:400,2,X300,X300 
> initialization
> sequence...
> 2019-Mar-27
> 13:52:51.229789,0x7f36d447c740,x300_impl.cpp:1731,2,X300,Maximum frame
> size: 1472 bytes.
> 2019-Mar-27
> 13:52:51.279558,0x7f36d447c740,x300_impl.cpp:942,2,X300,Radio 1x clock: 
> 200
> MHz
> 2019-Mar-27
> 13:52:51.298743,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DmaFIFO_0,Initializing
> block control (NOC ID: 0xF1F0D000)
> 2019-Mar-27
> 13:52:51.336670,0x7f36d447c740,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
> passed (Throughput: 1302 MB/s)
> 2019-Mar-27
> 13:52:51.387156,0x7f36d447c740,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
> passed (Throughput: 1320 MB/s)
> 2019-Mar-27
> 

Re: [USRP-users] (no subject)

[Nick Foster via USRP-users]

Make very sure that your program is actually linking in the library
correctly. Linkers are weird and their interaction with build systems is
often unpredictable and sometimes perverse. Find the symbols in the
compiled library with nm and see that they aren't undefined. Use make
VERBOSE=1 to see the library actually being used.

Nick

On Wed, Mar 27, 2019 at 2:55 PM John Medrano 
wrote:

> Thank you for the response.
>
> I have added to CMakeList.txt:
>
> find_library(SLADEW_LIB gnuradio-SLADEW)
> if(NOT SLADEW_LIB)
>   message(FATAL_ERROR "SLADEW library not found")
> endif()
>
> add later I add:
>
> target_link_libraries(rfnoc_freqmod ${UHD_LIBRARIES} ${Boost_LIBRARIES}
> ${SLADEW_LIB})
>
> It compiles fine but I still get same messages on start up.
>
> Please advise:
> John
>
>
> On Wed, Mar 27, 2019 at 3:00 PM Nick Foster  wrote:
>
>> Your program needs to be linked against the library which your custom
>> block controller is compiled into, if in fact your block is using a custom
>> block controller.
>>
>> uhd_usrp_probe and the other UHD utilities aren't linked against the
>> custom library. This isn't generally a problem since the utilities and
>> examples don't make use of your custom block.
>>
>> Nick
>>
>> On Wed, Mar 27, 2019, 1:26 PM John Medrano via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello,
>>>
>>> We have a custom RFNOC block that we have created. When we using
>>> GNURadio/Python everything works fine. When follow the examples in
>>> uhd/host/examples and generate an executable using C++, we get an error on
>>> execution.
>>>
>>> We noticed that on start up the python program has no issue locating
>>> controllers for all our custom blocks (FreqMod):
>>>
>>> 2019-Mar-27 13:52:50.824938,0x7f36d447c740,log.cpp:460,2,UHD,linux; GNU
>>> C++ version 7.3.0; Boost_106501; UHD_3.14.0.0-220-g97935b15
>>> 2019-Mar-27 13:52:50.947109,0x7f36d447c740,x300_impl.cpp:400,2,X300,X300
>>> initialization sequence...
>>> 2019-Mar-27
>>> 13:52:51.229789,0x7f36d447c740,x300_impl.cpp:1731,2,X300,Maximum frame
>>> size: 1472 bytes.
>>> 2019-Mar-27
>>> 13:52:51.279558,0x7f36d447c740,x300_impl.cpp:942,2,X300,Radio 1x clock: 200
>>> MHz
>>> 2019-Mar-27
>>> 13:52:51.298743,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DmaFIFO_0,Initializing
>>> block control (NOC ID: 0xF1F0D000)
>>> 2019-Mar-27
>>> 13:52:51.336670,0x7f36d447c740,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
>>> passed (Throughput: 1302 MB/s)
>>> 2019-Mar-27
>>> 13:52:51.387156,0x7f36d447c740,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
>>> passed (Throughput: 1320 MB/s)
>>> 2019-Mar-27
>>> 13:52:51.430922,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/Radio_0,Initializing
>>> block control (NOC ID: 0x12AD1001)
>>> 2019-Mar-27
>>> 13:52:51.529115,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/Radio_1,Initializing
>>> block control (NOC ID: 0x12AD1001)
>>> 2019-Mar-27
>>> 13:52:51.628687,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DUC_0,Initializing
>>> block control (NOC ID: 0xD0C0)
>>> 2019-Mar-27
>>> 13:52:51.50,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DUC_1,Initializing
>>> block control (NOC ID: 0xD0C0)
>>> 2019-Mar-27
>>> 13:52:51.704298,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DDC_0,Initializing
>>> block control (NOC ID: 0xDDC0)
>>> 2019-Mar-27
>>> 13:52:51.741327,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DDC_1,Initializing
>>> block control (NOC ID: 0xDDC0)
>>> 2019-Mar-27
>>> 13:52:51.920546,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/FreqMod_0,Initializing
>>> block control (NOC ID: 0x2833DDBAA1C8E99C)
>>>
>>> But when we run uhd_usrp_probe or our program we get:
>>>
>>> 2019-Mar-27 13:50:48.142811,0x7f489075e7c0,x300_impl.cpp:400,2,X300,X300
>>> initialization sequence...
>>> 2019-Mar-27
>>> 13:50:48.424155,0x7f489075e7c0,x300_impl.cpp:1731,2,X300,Maximum frame
>>> size: 1472 bytes.
>>> 2019-Mar-27
>>> 13:50:48.494774,0x7f489075e7c0,x300_impl.cpp:942,2,X300,Radio 1x clock: 200
>>> MHz
>>> 2019-Mar-27
>>> 13:50:48.509901,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DmaFIFO_0,Initializing
>>> block control (NOC ID: 0xF1F0D000)
>>> 2019-Mar-27
>>> 13:50:48.546377,0x7f489075e7c0,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
>>> passed (Throughput: 1317 MB/s)
>>> 2019-Mar-27
>>> 13:50:48.596601,0x7f489075e7c0,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
>>> passed (Throughput: 1304 MB/s)
>>> 2019-Mar-27
>>> 13:50:48.638428,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/Radio_0,Initializing
>>> block control (NOC ID: 0x12AD1001)
>>> 2019-Mar-27
>>> 13:50:48.736751,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/Radio_1,Initializing
>>> block control (NOC ID: 0x12AD1001)
>>> 2019-Mar-27
>>> 13:50:48.838951,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DUC_0,Initializing
>>> block control (NOC ID: 0xD0C0)
>>> 2019-Mar-27
>>> 13:50:48.877079,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DUC_1,Initializing
>>> block control (NOC ID: 

Re: [USRP-users] (no subject)

[Nick Foster via USRP-users]

Your program needs to be linked against the library which your custom block
controller is compiled into, if in fact your block is using a custom block
controller.

uhd_usrp_probe and the other UHD utilities aren't linked against the custom
library. This isn't generally a problem since the utilities and examples
don't make use of your custom block.

Nick

On Wed, Mar 27, 2019, 1:26 PM John Medrano via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> We have a custom RFNOC block that we have created. When we using
> GNURadio/Python everything works fine. When follow the examples in
> uhd/host/examples and generate an executable using C++, we get an error on
> execution.
>
> We noticed that on start up the python program has no issue locating
> controllers for all our custom blocks (FreqMod):
>
> 2019-Mar-27 13:52:50.824938,0x7f36d447c740,log.cpp:460,2,UHD,linux; GNU
> C++ version 7.3.0; Boost_106501; UHD_3.14.0.0-220-g97935b15
> 2019-Mar-27 13:52:50.947109,0x7f36d447c740,x300_impl.cpp:400,2,X300,X300
> initialization sequence...
> 2019-Mar-27
> 13:52:51.229789,0x7f36d447c740,x300_impl.cpp:1731,2,X300,Maximum frame
> size: 1472 bytes.
> 2019-Mar-27 13:52:51.279558,0x7f36d447c740,x300_impl.cpp:942,2,X300,Radio
> 1x clock: 200 MHz
> 2019-Mar-27
> 13:52:51.298743,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DmaFIFO_0,Initializing
> block control (NOC ID: 0xF1F0D000)
> 2019-Mar-27
> 13:52:51.336670,0x7f36d447c740,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
> passed (Throughput: 1302 MB/s)
> 2019-Mar-27
> 13:52:51.387156,0x7f36d447c740,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
> passed (Throughput: 1320 MB/s)
> 2019-Mar-27
> 13:52:51.430922,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/Radio_0,Initializing
> block control (NOC ID: 0x12AD1001)
> 2019-Mar-27
> 13:52:51.529115,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/Radio_1,Initializing
> block control (NOC ID: 0x12AD1001)
> 2019-Mar-27
> 13:52:51.628687,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DUC_0,Initializing
> block control (NOC ID: 0xD0C0)
> 2019-Mar-27
> 13:52:51.50,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DUC_1,Initializing
> block control (NOC ID: 0xD0C0)
> 2019-Mar-27
> 13:52:51.704298,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DDC_0,Initializing
> block control (NOC ID: 0xDDC0)
> 2019-Mar-27
> 13:52:51.741327,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/DDC_1,Initializing
> block control (NOC ID: 0xDDC0)
> 2019-Mar-27
> 13:52:51.920546,0x7f36d447c740,block_ctrl_base.cpp:60,2,0/FreqMod_0,Initializing
> block control (NOC ID: 0x2833DDBAA1C8E99C)
>
> But when we run uhd_usrp_probe or our program we get:
>
> 2019-Mar-27 13:50:48.142811,0x7f489075e7c0,x300_impl.cpp:400,2,X300,X300
> initialization sequence...
> 2019-Mar-27
> 13:50:48.424155,0x7f489075e7c0,x300_impl.cpp:1731,2,X300,Maximum frame
> size: 1472 bytes.
> 2019-Mar-27 13:50:48.494774,0x7f489075e7c0,x300_impl.cpp:942,2,X300,Radio
> 1x clock: 200 MHz
> 2019-Mar-27
> 13:50:48.509901,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DmaFIFO_0,Initializing
> block control (NOC ID: 0xF1F0D000)
> 2019-Mar-27
> 13:50:48.546377,0x7f489075e7c0,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
> passed (Throughput: 1317 MB/s)
> 2019-Mar-27
> 13:50:48.596601,0x7f489075e7c0,dma_fifo_block_ctrl_impl.cpp:44,2,0/DmaFIFO_0,BIST
> passed (Throughput: 1304 MB/s)
> 2019-Mar-27
> 13:50:48.638428,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/Radio_0,Initializing
> block control (NOC ID: 0x12AD1001)
> 2019-Mar-27
> 13:50:48.736751,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/Radio_1,Initializing
> block control (NOC ID: 0x12AD1001)
> 2019-Mar-27
> 13:50:48.838951,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DUC_0,Initializing
> block control (NOC ID: 0xD0C0)
> 2019-Mar-27
> 13:50:48.877079,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DUC_1,Initializing
> block control (NOC ID: 0xD0C0)
> 2019-Mar-27
> 13:50:48.916659,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DDC_0,Initializing
> block control (NOC ID: 0xDDC0)
> 2019-Mar-27
> 13:50:48.957457,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/DDC_1,Initializing
> block control (NOC ID: 0xDDC0)
> 2019-Mar-27
> 13:50:49.135814,0x7f489075e7c0,block_ctrl_base_factory.cpp:77,3,RFNOC,Can't
> find a block controller for key FreqMod, using default block
>  controller!
> 2019-Mar-27
> 13:50:49.139122,0x7f489075e7c0,block_ctrl_base.cpp:60,2,0/FreqMod_0,Initializing
> block control (NOC ID: 0x2833DDBAA1C8E99C)
>
> The error we receive is directly related to the above. Please advise.
>
> Thank you,
> John
> ___
> 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

Re: [USRP-users] A few questions about RFNoC streaming

[Nick Foster via USRP-users]

I can tell you the answer to #3 off the top of my head: the two streams
will be sample-aligned, and if you use timed start commands, they will be
time-aligned.

The other two are probably best answered by trying it out. Maybe someone
from Ettus can chime in.

Nick

On Fri, Mar 22, 2019 at 7:09 AM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Any suggestions?
>
> On Wed, Mar 20, 2019 at 9:49 PM Rob Kossler  wrote:
>
>> Yes, the example was for illustration only.  You can throw a couple of
>> DDCs in between the radio and add/sub block to slow the rate down.  But,
>> the questions are still the same.
>>
>> On Wed, Mar 20, 2019 at 7:49 PM Nick Foster  wrote:
>>
>>> First things first. The flow graph you're describing don't work because
>>> the two radio blocks will saturate the bus going into the addsub block. You
>>> will need to decimate the streams going into the addsub block.
>>>
>>> I don't have a ready answer to your question about the streamers, but
>>> I'd suggest using timed commands to align the two radio streams, if UHD
>>> isn't smart enough to recognize the two radios and propagate the stream
>>> command accordingly.
>>>
>>> Nick
>>>
>>> On Thu, Mar 21, 2019, 6:46 AM Rob Kossler via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hi,
 I am starting to develop more complicated RFNoC graphs and several
 questions occurred to me. I am using my own C++ application with the UHD
 RFNoC-enabled library.

 Consider a receive-only RFNoC graph with 2 radio blocks feeding a
 2-input, 2-output Add/Sub block.  Also, assume there are two rx_streamers
 connected to the 2 output ports of the Add/Sub block.  Note that these
 streams are no longer independent or one-to-one matched with the radio
 channels.

 1) How does an "issue_stream_cmd()" to one of the Add/Sub block ports
 propagate back to the radio block?  Actually, it would need to propagate
 back to both Radio blocks no matter which rx_streamer I used since they are
 no longer independent streams.  Does this make sense?
 2) What happens if I only call "issue_stream_cmd()" for one of the
 rx_streamers instead of both? Perhaps since the other streamer isn't
 running, it backpressures the streaming such that it eventually quits and
 thus quits for the other port as well?
 3) Do I have to do anything in the Add/Sub block to sync up the streams
 or can I rely on the first sample from Radio 0 being time-aligned with the
 first sample from Radio 1 (assuming I issued timed start commands)?

 Rob
 ___
 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

Re: [USRP-users] RFNoC questions - standalone system, docs

[Nick Foster via USRP-users]

I wrote a blog post a while back describing a RX->TX RFNoC loopback
application. It should still apply to the latest UHD:

https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/

Nick

On Sun, Mar 24, 2019 at 5:33 PM Julius Baxter via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I have a couple of quick questions.
>
> I have an N310 and intend to build a system which doesn't involve passing
> the stream through a host - ie. I want to add a CE or two which will handle
> Rx and generate samples for Tx. Has anyone done this, are there any
> pointers? I presume the host will still be involved to configure the blocks
> (radio, ddc, duc, etc.). Can I still use the Python USRP API to do this
> config?
>
> Is there anything complementing the Ettus KB on the RFNoC internals? I've
> seen some posts referencing what parameters on various blocks do, and other
> nuggets of knowledge regarding building CEs for RFNoC. Is there a
> centralised place for details on how RFNoC works, or is reading the RTL and
> this ml the best source of info?
>
> Thanks,
> Jules
>
>
> ___
> 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

Re: [USRP-users] UBX coherence between TX and RX

[Nick Foster via USRP-users]

Well, according to your description, you could transmit a carrier from TX
to RX (through an attenuator) with both sides set to the same frequency.
Your received signal should look like a sine wave at the frequency of the
offset.

On Mon, Mar 25, 2019 at 9:16 AM Michael R. Freedman via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> Do you have any suggestions as to how to measure the frequency delta
> between the transmit channel and the receive channel?
>
> As I sat down to do this, I realized I have no real way to do that.
>
>
> Mike
>
>
>
>
>
> On 03/24/2019 03:23 PM, Marcus D. Leech via USRP-users wrote:
>
> On 03/24/2019 02:39 PM, Freedman, Michael - 1008 - MITLL via USRP-users
> wrote:
>
> It is not just a phase offset. It is a frequency offset. The phase drifts 
> between the two. I can tolerate a phase offset at startup. A freq offset 
> however is causing problems.
>
> Mike
>
> Sent from my iPhone
>
> On Mar 24, 2019, at 4:28 AM, Marcus Müller  
>  wrote:
>
> Can you elaborate on what "not coherent" means to you – the relative
> phase should be constant after each tune, but if you don't tune
> simultaneously, i.e. with timed commands, random at each tune.
>
> Best regards,
> Marcus
>
> Also, what version of UHD?  What hardware rev of UBX cards?
>
>
> On Sat, 2019-03-23 at 17:06 -0400, Michael R. Freedman via USRP-users
> wrote:
>
> Hello,
>
>
> I have an issue where I tune both the TX and RX side of a UBX40 card
> in
> an X310 to the same frequency and find that the transmitted signal
> and
> what is received are not coherent.  I am using an external 10MHz
> reference and have tried the documented suggestions.
>
> at 150MHz it is coherent.
>
> at 155MHz it is NOT coherent.
>
>
> I have tried setting the dboard_clock_rate to 20MHz.  This made the
> problem appear at 150MHz as well.  I've tried integer_n tuning.
>
> I have verified that the ref_lock and lo_lock are both true.
>
>
> Any suggestions?
>
>
> Mike
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> ___
> 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
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] A few questions about RFNoC streaming

[Nick Foster via USRP-users]

First things first. The flow graph you're describing don't work because the
two radio blocks will saturate the bus going into the addsub block. You
will need to decimate the streams going into the addsub block.

I don't have a ready answer to your question about the streamers, but I'd
suggest using timed commands to align the two radio streams, if UHD isn't
smart enough to recognize the two radios and propagate the stream command
accordingly.

Nick

On Thu, Mar 21, 2019, 6:46 AM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> I am starting to develop more complicated RFNoC graphs and several
> questions occurred to me. I am using my own C++ application with the UHD
> RFNoC-enabled library.
>
> Consider a receive-only RFNoC graph with 2 radio blocks feeding a 2-input,
> 2-output Add/Sub block.  Also, assume there are two rx_streamers connected
> to the 2 output ports of the Add/Sub block.  Note that these streams are no
> longer independent or one-to-one matched with the radio channels.
>
> 1) How does an "issue_stream_cmd()" to one of the Add/Sub block ports
> propagate back to the radio block?  Actually, it would need to propagate
> back to both Radio blocks no matter which rx_streamer I used since they are
> no longer independent streams.  Does this make sense?
> 2) What happens if I only call "issue_stream_cmd()" for one of the
> rx_streamers instead of both? Perhaps since the other streamer isn't
> running, it backpressures the streaming such that it eventually quits and
> thus quits for the other port as well?
> 3) Do I have to do anything in the Add/Sub block to sync up the streams or
> can I rely on the first sample from Radio 0 being time-aligned with the
> first sample from Radio 1 (assuming I issued timed start commands)?
>
> Rob
> ___
> 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

Re: [USRP-users] Sending very short bursts with RFNoC on X310

[Nick Foster via USRP-users]

Jonathon,

Thanks for the early Saturday (or late Friday) reply.

On Sat, Mar 9, 2019 at 1:13 AM Jonathon Pendlum 
wrote:

> Hey Nick,
>
> The DDC and the DUC (or any other block using axi_rate_change) will not
> modify the packet size. Very small packets can cause underruns once the
> header becomes a large percentage of the overall packet size. I'm surprised
> that you are running into underruns at 20 samples per packet as that is
> less than 10% header overhead. The theoretical crossbar throughput is 375
> MSPS. Noc_shell's throughput is similar to the crossbar's since it also
> operates on the packet line by line. Flow control packets and crossbar
> switching add to the overhead as well, but there should still be plenty of
> throughput left.
>

I was surprised to see 20 sample packets underrunning as well. Maybe
there's a bubble state somewhere in the DUC or the crossbar. It underruns
not only reliably but consistently in the same places, especially for short
packets. Give it a shot -- an LFTX and an oscilloscope will show that it
tends to underrun after the first few packets!


>
> What version/branch of UHD are you using? If you are using UHD-3.13, try
> setting your MTU to something closer to your actual packet size or try
> using UHD-3.14.
>

This is with master (git hash 33f269f0), which is only a couple of weeks
old.


>
> As for the EOB issue, when the radio core encounters an underrun it will
> stop transmitting and wait for an EOB. I wonder if the EOB never comes for
> some reason, such as the DUC is not outputting it. Have you tried testing
> in loopback and seeing if the DUC actually outputs an EOB on the last
> packet?
>

Makes sense. EOB comes along just fine if there aren't underruns, but when
there are, the radio never sees it.

In the meantime, I can work around the problem by just padding my bursts
with zeroes to force the packet size up. It's not ideal but I think it'll
get me going.

Nick


>
> Jonathon
>
> On Sat, Mar 9, 2019 at 8:36 AM Nick Foster via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all,
>>
>> I'm trying to write an RFNoC application which generates very short
>> bursts -- 20 samples or less -- which are then upsampled. I'm running into
>> problems with the radio underflowing which I believe has to do with the DUC.
>>
>> I can reduce the problem to the following -- create an RFNoC graph (UHD
>> only, no gr-ettus) with a radio and a DUC. Wire the DUC to the radio and
>> get a tx_streamer pointing to the DUC. Set the DUC to interp=1024. Start
>> the streamer via calling the radio's set_tx_streamer().
>>
>> Now send a packet to the DUC, a short one. Try 20 samples. You'll see a
>> bunch of underflows come back, and if you set EOB then the radio will stop
>> transmitting. (Incidentally, why is that? If I set EOB and the transmission
>> results in an underflow, subsequent bursts won't transmit at all.)
>>
>> If I pull the radio out of the loop and gather the DUC output on the
>> host, Wireshark shows I'm receiving a whole slew of length-88 packets.
>> That's 20 samples after the 64-bit header. So, it looks to me like
>> axi_rate_change inside the DUC isn't resizing the output packets, it's just
>> sending out *lots of them* -- in this case, 1024 20-sample packets for
>> every input packet. This doesn't make a whole lot of sense to me as it's
>> inefficient, and I can fully believe the radio is underflowing while trying
>> to swallow a whole mess of short packets at full radio rate.
>>
>> So: is this intended behavior, and is there anything I can do to change
>> that behavior besides padding my bursts?
>>
>> Nick
>>
> ___
>> 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] Sending very short bursts with RFNoC on X310

[Nick Foster via USRP-users]

Hi all,

I'm trying to write an RFNoC application which generates very short bursts
-- 20 samples or less -- which are then upsampled. I'm running into
problems with the radio underflowing which I believe has to do with the DUC.

I can reduce the problem to the following -- create an RFNoC graph (UHD
only, no gr-ettus) with a radio and a DUC. Wire the DUC to the radio and
get a tx_streamer pointing to the DUC. Set the DUC to interp=1024. Start
the streamer via calling the radio's set_tx_streamer().

Now send a packet to the DUC, a short one. Try 20 samples. You'll see a
bunch of underflows come back, and if you set EOB then the radio will stop
transmitting. (Incidentally, why is that? If I set EOB and the transmission
results in an underflow, subsequent bursts won't transmit at all.)

If I pull the radio out of the loop and gather the DUC output on the host,
Wireshark shows I'm receiving a whole slew of length-88 packets. That's 20
samples after the 64-bit header. So, it looks to me like axi_rate_change
inside the DUC isn't resizing the output packets, it's just sending out *lots
of them* -- in this case, 1024 20-sample packets for every input packet.
This doesn't make a whole lot of sense to me as it's inefficient, and I can
fully believe the radio is underflowing while trying to swallow a whole
mess of short packets at full radio rate.

So: is this intended behavior, and is there anything I can do to change
that behavior besides padding my bursts?

Nick
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] [UHD] Announcing 3.14.0.0 Release Candidate 1

[Nick Foster via USRP-users]

Any plans to update to the latest API? Won't compile with anything after
17.05.

On Wed, Feb 13, 2019, 11:33 AM Michael West  wrote:

> Hi Nick,
>
> Information on using DPDK can be found here:
> http://files.ettus.com/manual/page_dpdk.html
>
> DPDK can be used with any example.  Think of it as an accelerator for
> Ethernet transports if using Intel NICs.
>
> Regards,
> Michael
>
> On Thu, Feb 7, 2019 at 10:29 AM Nick Foster  wrote:
>
>> Great news! DPDK support is an interesting development. Is there any
>> documentation or examples which show this capability?
>>
>> Nick
>>
>>
>> On Thu, Feb 7, 2019 at 10:05 AM Michael West via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> The release candidate of UHD version 3.14.0.0 has been tagged and is
>>> available for testing.  This API release introduces support for the N320
>>> and N321 USRPs soon to be released (watch for the announcement on
>>> ettus.com!), a DPDK-based transport, and several other features and bug
>>> fixes.  This release includes all bug fixes and enhancements in the
>>> 3.13.0.1, 3.13.0.2, and 3.13.1.0 maintenance releases.
>>>
>>> The tag for this release candidate:
>>> https://github.com/EttusResearch/uhd/releases/tag/v3.14.0.0-rc1
>>>
>>> There have been 406 commits since the last API release (3.13.0.0) which
>>> can be viewed here:
>>> https://github.com/EttusResearch/uhd/compare/v3.13.0.0...v3.14.0.0-rc1
>>>
>>> Please report any bugs found on the UHD issue tracker:
>>> http://github.com/EttusResearch/uhd/issues
>>> * Please do not use the issue tracker for help or support.
>>>
>>> Pull requests for direct code changes may be submitted to the UHD or
>>> FPGA repositories:
>>> http://github.com/EttusResearch/uhd/pulls
>>> http://github.com/EttusResearch/fpga/pulls
>>>
>>> CHANGELOG:
>>> ## 003.014.000.000
>>> * N320: Add N320 and N321
>>> * Test: Add Python API test
>>> * Device3: Move from packet-based to byte-based flow control
>>> * X300: Reduce default send_frame_size to 4000 over Ethernet
>>> * UHD: Release recv buffers earlier in rx_streamer
>>> * Device3: Constrain send_buff_size to input fifo size
>>> * X300: Change Ethernet buffering
>>> * MPMD: Parallelize broadcast-finding
>>> * Device: Parallelize device discovery
>>> * Docs: Fix Doxygen warnings
>>> * B100: Move fifo_ctrl_excelsior to b100 subdir
>>> * B100: Fix fifo_ctrl_excelsior not exiting
>>> * B100: Remove all Boostisms from fifo_ctrl_excelsior
>>> * B100: Demote some clocking-related log messages to trace
>>> * X300: Log git hash and compat number as debug message
>>> * N310: Modify AD9371 reset function to keep it in reset
>>> * N3xx: clocking API changes for transitioning clock and time sources
>>> * E320: bist: Fix ref_clock lock test implementation
>>> * UHD: Fix ADF400x driver for ref counter and charge pump mode
>>> * E320: bist: Add link_up test
>>> * MPM: Get list of temperatures from all thermal zones
>>> * E320: Add all 5 temp sensors, fan sensor and rssi sensors per channel
>>> * E320: Fix tx/rx atr - antenna and frequency settings
>>> * E320: Enable devtest for E320
>>> * X300: Move defaults to their own header
>>> * UHD: Improve constrained_device_args_t
>>> * X300: Use constrained_args
>>> * X300: Enable clock_source and time_source device args
>>> * Test: Integrate Python API Tester into Devtest
>>> * N3xx: Bump max rev to G/6
>>> * N3xx: Improve error messages for invalid clock/time settings
>>> * E320: images: Separate images package for Aurora image
>>> * B200: Remove superfluous fake lambda
>>> * B200: Add support for user regs
>>> * Docs: Add info on how to implement user regs on B200
>>> * UHD API: Add multi_usrp::get_user_settings_iface()
>>> * N310: move init_rf_cal before JESD de/framer bringup
>>> * UHD: Remove usage of time_t (except when required)
>>> * NIRIO: Demote RPC client cancel/abort to TRACE
>>> * RFNoC: Convert SR_READBACK_REG_FIFOSIZE to bytes
>>> * Utils: Add Zip test to downloader
>>> * Utils: Factor wait_for_lo_lock() out of cal utils
>>> * DPDK: Add DPDK-based sockets-like library
>>> * MPMD: add option to enum rfnoc blocks from args
>>> * E320: Get RFNoC crossbar baseport from FPGA
>>> * N3xx: Get RFNoC crossbar baseport from FPGA
>>> * UHD: add default xport params to udp_zero_copy
>>> * MPM: add link_speed xport_info
>>> * MPMD: add link speed to xport udp
>>> * Device3: remove tx_hint[send_buff_size]
>>> * X300: remove default_buff_args properties
>>> * RFNoC: Add ability to enable/disable RX timestamp
>>> * RFNoC: add async message handler
>>> * Examples: add rfnoc_radio_loopback example
>>> * UHD: Update rx_frontend_gen3.v controls for 1/4-rate mixer
>>> * UHD API: Move definition of ALL_MBOARDS and ALL_CHANS constants to
>>>CPP file.
>>> * MPM: Add __mpm_device__ as usrp_hwd module variable
>>> * MPM: Add usrp_update_fs
>>> * UHD: Add traffic counter to null source sink
>>> * Examples: Add benchmark_streamer example
>>> * Tools: Add tool to analyze settling time of gain and freq changes
>>> * UHD 

Re: [USRP-users] [UHD] Announcing 3.14.0.0 Release Candidate 1

[Nick Foster via USRP-users]

Great news! DPDK support is an interesting development. Is there any
documentation or examples which show this capability?

Nick


On Thu, Feb 7, 2019 at 10:05 AM Michael West via USRP-users <
usrp-users@lists.ettus.com> wrote:

> The release candidate of UHD version 3.14.0.0 has been tagged and is
> available for testing.  This API release introduces support for the N320
> and N321 USRPs soon to be released (watch for the announcement on
> ettus.com!), a DPDK-based transport, and several other features and bug
> fixes.  This release includes all bug fixes and enhancements in the
> 3.13.0.1, 3.13.0.2, and 3.13.1.0 maintenance releases.
>
> The tag for this release candidate:
> https://github.com/EttusResearch/uhd/releases/tag/v3.14.0.0-rc1
>
> There have been 406 commits since the last API release (3.13.0.0) which
> can be viewed here:
> https://github.com/EttusResearch/uhd/compare/v3.13.0.0...v3.14.0.0-rc1
>
> Please report any bugs found on the UHD issue tracker:
> http://github.com/EttusResearch/uhd/issues
> * Please do not use the issue tracker for help or support.
>
> Pull requests for direct code changes may be submitted to the UHD or FPGA
> repositories:
> http://github.com/EttusResearch/uhd/pulls
> http://github.com/EttusResearch/fpga/pulls
>
> CHANGELOG:
> ## 003.014.000.000
> * N320: Add N320 and N321
> * Test: Add Python API test
> * Device3: Move from packet-based to byte-based flow control
> * X300: Reduce default send_frame_size to 4000 over Ethernet
> * UHD: Release recv buffers earlier in rx_streamer
> * Device3: Constrain send_buff_size to input fifo size
> * X300: Change Ethernet buffering
> * MPMD: Parallelize broadcast-finding
> * Device: Parallelize device discovery
> * Docs: Fix Doxygen warnings
> * B100: Move fifo_ctrl_excelsior to b100 subdir
> * B100: Fix fifo_ctrl_excelsior not exiting
> * B100: Remove all Boostisms from fifo_ctrl_excelsior
> * B100: Demote some clocking-related log messages to trace
> * X300: Log git hash and compat number as debug message
> * N310: Modify AD9371 reset function to keep it in reset
> * N3xx: clocking API changes for transitioning clock and time sources
> * E320: bist: Fix ref_clock lock test implementation
> * UHD: Fix ADF400x driver for ref counter and charge pump mode
> * E320: bist: Add link_up test
> * MPM: Get list of temperatures from all thermal zones
> * E320: Add all 5 temp sensors, fan sensor and rssi sensors per channel
> * E320: Fix tx/rx atr - antenna and frequency settings
> * E320: Enable devtest for E320
> * X300: Move defaults to their own header
> * UHD: Improve constrained_device_args_t
> * X300: Use constrained_args
> * X300: Enable clock_source and time_source device args
> * Test: Integrate Python API Tester into Devtest
> * N3xx: Bump max rev to G/6
> * N3xx: Improve error messages for invalid clock/time settings
> * E320: images: Separate images package for Aurora image
> * B200: Remove superfluous fake lambda
> * B200: Add support for user regs
> * Docs: Add info on how to implement user regs on B200
> * UHD API: Add multi_usrp::get_user_settings_iface()
> * N310: move init_rf_cal before JESD de/framer bringup
> * UHD: Remove usage of time_t (except when required)
> * NIRIO: Demote RPC client cancel/abort to TRACE
> * RFNoC: Convert SR_READBACK_REG_FIFOSIZE to bytes
> * Utils: Add Zip test to downloader
> * Utils: Factor wait_for_lo_lock() out of cal utils
> * DPDK: Add DPDK-based sockets-like library
> * MPMD: add option to enum rfnoc blocks from args
> * E320: Get RFNoC crossbar baseport from FPGA
> * N3xx: Get RFNoC crossbar baseport from FPGA
> * UHD: add default xport params to udp_zero_copy
> * MPM: add link_speed xport_info
> * MPMD: add link speed to xport udp
> * Device3: remove tx_hint[send_buff_size]
> * X300: remove default_buff_args properties
> * RFNoC: Add ability to enable/disable RX timestamp
> * RFNoC: add async message handler
> * Examples: add rfnoc_radio_loopback example
> * UHD: Update rx_frontend_gen3.v controls for 1/4-rate mixer
> * UHD API: Move definition of ALL_MBOARDS and ALL_CHANS constants to
>CPP file.
> * MPM: Add __mpm_device__ as usrp_hwd module variable
> * MPM: Add usrp_update_fs
> * UHD: Add traffic counter to null source sink
> * Examples: Add benchmark_streamer example
> * Tools: Add tool to analyze settling time of gain and freq changes
> * UHD API: Add multi_usrp::set_sync_source() API
> * UHD: Improve documentation for the UHD exception types
> * Examples: Add dual measurements to benchmark_streamer
> * MPM: Add i2c APIs for simple transfers
> * MPM: Add vector-based transfer function for i2c
> * UHD: Improve documentation for set_{time,clock,sync}_source
> * CMake: Bump CMake minimum version to 2.8.12
> * MPM: Add variable configuration support to nijesdcore
> * MPM: Add eyescan utility to nijesdcore
> * MPM: Add PRBS-31 testing to nijesdcore
> * CMake: Change SOVERSION and VERSION for the library files
> * Test: Add graph impl test to device3_test
> * RFNoC: Changes 

Re: [USRP-users] Protecting USRP's from humidity and salt

[Nick Foster via USRP-users]

A HEPA filter won't do anything to reduce salt or moisture in the air
inside the enclosure. There are a few things you could do to try to ensure
the electronics live a while.

Just ensure that there is adequate climate control inside the shack. This
means air conditioning in the summer to bring the humidity down, and
heating in the winter to stay far above the dewpoint. The dehumidifier is a
great idea and when combined with climate control and a plan to minimize
air exchange with the outside is probably your best bet.

Also, you could buy a can of spray-on conformal coating and just coat the
USRP's electronics. This would require masking off connectors and is pretty
invasive. If you go this route I'd recommend an acrylic like HumiSeal 1B73.

Nick

On Mon, Jan 7, 2019 at 2:02 PM Ali Dormiani via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello everyone,
>
> I have an application in which we will be deploying some N310's on a pier
> (right next to the ocean).
>
> The USRP's will be in a small 10x13x8 ft shack that is reasonably
> weatherproofed. I say reasonably because there are gaps in the door-frame
> and a small hole for passing coaxial cables out to the antenna mast.
>
> My current (questionable) plan is to put a strong de-humidifier in the
> shack and add HEPA filters to the AC unit that is built into the shack.
>
> As an added precaution, I want to buy some bulk filter material, cut it
> up, and fasten it to the N310's intake and exhaust.
>
> This leads to obvious heat concerns. It seems that the N310 has a thermal
> design power (TDP) of 75W so I think a thin 1 in think HEPA filter would be
> ok? (the Nvidia 1050 ti also has a TDP of 75W and has some passively cooled
> variants)
>
> The following link shows all the various types of HEPA filters on the
> market. Have not decided which type would be best.
>
> https://www.airfilterusa.com/commercial-industrial/air-filter-media
>
> I would like some feedback on how feasible this plan is. Additionally, I
> would like to hear of other solutions used by other USRP users.*
>
> *I've looked into environmental enclosures and those are too bulky for the
> shack. We have to share space with other research projects.
>
> Thank you for your time,
>
> Ali Dormiani
>
> ___
> 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

Re: [USRP-users] X310 xpr Files

[Nick Foster via USRP-users]

You can do "make GUI=1 X310_HG" to open the Vivado GUI and build the
project.

Nick

On Tue, Dec 18, 2018 at 1:33 PM Alexander Olihovik via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> Will running "make X310_HG" generate a .xpr file that I can open with
> Vivado? I have a .xpr for the E310 from a previous effort so I think it can
> be done, but I wasn't the originator of this file.
> I was following this guide:
> http://files.ettus.com/manual/md_usrp3_build_instructions.html
>
> Best,
> Alex
> ___
> 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

Re: [USRP-users] RFNoC data format

[Nick Foster via USRP-users]

The values are converted within UHD before sending to or after receiving
from the device. The mapping is signed int16 <-> float [-1, 1]. If you need
to work with the original int16 data you can just select complex int16 in
the "[input, output] type" dropdown in the sink/source blocks.

Nick

On Fri, Oct 19, 2018 at 6:54 AM Kranz Samuel Josef via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi
>
>
>
> How do data formats work in rfnoc development? If I have a look at the
> tutorial gain block (
> https://kb.ettus.com/Getting_Started_with_RFNoC_Development)
>
> The gain block accepts an AXI stream containing concatenated I and Q
> samples, which are interpreted as 16bit values. But when I have a look at
> the GnuRadio block
>
> the data host format is complex float32 and the device format is int16.
> When and where are those values converted and how are they mapped?
>
>
>
> Thanks
>
> Samuel
> ___
> 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

Re: [USRP-users] GPIO pin used for ground on the X300

[Nick Foster via USRP-users]

Any of those choices are fine.

On Tue, Oct 16, 2018 at 11:22 AM Mega Samples via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi USRP-users,
>
> I have an X300.  I am trying to connect an external circuit to GPIO pin 2
> ("data[0]" on the pinout).  What is a good pin to use for ground -- pin 14
> or 15, which are labelled "0V"?  Or the shell of the DB15 connector?
>
> Thanks in advance,
> Mike
>
> ___
> 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

Re: [USRP-users] Synch'ing two USRP-X310

[Nick Foster via USRP-users]

It is definitely regenerated, and I can believe that there's no
compensation for delay. I haven't measured the output on a phase noise
analyzer, but as it's coming from the same clock generator which provides
the sample clock for the device I would expect it to be similarly clean.

Nick

On Tue, Oct 16, 2018 at 9:07 AM Marcus D. Leech  wrote:

> On 10/16/2018 12:00 PM, Nick Foster wrote:
>
> Wait, what? I've been using REF OUT for years now. What am I missing? What
> does "aren't actually fully supported" mean?
>
> My understanding, and R can correct me if I'm wrong, is that the REF OUT
> not only has no phase-length compensation, but it's
>   a regenerated signal with unpleasant phase-noise.
>
> But if those issues have been addressed, then I retract my statement.
>
>
>
> On Tue, Oct 16, 2018 at 8:57 AM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 10/16/2018 07:44 AM, Francois Quitin via USRP-users wrote:
>>
>> Dear all,
>>
>>
>>
>> We encountered a small problem when we try to build a 4-element MIMO
>> array with two X310 (equipped with UBX daughterboards). We are working on
>> UHD-3.10.3:
>>
>> -  When we use an octoclock to provide the 10 MHz Ref and the
>> PPS to both X310, the phase of each receiving front-end stays nicely
>> constant (see octoclock.png). The Ref Source and Time Source are set to
>> “external” in GNU Radio (the points represent a measurement taken every ten
>> seconds)
>>
>> -  When we use the 10 MHz Ref Out and PPS Out from one X310 and
>> feed it to the Ref In and PPS In of the other X310, we observe a drift in
>> the phases of the channels from the second X310. This is shown in the graph
>> daisyChain.png, where we take one point every ten seconds. We configured
>> GNU Radio to set the Ref Source and Time source of the first USRP to
>> “default”, the ones of the second USRP to “external”.
>>
>>
>>
>> This drift is something more severe, sometimes less, but it’s always
>> present. Any idea why we observe this?
>>
>>
>>
>> Many thanks,
>>
>>
>>
>> François
>>
>>
>>
>> ---
>>
>> Francois QUITIN
>>
>> Assistant Professor
>>
>>
>>
>> BEAMS Dpt. – Embedded Electronics
>>
>> Brussels School of Engineering
>>
>> Université Libre de Bruxelles (ULB)
>>
>>
>>
>> Web   https://sites.google.com/site/fquitin2/
>>
>> Phone +32 2 650 2829 <+32%202%20650%2028%2029>
>>
>>
>>
>> The REF OUT and PPS OUT ports aren't actually fully supported in the FPGA
>> code, and we don't, at this point, recommend their use.
>>
>>
>>
>> ___
>> 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

Re: [USRP-users] Synch'ing two USRP-X310

[Nick Foster via USRP-users]

Wait, what? I've been using REF OUT for years now. What am I missing? What
does "aren't actually fully supported" mean?

On Tue, Oct 16, 2018 at 8:57 AM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 10/16/2018 07:44 AM, Francois Quitin via USRP-users wrote:
>
> Dear all,
>
>
>
> We encountered a small problem when we try to build a 4-element MIMO array
> with two X310 (equipped with UBX daughterboards). We are working on
> UHD-3.10.3:
>
> -  When we use an octoclock to provide the 10 MHz Ref and the PPS
> to both X310, the phase of each receiving front-end stays nicely constant
> (see octoclock.png). The Ref Source and Time Source are set to “external”
> in GNU Radio (the points represent a measurement taken every ten seconds)
>
> -  When we use the 10 MHz Ref Out and PPS Out from one X310 and
> feed it to the Ref In and PPS In of the other X310, we observe a drift in
> the phases of the channels from the second X310. This is shown in the graph
> daisyChain.png, where we take one point every ten seconds. We configured
> GNU Radio to set the Ref Source and Time source of the first USRP to
> “default”, the ones of the second USRP to “external”.
>
>
>
> This drift is something more severe, sometimes less, but it’s always
> present. Any idea why we observe this?
>
>
>
> Many thanks,
>
>
>
> François
>
>
>
> ---
>
> Francois QUITIN
>
> Assistant Professor
>
>
>
> BEAMS Dpt. – Embedded Electronics
>
> Brussels School of Engineering
>
> Université Libre de Bruxelles (ULB)
>
>
>
> Web   https://sites.google.com/site/fquitin2/
>
> Phone +32 2 650 2829 <+32%202%20650%2028%2029>
>
>
>
> The REF OUT and PPS OUT ports aren't actually fully supported in the FPGA
> code, and we don't, at this point, recommend their use.
>
>
>
> ___
> 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

Re: [USRP-users] Rfnoc latency

[Nick Foster via USRP-users]

In a packet-switched system, because a whole packet must be buffered before
being passed through the crossbar, your delay is going to be governed by
your packet size and your sample rate. If you are decimating down to a
lower sample rate, you will incur larger delays.

To a first approximation, you can say the delay of a block will be (packet
size / sample rate), plus a bit of overhead. If I understand the Sunderlin
paper correctly, that overhead is what he's measuring.

I am able to get loopback operation in an X310 down to about 26us latency
with several blocks in the loop through careful optimization of packet size
and by keeping the full 200Msps sample rate (even though my application
only requires 30kHz of bandwidth). If you can run your custom block at full
bus speed, that's the best way to ensure low latency. If you require narrow
bandwidths, consider a cascade of FIR filters instead of DDC-[block]-DUC.

Nick

On Fri, Sep 28, 2018 at 2:44 AM Sebastian Bräuer via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> I am currently working on a custom block that implements
> Listen-Before-Talk directly on the X310 and I have question regarding
> the latency that I can expect in between RFnoC blocks. This article [1]
> claims that each block delays the signal by about 2us which would put
> the turn-around time for my block to about 10us (RxRadio -> DDC ->
> custom block -> DUC -> TxRadio) but I am measuring turn-around times of
> roughly 150us, far higher than expected. My custom block does not buffer
> anything besides some flops.
>
> Has anyone an idea what might be the cause of this? I already tried
> reducing the spp of the radio with very limited success.
>
> [1] https://pubs.gnuradio.org/index.php/grcon/article/view/37
>
>
> ___
> 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

Re: [USRP-users] RFNoC loopback

[Nick Foster via USRP-users]

Haven't had time to look at it, but certainly you should be able to connect
blocks directly in UHD; this should be independent of loopback operation.
I'll give it a shot in the next few days.

Nick

On Fri, Sep 28, 2018 at 2:39 AM Daniel Rauschen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Has nobody figured out how to do a RFNoC loopback in UHD/C++ ?
>
>
> On 26.09.2018 17:12, Daniel Rauschen via USRP-users wrote:
>
> Hi,
>
> sure, find the cpp attached.
>
> Thanks and best regards,
> Daniel
>
> On 26.09.2018 16:56, Brian Padalino wrote:
>
> On Wed, Sep 26, 2018 at 10:36 AM Daniel Rauschen via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all,
>>
>> I have a question regarding a RFNoC loopback in plain UHD.
>>
>> I am familiar with [1] and I have a working solution with gr-ettus and
>> python. The problem is, I can not figure out how to connect the blocks
>> in plain UHD. Does anyone have a working example in UHD for a RFNoC
>> loopback?
>>
>> Connecting in UHD/c++ fails with following error: "Error: RuntimeError:
>> On node 0/Radio_0, output port 0 is already connected."...
>>
>> Any help is highly appreciated :)
>>
>
> You didn't show us how you tried to connect them?  Can you attach your
> source file?
>
> Brian
>
>
>
>
> ___
> 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
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] axi_round_and_clip busted?

[Nick Foster via USRP-users]

I've successfully used axi_round_and_clip in a number of designs and it
seems to simulate fine for me. Xsim or vsim? How is it being instantiated?
What weird internal simulation issues are you seeing?

Nick

On Fri, Aug 31, 2018 at 2:58 PM Andrew Danowitz via USRP-users <
usrp-users@lists.ettus.com> wrote:

> When I try to use axi_round_and_clip in my design, simulation won't run
> and has weird internal simulation issues. If I build it into an rfnoc
> image, the flow graph doesn't return any data. Has anyone else run into
> this?
>
> --
> Information contained, linked, or attached to this email and all verbal
> communications from WhiteFox Defense to your entity in the prior 30 days
> constitute proprietary and confidential information unless otherwise
> indicated and is therefore subject to obligations in any executed
> confidentiality agreements. Further, this email is intended solely for the
> use of the individual or entity to whom they are addressed. If you are not
> the intended recipient and this message has been addressed to you in error,
> please promptly notify i...@whitefoxdefense.com and destroy all copies of
> the message and any attachments. This email and attachments may contain
> technical data as defined in the International Traffic In Arms Regulations
> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
> Parts 730 – 780.  Export of this material may be controlled by these
> regulations and may not be exported or transferred to non-U.S. persons
> without prior written approval from the U.S. government.
> ___
> 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

Re: [USRP-users] About CHDR packet size

[Nick Foster via USRP-users]

That's the MTU of your network interface limiting the CHDR packet size.
Can't break up CHDR packets over multiple network packets.

Nick

On Wed, Aug 1, 2018 at 11:25 AM Leandro Echevarría via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey everybody,
>
> I'll somehow repeat a question I asked here a couple of months ago, to see
> again if I can get some guiding. Hope you understand:
>
> The CHDR packet length field in the CHDR header is 16 bits (i.e. 65536
> bytes theoretical max length), but by doing Wireshark captures and playing
> with the samples per paket in benchmark_rate.cpp I've seen it's never set
> to be more than 7984 bytes without producing timeouts (and 7992 if no
> timestamp is used I suppose). This is, I could not stream successfully with
> an spp bigger than 1996.
> I'm designing my own NoC block, and I'd need to know if I can form CHDR
> packets of a size bigger than 7984 bytes (be it using tlast signalling,
> or .SIMPLE_MODE(0) and providing a tuser header) and still not have dropped
> frames. Is this possible? Or should I just default to this size to avoid
> further issues?
>
> Thanks again,
>
> Leo
> ___
> 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

Re: [USRP-users] X310 software reset revisted

[Nick Foster via USRP-users]

What is this witchery?? Is this a reset to the  PCIe controller?

Nick

On Mon, Jul 23, 2018 at 10:44 AM Nate Temple  wrote:

> Hi Jason,
>
> This magic poke should do the trick:
>
> python $UHD_INSTALL_DIR/firmware/usrp3/x300/x300_debug.py --addr=
> --poke=0x100058 --data=1
>
>
> Regards,
> Nate Temple
>
> On Mon, Jul 23, 2018 at 9:45 AM, Nick Foster via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I've solved this with the USB JTAG interface and an external machine. An
>> RPi will happily run Vivado Lab.
>>
>> AFAIK there are no plans to integrate a software reset into the X310.
>>
>> Nick
>>
>> On Mon, Jul 23, 2018 at 6:11 AM Jason Matusiak via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> I know it has been questioned many times on here, but I wanted to verify
>>> something.  It has always been said that there is no way to do a software
>>> reset on the X310; I am curious if that is "currently" or "ever?"
>>>
>>> I wasn't sure if there was a way to send a packet either via UHD or
>>> RFNoC that could trigger a reset of some kind (this assumes that you have a
>>> functioning X310 on the other end), and no one has had time to look into
>>> it?  Or if it has been looked into and there truly is no way to do it.
>>>
>>> I have some situations where I cannot get to my X310s easily, so if I
>>> need to reflash the bitfile (which is going to be necessary for RFNoC
>>> flowgraphs, I will have to add an external appliance to get the job
>>> done.  I was thinking about looking into it, but if it already has and was
>>> deemed a non-starter, I don't want to waste the cycles.
>>> ___
>>> 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

Re: [USRP-users] X310 software reset revisted

[Nick Foster via USRP-users]

I've solved this with the USB JTAG interface and an external machine. An
RPi will happily run Vivado Lab.

AFAIK there are no plans to integrate a software reset into the X310.

Nick

On Mon, Jul 23, 2018 at 6:11 AM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I know it has been questioned many times on here, but I wanted to verify
> something.  It has always been said that there is no way to do a software
> reset on the X310; I am curious if that is "currently" or "ever?"
>
> I wasn't sure if there was a way to send a packet either via UHD or RFNoC
> that could trigger a reset of some kind (this assumes that you have a
> functioning X310 on the other end), and no one has had time to look into
> it?  Or if it has been looked into and there truly is no way to do it.
>
> I have some situations where I cannot get to my X310s easily, so if I need
> to reflash the bitfile (which is going to be necessary for RFNoC
> flowgraphs, I will have to add an external appliance to get the job
> done.  I was thinking about looking into it, but if it already has and was
> deemed a non-starter, I don't want to waste the cycles.
> ___
> 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

Re: [USRP-users] X310 calibration with WBX

[Nick Foster via USRP-users]

OK, just one more bump -- can anyone from Ettus confirm that they're able
to get calibration working on X310, and that it actually reduces DC offset
and IQ imbalance images? I think it's broken in master as well.

Nick

On Fri, Jun 29, 2018 at 1:34 PM Nick Foster  wrote:

> Following up on this, I have an additional question: is there any plan to
> expose the DC offset and IQ balance API through device3? Currently it
> appears as though the legacy interface can make use of these functions to
> manually set IQ balance and DC offset, while device3-based programs (i.e.,
> anything using RFNoC) cannot. Am I correct in this?
>
> Nick
>
> On Thu, Jun 28, 2018 at 6:22 PM Nick Foster  wrote:
>
>> Hi all,
>>
>> I haven't looked at daughterboard calibration in a long time, and picking
>> it up, it sure looks broken to me. I'm using X310 + WBX on rfnoc-devel as
>> of March. Let's assume for the moment I'm running a stock FPGA image -- I'm
>> not, but for testing I replicated the same results on the stock image.
>>
>> I ran TX DC offset cal as follows:
>> uhd_cal_tx_dc_offset --args=addr=192.168.10.2 --freq_start=70e6
>> --freq_stop=150e6 --freq_step=1e6
>>
>> And I ran TX IQ imbalance cal as follows:
>> uhd_cal_tx_iq_balance --args=addr=192.168.10.2 --freq_start=70e6
>> --freq_stop=150e6 --freq_step=1e6
>>
>> Both DC offset and IQ imbalance are significantly worse after running
>> calibration. DC offset is 30dB higher and IQ imbalance is 27dB worse.
>>
>> I also tried default parameters in case the frequency step is sensitive
>> to the TX offset setting, with no change (it actually got somewhat
>> worse...).
>>
>> Is there anything I should know about the calibration utilities which
>> prevents them from being used on relatively recent UHD releases? Did
>> someone cross up the I and Q channels in the correction registers?
>>
>> Nick
>>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoc Relay

[Nick Foster via USRP-users]

Pol,

Glad to hear it! I can answer at least a few of your questions.

On Mon, Jul 2, 2018 at 3:32 AM Pol Henarejos  wrote:

> Dear all,
>
> I have more news on that. After following the steps provided by Nick, I
> finally succeed with the loopback. However, I have some observations:
> 1- At the Addendum, it is described that set_tx_streamer shall be used
> with E310. After many hours spent, I tried to set it also with X300 and
> it worked with a simple flowgraph. So, my impression is that the
> set_tx_streamer has to be also used in the case of X300, at least in my
> case.
>

That's very strange to me, although I know they've updated the streamer
logic since I've last merged from rfnoc-devel.


> 2- I use the rfnoc-devel commit f3118cb6.
> 3- I had to employ the 120 Msps master_clock_rate. For higher master
> rates, the system does not work. No errors nor complains are displayed.
> The leds just do not blink.
>

Can you be very specific about what the flowgraph looked like which would
not work at 200Msps?


> 4- In very very simple flowgraphs (radio RX -> radio TX without
> queues/FIFOs) the loopback works at 200 Msps, but if some additional
> blocks (splitters, adders, duc/ddc) are added, the system does not work
> (no errors again, just leds off).
>

This is because RFNoC blocks have a total input/output bandwidth which is
independent of the number of inputs/outputs. You get enough bandwidth to
stream 1 input/1 output at 200Msps, but if you use a splitter (1 input, 2
outputs) or an addsub (2 inputs, 2 outputs) you can no longer stream at
full rate.


> 5- The presence of ddc/duc to reduce the clock_rate of intermediate
> blocks seems that does not affect to the performance. All intermediate
> blocks can work at 120 Msps but not at 200.
>

I'm assuming this is related to the 1in/1out thing.


> 6- I cannot stop the workflow. This is very annoying because I have to
> power off the USRP *every time* that I run the flowgraph. Even though I
> send STREAM_MODE_STOP_CONTINUOUS to both rx radio and I set
> set_tx/rx_streamer to false, the loopback still runs. I use GRC and I am
> not sure wether is caused by gnuradio or RFNoC. I am going to work with
> this.
>

Simplest thing to do is just run uhd_usrp_probe. I would have guessed
sending a stream command which stops things would work as well but to be
honest I haven't tried it because my use case doesn't demand it.

Nick


>
> IMHO a warn/error/complain should be displayed if the RFNoC system
> cannot work due to the master clock rate because there is no additional
> information a priori to know what's wrong. My USRPs are placed in a
> remote lab and I am not able to see wether tx/rx leds are blinking or
> are off. My impression is that the blocks cannot meet the master clock
> rate but I am pretty sure that you can provide more information on that.
>
> I will update this thread if more progresses are achieved.
>
> Thank you all.
>
>
> Dr. Pol Henarejos
> Researcher
> Array and Multi-Sensor Processing Department, Communication Systems
> Division
> pol.henare...@cttc.cat
>
> Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
> Av. Carl Friedrich Gauss, 7
> 08860 Castelldefels, Barcelona (Spain)
> Tel: +34 93 645 29 00  Ext: 2177 <+34%20936%2045%2029%2000>
> www.cttc.cat
>
> El 25/6/2018 a les 17:28, Nick Foster via USRP-users ha escrit:
> > What is the behavior of the lights on the front panel?
> >
> > On Mon, Jun 25, 2018, 12:31 AM Pol Henarejos via USRP-users
> > mailto:usrp-users@lists.ettus.com>> wrote:
> >
> > Dear Derek,
> >
> > I tried the link that you gave but no luck.
> > 1) I disabled the use of timestamp and, dissecting the packets with
> > wireshark, I cross-checked that the use_timestamp bit is 0.
> > 2) I added the set_rx_streamer and issue_cmd to my flograph but
> nothing
> > happens. I am not sure if both commands work properly, but I guess
> > they do.
> >
> > Do you have additional hints on that?
> >
> > Thank you.
> >
> >
> > Dr. Pol Henarejos
> > Researcher
> > Array and Multi-Sensor Processing Department, Communication Systems
> > Division
> > pol.henare...@cttc.cat <mailto:pol.henare...@cttc.cat>
> >
> > Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
> > Av. Carl Friedrich Gauss, 7
> > 08860 Castelldefels, Barcelona (Spain)
> > Tel: +34 93 645 29 00  Ext: 2177 <+34%20936%2045%2029%2000>
> > www.cttc.cat <http://www.cttc.cat>
> >
> > El 22/6/2018 a les 14:21, Pol Henarejos via USRP-users ha escrit:
> >  > Thank you, Derek. I 

Re: [USRP-users] X310 calibration with WBX

[Nick Foster via USRP-users]

Following up on this, I have an additional question: is there any plan to
expose the DC offset and IQ balance API through device3? Currently it
appears as though the legacy interface can make use of these functions to
manually set IQ balance and DC offset, while device3-based programs (i.e.,
anything using RFNoC) cannot. Am I correct in this?

Nick

On Thu, Jun 28, 2018 at 6:22 PM Nick Foster  wrote:

> Hi all,
>
> I haven't looked at daughterboard calibration in a long time, and picking
> it up, it sure looks broken to me. I'm using X310 + WBX on rfnoc-devel as
> of March. Let's assume for the moment I'm running a stock FPGA image -- I'm
> not, but for testing I replicated the same results on the stock image.
>
> I ran TX DC offset cal as follows:
> uhd_cal_tx_dc_offset --args=addr=192.168.10.2 --freq_start=70e6
> --freq_stop=150e6 --freq_step=1e6
>
> And I ran TX IQ imbalance cal as follows:
> uhd_cal_tx_iq_balance --args=addr=192.168.10.2 --freq_start=70e6
> --freq_stop=150e6 --freq_step=1e6
>
> Both DC offset and IQ imbalance are significantly worse after running
> calibration. DC offset is 30dB higher and IQ imbalance is 27dB worse.
>
> I also tried default parameters in case the frequency step is sensitive to
> the TX offset setting, with no change (it actually got somewhat worse...).
>
> Is there anything I should know about the calibration utilities which
> prevents them from being used on relatively recent UHD releases? Did
> someone cross up the I and Q channels in the correction registers?
>
> Nick
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] X310 calibration with WBX

[Nick Foster via USRP-users]

Hi all,

I haven't looked at daughterboard calibration in a long time, and picking
it up, it sure looks broken to me. I'm using X310 + WBX on rfnoc-devel as
of March. Let's assume for the moment I'm running a stock FPGA image -- I'm
not, but for testing I replicated the same results on the stock image.

I ran TX DC offset cal as follows:
uhd_cal_tx_dc_offset --args=addr=192.168.10.2 --freq_start=70e6
--freq_stop=150e6 --freq_step=1e6

And I ran TX IQ imbalance cal as follows:
uhd_cal_tx_iq_balance --args=addr=192.168.10.2 --freq_start=70e6
--freq_stop=150e6 --freq_step=1e6

Both DC offset and IQ imbalance are significantly worse after running
calibration. DC offset is 30dB higher and IQ imbalance is 27dB worse.

I also tried default parameters in case the frequency step is sensitive to
the TX offset setting, with no change (it actually got somewhat worse...).

Is there anything I should know about the calibration utilities which
prevents them from being used on relatively recent UHD releases? Did
someone cross up the I and Q channels in the correction registers?

Nick
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoc Relay

[Nick Foster via USRP-users]

What is the behavior of the lights on the front panel?

On Mon, Jun 25, 2018, 12:31 AM Pol Henarejos via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear Derek,
>
> I tried the link that you gave but no luck.
> 1) I disabled the use of timestamp and, dissecting the packets with
> wireshark, I cross-checked that the use_timestamp bit is 0.
> 2) I added the set_rx_streamer and issue_cmd to my flograph but nothing
> happens. I am not sure if both commands work properly, but I guess they do.
>
> Do you have additional hints on that?
>
> Thank you.
>
>
> Dr. Pol Henarejos
> Researcher
> Array and Multi-Sensor Processing Department, Communication Systems
> Division
> pol.henare...@cttc.cat
>
> Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
> Av. Carl Friedrich Gauss, 7
> 08860 Castelldefels, Barcelona (Spain)
> Tel: +34 93 645 29 00  Ext: 2177
> www.cttc.cat
>
> El 22/6/2018 a les 14:21, Pol Henarejos via USRP-users ha escrit:
> > Thank you, Derek. I will take a look.
> > I hope that some progress will be achieved in a near future.
> >
> > Best regards.
> >
> >
> > Dr. Pol Henarejos
> > Researcher
> > Array and Multi-Sensor Processing Department, Communication Systems
> > Division
> > pol.henare...@cttc.cat
> >
> > Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
> > Av. Carl Friedrich Gauss, 7
> > 08860 Castelldefels, Barcelona (Spain)
> > Tel: +34 93 645 29 00  Ext: 2177
> > www.cttc.cat
> >
> > El 22/6/2018 a les 13:13, Derek Kozel ha escrit:
> >> Hello Dr Henarejos,
> >>
> >> Currently an RFNoC only flowgraph is not fully supported. What is
> >> missing is the issuing of the commands to start streaming and a
> >> mechanism to handle timestamps. Some modifications are needed to make
> >> these work.
> >> Nick Foster has done a write up on a few different ways of handling
> >> the necessary modifications.
> >>
> >> https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
> >>
> >> Regards,
> >> Derek
> >>
> >> On Fri, Jun 22, 2018 at 10:10 AM, Pol Henarejos via USRP-users
> >> mailto:usrp-users@lists.ettus.com>> wrote:
> >>
> >> Dear all,
> >>
> >> I am playing with RFNoC on a USRP X300. I built a custom RFNoC FPGA
> >> image with the blocks that I need successfully and everything goes
> >> smooth. However, if I want to use a flowgraph with only RFNoC blocks
> >> (RFNoC Radio RX --> DmaFIFO --> RFNoC Radio TX), it does not work.
> >> The USRP does nothing (no blinking leds, no error messages,
> >> nothing). If I replace the DmaFIFO block with a Copy block, then it
> >> works but, as expected, this is not efficient since all the samples
> >> go to the host and go back to the USRP. I would want to perform a
> >> relay by using only RFNoC blocks. My impression is that a command to
> >> the USRP might be needed (a streaming command or so), but I have no
> >> idea what is wrong.
> >>
> >> I attach the flowgraph.
> >>
> >> (only RFNoC blocks does not work)
> >>
> >> (flowing samples to host and going back to USRP does work but it is
> >> extremely inefficient)
> >>
> >> Thank you.
> >>
> >>
> >> --
> >> Dr. Pol Henarejos
> >> Researcher
> >> Array and Multi-Sensor Processing Department, Communication
> >> Systems Division
> >> pol.henare...@cttc.cat 
> >>
> >> Centre Tecnològic de Telecomunicacions de Catalunya (CTTC)
> >> Av. Carl Friedrich Gauss, 7
> >> 08860 Castelldefels, Barcelona (Spain)
> >> Tel: +34 93 645 29 00  Ext: 2177
> >> www.cttc.cat 
> >>
> >>
> >> ___
> >> 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
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] RFNoC Overrun Using Split Stream

[Nick Foster via USRP-users]

It's not necessarily a limitation in RFNoC, or at least it seems to be a
reasonable one; if the bus is to support 2 full-rate streams on a single
block, why not 3, or even 4? To allow multiple streams at full rate you'd
have to either increase the speed of bus_clk relative to ce_clk, or you'd
have to increase the width of the RFNoC bus itself. Both solutions have
pretty severe consequences in terms of resource usage, and both would
increase resource use for every RFNoC application, even those that don't
require full-rate streaming from two ports.

The limitation comes from the fact that all ports in a RFNoC block are
muxed onto the same 64-bit-wide RFNoC bus, and so the bandwidth of that
connection to the main NoC router is shared by all the ports in a
block. If bus_clk
== ce_clk, then you could theoretically get two ports on a single block
streaming at full rate (since each port is 32 bits wide), but overhead will
prevent that from succeeding in the real world. Maybe there's some
reasonable increase to bus_clk that would allow this and still meet timing,
but I haven't played with that and bus_clk already seems to be near the
hairy edge of meeting timing in my builds.

I've worked around this in the past by instantiating multiple RFNoC blocks
(not ports!) in my block and bringing them out to the top level. You'll
then have to connect both blocks to the NoC bus in
rfnoc_ce_auto_inst_x310.v. It's a bit messy especially if you want to use
gr-uhd, because you have to write a separate host descriptor and GRC block
for each additional input/output, but it does work. I can stream four
full-rate streams from a single processing block this way. I suppose I
should update my "Stupid NoC Tricks" guide to include this one, but it
probably won't happen soon.

The error you're currently seeing looks like another issue. What happens if
you stream to a single FFT sink with two inputs?

Nick

On Thu, Jun 7, 2018 at 8:39 PM Peter Sanchez  wrote:

> Thanks Juan and Nick. Do you know if this is something RFNoC plans to
> address in the future?
>
> I put a DDC in front of the Split Stream block and now I don't see anymore
> overrun errors, but I have 2 new problems. First, I can only run the flow
> graph one time like Juan described. If I stop it and try to run it again I
> don't get anything in my GUI FFT Sink windows, and the terminal prints
> timeout on chan 0 errors.
> Second, I have 2 FFT Sink windows (one for each steam) and they seem to
> update slowly and one at a time. The top one will show live data for 1
> second while the bottom looks like it has paused, then the bottom will show
> live data for 1 second and the top looks paused and so on. CPU usage is low
> and data from the X310 is only at 40MB/s.
>
> On Thu, Jun 7, 2018 at 12:12 AM, Nick Foster  wrote:
>
>> The same solution that works for E310 won't work for X310. The easiest
>> fix will be to use a DDC block to reduce the sample rate ahead of the Split
>> Stream block. The RFNoC bus cannot handle two full-rate streams on a single
>> NoC port.
>>
>> Nick
>>
>>
>> On Thu, Jun 7, 2018, 2:44 AM Juan Francisco via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Unfortunately I don't have a fix for this, but I have seen similar
>>> behavior.  I have only been able to get the SplitStream block on the first
>>> run after an FPGA reconfiguration (or X310 power cycle).  If you try
>>> running the flowgraph a second time, it hangs and nothing gets through the
>>> SplitStream.
>>>
>>> On Wed, Jun 6, 2018 at 7:05 PM, Peter Sanchez via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hi All,

 I have a RFNoC Receiver --> Split stream --> x2 DDC blocks on the X310.
 I see a ton of overrun on chan 0 errors after adding the Split Stream
 block and GNU Radio Companion eventually crashes all together.


 I read about a similar problem on the E310 and the fix was to change
 the ce_clk to bus_clk in the rfnoc_ce_auto_inst (
 http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-February/023539.html
 ).
 I tried changing that in the rfnoc_ce_auto_inst_x310.v code and
 reflashed the FPGA but this didn't change the overrun errors.

 Any thoughts?
 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

Re: [USRP-users] X310 Register's Memory Capability

[Nick Foster via USRP-users]

It's going to depend on how much block RAM the image is already using, and
how much more you can use while still getting the image to route. The
easiest way to find out will be to try it.

On Thu, Jun 7, 2018, 9:14 AM shachar J. brown 
wrote:

> Thanks Nick, that's an excellent example.
> Do you know what are the memory size restrictions of the configuration
> data?
>
> On Thu, Jun 7, 2018 at 10:50 AM, Nick Foster  wrote:
>
>> Look at the RFNoC FIR filter block for a good example of pushing
>> configuration data into a block via the settings bus.
>>
>> On Thu, Jun 7, 2018, 8:25 AM shachar J. brown via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi all,
>>>
>>> I'm working on an X310.
>>>
>>> I have large data (tables of 1-3 K of variables) I would like to insert
>>> into the FPGA's memory registers while running.
>>>
>>> How much space is available in the FPGA? Seemingly, the Address for the
>>> "set_register" is only 8 bits long, and the first 128 addresses are
>>> reserved for the Noc_Shell. So... Does that mean I can store only 128
>>> variables at a time?
>>>
>>> (Just to clarify: I want to change the data while running, and I'd like
>>> it to be inside the FPGA for performance issues).
>>>
>>> Thank a ton!
>>> Steve
>>> ___
>>> 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

Re: [USRP-users] X310 Register's Memory Capability

[Nick Foster via USRP-users]

Look at the RFNoC FIR filter block for a good example of pushing
configuration data into a block via the settings bus.

On Thu, Jun 7, 2018, 8:25 AM shachar J. brown via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I'm working on an X310.
>
> I have large data (tables of 1-3 K of variables) I would like to insert
> into the FPGA's memory registers while running.
>
> How much space is available in the FPGA? Seemingly, the Address for the
> "set_register" is only 8 bits long, and the first 128 addresses are
> reserved for the Noc_Shell. So... Does that mean I can store only 128
> variables at a time?
>
> (Just to clarify: I want to change the data while running, and I'd like it
> to be inside the FPGA for performance issues).
>
> Thank a ton!
> Steve
> ___
> 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

Re: [USRP-users] RFNoC Overrun Using Split Stream

[Nick Foster via USRP-users]

The same solution that works for E310 won't work for X310. The easiest fix
will be to use a DDC block to reduce the sample rate ahead of the Split
Stream block. The RFNoC bus cannot handle two full-rate streams on a single
NoC port.

Nick

On Thu, Jun 7, 2018, 2:44 AM Juan Francisco via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Unfortunately I don't have a fix for this, but I have seen similar
> behavior.  I have only been able to get the SplitStream block on the first
> run after an FPGA reconfiguration (or X310 power cycle).  If you try
> running the flowgraph a second time, it hangs and nothing gets through the
> SplitStream.
>
> On Wed, Jun 6, 2018 at 7:05 PM, Peter Sanchez via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi All,
>>
>> I have a RFNoC Receiver --> Split stream --> x2 DDC blocks on the X310.
>> I see a ton of overrun on chan 0 errors after adding the Split Stream
>> block and GNU Radio Companion eventually crashes all together.
>>
>>
>> I read about a similar problem on the E310 and the fix was to change the
>> ce_clk to bus_clk in the rfnoc_ce_auto_inst (
>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-February/023539.html
>> ).
>> I tried changing that in the rfnoc_ce_auto_inst_x310.v code and reflashed
>> the FPGA but this didn't change the overrun errors.
>>
>> Any thoughts?
>> 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

Re: [USRP-users] Question regarding the term "wrt A/D full scale" on OpenBTS

[Nick Foster via USRP-users]

Oscar, that document covers a *lot* of testing using quite a lot of
expensive calibrated instrumentation. Maybe you could elaborate a bit on
what exactly you want to test, and why?

On Sun, Jun 3, 2018 at 9:49 AM oscar llerena via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Thanks Nick and Neel for the help.
>
> So, do you have any suggestion how I can obtain the following curves:
> https://kb.ettus.com/images/c/cb/B200_RF_Performance.pdf
> with for example GNURadio flowgraph?
>
> Thanks
>
> On Tue, May 22, 2018 at 3:33 PM, Nick Foster  wrote:
>
>> Neither. It will depend on the gain setting and individual variation in
>> the device. It is not calibrated to any specific dBm value and if you
>> require dBm you must calibrate your readings against a known source. The
>> listed maximum power figure is a maximum to avoid damage to the device.
>>
>> Nick
>>
>> On Mon, May 21, 2018 at 10:35 AM oscar llerena via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi everyone
>>>
>>> On the following OpenBTS parameter:
>>>
>>> OpenBTS> devconfig GSM.Radio.RSSITarget
>>> GSM.Radio.RSSITarget -50 [default]
>>> - description:  Target uplink RSSI (Received Signal Strength
>>> Indication) for MS power control loop, in dB wrt to A/D full scale.
>>>
>>> The description indicates that the RSSI value is minus 50 dB with
>>> respect to the A/D full scale. Now, according to Ettus on link [1] the
>>> USRP B210 has a maximum input power of 0 dBm, although other sources [2]
>>> state that maximum input power is -15dBm. In this case, which dBm power
>>> level will mean the term "with respect to A/D full scale".
>>>
>>> Thanks
>>>
>>> [1] https://kb.ettus.com/B200/B210/B200mini/B205mini
>>> [2] https://files.ettus.com/manual/page_usrp_b200.html
>>>
>>>
>>> --
>>> Oscar Llerena
>>> Tlf: 997575596
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>
>
> --
> Oscar Llerena
> Tlf: 997575596
> ___
> 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

Re: [USRP-users] Multiple Output RFNoC Block

[Nick Foster via USRP-users]

I'm positive I've done exactly this, but it was 18 months ago -- and that
design has since moved to using 1 input and 2 outputs instead. I don't
recall having any trouble getting that part to work, but there's been a lot
of changes to RFNoC since then.

On Tue, May 29, 2018, 5:12 PM EJ Kreinar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Brian,
>
> Fascinating question! I'm not sure many have considered this possibility
> (1-input, 4-output RFNoC block), though I agree I'd like to see RFNoC
> support this use-case...
>
> Looks to me like this for loop in device3_io_impl could be getting in the
> way:
> https://github.com/EttusResearch/uhd/blob/rfnoc-devel/host/lib/usrp/device3/device3_io_impl.cpp#L569
>
> Correct me if I'm wrong here, but it appears to be looping through all
> upstream nodes and writing the response destination using the block port of
> the *terminator* node, rather than the block port that's connected in the
> RFNoC graph. This suggests to me there's an assumption that each block port
> is always connected to the corresponding block port number of all upstream
> nodes-- which is probably how the blocks are used in the majority of
> configurations (2-channel radio -> 2-channel DDC -> 2-channel DMA FIFO),
> but may not be sufficient for the arbitrary case...
>
> Is my interpretation correct??
> EJ
>
>
>
> On Mon, May 28, 2018 at 5:35 PM, Brian Padalino via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I've got a single input, 4-output RFNoC block that I am trying to hook up
>> to a C++ testbench, but I'm having some trouble.
>>
>> Referencing the unaligned output version from gr-ettus:
>>
>>
>> https://github.com/EttusResearch/gr-ettus/blob/master/lib/rfnoc_block_impl.cc
>>
>> My graph is Radio -> DDC -> Custom Block -> Host.
>>
>> I am setting up my device_addr_t with 3 attributes: block_id, block_port,
>> and block_portX where X is from 0 to 3.
>>
>> When I print my args I am sending into get_rx_stream(), they look
>> appropriate:
>>
>>   block_id=0/MYBLOCK_0,block_port=0,block_port0=0
>>
>> The issue is when I get to block port 2, I get a LookupError about
>> 0/Radio_0:
>>
>>   Error: LookupError: KeyError: [0/Radio_0] sr_write(): No such port: 2
>>
>> I'm sure I'm just doing something incorrectly, but I can't find much
>> documentation on getting the streams working with multiple unaligned output
>> ports from the same block coming back to the host.  I'm very confused why
>> port 2 of the Radio is being addressed?
>>
>> I've used the noc_block_invert_tb as my guide to produce the streams in
>> the FPGA:
>>
>>
>> https://github.com/EttusResearch/fpga/tree/rfnoc-devel/usrp3/lib/rfnoc/noc_block_invert_tb
>>
>> And an HDL testbench appears to work correctly.  Host UHD guidance is
>> appreciated.  It would be nice to see real example C++ code interacting
>> with UHD directly with the stock FPGA image.  I believe fosphor has 2
>> output ports and 1 input port?
>>
>> Thanks,
>> Brian
>>
>> ___
>> 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

Re: [USRP-users] Question regarding the term "wrt A/D full scale" on OpenBTS

[Nick Foster via USRP-users]

Neither. It will depend on the gain setting and individual variation in the
device. It is not calibrated to any specific dBm value and if you require
dBm you must calibrate your readings against a known source. The listed
maximum power figure is a maximum to avoid damage to the device.

Nick

On Mon, May 21, 2018 at 10:35 AM oscar llerena via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone
>
> On the following OpenBTS parameter:
>
> OpenBTS> devconfig GSM.Radio.RSSITarget
> GSM.Radio.RSSITarget -50 [default]
> - description:  Target uplink RSSI (Received Signal Strength
> Indication) for MS power control loop, in dB wrt to A/D full scale.
>
> The description indicates that the RSSI value is minus 50 dB with respect
> to the A/D full scale. Now, according to Ettus on link [1] the USRP B210
> has a maximum input power of 0 dBm, although other sources [2] state that
> maximum input power is -15dBm. In this case, which dBm power level will
> mean the term "with respect to A/D full scale".
>
> Thanks
>
> [1] https://kb.ettus.com/B200/B210/B200mini/B205mini
> [2] https://files.ettus.com/manual/page_usrp_b200.html
>
>
> --
> Oscar Llerena
> Tlf: 997575596
> ___
> 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

Re: [USRP-users] Getting started with FPGA and RFNoC developement

[Nick Foster via USRP-users]

On Thu, Apr 19, 2018 at 2:48 AM TIMMEN Koen <
koen.tim...@thalesaleniaspace.com> wrote:

> Nick,
>
>
>
> Since you replied to my previous questions regarding working with RFNoC, I
> would like to address some follow up questions to you if you don’t mind. I
> am still working on the same subject and was working on wrapping the custom
> IP into AXI4, but while doing that only encountered more questions I was
> not able to find answers to.
>
>
>
> First of all, I think I understand the work of my predecessor a bit better
> now. What he did, is to create a custom version of the N210 Tx DUC chain in
> order to add samples to the stream. These samples are generated on the FPGA
> itself using a whole array of user registers. These user registers are
> controlled by a custom build C++ module, running on a host computer at the
> same time.
>
>
>
> When I would port this signal generation module to the X310, I will have
> to deal with a completely different USRP architecture. So my thinking was
> that I could isolate the signal generation module and implement it in
> RFNoC. In RFNoC I could then add its output to the output of a radio source
> block, after which the combined samples can be fed to a radio sink block.
> Do you think this is a legit way to do this? Hopefully my explanation makes
> sense.
>

This is perfectly fine assuming that you really want to add (as in
mathematically sum) your generated samples to the existing received
samples. Your block will need to produce samples continuously at least as
fast as the radio block. The system handles backpressure for you, so you
won't need to do any throttling inside your block -- just follow the AXI
stream spec and don't generate samples when the downstream isn't ready.


>
>
> If it does, I encounter a new problem. The registers on the FPGA that the
> signal generation module uses, need to be continuously updated. To expand
> upon this: the simulation it should be running encompasses a dynamic
> receiver, so it needs to be able to implement changing Doppler, antenna
> position etc. This scenario is handled by the C++ module, that sets
> register values controlling the carrier frequency and arrival time to exert
> these effects on the generated signals. Now, how can I control these
> registers when implementing the module in RFNoC. I’ve read about controller
> blocks, which should be able to deal with more complex computing to set
> register values. But I’m not sure if this is what I’m searching for. Could
> you shine some light on this for me?
>

There are user registers in RFNoC via the settings bus, and the UHD API
brings that out to userspace. There are plenty of examples included in UHD.
You can just instantiate your flowgraph and then set the registers from the
same instantiation. You might not even need a custom controller --  if you
just need to push a value into a register, the "NoCScript" system lets you
access your custom registers by name without making a custom block
controller. You would need a custom block controller if you're doing things
like streaming FIR coefficients into a block, or if you have to do some
intricate computation on the incoming value before it gets pushed into the
register.

Nick


>
>
> Hopefully I have been clear in my explanation, if not please let me know.
> I hope you will be able to help me along again.
>
>
>
> Kind regards,
>
>
>
> Koen Timmen
>
>
>
> *De :* Nick Foster [mailto:bistrom...@gmail.com]
> *Envoyé :* jeudi 22 mars 2018 18:16
> *À :* TIMMEN Koen
> *Cc :* usrp-users@lists.ettus.com
> *Objet :* Re: [USRP-users] Getting started with FPGA and RFNoC
> developement
>
>
>
> Replies inline.
>
>
> On Thu, Mar 22, 2018 at 9:48 AM TIMMEN Koen via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hello,
>
>
>
> First of all I would like to mention that I am not sure if this is the
> right location to ask these type of questions. However, I tried to find
> answers to my questions elsewhere but couldn’t find a better suited
> location, so I hope I’m not at the wrong address and causing too much
> clutter in the e-mail list.
>
>
>
> My experience with USRPs is almost nonexistent. Over the last few weeks I
> have looked around on the internet, learning about the concepts of FPGAs
> and HDL coding and I followed the Getting Started Guide for RFNoC. I am
> familiar with signal processing and the required mathematics and I would
> like to apply this knowledge in the domain of FPGAs, possibly while using
> RFNoC. This, I will be doing within the scope of an assignment that was
> given to me: what needs to be done is to set-up a USRP X310 with a real
> time signal generation module. Currently, this module is already up and
> running on a USRP N210 and all HDL code and host code is available to me.
> So all that needs to be done, is to use the existing HDL code and port it
> to another device. At least.. that’s how I interpret the task. Like I said,
> I am new to the USRP field and I have difficulties approaching it. Where do
> 

Re: [USRP-users] AD9361 in USRP B210

[Nick Foster via USRP-users]

They are both necessary and serve completely separate and complementary
functions. At this point you are best served by reading the documentation.

Nick

On Wed, Apr 11, 2018, 10:33 PM Yeo Jin Kuang Alvin (IA) 
wrote:

> Hi,
>
>
>
> Thank you! Btw will the FPGA image be ‘overlap’ after running the UHD
> software or they can both run concurrently?
>
>
>
> Thank you in advance!
>
>
>
> *From:* Nick Foster [mailto:bistrom...@gmail.com]
> *Sent:* Thursday, 12 April 2018 1:28 PM
>
>
> *To:* Yeo Jin Kuang Alvin (IA)
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] AD9361 in USRP B210
>
>
>
> On Wed, Apr 11, 2018 at 10:15 PM Yeo Jin Kuang Alvin (IA) <
> yjink...@dso.org.sg> wrote:
>
> Hi,
>
>
>
> Sorry I am very new to all these, do you mean that I have to download
> visual studio to compile all the UHD .cpp and run them for the UHD
> commands?
>
>
>
> No, I mean that you can probably just get away with using UHD as-is with a
> program you write (either in Python or C++) invoking a UHD device and
> configuring it. There are many examples included in uhd/host/examples. If
> you are lucky you might even get away with using one of the example
> programs without modification, but I doubt it.
>
>
>
> And for the FPGA image you talking about, is it the .bit file that is
> generated in the IMPACT?
>
>
>
> Yes.
>
> You have a long learning curve ahead of you. It's a good idea at this
> point to simply install UHD and get started using the B210 with some of the
> UHD examples to see how it works in practice.
>
> Nick
>
>
>
>
>
> Thank you in advance!
>
>
>
> *From:* Nick Foster [mailto:bistrom...@gmail.com]
> *Sent:* Thursday, 12 April 2018 12:04 PM
>
>
> *To:* Yeo Jin Kuang Alvin (IA)
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] AD9361 in USRP B210
>
>
>
> The best option is probably to use existing UHD commands to set the gain,
> frequency, master clock rate, etc., while modifying the image to generate
> the transmit signal in the FPGA rather than in the host.
>
> Nick
>
>
>
> On Wed, Apr 11, 2018 at 6:41 PM Yeo Jin Kuang Alvin (IA) <
> yjink...@dso.org.sg> wrote:
>
> Hi,
>
>
>
> I have the FPGA source code using Xilinx ISE 14.7, I want to output a
> signal out that is generated from the FPGA, however I suppose I have to
> control the AD9361 to get an output out to transmit unless I am wrong.
>
>
>
> Thanks in advance!
>
>
>
> *From:* Nick Foster [mailto:bistrom...@gmail.com]
> *Sent:* Thursday, 12 April 2018 9:39 AM
> *To:* Yeo Jin Kuang Alvin (IA)
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] AD9361 in USRP B210
>
>
>
> What exactly do you want to do?
>
>
>
> On Wed, Apr 11, 2018 at 6:33 PM Yeo Jin Kuang Alvin (IA) via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hi all,
>
>
>
> How do we set up the Ad9361_driver and ad9361 controls in the
> uhd/host/lib/usrp/common file for Ubuntu? What are the steps and
> prerequisites for this?
>
>
>
> Thank you in advance!
>
> ___
> 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

Re: [USRP-users] AD9361 in USRP B210

[Nick Foster via USRP-users]

The best option is probably to use existing UHD commands to set the gain,
frequency, master clock rate, etc., while modifying the image to generate
the transmit signal in the FPGA rather than in the host.

Nick

On Wed, Apr 11, 2018 at 6:41 PM Yeo Jin Kuang Alvin (IA) <
yjink...@dso.org.sg> wrote:

> Hi,
>
>
>
> I have the FPGA source code using Xilinx ISE 14.7, I want to output a
> signal out that is generated from the FPGA, however I suppose I have to
> control the AD9361 to get an output out to transmit unless I am wrong.
>
>
>
> Thanks in advance!
>
>
>
> *From:* Nick Foster [mailto:bistrom...@gmail.com]
> *Sent:* Thursday, 12 April 2018 9:39 AM
> *To:* Yeo Jin Kuang Alvin (IA)
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] AD9361 in USRP B210
>
>
>
> What exactly do you want to do?
>
>
>
> On Wed, Apr 11, 2018 at 6:33 PM Yeo Jin Kuang Alvin (IA) via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hi all,
>
>
>
> How do we set up the Ad9361_driver and ad9361 controls in the
> uhd/host/lib/usrp/common file for Ubuntu? What are the steps and
> prerequisites for this?
>
>
>
> Thank you in advance!
>
> ___
> 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

Re: [USRP-users] AD9361 in USRP B210

[Nick Foster via USRP-users]

What exactly do you want to do?

On Wed, Apr 11, 2018 at 6:33 PM Yeo Jin Kuang Alvin (IA) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
>
>
> How do we set up the Ad9361_driver and ad9361 controls in the
> uhd/host/lib/usrp/common file for Ubuntu? What are the steps and
> prerequisites for this?
>
>
>
> Thank you in advance!
> ___
> 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

Re: [USRP-users] RFNoC spp rate limitation

[Nick Foster via USRP-users]

Just chiming in to say you aren't crazy -- I've seen similar results in my
RFNoC loopback testing. There's a critical spp that you can't go below at
full rate without experiencing over/underflows. I didn't take the time to
dig down to the bottom of it, so I can't be of too much help here except to
confirm what you're seeing.

Nick

On Sat, Mar 24, 2018 at 11:52 AM Sebastian Leutner via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I tried using the packet_resizer block which improved things a little
> bit but not significantly. I figured that as soon as the difference
> between the spp (coming from the Radio) and the set packet size in the
> resizer block is too large, I get overruns again. I increased the
> STR_SINK_FIFOSIZE of the packet_resizer from 11 to 14 and now am able to
> run [Radio, spp=64] -> [Resizer, pkt_size=6000] -> [FIFO] -> [Null Sink]
> without problems. However, when trying pkt_size 7000 I get overruns
> again and same goes for any RFNoC blocks connected in between the Radio
> and Resizer blocks using spp=64 .
>
> By outputting the UHD trace messages and digging into some of its code,
> I found out that the RFNoC flow control is configured in such a way that
> it will send at least one ACK for every two packets on the bus (every
> packet for smaller input FIFO or larger pkt_size).
>
> See /uhd/host/lib/rfnoc/graph_impl.cpp:
>  > // On the same crossbar, use lots of FC packets
>  > size_t pkts_per_ack = std::min(
>  > uhd::rfnoc::DEFAULT_FC_XBAR_PKTS_PER_ACK,
>  > buf_size_pkts - 1
>  > );
> DEFAULT_FC_XBAR_PKTS_PER_ACK is set to 2 in constants.hpp.
>
>  From my understanding we should really take the max here instead of the
> min. We already calculated buf_size_pkts based on the input FIFO size of
> the next downstream block. Do I miss something here?
>
> Furthermore, UHD assumes the maximum packet size (=8000) for the Radio
> block although I set spp=64. I will try next week to also set the
> pkt_size in the Radio block stream args explicitly or (if that does not
> help) in its port definition in the UHD block description .xml file.
>
> I am not absolutely sure, if the FC is the only reason for my problems
> but it definitely increase the amount of ACK messages for smaller spp.
> Another workaround for me would probably to increase the
> STR_SINK_FIFOSIZE for all the RFNoC blocks I'm using.
>
> Regarding the bus clk_rate: It is set to 166.67 MHz  in rfnoc-devel at
> the moment (=10.67 Gbps raw throughput). Calculating the additional
> overhead from CHDR headers when using spp=64 I get 6.80 Gbps (compared
> to the raw (un-packetized) 6.40 Gbps). From my understanding, the
> crossbar should be capable of handling this amount since I have only one
> stream direction through my blocks (please correct me if I'm wrong here).
>
> Thanks for your ideas and feedback!
>
>
> EJ Kreinar wrote:> Hi Sebastian,
> >
> >  > Do you think that it would suffice to change the packet size at my
> > last RFNoC block before the host? I will try out the already available
> > packet_resizer block tomorrow.
> >
> > Yes, this is probably the easiest solution. But, if you're not opposed
> > to custom HDL, an alternate option could be to create a modified FFT
> > block that simply outputs an integer number of FFTs within a single
> packet.
> >
> >> So the question would be if RFNoC can handle passing packets with spp=64
> > at 200 MSps between RFNoC blocks
> >
> > That's a good question... RFNoC blocks all share a crossbar, which runs
> > at a particular bus_clk rate, so there is a max throughput that the bus
> > can handle... Each sample on the crossbar is 8 bytes, so you get a total
> > throughput of bus_clk*8 bytes/second. There's also a header overhead of
> > 16 bytes per packet (or 8 bytes if there's no timestamp).
> >
> > I'm actually not sure what the current X310 bus_clk rate is set to... I
> > just noticed a recent commit that supposedly changes bus_clk to 187.5
> > MHz
> > (
> https://github.com/EttusResearch/fpga/commit/d08203f60d3460a170ad8b3550b478113b7c5968
> > <
> https://github.com/EttusResearch/fpga/commit/d08203f60d3460a170ad8b3550b478113b7c5968
> >).
> > So I'm not exactly clear what the bus_clk was set to before that, or on
> > the rfnoc-devel branch...
> >
> > But unless I'm misunderstanding, having multiple RFNoC blocks running at
> > a full 200 Msps might saturate the bus? Is that correct?
> >
> > EJ
> >
> > On Thu, Mar 22, 2018 at 3:33 PM, Sebastian Leutner via USRP-users
> > > wrote:
> >
> > Hi all,
> >
> > when working with RFNoC at 200 MSps on the X310
> > using 10GbE I
> > experience overruns when using less than 512 samples
> > per packet (spp).
> > A simple flow graph [RFNoC Radio] -> [RFNoC FIFO] ->
> > [Null sink] with
> > the spp stream arg 

Re: [USRP-users] Getting started with FPGA and RFNoC developement

[Nick Foster via USRP-users]

Replies inline.

On Thu, Mar 22, 2018 at 9:48 AM TIMMEN Koen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
>
>
> First of all I would like to mention that I am not sure if this is the
> right location to ask these type of questions. However, I tried to find
> answers to my questions elsewhere but couldn’t find a better suited
> location, so I hope I’m not at the wrong address and causing too much
> clutter in the e-mail list.
>
>
>
> My experience with USRPs is almost nonexistent. Over the last few weeks I
> have looked around on the internet, learning about the concepts of FPGAs
> and HDL coding and I followed the Getting Started Guide for RFNoC. I am
> familiar with signal processing and the required mathematics and I would
> like to apply this knowledge in the domain of FPGAs, possibly while using
> RFNoC. This, I will be doing within the scope of an assignment that was
> given to me: what needs to be done is to set-up a USRP X310 with a real
> time signal generation module. Currently, this module is already up and
> running on a USRP N210 and all HDL code and host code is available to me.
> So all that needs to be done, is to use the existing HDL code and port it
> to another device. At least.. that’s how I interpret the task. Like I said,
> I am new to the USRP field and I have difficulties approaching it. Where do
> I get started? Do I need to know in-depth HDL coding etc.
>

You will have to have a pretty solid understanding of HDL, yes. Do I have
this right -- you inherited an existing N210 HDL design (not the stock
code, but a custom build), and you're responsible for porting it to X310?


>
>
> Here are some of the questions I have, I would like to thank anyone who is
> kind enough to reply to them in advance for answering:
>
> · HDL code is device independent, correct? Giving that the new
> FPGA has enough available hardware to synthesize the code, it shouldn’t be
> a problem to reuse the HDL code on a different device. So my thinking was
> that I could simply keep all the code that was created by someone skilled
> on the subject and simply create a new device specific image and no changes
> would be required. Is this correct or am I too naïve about this? (My
> attempts at doing this using Vivado, were useless and I can’t figure out
> what I am doing wrong.)
>
HDL code is nominally device independent, for the simplest cases. In every
part which interfaces with actual hardware it will be extremely
device-dependent. In the case of the N210 design you have, while the core
custom signal processing code which your predecessor created may (or may
not!) be easily portable, the surrounding HDL which composes the rest of
the design is 100% specific to the N210.


> · The existing HDL code is written in VHDL, but upon following
> the RFNoC getting started guide, I noticed the rfnocmodtool produces
> Verilog skeleton code. Is it also possible to make this work with the code
> I currently have or will I have to translate the code into Verilog?
>
You can wrap VHDL modules into Verilog designs.


> · Will RFNoC be a useful tool in fulfilling this task?
>
Yes, but -- before you go anywhere near RFNoC or any hardware at all, I
suggest you spend some time on an intermediate task. That is, creating a
testbench with which you can isolate the relevant DSP code, learn how it
works, and wrap it into something that can be used in an RFNoC block. You
will be best served if you create an AXI4 Stream interface to the DSP code
-- if you are lucky, it already uses an AXI4 Stream interface, in which
case your job gets easier.

Once you have a good understanding of the custom code, and once you have it
isolated into a testbench using AXI4 Streams to interface to it, you can
wrap it into an RFNoC block fairly easily, and at that point you can use it
in an X310 design.


> · There are many ready to use RFNoC blocks available through the
> ettus open source library. But I have trouble understanding what they are
> used for… where can I find a description of these blocks? Normally I would
> expect the function of a block written in the code itself. And since I do
> not read HDL code that well, the meaning of the code is not directly
> obvious to me.
>

Unfortunately documentation is not RFNoC's strong suit. The code is still
the best documentation as to the function of these blocks.


> · To close off, I realize that maybe I am too much a beginner to
> start this project. In that case, where should I begin? Is a HDL coding
> course the place to start?
>

I think that would be a good place to start! I wouldn't look at that (or
anything) as a hard prerequisite. Better to look at it as something which
will certainly speed your understanding and get you to a solution faster.

Nick


>
>
> Kind regards,
>
>
>
> Koen
>
>
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 

Re: [USRP-users] How to change B210 10Mz from Output to Input?

[Nick Foster via USRP-users]

Without an external reference, the onboard 40MHz VCTCXO will handle
creating a decent reference without the benefit of the PLL locking it to a
10MHz reference. Wouldn't be much use otherwise.

On Fri, Mar 9, 2018, 9:46 PM Sailor Jerry 
wrote:

> Guys, thank you so much for your support, you are awesome!
>
> Now I feel myself as complete idiot. I removed GPSDO. Disconnected the
> 10MHz clock, by USRP is still working and it seems to be on more or less
> correct correct frequency. I clearly can see the input tone on fft utility.
>
> Is there some other clock source I'm unaware off?  Can I see the ADF4001
> lock status?  Here is the output I'm getting:
> linux; GNU C++ version 5.3.1 20151219; Boost_105800;
> UHD_003.009.002-0-unknown
>
> -- Loading firmware image: /usr/share/uhd/images/usrp_b200_fw.hex...
> -- Detected Device: B210
> -- Loading FPGA image: /usr/share/uhd/images/usrp_b210_fpga.bin...
> -- Operating over USB 3.
> -- Detecting internal GPSDO No GPSDO found
> -- Initialize CODEC control...
> -- Initialize Radio control...
> -- Performing register loopback test... pass
> -- Performing register loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Performing CODEC loopback test... pass
> -- Asking for clock rate 16.00 MHz...
> -- Actually got clock rate 16.00 MHz.
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> -- Setting master clock rate selection to 'automatic'.
> -- Asking for clock rate 32.00 MHz...
> -- Actually got clock rate 32.00 MHz.
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
>
>
>
>
> On Fri, Mar 9, 2018 at 9:09 PM Sailor Jerry 
> wrote:
>
>> That would explain it , thanks :-)
>>
>> On Fri, Mar 9, 2018 at 9:07 PM Nick Foster  wrote:
>>
>>> I uh what? I don't see why that would be the case. The whole reason U103
>>> exists is to switch between a GPSDO (if present) and an external reference.
>>>
>>> You might wait for the official Ettus response for this if you don't
>>> want to take responsibility for blowing it up, but I drew the schematic and
>>> I say you're fine.
>>>
>>> Incidentally, very early prototypes of the B200 used a neat PIN diode
>>> switch ring which would allow outputting the GPSDO signal as well as using
>>> either the reference port or GPSDO as a clock input. I can't remember why
>>> it didn't make it into production, but one side effect would be that if
>>> misconfigured, you could damage hardware. Maybe that was it. ;)
>>>
>>> Nick
>>>
>>> On Fri, Mar 9, 2018 at 8:48 PM Marcus D. Leech 
>>> wrote:
>>>
 On 03/09/2018 11:44 PM, Sailor Jerry wrote:

 Thanks. Shall I ignore that sentence from USRP B2x0 Series manual "The
 B200 and B210 cannot support an external 10 MHz reference if a GPSDO is
 already present on the motherboard. If an external 10 MHz is to be used,
 the GPSDO needs to be physically removed from the device beforehand."?

 I think that advice is still correct, but I cannot remember why.  Nick?




 On Fri, Mar 9, 2018 at 8:32 PM Marcus D. Leech 
 wrote:

> On 03/09/2018 11:25 PM, Sailor Jerry wrote:
>
> Would be happy to restore it to original condition :-)
>
> I'm using the uhd_rx_cfile to capture the data. How do I control U103
> from this app? I don't see any command line arguments for that? Do I need
> to rebuild it?
>
> You'd have to add that, inserting a call to set_clock_source() at an
> appropriate place.
>
> The example apps (and this is one) don't necessarily expose all
> available features.
>
>
>
>
>
> On Fri, Mar 9, 2018 at 8:08 PM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 03/09/2018 08:11 PM, Nick Foster wrote:
>>
>> It's a slick mod though. See the zero-ohm resistor bridging U103 pins
>> 1 and 3? Remove it, and you'll return the B210 to factory standard.
>>
>> Assuming no other modifications have also been made.  =)
>>
>> Nick
>>
>> Your eyes are much better than mine
>>
>>
>>
>> On Fri, Mar 9, 2018 at 4:31 PM Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 03/09/2018 07:22 PM, Sailor Jerry via USRP-users wrote:
>>>
>>> HI Marcus, I see your point and also saw the schematic. The previous
>>> owner told me that this particular board was modified to have 10 MHz be
>>> brought out to the outside connector. I did verify it with the scope and
>>> indeed saw the 10 MHz coming out. I don't know if it's one of the 
>>> standard
>>> factory options or just some custom modifications (the board has
>>> Olifantasia label on it).  Will take a closer look at pins 3 and 1 of 
>>> U103
>>> as you 

Re: [USRP-users] How to change B210 10Mz from Output to Input?

[Nick Foster via USRP-users]

I uh what? I don't see why that would be the case. The whole reason U103
exists is to switch between a GPSDO (if present) and an external reference.

You might wait for the official Ettus response for this if you don't want
to take responsibility for blowing it up, but I drew the schematic and I
say you're fine.

Incidentally, very early prototypes of the B200 used a neat PIN diode
switch ring which would allow outputting the GPSDO signal as well as using
either the reference port or GPSDO as a clock input. I can't remember why
it didn't make it into production, but one side effect would be that if
misconfigured, you could damage hardware. Maybe that was it. ;)

Nick

On Fri, Mar 9, 2018 at 8:48 PM Marcus D. Leech  wrote:

> On 03/09/2018 11:44 PM, Sailor Jerry wrote:
>
> Thanks. Shall I ignore that sentence from USRP B2x0 Series manual "The
> B200 and B210 cannot support an external 10 MHz reference if a GPSDO is
> already present on the motherboard. If an external 10 MHz is to be used,
> the GPSDO needs to be physically removed from the device beforehand."?
>
> I think that advice is still correct, but I cannot remember why.  Nick?
>
>
>
>
> On Fri, Mar 9, 2018 at 8:32 PM Marcus D. Leech  wrote:
>
>> On 03/09/2018 11:25 PM, Sailor Jerry wrote:
>>
>> Would be happy to restore it to original condition :-)
>>
>> I'm using the uhd_rx_cfile to capture the data. How do I control U103
>> from this app? I don't see any command line arguments for that? Do I need
>> to rebuild it?
>>
>> You'd have to add that, inserting a call to set_clock_source() at an
>> appropriate place.
>>
>> The example apps (and this is one) don't necessarily expose all available
>> features.
>>
>>
>>
>>
>>
>> On Fri, Mar 9, 2018 at 8:08 PM Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 03/09/2018 08:11 PM, Nick Foster wrote:
>>>
>>> It's a slick mod though. See the zero-ohm resistor bridging U103 pins 1
>>> and 3? Remove it, and you'll return the B210 to factory standard.
>>>
>>> Assuming no other modifications have also been made.  =)
>>>
>>> Nick
>>>
>>> Your eyes are much better than mine
>>>
>>>
>>>
>>> On Fri, Mar 9, 2018 at 4:31 PM Marcus D. Leech via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 On 03/09/2018 07:22 PM, Sailor Jerry via USRP-users wrote:

 HI Marcus, I see your point and also saw the schematic. The previous
 owner told me that this particular board was modified to have 10 MHz be
 brought out to the outside connector. I did verify it with the scope and
 indeed saw the 10 MHz coming out. I don't know if it's one of the standard
 factory options or just some custom modifications (the board has
 Olifantasia label on it).  Will take a closer look at pins 3 and 1 of U103
 as you suggest.  If they are bridged indeed then I guess simple removal of
 GPSDO would do the trick.


 That is NOT a factory-standard option.




 On Fri, Mar 9, 2018 at 4:10 PM Marcus Müller 
 wrote:

> Dear Sailor Jerry,
>
> I'm not sure I'm following here: The 10 MHz connector is hardware-wise
> connected only to inputs, not to anything that can output anything;
> compare the schematic[1] on page 1. So, I'm pretty certain your device
> can't be condigured to have the 10 MHz connector be an output for
> anything.
>
> Can you maybe describe the problem you're having?
>
> Best regards,
> Marcus
>
> [1] https://files.ettus.com/schematics/b200/b210.pdf
> On Fri, 2018-03-09 at 23:51 +, Sailor Jerry via USRP-users wrote:
> > I inherited the B210 board that has the 10 MHz connector configured
> > as an output. I wonder if anyone is aware of this configuration and
> > if it's possible to reconfigure it to accept the external 10 MHz
> > input.
> >
> > My current plan is simply remove GPSDO and hope for the best.
> >
> > Attached are two pictures of my board. One is with GPSDO inserted and
> > another one with GPSDO removed.
> >
> > Thanks a lot!
> >
> >
> >
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


 ___
 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

>>>
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
>

Re: [USRP-users] How to change B210 10Mz from Output to Input?

[Nick Foster via USRP-users]

It's a slick mod though. See the zero-ohm resistor bridging U103 pins 1 and
3? Remove it, and you'll return the B210 to factory standard.

Assuming no other modifications have also been made.  =)

Nick

On Fri, Mar 9, 2018 at 4:31 PM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 03/09/2018 07:22 PM, Sailor Jerry via USRP-users wrote:
>
> HI Marcus, I see your point and also saw the schematic. The previous owner
> told me that this particular board was modified to have 10 MHz be brought
> out to the outside connector. I did verify it with the scope and indeed saw
> the 10 MHz coming out. I don't know if it's one of the standard factory
> options or just some custom modifications (the board has Olifantasia label
> on it).  Will take a closer look at pins 3 and 1 of U103 as you suggest.
> If they are bridged indeed then I guess simple removal of GPSDO would do
> the trick.
>
>
> That is NOT a factory-standard option.
>
>
>
>
> On Fri, Mar 9, 2018 at 4:10 PM Marcus Müller 
> wrote:
>
>> Dear Sailor Jerry,
>>
>> I'm not sure I'm following here: The 10 MHz connector is hardware-wise
>> connected only to inputs, not to anything that can output anything;
>> compare the schematic[1] on page 1. So, I'm pretty certain your device
>> can't be condigured to have the 10 MHz connector be an output for
>> anything.
>>
>> Can you maybe describe the problem you're having?
>>
>> Best regards,
>> Marcus
>>
>> [1] https://files.ettus.com/schematics/b200/b210.pdf
>> On Fri, 2018-03-09 at 23:51 +, Sailor Jerry via USRP-users wrote:
>> > I inherited the B210 board that has the 10 MHz connector configured
>> > as an output. I wonder if anyone is aware of this configuration and
>> > if it's possible to reconfigure it to accept the external 10 MHz
>> > input.
>> >
>> > My current plan is simply remove GPSDO and hope for the best.
>> >
>> > Attached are two pictures of my board. One is with GPSDO inserted and
>> > another one with GPSDO removed.
>> >
>> > Thanks a lot!
>> >
>> >
>> >
>> > ___
>> > USRP-users mailing list
>> > USRP-users@lists.ettus.com
>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
>
> ___
> 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
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] GRC + RFNoC + Radio Loopback

[Nick Foster via USRP-users]

If the lights are on, the device is streaming, guaranteed. At this point,
make sure your frequencies, gains, and antenna selections are correct.

Nick

On Fri, Mar 9, 2018 at 11:19 AM Kei Nguyen 
wrote:

> Sorry I mean the lights were on when I closed the program.
> Thanks Sam for the suggestion I will try to take a look into it.
>
> On Fri, Mar 9, 2018 at 2:02 PM, Nick Foster  wrote:
>
>> The lights are on because the device isn't instructed to stop streaming
>> on program stop, and it will continue loopback operation after the host has
>> closed the program. You can manually issue a stream command to stop the
>> stream before program stop if you want to change this behavior.
>>
>> Kei, why would the flow go through the host at all in the example you
>> initially posted? The DMA FIFO exists on the FPGA.
>>
>> Sam, the headers don't have to be modified in the FPGA if UHD instructs
>> the RX Radio to omit timestamps.
>>
>> Nick
>>
>> On Fri, Mar 9, 2018 at 10:57 AM Samuel Prager  wrote:
>>
>>> Hello,
>>>
>>> I have had this issue and may be able to help. I believe that is because
>>> the rx packet headers need to be modified before the radio will transmit
>>> them. I would suggest looking at the siggen block and making a new ‘relay’
>>> noc block between the rx and tx in the fpga that modifies headers
>>> appropriately. I would guess that the lights are on because you have filled
>>> up all fifos.
>>>
>>> Sam
>>>
>>>
>>> On Mar 9, 2018, 10:39 AM -0800, Kei Nguyen via USRP-users , wrote:
>>>
>>> Thanks. After setting spp=600 and omit the DMA FIFO, it doesn't raise
>>> the errors anymore and I can run the flowgraph without having to power
>>> cycle. I think that is because the flow doesn't go through the host
>>> anymore. But it's weird that after stopping the flowgraph the RX and TX
>>> lights are still on. Why is that?
>>> By the way still I can't receive the relay signal in USRP 3.
>>>
>>> On Fri, Mar 9, 2018 at 1:27 PM, Nick Foster 
>>> wrote:
>>>
 Are you using a custom FPGA image? What happens if you just omit the
 DMA FIFO?

 Also, set a reasonable spp in your RX Radio block arguments -- 300 to
 600 is a good start.

 Nick

 On Fri, Mar 9, 2018 at 10:24 AM Kei Nguyen 
 wrote:

> Thanks for the reply and sorry for not providing much information. My
> case is that I want to do a relay transmission with the setup: USRP 1
> transmits --> USRP 2 receives and retransmits with a shifted fc --> USRP 3
> receives.
> The problem is in USRP 2, as you pointed out in your post. I'm testing
> on a simple flowgraph RX --> DDC --> DmaFIFO --> DUC (frequency shifted by
> 5MHz) --> TX. I used your approach [1] in step 1 of your tutorial (also 
> did
> step 2 and 3) and rebuilt.
> At first the flowgraph runs without errors. The TX and RX lights were
> on, so it seemed to transmit something. But in USRP 3 I didn't see the
> relay signals (only the original signal that USRP1 transmits).
> Also, in the following runs, it raised the errors:
> [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_4.0.0.rfnoc-devel-409-gec9138eb]
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Determining maximum frame size...
> [INFO] [X300] Maximum frame size: 1472 bytes.
> [INFO] [X300] Setup basic communication...
> [INFO] [X300] Loading values from EEPROM...
> [INFO] [X300] Setup RF frontend clocking...
> [INFO] [X300] Radio 1x clock:200
> [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 0...
> [INFO] [RFNOC] pass (Throughput: 1302.9MB/s)
> [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 1...
> [INFO] [RFNOC] pass (Throughput: 1293.6MB/s)
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> [INFO] [RFNOC] Assuming max packet size for 0/DDC_0
> [INFO] [RFNOC] Assuming max packet size for 0/DmaFIFO_0
> [INFO] [RFNOC] Assuming max packet size for 0/DUC_0
> [INFO] [RFNOC] Assuming max packet size for 0/Radio_0
> kei@kei-Precision-T7610:~/test_rfnoc$ ./relay.py
> [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_4.0.0.rfnoc-devel-409-gec9138eb]
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Determining maximum frame size...
> [INFO] [X300] Maximum frame size: 1472 bytes.
> [INFO] [X300] Setup basic communication...
> [INFO] [X300] Loading values from EEPROM...
> [INFO] [X300] Setup RF 

Re: [USRP-users] GRC + RFNoC + Radio Loopback

[Nick Foster via USRP-users]

Are you using a custom FPGA image? What happens if you just omit the DMA
FIFO?

Also, set a reasonable spp in your RX Radio block arguments -- 300 to 600
is a good start.

Nick

On Fri, Mar 9, 2018 at 10:24 AM Kei Nguyen 
wrote:

> Thanks for the reply and sorry for not providing much information. My case
> is that I want to do a relay transmission with the setup: USRP 1 transmits
> --> USRP 2 receives and retransmits with a shifted fc --> USRP 3 receives.
> The problem is in USRP 2, as you pointed out in your post. I'm testing on
> a simple flowgraph RX --> DDC --> DmaFIFO --> DUC (frequency shifted by
> 5MHz) --> TX. I used your approach [1] in step 1 of your tutorial (also did
> step 2 and 3) and rebuilt.
> At first the flowgraph runs without errors. The TX and RX lights were on,
> so it seemed to transmit something. But in USRP 3 I didn't see the relay
> signals (only the original signal that USRP1 transmits).
> Also, in the following runs, it raised the errors:
> [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_4.0.0.rfnoc-devel-409-gec9138eb]
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Determining maximum frame size...
> [INFO] [X300] Maximum frame size: 1472 bytes.
> [INFO] [X300] Setup basic communication...
> [INFO] [X300] Loading values from EEPROM...
> [INFO] [X300] Setup RF frontend clocking...
> [INFO] [X300] Radio 1x clock:200
> [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 0...
> [INFO] [RFNOC] pass (Throughput: 1302.9MB/s)
> [INFO] [RFNOC] [DMA FIFO] Running BIST for FIFO 1...
> [INFO] [RFNOC] pass (Throughput: 1293.6MB/s)
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [RFNOC RADIO] Register loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> [INFO] [CORES] Performing timer loopback test...
> [INFO] [CORES] Timer loopback test passed
> [INFO] [RFNOC] Assuming max packet size for 0/DDC_0
> [INFO] [RFNOC] Assuming max packet size for 0/DmaFIFO_0
> [INFO] [RFNOC] Assuming max packet size for 0/DUC_0
> [INFO] [RFNOC] Assuming max packet size for 0/Radio_0
> kei@kei-Precision-T7610:~/test_rfnoc$ ./relay.py
> [INFO] [UHDlinux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_4.0.0.rfnoc-devel-409-gec9138eb]
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Determining maximum frame size...
> [INFO] [X300] Maximum frame size: 1472 bytes.
> [INFO] [X300] Setup basic communication...
> [INFO] [X300] Loading values from EEPROM...
> [INFO] [X300] Setup RF frontend clocking...
> [INFO] [X300] Radio 1x clock:200
> [ERROR] [UHD] Exception caught in safe-call.
>   in virtual ctrl_iface_impl::~ctrl_iface_impl()
>   at /home/kei/rfnoc/src/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
> this->peek32(0); -> EnvironmentError: IOError: Block ctrl (CE_00_Port_30)
> packet parse error - EnvironmentError: IOError: Expected packet index: 3
> Received index: 4
> Traceback (most recent call last):
>   File "./relay.py", line 291, in 
> main()
>   File "./relay.py", line 279, in main
> tb = top_block_cls(freq=options.freq)
>   File "./relay.py", line 72, in __init__
> self.device3 = device3 = ettus.device3(uhd.device_addr_t(
> ",".join(('type=x300', "")) ))
>   File "/home/kei/rfnoc/lib/python2.7/dist-packages/ettus/ettus_swig.py",
> line 1610, in make
> return _ettus_swig.device3_make(device_addr)
> RuntimeError: EnvironmentError: IOError: [0/DmaFIFO_0] sr_read64() failed:
> EnvironmentError: IOError: Block ctrl (CE_00_Port_30) packet parse error -
> EnvironmentError: IOError: Expected SID: 02:30>00:00  Received SID:
> 02:c0>00:00
>
>
> which is exactly the errors that Christophe faced in the previous post. I
> had to power cycle to run the flowgraph again.
> Attachments are the changed files. I'm using uhd version UHD
> 4.0.0.rfnoc-devel-409-gec9138eb and gnuradio version
> 3.7.12git-295-ga0adcd33.
> Sorry for the long post.
>
>
>
> On Fri, Mar 9, 2018 at 12:21 PM, Nick Foster  wrote:
>
>> You're going to have to ask a better question than that. Please provide
>> the following:
>>
>> * What you are trying to accomplish
>> * What hardware you are using
>> * What UHD and Gnuradio version you are using
>> * The approach you followed
>> * The result you expected
>> * The result you actually got
>> * A flowgraph which exhibits the problem
>>
>> If you put effort into your question, we can put effort into answering
>> you.
>>
>> Nick
>>
>> On Thu, Mar 8, 2018 at 10:39 AM Kei Nguyen via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello, is this problem resolved? I am facing the same issue in the last
>>> email. Also, I tried to receive the relay signal with another usrp but it
>>> doesn't receive anything in my transmit frequency.
>>>
>>> Hai
>>> ___
>>> USRP-users 

Re: [USRP-users] E312 Loopback Path Delay Changes when FPGA image is reloaded

[Nick Foster via USRP-users]

One thing that struck me: I don't think you should have to disable the
streamer to switch between cal and radio channels. Just for experiment's
sake, try leaving both channels active in the streamer. You can pull
samples from both channels in your recv() command, and just use the channel
you're interested in. Does doing this affect the result?

Nick

On Fri, Mar 9, 2018 at 10:13 AM Samuel Prager <spra...@usc.edu> wrote:

> Hey Nick,
>
> No prob blew at all. The flag *“no_reload_fpga”* seems to work for that.
> The bigger problem is that each time the fpga image is loaded on the e3xx,
> the relative path delays between the RXA and RXB channels changes randomly
> as seen by the sample group jumps in the image I originally attached. The
> random LO phase is measured and removed, so there is something else
> happening in this strange case.
>
> If anyone has any ideas as to what could be causing this please help! The
> phase stability of the E312 is amazing within the same fpga image cycle but
> these relatively large jumps after reload/ power cycle are a deal breaker
> for some applications!
>
> Thanks
>
> Sam
>
> On Mar 9, 2018, 9:19 AM -0800, Nick Foster via USRP-users <
> usrp-users@lists.ettus.com>, wrote:
>
> Sam,
>
> Sorry I haven't gotten back -- it sounds like you're doing everything
> right. The usual quick fixes probably don't apply here. I haven't had time
> to look more in depth into it, or to try to replicate it on my own hardware.
>
> Marcus is right -- the E3xx uses an idle image in order to reduce power
> consumption when the radio is inactive. I'm not sure if there's a flag that
> will tell UHD not to load the idle image.
>
> Nick
>
> On Thu, Mar 8, 2018 at 9:30 PM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 03/09/2018 12:11 AM, Samuel Prager via USRP-users wrote:
>>
>> Still looking for more info on this problem.
>>
>> I have the exact same RfNoC block/software program running on an X300 and
>> see no such jumps or otherwise unexpected behavior.
>>
>> I have attempted to isolate this issue on the E312 by creating the
>> device3 with the *“no_reload_fpga”* flag. (Appropriate image is loaded
>> before hand with the uhd_usrp_image_loader. Running my program the first
>> time works as expected, but if I kill the program and restart, I get this
>> error:
>>
>> *“AssertionError: zf_peek32(ctrl_base+ARBITER_RB_ADDR_SPACE) > 0 in
>> virtual void e300_fifo_mb::release()"*
>>
>> The last few lines in the Uhd log file are:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *e300_impl.cpp:639,1,E300,[E300] Setting up dest map for host ep 0 to be
>> stream 0 device3_impl.cpp:131,0, DEVICE3, Setting up NoC-Shell Control for
>> port #0 (SID; 00:00>02:10) device3_impl.cpp:139,0,DEVICE3, OK
>> davice3_impl.cpp:141,0, DEVICE3, Port 16: found NoC-Block with ID
>> 12AD1000. e300_impl.cpp:639,1,E300, [E300] Setting up dest map for
>> host ep 1 to be stream 1 device3_impl.cpp:160,0,DEVICE3, Setting up NoC
>> Shell port for #1 (SID: 00:01>02:11)*
>>
>>
>>
>> Shouldn’t the E312 be able to operate without needing to reload the FPGA
>> image each time? Has this been tested? I would really appreciate any hints
>> or pointers into why this is happening.
>>
>> Thank you,
>>
>> Sam
>>
>> The E3xx run an "idle" image when the device is not being used.  I cannot
>> remember the reason for that, TBH.
>>
>>
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com=DwMFaQ=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI=opIuWAKmywF059tAs2i3Pg=HkJbIenCP1t5oGgIxFFvHftFEabvbCk9VlUuv6EBHqA=HutNULVtirv0JuQ4R8HiR34nBs82dDVsc3zQccm3BTU=>
>>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
>
>
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com=DwICAg=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI=opIuWAKmywF059tAs2i3Pg=HkJbIenCP1t5oGgIxFFvHftFEabvbCk9VlUuv6EBHqA=HutNULVtirv0JuQ4R8HiR34nBs82dDVsc3zQccm3BTU=
>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] GRC + RFNoC + Radio Loopback

[Nick Foster via USRP-users]

You're going to have to ask a better question than that. Please provide the
following:

* What you are trying to accomplish
* What hardware you are using
* What UHD and Gnuradio version you are using
* The approach you followed
* The result you expected
* The result you actually got
* A flowgraph which exhibits the problem

If you put effort into your question, we can put effort into answering you.

Nick

On Thu, Mar 8, 2018 at 10:39 AM Kei Nguyen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello, is this problem resolved? I am facing the same issue in the last
> email. Also, I tried to receive the relay signal with another usrp but it
> doesn't receive anything in my transmit frequency.
>
> Hai
> ___
> 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