[USRP-users] N3xx arm processor datarate

[Samuel Prager via USRP-users]

Hello,

I have been unable to find answer as to what is the maximum streaming data rate 
is from the zynq fpga to the arm processor in the N3xx USRPs operating in 
embedded mode.

Does anyone have an answer to this question?

Thank you,

Sam

Samuel Prager
PhD Student, Electrical Engineering
University of Southern California
Viterbi School of Engineering
spra...@usc.edu
prager@gmail.com
(916) 671-0976
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

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

[Samuel Prager via USRP-users]

Hi Nick,

I can try this, but the reason I disable one or the other streamer is so that I 
can sample at the full 50MHz. Running both streamers cuts the sample rate in 
half and I am only using the cal channel to measure/correct the random LO phase 
offset.

In this switching mode, the data always comes from radio block 1, but the 
AD9361 routes it to either RXA or RXB at full rate depending on the active 
streamer.

I also switch back and forth between the channels thousands of times on a 
single power cycle without an issue.

Even if I only receive on a single channel (RXA) and match filter with a 
reference waveform file, I am still seeing the same behavior: tight groupings 
in measured phase slope delay but with random hops in group mean whenever the 
image is reloaded.

Sam

On Mar 9, 2018, 10:22 AM -0800, Nick Foster <bistrom...@gmail.com>, wrote:
> 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 (S

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

[Samuel Prager via USRP-users]

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
> ___
> 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] E312 Loopback Path Delay Changes when FPGA image is reloaded

[Samuel Prager via USRP-users]

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

On Mar 6, 2018, 12:40 PM -0800, Prager, Samuel M (334E) via USRP-users 
, wrote:
> Hi Nick,
>
> Thanks for the response. I am streaming from one channel at a time. I switch 
> between channels by toggling:
>
>  _radio_ctrl->set_rx_streamer(false, _radio_chan);
>  _radio_ctrl->set_rx_streamer(true, _calib_chan);
>
> And then issue timed RX stream commands:
>
> uhd::time_spec_t timenow = _radio_ctrl->get_time_now();
>        uhd::time_spec_t time_spec = 
> uhd::time_spec_t(seconds_in_future)+timenow;
>         stream_cmd.stream_now = false;
>    stream_cmd.time_spec = time_spec;
> issue_stream_cmd_override(stream_cmd, _radio_chan);
>
> Where issue_stream_cmd_override() is the same as 
> _radio_ctrl->issue_stream_cmd() except that it doesn’t check that the 
> requested channel is active (easiest way I found to quickly switch between 
> RXA and RXB). I also set the MCS register in the aD9361 initialization so 
> that the two channels are phase coherent.
>
> A signal generator upstream from the radio in the FPGA generates the TX pulse 
> on request (with a timestamp to forward) and creates a vita header with the 
> same timestamp used for the RX stream command, so TX and RX begin at the same 
> clock cycle.
>
> Thanks,
>
> Sam
>
> From: Nick Foster [mailto:bistrom...@gmail.com]
> Sent: Tuesday, March 06, 2018 11:57 AM
> To: Prager, Samuel M (334E) 
> Cc: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] E312 Loopback Path Delay Changes when FPGA image is 
> reloaded
>
> Could you post your flowgraph or UHD program, or the relevant excerpts? Are 
> the two RX channels being loaded simultaneously? Are you using timed commands 
> to start the RX and TX streams?
> Nick
>
> On Tue, Mar 6, 2018 at 11:52 AM Prager, Samuel M (334E) via USRP-users 
>  wrote:
> > quote_type
> > Hello,
> >
> > We are interested in using the E312 as a phase-sensitive radar sounder and 
> > have run into an interesting issue.
> >
> > We are measuring (relative) cable length by estimating linear phase slope 
> > from a 10MHz chirp pulse and are using the following test setup (attached):
> >
> > We have set the appropriate AD9361 registers to keep the VCO/PLL dividers 
> > on so that RXA (data) and RXB (calibration) are phase coherent. We perform 
> > pulse averaging on each channel and match filter with the cal channel pulse 
> > (shorter cable).
> >
> > We have noticed that the phase measurements remain stable within <1 cm 99% 
> > confidence interval for successive trials with multiple re-tunings of the 
> > LO over long periods of time. However, we have found that if the FPGA bit 
> > file is unloaded (put in idle mode) and then reloaded (either through 
> > power-cycle or termination of UHD-based application), the measured phase 
> > slope jumps randomly.
> >
> > We’re really scratching our heads over this behavior… multiple trials on a 
> > given ‘cycle’ remain stable around a mean value, but that value jumps 
> > around from cycle to cycle in a seemingly random way.
> >
> > I have attached plots for two tests - the vertical black dotted lines are 
> > placed to show when the E312 FPGA image was cycled. Each data point is 
> > taken from a separate LO tuning (ie. tune to 400mhz, collect data, tune to 
> > 1ghz, wait, tune to 400mhz, collect data,…)
> >
> > Any ideas about where could possibly be coming from? Is there somewhere in 
> > the E312 initialization that the relative path between RXA and RXB may be 
> > changed non-deterministically?
> >
> > I really appreciate any help!
> >
> > Thank you,
> >
> > Sam
> >
> > 

Re: [USRP-users] RFNoC block fpga control source issues

[Samuel Prager via USRP-users]

Hi Jonathan,

Yes I add my block and the radio block, connect them and tell my block to send 
commands to radio block. I have confirmed today that the simulation still works 
correctly in Vivado 2017.4 — the settings registers are written as expected, an 
rx command is generated in the radio and the correct number of samples are 
streamed back into the tb_streamer.

