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 12AD100000000000. 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 <usrp-users@lists.ettus.com>, 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) <samuel.m.pra...@jpl.nasa.gov> > 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 > <usrp-users@lists.ettus.com> 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 > > > > _______________________________________________ > > 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