Sam
On Oct 21, 2018, 9:20 AM -0700, Jon Pendlum , wrote:
> How does your testbench work? Do you add the radio core block, send timed 
> commands to it, and see the outputs toggle?
>
> > On Sat, Oct 20, 2018 at 1:05 PM Samuel Prager  wrote:
> > > Hi Jonathon,
> > >
> > > Thanks for the response! Yes I’m using ce_clk and ce_rst. Thanks for 
> > > sharing your code — the only real difference I see is that you increment 
> > > the seq_num. I am leaving it as 12’b0 — could this be causing an issue?
> > >
> > > I should also say that In my case, the command packets are being sent to 
> > > the radio block to trigger timed receive commands in order to reduce the 
> > > number of software sr_writes.
> > >
> > > Here’s my code just in case: https://pastebin.com/Asgj7Jw2.
> > >
> > > This is something that was simulated/verified and worked in the past, but 
> > > perhaps a change has been made that prevents this from working?
> > >
> > > I will try a release tag as soon as possible — however this is something 
> > > I’ve been seeing for a couple of months now that has kept me on 
> > > pre-2017.4 releases.
> > >
> > > Sam
> > > On Oct 19, 2018, 8:17 PM -0700, Jon Pendlum , 
> > > wrote:
> > > > Hi Sam,
> > > >
> > > > I am using command packets to tune the DDC block's DSP frequency. Are 
> > > > you using ce_clk and ce_rst for clock and reset? Here is my code if you 
> > > > want to take a look: https://pastebin.com/1AeHFb0J. Also, it might be 
> > > > worth trying your code on a release tag like v3.13.0.2 in case master 
> > > > has a regression.
> > > >
> > > > Jonathon
> > > >
> > > > > On Sat, Oct 20, 2018 at 8:11 AM Samuel Prager via USRP-users 
> > > > >  wrote:
> > > > > > Hello,
> > > > > >
> > > > > > I have an RFNoC block that generates command packets to write 
> > > > > > settings registers of the downstream connected block using the 
> > > > > > Control Source (cmdout_tdata) of the noc_shell . Previously this 
> > > > > > had worked perfectly (prior to approximately d6b2283 on 
> > > > > > rfnoc-devel), for both the X300 and E310, but this functionality 
> > > > > > appears to perhaps be broken in the more recent FPGA releases — 
> > > > > > since around the switch to Vivado 2017.4 and the move of the noc 
> > > > > > block clock domain crossing to axi_wrapper.v). I have tried the 
> > > > > > latest master branch (4f25ed1) with no success.
> > > > > >
> > > > > > Is this a known issue? Can anyone shed light on what might have 
> > > > > > caused this?
> > > > > >
> > > > > > The control packets are generated in my block as follows:
> > > > > >
> > > > > > wire eob = 1’b0;
> > > > > > wire [1:0] pkt_type = 2'b10;
> > > > > > wire [11:0] seqnum = 12'd0; // don't care
> > > > > > wire [15:0] payload_length = 16'd16; //don't care (payload length 
> > > > > > in bytes)
> > > > > > assign cmd_tdata = {24’d0,set_bus_addr[7:0], set_bus_val[31:0]};
> > > > > >
> > > > > > cvita_hdr_encoder cvita_hdr_encoder(
> > > > > > .pkt_type(pkt_type),.eob(eob), .has_time(1'b0),
> > > > > > .seqnum(seqnum),
> > > > > > .payload_length(payload_length),
> > > > > > .src_sid(src_sid), .dst_sid(dst_sid),
> > > > > > .vita_time(vita_time),
> > > > > > .header(cmd_tuser)
> > > > > > );
> > > > > >
> > > > > > chdr_framer #(.SIZE(FIFO_SIZE), .WIDTH(64)) chdr_framer (
> > > > > > .clk(clk), .reset(reset), .clear(clear),
> > > > > > .i_tdata(cmd_tdata), .i_tuser(cmd_tuser), .i_tlast(cmd_tlast), 
> > > > > > .i_tvalid(cmd_tvalid), .i_tready(cmd_tready),
> > > > > > .o_tdata(cmdout_tdata), .o_tlast(cmdout_tlast), 
> > > > > > .o_tvalid(cmdout_tvalid), .o_tready(cmdout_tready));
> > > > > >
> > > > > > The command packets appear to never reach the destination rfnoc 
> > > > > > block, but I am at a loss for the cause.
> > > > > >
> > > > > > Is anyone currently using the control source functionality of the 
> > > > > > noc_shell? I would really appreciate any pointers on how to fix 
> > > > > > this.
> > > > > >
> > > > > > Thank you,
> > > > > >
> > > > > > Sam
> > > > > >
> > > > > > ___
> > > > > > 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 block fpga control source issues

[Samuel Prager via USRP-users]

Hi Jonathon,

Thanks for the response! Yes I’m using ce_clk and ce_rst. Thanks for sharing 
your code — the only real difference I see is that you increment the seq_num. I 
am leaving it as 12’b0 — could this be causing an issue?

I should also say that In my case, the command packets are being sent to the 
radio block to trigger timed receive commands in order to reduce the number of 
software sr_writes.

Here’s my code just in case: https://pastebin.com/Asgj7Jw2.

This is something that was simulated/verified and worked in the past, but 
perhaps a change has been made that prevents this from working?

I will try a release tag as soon as possible — however this is something I’ve 
been seeing for a couple of months now that has kept me on pre-2017.4 releases.

Sam
On Oct 19, 2018, 8:17 PM -0700, Jon Pendlum , wrote:
> Hi Sam,
>
> I am using command packets to tune the DDC block's DSP frequency. Are you 
> using ce_clk and ce_rst for clock and reset? Here is my code if you want to 
> take a look: https://pastebin.com/1AeHFb0J. Also, it might be worth trying 
> your code on a release tag like v3.13.0.2 in case master has a regression.
>
> Jonathon
>
> > On Sat, Oct 20, 2018 at 8:11 AM Samuel Prager via USRP-users 
> >  wrote:
> > > Hello,
> > >
> > > I have an RFNoC block that generates command packets to write settings 
> > > registers of the downstream connected block using the Control Source 
> > > (cmdout_tdata) of the noc_shell . Previously this had worked perfectly 
> > > (prior to approximately d6b2283 on rfnoc-devel), for both the X300 and 
> > > E310, but this functionality appears to perhaps be broken in the more 
> > > recent FPGA releases — since around the switch to Vivado 2017.4 and the 
> > > move of the noc block clock domain crossing to axi_wrapper.v). I have 
> > > tried the latest master branch (4f25ed1) with no success.
> > >
> > > Is this a known issue? Can anyone shed light on what might have caused 
> > > this?
> > >
> > > The control packets are generated in my block as follows:
> > >
> > > wire eob = 1’b0;
> > > wire [1:0] pkt_type = 2'b10;
> > > wire [11:0] seqnum = 12'd0; // don't care
> > > wire [15:0] payload_length = 16'd16; //don't care (payload length in 
> > > bytes)
> > > assign cmd_tdata = {24’d0,set_bus_addr[7:0], set_bus_val[31:0]};
> > >
> > > cvita_hdr_encoder cvita_hdr_encoder(
> > > .pkt_type(pkt_type),.eob(eob), .has_time(1'b0),
> > > .seqnum(seqnum),
> > > .payload_length(payload_length),
> > > .src_sid(src_sid), .dst_sid(dst_sid),
> > > .vita_time(vita_time),
> > > .header(cmd_tuser)
> > > );
> > >
> > > chdr_framer #(.SIZE(FIFO_SIZE), .WIDTH(64)) chdr_framer (
> > > .clk(clk), .reset(reset), .clear(clear),
> > > .i_tdata(cmd_tdata), .i_tuser(cmd_tuser), .i_tlast(cmd_tlast), 
> > > .i_tvalid(cmd_tvalid), .i_tready(cmd_tready),
> > > .o_tdata(cmdout_tdata), .o_tlast(cmdout_tlast), .o_tvalid(cmdout_tvalid), 
> > > .o_tready(cmdout_tready));
> > >
> > > The command packets appear to never reach the destination rfnoc block, 
> > > but I am at a loss for the cause.
> > >
> > > Is anyone currently using the control source functionality of the 
> > > noc_shell? I would really appreciate any pointers on how to fix this.
> > >
> > > Thank you,
> > >
> > > Sam
> > >
> > > ___
> > > 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] RFNoC block fpga control source issues

[Samuel Prager via USRP-users]

Hello,

I have an RFNoC block that generates command packets to write settings 
registers of the downstream connected block using the Control Source 
(cmdout_tdata) of the noc_shell . Previously this had worked perfectly (prior 
to approximately d6b2283 on rfnoc-devel), for both the X300 and E310, but this 
functionality appears to perhaps be broken in the more recent FPGA releases — 
since around the switch to Vivado 2017.4 and the move of the noc block clock 
domain crossing to axi_wrapper.v). I have tried the latest master branch 
(4f25ed1) with no success.

Is this a known issue? Can anyone shed light on what might have caused this?

The control packets are generated in my block as follows:

wire eob = 1’b0;
wire [1:0] pkt_type = 2'b10;
wire [11:0] seqnum = 12'd0; // don't care
wire [15:0] payload_length = 16'd16; //don't care (payload length in bytes)
assign cmd_tdata = {24’d0,set_bus_addr[7:0], set_bus_val[31:0]};

cvita_hdr_encoder cvita_hdr_encoder(
.pkt_type(pkt_type),.eob(eob), .has_time(1'b0),
.seqnum(seqnum),
.payload_length(payload_length),
.src_sid(src_sid), .dst_sid(dst_sid),
.vita_time(vita_time),
.header(cmd_tuser)
);

chdr_framer #(.SIZE(FIFO_SIZE), .WIDTH(64)) chdr_framer (
.clk(clk), .reset(reset), .clear(clear),
.i_tdata(cmd_tdata), .i_tuser(cmd_tuser), .i_tlast(cmd_tlast), 
.i_tvalid(cmd_tvalid), .i_tready(cmd_tready),
.o_tdata(cmdout_tdata), .o_tlast(cmdout_tlast), .o_tvalid(cmdout_tvalid), 
.o_tready(cmdout_tready));

The command packets appear to never reach the destination rfnoc block, but I am 
at a loss for the cause.

Is anyone currently using the control source functionality of the noc_shell? I 
would really appreciate any pointers on how to fix this.

Thank you,

Sam

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

Re: [USRP-users] RFNoC block fpga control source issues

[Samuel Prager via USRP-users]

file cmd_pkt_proc.v. That is the state machine 
> > > > > that receives command packets and issues settings bus writes. You 
> > > > > should be able to see your command packets come in and get processed 
> > > > > by the state machine. You can double check the command packet / timed 
> > > > > command vita time versus the radio core's vita time. You can also see 
> > > > > if the state machine gets stuck in a certain state.
> > > > >
> > > > > Jonathon
> > > > >
> > > > > > On Wed, Oct 24, 2018 at 9:44 AM Samuel Prager  
> > > > > > wrote:
> > > > > > > Hi Jonathan,
> > > > > > >
> > > > > > > Just following up on this. I have switched to the UHD 3.13 
> > > > > > > release + FPGA version 5.2. This issue still persists.
> > > > > > >
> > > > > > > Is it possible that a change to UHD could be causing this to not 
> > > > > > > work?
> > > > > > >
> > > > > > > If anyone can confirm that they are able to send commands to the 
> > > > > > > radio block from an rfnoc block in recent versions of UHD it 
> > > > > > > would help a lot.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Sam
> > > > > > >
> > > > > > > On Oct 22, 2018, 1:06 PM -0700, Samuel Prager , 
> > > > > > > wrote:
> > > > > > > > Hi Jonathan,
> > > > > > > >
> > > > > > > > Yes I add my block and the radio block, connect them and tell 
> > > > > > > > my block to send commands to radio block. I have confirmed 
> > > > > > > > today that the simulation still works correctly in Vivado 
> > > > > > > > 2017.4 — the settings registers are written as expected, an rx 
> > > > > > > > command is generated in the radio and the correct number of 
> > > > > > > > samples are streamed back into the tb_streamer.
> > > > > > > >
> > > > > > > > Sam
> > > > > > > > On Oct 21, 2018, 9:20 AM -0700, Jon Pendlum 
> > > > > > > > , wrote:
> > > > > > > > > How does your testbench work? Do you add the radio core 
> > > > > > > > > block, send timed commands to it, and see the outputs toggle?
> > > > > > > > >
> > > > > > > > > > On Sat, Oct 20, 2018 at 1:05 PM Samuel Prager 
> > > > > > > > > >  wrote:
> > > > > > > > > > > Hi Jonathon,
> > > > > > > > > > >
> > > > > > > > > > > Thanks for the response! Yes I’m using ce_clk and ce_rst. 
> > > > > > > > > > > Thanks for sharing your code — the only real difference I 
> > > > > > > > > > > see is that you increment the seq_num. I am leaving it as 
> > > > > > > > > > > 12’b0 — could this be causing an issue?
> > > > > > > > > > >
> > > > > > > > > > > I should also say that In my case, the command packets 
> > > > > > > > > > > are being sent to the radio block to trigger timed 
> > > > > > > > > > > receive commands in order to reduce the number of 
> > > > > > > > > > > software sr_writes.
> > > > > > > > > > >
> > > > > > > > > > > Here’s my code just in case: 
> > > > > > > > > > > https://pastebin.com/Asgj7Jw2.
> > > > > > > > > > >
> > > > > > > > > > > This is something that was simulated/verified and worked 
> > > > > > > > > > > in the past, but perhaps a change has been made that 
> > > > > > > > > > > prevents this from working?
> > > > > > > > > > >
> > > > > > > > > > > I will try a release tag as soon as possible — however 
> > > > > > > > > > > this is something I’ve been seeing for a couple of months 
> > > > > > > > > > > now that has

Re: [USRP-users] RFNoC block fpga control source issues

[Samuel Prager via USRP-users]

this 
> > > > > > > > from working?
> > > > > > > >
> > > > > > > > I will try a release tag as soon as possible — however this is 
> > > > > > > > something I’ve been seeing for a couple of months now that has 
> > > > > > > > kept me on pre-2017.4 releases.
> > > > > > > >
> > > > > > > > Sam
> > > > > > > > On Oct 19, 2018, 8:17 PM -0700, Jon Pendlum 
> > > > > > > > , wrote:
> > > > > > > > > Hi Sam,
> > > > > > > > >
> > > > > > > > > I am using command packets to tune the DDC block's DSP 
> > > > > > > > > frequency. Are you using ce_clk and ce_rst for clock and 
> > > > > > > > > reset? Here is my code if you want to take a look: 
> > > > > > > > > https://pastebin.com/1AeHFb0J. Also, it might be worth trying 
> > > > > > > > > your code on a release tag like v3.13.0.2 in case master has 
> > > > > > > > > a regression.
> > > > > > > > >
> > > > > > > > > Jonathon
> > > > > > > > >
> > > > > > > > > > On Sat, Oct 20, 2018 at 8:11 AM Samuel Prager via 
> > > > > > > > > > USRP-users  wrote:
> > > > > > > > > > > Hello,
> > > > > > > > > > >
> > > > > > > > > > > I have an RFNoC block that generates command packets to 
> > > > > > > > > > > write settings registers of the downstream connected 
> > > > > > > > > > > block using the Control Source (cmdout_tdata) of the 
> > > > > > > > > > > noc_shell . Previously this had worked perfectly (prior 
> > > > > > > > > > > to approximately d6b2283 on rfnoc-devel), for both the 
> > > > > > > > > > > X300 and E310, but this functionality appears to perhaps 
> > > > > > > > > > > be broken in the more recent FPGA releases — since around 
> > > > > > > > > > > the switch to Vivado 2017.4 and the move of the noc block 
> > > > > > > > > > > clock domain crossing to axi_wrapper.v). I have tried the 
> > > > > > > > > > > latest master branch (4f25ed1) with no success.
> > > > > > > > > > >
> > > > > > > > > > > Is this a known issue? Can anyone shed light on what 
> > > > > > > > > > > might have caused this?
> > > > > > > > > > >
> > > > > > > > > > > The control packets are generated in my block as follows:
> > > > > > > > > > >
> > > > > > > > > > > wire eob = 1’b0;
> > > > > > > > > > > wire [1:0] pkt_type = 2'b10;
> > > > > > > > > > > wire [11:0] seqnum = 12'd0; // don't care
> > > > > > > > > > > wire [15:0] payload_length = 16'd16; //don't care 
> > > > > > > > > > > (payload length in bytes)
> > > > > > > > > > > assign cmd_tdata = {24’d0,set_bus_addr[7:0], 
> > > > > > > > > > > set_bus_val[31:0]};
> > > > > > > > > > >
> > > > > > > > > > > cvita_hdr_encoder cvita_hdr_encoder(
> > > > > > > > > > > .pkt_type(pkt_type),.eob(eob), .has_time(1'b0),
> > > > > > > > > > > .seqnum(seqnum),
> > > > > > > > > > > .payload_length(payload_length),
> > > > > > > > > > > .src_sid(src_sid), .dst_sid(dst_sid),
> > > > > > > > > > > .vita_time(vita_time),
> > > > > > > > > > > .header(cmd_tuser)
> > > > > > > > > > > );
> > > > > > > > > > >
> > > > > > > > > > > chdr_framer #(.SIZE(FIFO_SIZE), .WIDTH(64)) chdr_framer (
> > > > > > > > > > > .clk(clk), .reset(reset), .clear(clear),
> > > > > > > > > > > .i_tdata(cmd_tdata), .i_tuser(cmd_tuser), 
> > > > > > > > > > > .i_tlast(cmd_tlast), .i_tvalid(cmd_tvalid), 
> > > > > > > > > > > .i_tready(cmd_tready),
> > > > > > > > > > > .o_tdata(cmdout_tdata), .o_tlast(cmdout_tlast), 
> > > > > > > > > > > .o_tvalid(cmdout_tvalid), .o_tready(cmdout_tready));
> > > > > > > > > > >
> > > > > > > > > > > The command packets appear to never reach the destination 
> > > > > > > > > > > rfnoc block, but I am at a loss for the cause.
> > > > > > > > > > >
> > > > > > > > > > > Is anyone currently using the control source 
> > > > > > > > > > > functionality of the noc_shell? I would really appreciate 
> > > > > > > > > > > any pointers on how to fix this.
> > > > > > > > > > >
> > > > > > > > > > > Thank you,
> > > > > > > > > > >
> > > > > > > > > > > Sam
> > > > > > > > > > >
> > > > > > > > > > > ___
> > > > > > > > > > > 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 block fpga control source issues

[Samuel Prager via USRP-users]

Hey Jonathon,

I had a chance to debug this a little further (On an N300) and have observed 
the following behavior:

The command packets are getting through to the radio block but are being 
buffered somewhere along the line so that the first command is either not 
received or not processed until exactly 16 have been sent.

So if I am sending commands in a loop, there is a 16 command delay before the 
settings bus writes and a rx command is triggered in the radio.

This seems to indicate that there is a buffer somewhere that doesn’t pass the 
commands until it is full.

Any thoughts on what the culprit could be?

Sam
On Oct 23, 2018, 11:17 PM -0700, Jon Pendlum , wrote:
> Hey Sam,
>
> There have been some changes to noc_shell, maybe they are related to your 
> issue. If you want to try to debug this on the FPGA, I suggest using 
> chipscope on the file cmd_pkt_proc.v. That is the state machine that receives 
> command packets and issues settings bus writes. You should be able to see 
> your command packets come in and get processed by the state machine. You can 
> double check the command packet / timed command vita time versus the radio 
> core's vita time. You can also see if the state machine gets stuck in a 
> certain state.
>
> Jonathon
>
> > On Wed, Oct 24, 2018 at 9:44 AM Samuel Prager  wrote:
> > > Hi Jonathan,
> > >
> > > Just following up on this. I have switched to the UHD 3.13 release + FPGA 
> > > version 5.2. This issue still persists.
> > >
> > > Is it possible that a change to UHD could be causing this to not work?
> > >
> > > If anyone can confirm that they are able to send commands to the radio 
> > > block from an rfnoc block in recent versions of UHD it would help a lot.
> > >
> > > Thanks,
> > >
> > > Sam
> > >
> > > On Oct 22, 2018, 1:06 PM -0700, Samuel Prager , wrote:
> > > > Hi Jonathan,
> > > >
> > > > Yes I add my block and the radio block, connect them and tell my block 
> > > > to send commands to radio block. I have confirmed today that the 
> > > > simulation still works correctly in Vivado 2017.4 — the settings 
> > > > registers are written as expected, an rx command is generated in the 
> > > > radio and the correct number of samples are streamed back into the 
> > > > tb_streamer.
> > > >
> > > > Sam
> > > > On Oct 21, 2018, 9:20 AM -0700, Jon Pendlum , 
> > > > wrote:
> > > > > How does your testbench work? Do you add the radio core block, send 
> > > > > timed commands to it, and see the outputs toggle?
> > > > >
> > > > > > On Sat, Oct 20, 2018 at 1:05 PM Samuel Prager  
> > > > > > wrote:
> > > > > > > Hi Jonathon,
> > > > > > >
> > > > > > > Thanks for the response! Yes I’m using ce_clk and ce_rst. Thanks 
> > > > > > > for sharing your code — the only real difference I see is that 
> > > > > > > you increment the seq_num. I am leaving it as 12’b0 — could this 
> > > > > > > be causing an issue?
> > > > > > >
> > > > > > > I should also say that In my case, the command packets are being 
> > > > > > > sent to the radio block to trigger timed receive commands in 
> > > > > > > order to reduce the number of software sr_writes.
> > > > > > >
> > > > > > > Here’s my code just in case: https://pastebin.com/Asgj7Jw2.
> > > > > > >
> > > > > > > This is something that was simulated/verified and worked in the 
> > > > > > > past, but perhaps a change has been made that prevents this from 
> > > > > > > working?
> > > > > > >
> > > > > > > I will try a release tag as soon as possible — however this is 
> > > > > > > something I’ve been seeing for a couple of months now that has 
> > > > > > > kept me on pre-2017.4 releases.
> > > > > > >
> > > > > > > Sam
> > > > > > > On Oct 19, 2018, 8:17 PM -0700, Jon Pendlum 
> > > > > > > , wrote:
> > > > > > > > Hi Sam,
> > > > > > > >
> > > > > > > > I am using command packets to tune the DDC block's DSP 
> > > > > > > > frequency. Are you using ce_clk and ce_rst for clock and reset? 
> > > > > > > > Here is my code if 

Re: [USRP-users] RFNoC block fpga control source issues

[Samuel Prager via USRP-users]

Hi Jonathan,

Just following up on this. I have switched to the UHD 3.13 release + FPGA 
version 5.2. This issue still persists.

Is it possible that a change to UHD could be causing this to not work?

If anyone can confirm that they are able to send commands to the radio block 
from an rfnoc block in recent versions of UHD it would help a lot.

Thanks,

Sam

On Oct 22, 2018, 1:06 PM -0700, Samuel Prager , wrote:
> Hi Jonathan,
>
> Yes I add my block and the radio block, connect them and tell my block to 
> send commands to radio block. I have confirmed today that the simulation 
> still works correctly in Vivado 2017.4 — the settings registers are written 
> as expected, an rx command is generated in the radio and the correct number 
> of samples are streamed back into the tb_streamer.
>
> Sam
> On Oct 21, 2018, 9:20 AM -0700, Jon Pendlum , wrote:
> > How does your testbench work? Do you add the radio core block, send timed 
> > commands to it, and see the outputs toggle?
> >
> > > On Sat, Oct 20, 2018 at 1:05 PM Samuel Prager  wrote:
> > > > Hi Jonathon,
> > > >
> > > > Thanks for the response! Yes I’m using ce_clk and ce_rst. Thanks for 
> > > > sharing your code — the only real difference I see is that you 
> > > > increment the seq_num. I am leaving it as 12’b0 — could this be causing 
> > > > an issue?
> > > >
> > > > I should also say that In my case, the command packets are being sent 
> > > > to the radio block to trigger timed receive commands in order to reduce 
> > > > the number of software sr_writes.
> > > >
> > > > Here’s my code just in case: https://pastebin.com/Asgj7Jw2.
> > > >
> > > > This is something that was simulated/verified and worked in the past, 
> > > > but perhaps a change has been made that prevents this from working?
> > > >
> > > > I will try a release tag as soon as possible — however this is 
> > > > something I’ve been seeing for a couple of months now that has kept me 
> > > > on pre-2017.4 releases.
> > > >
> > > > Sam
> > > > On Oct 19, 2018, 8:17 PM -0700, Jon Pendlum , 
> > > > wrote:
> > > > > Hi Sam,
> > > > >
> > > > > I am using command packets to tune the DDC block's DSP frequency. Are 
> > > > > you using ce_clk and ce_rst for clock and reset? Here is my code if 
> > > > > you want to take a look: https://pastebin.com/1AeHFb0J. Also, it 
> > > > > might be worth trying your code on a release tag like v3.13.0.2 in 
> > > > > case master has a regression.
> > > > >
> > > > > Jonathon
> > > > >
> > > > > > On Sat, Oct 20, 2018 at 8:11 AM Samuel Prager via USRP-users 
> > > > > >  wrote:
> > > > > > > Hello,
> > > > > > >
> > > > > > > I have an RFNoC block that generates command packets to write 
> > > > > > > settings registers of the downstream connected block using the 
> > > > > > > Control Source (cmdout_tdata) of the noc_shell . Previously this 
> > > > > > > had worked perfectly (prior to approximately d6b2283 on 
> > > > > > > rfnoc-devel), for both the X300 and E310, but this functionality 
> > > > > > > appears to perhaps be broken in the more recent FPGA releases — 
> > > > > > > since around the switch to Vivado 2017.4 and the move of the noc 
> > > > > > > block clock domain crossing to axi_wrapper.v). I have tried the 
> > > > > > > latest master branch (4f25ed1) with no success.
> > > > > > >
> > > > > > > Is this a known issue? Can anyone shed light on what might have 
> > > > > > > caused this?
> > > > > > >
> > > > > > > The control packets are generated in my block as follows:
> > > > > > >
> > > > > > > wire eob = 1’b0;
> > > > > > > wire [1:0] pkt_type = 2'b10;
> > > > > > > wire [11:0] seqnum = 12'd0; // don't care
> > > > > > > wire [15:0] payload_length = 16'd16; //don't care (payload length 
> > > > > > > in bytes)
> > > > > > > assign cmd_tdata = {24’d0,set_bus_addr[7:0], set_bus_val[31:0]};
> > > > > > >
> > > > > > > cvita_hdr_encoder cvita_hdr_encoder(
> > > > > > > .pkt_type(pkt_type),.

Re: [USRP-users] Issues with N300 - GPSDO Lock/Synchronization, Spectrum asymmetry, MPM performance and Low band phase

[Samuel Prager via USRP-users]

Hi Marcus,

Following up on this. I tried transmitting a 100mhz BW LFM chirp with the 
baseband amplitude scaled down by 1/2 to +-16384. Same behavior as before and 
consistent across all tuning frequencies and RX gains.

Here is a link to an image of the result 
(n300_chirp100mhz_halfbbgain_tx35db_vs_tx34p5db.png : 
https://drive.google.com/open?id=1ccaEVohtXDLh1r-rSNSIHcxdpoQBbkjc). Graph 1: 
TX gain = 34.5, Graph 2: TX gain = 35, Graph 3: ideal 100 MHz LFM chirp.

Regards,

Sam
On Jan 25, 2019, 3:06 PM -0800, Marcus D. Leech via USRP-users 
, wrote:
> On 01/25/2019 05:30 PM, Nate Temple via USRP-users wrote:
> > Hi Sam,
> >
> > These are all new issues that we were unaware of. I will follow up with you 
> > off list to debug these issues through your previously sent email to 
> > supp...@ettus.com.
> >
> >
> > Regards,
> > Nate Temple
> >
> Also, on the asymmetric spectrum issue, Samuel, you noted that it was fine 
> about 0.5dB below 35dB gain setting.  What happens if you
>   reduce a baseband magnitude a little bit--does this improve the dynamic 
> range of the RF gain setting control before the "weirdness"
>   happens?
>
>
> ___
> 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=VAd3mjSAxhn0YO_zt6xVvUKaifxo8PYQgP_frYvFB64=RiQEyPk8ccdy3g0Oj58T2CAQvc14m4CtK5EM4-cTK8g=
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Issues with N300 - GPSDO Lock/Synchronization, Spectrum asymmetry, MPM performance and Low band phase

[Samuel Prager via USRP-users]

Hello,

We are experiencing a number of issues with our N300s. We would like to know if 
these are known issues and whether or not they are being addressed.

We have recently updated the filesystems, FPGA images and UHD/MPM to 3.13.1 
(currently up to date with UHD 3.13.1 release, commit 711ec8a). We are using 
our N300s in embedded mode. All software/rfnoc firmware has been previously 
tested and used on X300s and E312s.

I have uploaded a few supporting images to a google drive folder. (Link: 
https://drive.google.com/drive/folders/1b1T69G7AAA2-QlIByBYp9UQ_gs8_1253?usp=sharing)


1) GPSDO Locking and Synchronization:

- The time to obtain and GPS lock, even when outside is long and often 
unstable. Code used to query GPSDO lock:

> uhd::property_tree::sptr tree = _usrp->get_tree();
> uhd::fs_path path;
> std::vector mboard_names = tree->list("/mboards");
> path = "/mboards/" + mboard_names[0];
> try {
> path = "/mboards/" + mboard_names[0];
> try {
>  tree->access(path / "sensors" / "gps_locked").get().value;
> } catch (std::exception &) {
> } catch (std::exception &) {
>  std::cerr << "Error: No response from GPSDO" << std::endl;
>  return false;
> }
> //Check for GPS lock
> uhd::sensor_value_t gps_locked = tree->access(path / "sensors" / 
> "gps_locked").get();
> return(gps_locked.to_bool());
> }

This is a printout of the N300 sensor values when GPSDO is in a non-locked 
state:
> - Sensors -
> Clock Source: gpsdo
> Time Source: gpsdo
> ref_locked: true
> gps_locked: false
> gps_time: 1548206414
> gps_tpv: {"ept": 0.0050001, "speed": 3.7042, "epv": 
> 73.594, "device": "/dev/ttyPS1", "eps": 141.210001, 
> "lon": -118.169881667, "epy": 109.009, "epx": 101.339, "alt": 
> 367.69, "lat": 34.20062666702, "class": "TPV", "epc": 92.0, 
> "track": 318.0, "time": "2019-01-23T01:20:14.000Z", "mode": 3, "climb": 
> 32.203}
> gps_sky: {"hdop": 9.3007, "class": "SKY", "device": 
> "/dev/ttyPS1", "pdop": 9.8007, "vdop": 3.2002, 
> "ydop": 7.2696, "tdop": 3.6201, "gdop": 11.09, 
> "satellites": [{"PRN": 30, "az": 53, "el": 71, "ss": 26, "used": false}, 
> {"PRN": 28, "az": 327, "el": 67, "ss": 0, "used": false}, {"PRN": 135, "az": 
> 205, "el": 47, "ss": 34, "used": false}, {"PRN": 7, "az": 101, "el": 44, 
> "ss": 33, "used": true}, {"PRN": 17, "az": 188, "el": 44, "ss": 32, "used": 
> true}, {"PRN": 13, "az": 308, "el": 38, "ss": 0, "used": false}, {"PRN": 11, 
> "az": 80, "el": 32, "ss": 34, "used": true}, {"PRN": 1, "az": 99, "el": 17, 
> "ss": 27, "used": false}, {"PRN": 19, "az": 199, "el": 17, "ss": 28, "used": 
> true}, {"PRN": 18, "az": 70, "el": 14, "ss": 28, "used": true}, {"PRN": 8, 
> "az": 39, "el": 11, "ss": 0, "used": false}, {"PRN": 9, "az": 164, "el": 10, 
> "ss": 27, "used": false}, {"PRN": 15, "az": 321, "el": 7, "ss": 0, "used": 
> false}, {"PRN": 5, "az": 255, "el": 4, "ss": 0, "used": false}], "xdop": 
> 6.7598}
> fan: 4320
> temp: 42.0

This is a printout of the N300 sensor values when GPSDO is in a locked state:

> - Sensors -
> Clock Source: gpsdo
> Time Source: gpsdo
> ref_locked: true
> gps_locked: true
> gps_time: 1548215759
> gps_tpv: {"lat": 34.200188333, "class": "TPV", "speed": 0.0, "device": 
> "/dev/ttyPS1", "epv": 112.7, "ept": 0.0050001, "alt": 
> 341.12, "mode": 3, "time": "2019-01-23T03:55:57.000Z", "climb": 
> 0.69996, "lon": -118.169401667, "epc": 225.41, 
> "track": 148.09}
> gps_sky: {"hdop": 3.2998, "class": "SKY", "satellites": [{"used": 
> false, "el": 80, "az": 318, "PRN": 19, "ss": 12}, {"used": false, "el": 58, 
> "az": 32, "PRN": 17, "ss": 13}, {"used": true, "el": 49, "az": 199, "PRN": 
> 133, "ss": 35}, {"used": false, "el": 47, "az": 205, "PRN": 135, "ss": 31}, 
> {"used": true, "el": 42, "az": 159, "PRN": 6, "ss": 31}, {"used": false, 
> "el": 36, "az": 311, "PRN": 24, "ss": 0}, {"used": true, "el": 35, "az": 75, 
> "PRN": 28, "ss": 29}, {"used": true, "el": 24, "az": 221, "PRN": 13, "ss": 
> 32}, {"used": false, "el": 19, "az": 258, "PRN": 15, "ss": 17}, {"used": 
> false, "el": 17, "az": 189, "PRN": 2, "ss": 23}, {"used": false, "el": 16, 
> "az": 146, "PRN": 30, "ss": 21}, {"used": false, "el": 8, "az": 290, "PRN": 
> 12, "ss": 15}, {"used": false, "el": 5, "az": 35, "PRN": 1, "ss": 0}], 
> "vdop": 4.9004, "device": "/dev/ttyPS1", "pdop": 
> 5.9004}
> fan: 4320
> temp: 38.0

We note that in the ‘unlocked’ state, based on the gps_sky and gps_tpv reports, 
there are actually more satellites being used for the position calculation 
(‘used’ set to ‘true’). Additionally, the signal strengths (’ss’) in general 
are as good, if not better, than those in the ‘locked’ state.

This is a consistent problem across multiple N300s. In some cases, gps_locked 
is not being 

[USRP-users] E310/E312 AD9361 Fast Tuning

[Samuel Prager via USRP-users]

Hello,

We are currently seeing frequency tuning times of >100 ms, even when re-tuning 
to within 100 MHz of the previous frequency (wherein calibrations routines 
should not be rerunning). We are looking at ways to speed this up, including 
use of fast lock profiles.


If anyone could provide pointers or share code that would be great.

Thank you,

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

Re: [USRP-users] problem with fftw_plan_dft_2d

[Samuel Prager via USRP-users]

From a cursory glance it looks like you are creating (hermetian) symmetry in 
your data with phy [whatever][whatever]

I would suggest reviewing the properties of the discrete Fourier transform.
On May 16, 2019, 9:11 PM -0700, Koyel Das (Vehere) via USRP-users 
, wrote:
> Hi Marcus,
>
> I emailed to f...@fftw.org but got no response so I thought some USRP users 
> might also be using this library and hence I may get a response. That is why.
>
> Regards,
> Koyel Das
> Senior – Product Engineer
> Vehere | Proactive Communications Intelligence & Cyber Defence
> M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: www.vehere.com
>
>
>
> Vehere is the proud recipient of the Fastest Growing Technology Company 
> Awards in India & Asia since 2012!
>
> The content of this e-mail is confidential and intended solely for the use of 
> the addressee. The text of this email (including any attachments) may contain 
> information, which is proprietary and/or confidential or privileged in nature 
> belonging to Vehere Interactive Pvt Ltd and/or its associates/ group 
> companies/ subsidiaries. If you are not the addressee, or the person 
> responsible for delivering it to the addressee, any disclosure, copying, 
> distribution or any action taken or omitted to be taken in reliance on it is 
> prohibited and may be unlawful. If you have received this e-mail in error, 
> please notify the sender and remove this communication entirely from your 
> system. The recipient acknowledges that no guarantee or any warranty is given 
> as to completeness and accuracy of the content of the email. The recipient 
> further acknowledges that the views contained in the email message are those 
> of the sender and may not necessarily reflect those of Vehere Interactive Pvt 
> Ltd. Before opening and accessing the attachment please check and scan for 
> virus. WARNING: Computer viruses can be transmitted via email. The recipient 
> should check this email and any attachments for the presence of viruses. The 
> company accepts no liability for any damage caused by any virus transmitted 
> by this email.
> From: USRP-users  on behalf of Marcus D. 
> Leech via USRP-users 
> Sent: Friday, May 17, 2019 9:27:34 AM
> To: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] problem with fftw_plan_dft_2d
>
> On 05/16/2019 11:52 PM, Koyel Das (Vehere) via USRP-users wrote:
> > Hi,
> >
> > Following is a snapshot of my code using fftw_plan_dft_2d. I am getting all 
> > zeros in the imaginary part of fft (in the printf command of the following 
> > code:last line). The real part is correct.Could you please tell where am I 
> > going wrong?
> >
> >  fftw_complex *imageOutputPlane=VDDSAlgorithm::imageOutPlane;
> >     fftw_complex *imageInputPlane=VDDSAlgorithm::imageInputPlane;
> >     unsigned char*imageData=VDDSAlgorithm::imageData;
> >     unsigned char*imageDataFinal=VDDSAlgorithm::imageDataFinal;
> >
> >     
> > memset(imageInputPlane,0x0,IMAGE_DIMENSION*IMAGE_DIMENSION*sizeof(fftw_complex));
> >     
> > memset(imageOutputPlane,0x0,IMAGE_DIMENSION*IMAGE_DIMENSION*sizeof(fftw_complex));
> >     memset(imageData,0x0,IMAGE_DIMENSION*IMAGE_DIMENSION);
> >
> >     for(size_t count=0;count >        
> > imageInputPlane[(int)round(IMAGE_DIMENSION/2+diffX[count])*IMAGE_DIMENSION+(int)round(IMAGE_DIMENSION/2-diffY[count])][0]=phy[count][0];
> >        
> > imageInputPlane[(int)round(IMAGE_DIMENSION/2+diffX[count])*IMAGE_DIMENSION+(int)round(IMAGE_DIMENSION/2-diffY[count])][1]=-(phy[count][1]);
> >        
> > imageInputPlane[(int)round(IMAGE_DIMENSION/2-diffX[count])*IMAGE_DIMENSION+(int)round(IMAGE_DIMENSION/2+diffY[count])][0]=phy[count][0];
> >        
> > imageInputPlane[(int)round(IMAGE_DIMENSION/2-diffX[count])*IMAGE_DIMENSION+(int)round(IMAGE_DIMENSION/2+diffY[count])][1]=phy[count][1];
> >     }
> >
> >     fftLock.lock();
> >     fftw_plan  planeX=fftw_plan_dft_2d(IMAGE_DIMENSION,IMAGE_DIMENSION, 
> > imageInputPlane, imageOutputPlane, FFTW_FORWARD, FFTW_ESTIMATE);
> >     fftw_execute(planeX);
> >     fftw_destroy_plan(planeX);
> >     fftLock.unlock();
> >
> >
> >     double max=0;
> >     for(size_t row=0;row >         for(size_t col=0;col >             if(col==0)printf("\n");
> >             if(col<100){
> >                 
> > printf("(%lf,%lf)",imageOutputPlane[row*IMAGE_DIMENSION+col][0],imageOutputPlane[row*IMAGE_DIMENSION+col][1]);
> >             }
> >
> >         }
> >     }
> >
> > Regards,
> > Koyel Das
> > Senior – Product Engineer
> > Vehere | Proactive Communications Intelligence & Cyber Defence
> > M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
> > www.vehere.com
> I'm having a hard time seeing how this is related to UHD and USRPs.
>
> There's probably a support forum for FFTW out there that would be more 
> helpful than here.
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> 

Re: [USRP-users] [EXT] Re: Question about the IMU (MPU-9150) on the E310

[Samuel Prager via USRP-users]

Hi Isaac,

I vaguely remember seeing this behavior on one of our e312s but it’s been a 
while. If I recall, the solution involved the RTIMULib.ini file (which should 
be created in /etc). Either the ini file was set to use the wrong SPI bus or 
the ini file was being saved in the wrong place or not at all. I would start 
there.

Sam
On Nov 18, 2019, 8:24 AM -0800, Beeman, Isaac L. , wrote:
> Hi Sam,
>
> Thanks for linking your simple example program for streaming IMU data. I 
> finally got the RTIMULib built and installed on the E312, but when I run your 
> program I get this output:
>
> root@ni-e31x-:~/usr/E312IMUTest/build# ./E312IMUTest
> Do something here with example option input: for example
> Settings file not found. Using defaults and creating settings file
> Failed to open I2C bus 1
> Failed to open SPI bus 0, select 0
> Failed to open SPI bus 0, select 1
> No IMU detected
> Using fusion algorithm RTQF
> No IMU found
> Error intializing IMU
>
> Was there any other setup I needed to do before running it (i.e. creating a 
> settings file for the radio)? Do you think using a newer version of UHD and 
> the E312 image might cause this issue?
>
> Isaac Beeman
>
> From: Samuel Prager 
> Sent: Tuesday, November 12, 2019 5:50 PM
> To: Beeman, Isaac L. ; Michael Dickens 
> 
> Cc: usrp-users@lists.ettus.com 
> Subject: [EXT] Re: [USRP-users] Question about the IMU (MPU-9150) on the E310
>
> Hi Isaac,
>
> Here is a simple example program I wrote a while back for continuously 
> streaming IMU data on the E310/E312.
>
> https://github.com/samprager/E312IMUTest
>
> See the README for RTIMULib installation instructions (the correct library is 
> https://github.com/RPi-Distro/RTIMULib).
>
> Sam
> On Nov 12, 2019, 12:30 PM -0800, Michael Dickens via USRP-users 
> , wrote:
> > Hi Isaac - UHD itself provides no API to the IMU; never has. The RTIMULib, 
> > possibly an older version than current and assuming it can be built and 
> > installed on the E310, should be able to access the IMU to provide 
> > information from it. Note "possibly", "assuming", "should" ... clearly this 
> > isn't a majorly supported feature of the E310! Good luck! - MLD
> >
> > On Tue, Nov 12, 2019 at 12:37 PM Beeman, Isaac L. via USRP-users 
> >  wrote:
> > > Marcus and List,
> > >
> > > I was hoping someone knew the steps involved to get the RTIMULib setup on 
> > > the USRP. I tried building and installing both the RTIMULib and Linux 
> > > folders, but the Linux one fails:
> > >
> > >
> > > -- Found unsuitable Qt version "" from NOTFOUND
> > > Qt QTOPENGL library not found.
> > > Qt QTGUI library not found.
> > > Qt QTCORE library not found.
> > > CMake Error at RTIMULibGL/CMakeLists.txt:90 (QT4_ADD_RESOURCES):
> > >     Unknown CMake command "QT4_ADD_RESOURCES".
> > > -- Configuring incomplete, errors occurred!
> > >
> > >
> > > I figured that I can't install the RTIMULibDemo apps because they use a 
> > > GUI, so I built and installed the RTIMULibDrive and RTIMULibCal 
> > > individually. Only, when I try to run one of these apps I get the 
> > > following error:
> > >
> > >
> > > RTIMULibDrive: error while loading shared libraries: libRTIMULib.so.7: 
> > > cannot open shared object file: No such file or directory
> > >
> > >
> > > I don't get how to fix this. When I build and install the same apps on my 
> > > host computer they run fine (but obviously can't find any IMU). 
> > > Considering that any applications I write also use the same libraries, I 
> > > feel like this is going to be an issue.
> > >
> > > There isn't any documentation that I can find on the usage of the C++ 
> > > library for RTIMULib. Just reading the code in RTIMULibDrive.cpp as an 
> > > example, it doesn't seem too complicated, but it obviously is a generic 
> > > program that isn't using the settings needed to connect to the MPU-9150.
> > >
> > > If anyone knows how to get one of these apps (RTIMULibDrive or 
> > > RTIMULibCal) working or how to use RTIMULib.h in connecting to the 
> > > MPU-9150 over I2C, it would be much appreciated.
> > >
> > > -Isaac Beeman
> > >
> > >
> > >
> > > P.S. I also tried 'i2cdetect -y 0' to see if the MPU-9150 has the I2C 
> > > address 0x69 like the schematics say, but I only get:
> > >
> > > Warning: Can't use SMBus Quick Write command, will skip some addresses
> > >      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> > > 00:
> > > 10:
> > > 20:
> > > 30: -- -- -- -- -- -- -- --
> > > 40:
> > > 50: UU UU -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > > 60:
> > > 70:
> > >
> > > with nothing under 0x69. So that's weird.
> > >
> > >
> > > -Original Message-
> > > From: USRP-users  On Behalf Of Marcus 
> > > D. Leech via USRP-users
> > > Sent: Tuesday, November 12, 2019 10:35 AM
> > > To: usrp-users@lists.ettus.com
> > > Subject: [EXT] Re: [USRP-users] Question about the IMU (MPU-9150) on the 
> > > E310
> > >
> > > On 11/12/2019 10:26 AM, Beeman, Isaac L. via USRP-users wrote:
> > > > Hi List,
> > > >
> > > > I have 

Re: [USRP-users] Question about the IMU (MPU-9150) on the E310

[Samuel Prager via USRP-users]

Hi Isaac,

Here is a simple example program I wrote a while back for continuously 
streaming IMU data on the E310/E312.

https://github.com/samprager/E312IMUTest

See the README for RTIMULib installation instructions (the correct library is 
https://github.com/RPi-Distro/RTIMULib).

Sam
On Nov 12, 2019, 12:30 PM -0800, Michael Dickens via USRP-users 
, wrote:
> Hi Isaac - UHD itself provides no API to the IMU; never has. The RTIMULib, 
> possibly an older version than current and assuming it can be built and 
> installed on the E310, should be able to access the IMU to provide 
> information from it. Note "possibly", "assuming", "should" ... clearly this 
> isn't a majorly supported feature of the E310! Good luck! - MLD
>
> > On Tue, Nov 12, 2019 at 12:37 PM Beeman, Isaac L. via USRP-users 
> >  wrote:
> > > Marcus and List,
> > >
> > > I was hoping someone knew the steps involved to get the RTIMULib setup on 
> > > the USRP. I tried building and installing both the RTIMULib and Linux 
> > > folders, but the Linux one fails:
> > >
> > >
> > > -- Found unsuitable Qt version "" from NOTFOUND
> > > Qt QTOPENGL library not found.
> > > Qt QTGUI library not found.
> > > Qt QTCORE library not found.
> > > CMake Error at RTIMULibGL/CMakeLists.txt:90 (QT4_ADD_RESOURCES):
> > >     Unknown CMake command "QT4_ADD_RESOURCES".
> > > -- Configuring incomplete, errors occurred!
> > >
> > >
> > > I figured that I can't install the RTIMULibDemo apps because they use a 
> > > GUI, so I built and installed the RTIMULibDrive and RTIMULibCal 
> > > individually. Only, when I try to run one of these apps I get the 
> > > following error:
> > >
> > >
> > > RTIMULibDrive: error while loading shared libraries: libRTIMULib.so.7: 
> > > cannot open shared object file: No such file or directory
> > >
> > >
> > > I don't get how to fix this. When I build and install the same apps on my 
> > > host computer they run fine (but obviously can't find any IMU). 
> > > Considering that any applications I write also use the same libraries, I 
> > > feel like this is going to be an issue.
> > >
> > > There isn't any documentation that I can find on the usage of the C++ 
> > > library for RTIMULib. Just reading the code in RTIMULibDrive.cpp as an 
> > > example, it doesn't seem too complicated, but it obviously is a generic 
> > > program that isn't using the settings needed to connect to the MPU-9150.
> > >
> > > If anyone knows how to get one of these apps (RTIMULibDrive or 
> > > RTIMULibCal) working or how to use RTIMULib.h in connecting to the 
> > > MPU-9150 over I2C, it would be much appreciated.
> > >
> > > -Isaac Beeman
> > >
> > >
> > >
> > > P.S. I also tried 'i2cdetect -y 0' to see if the MPU-9150 has the I2C 
> > > address 0x69 like the schematics say, but I only get:
> > >
> > > Warning: Can't use SMBus Quick Write command, will skip some addresses
> > >      0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
> > > 00:
> > > 10:
> > > 20:
> > > 30: -- -- -- -- -- -- -- --
> > > 40:
> > > 50: UU UU -- -- -- -- -- -- -- -- -- -- -- -- -- --
> > > 60:
> > > 70:
> > >
> > > with nothing under 0x69. So that's weird.
> > >
> > >
> > > -Original Message-
> > > From: USRP-users  On Behalf Of Marcus 
> > > D. Leech via USRP-users
> > > Sent: Tuesday, November 12, 2019 10:35 AM
> > > To: usrp-users@lists.ettus.com
> > > Subject: [EXT] Re: [USRP-users] Question about the IMU (MPU-9150) on the 
> > > E310
> > >
> > > On 11/12/2019 10:26 AM, Beeman, Isaac L. via USRP-users wrote:
> > > > Hi List,
> > > >
> > > > I have recently started working with the E310/E312 and have gotten 
> > > > multichannel RX/TX and GPS working, but I can't figure out how to grab 
> > > > data off of the internal IMU/MPU-9150. I found some website 
> > > > (http://gnuradio.cn/en/html/support/en/page_usrp_e3x0.html) that said 
> > > > that the USRP image should contain RTIMULib applications with allow the 
> > > > user to test the IMU, but, unless I am looking in the wrong place, the 
> > > > current image for the E310 does not have any RTIMULib applications on 
> > > > it.
> > > >
> > > > I want to know if there are any API calls or libraries that would allow 
> > > > me to do development with the IMU.
> > > >
> > > > -Isaac Beeman
> > > >
> > > > ___
> > >
> > > You might start here:
> > >
> > > https://github.com/RTIMULib
> > >
> > > ___
> > > USRP-users mailing list
> > > USRP-users@lists.ettus.com
> > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> --
> Michael Dickens
> Ettus Research Technical Support
> Email: supp...@ettus.com
> Web: https://ettus.com/
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
>