Hello, Just replying to see if there are any updates on this issue. Thanks, Sam On Jun 6, 2017, 5:22 PM -0700, Prager, Samuel M (334E) <samuel.m.prager@jpl.nasa.gov>, wrote: > > Hi Jonathon, > > > > > > Thanks for the response. > > > > > > Issue 1) > > > When you receive a pulse, are you only calling recv() or are you doing anything else? This looks like UHD expected the response packet to have a sequence number of 0, but the radio replied with a sequence number of 890. This could happen if the radio block got reset. You said this code works fine when running on the X300 though right? > > > > > > > > > Yes, I am only calling recv() when receiving a pulse. The only time I call usrp->clear() is when the blocks are initially connected. Yes, this code works on the X300. > > > > > > Additionally, if I do not attempt any settings reg reads, but instead immediately call recv() a second time, I receive a few hundred samples before getting a timeout due to drops. For each successive pulse, I am using the same rx_stream object (persistent and created in the program initialization with rx_stream = _usrp->get_rx_stream(stream_args); ). I assume that this isn’t an issue. > > > > > > Issue 2) > > > Can you do an external loopback with something simple like a tone? The AD9361 is a fairly complicated device and starting off with a simpler test case might give us a better clue. > > > > > > I will try a simple tone if this problem persists after my first issue is resolved. In the mean-time, do you have any estimate of what the signal delay time is for a signal to propagate through the rx and tx frontend? I know that this is complicated and will change with freq, bw, etc but if you have a ballpark estimate, that would be helpful. On the x300, I recall the signal propagation delay through external loopback was ~512 ticks @ 200 mhz. > > > > > > > > > > > > > > > From: Samuel Prager [mailto:sprager@usc.edu] > Sent: Tuesday, June 06, 2017 9:58 AM > To: Prager, Samuel M (334E) <samuel.m.prager@jpl.nasa.gov> > Subject: Fwd: Re: [USRP-users] E310 Rfnoc clocking guidelines/ performance issues > > > > > > > > > > > > > ---------- Forwarded message ---------- > From: Jonathon Pendlum <jonathon.pendlum@ettus.com (mailto:jonathon.pendlum@ettus.com)> > Date: May 18, 2017, 10:28 AM -0700 > To: Samuel Prager <sprager@usc.edu (mailto:sprager@usc.edu)> > Cc: Ryan Marlow via USRP-users <usrp-users@lists.ettus.com (mailto:usrp-users@lists.ettus.com)> > Subject: Re: [USRP-users] E310 Rfnoc clocking guidelines/ performance issues > > > > > > > > Hi Sam, > > > > > > > > > > > > > > > > > > Issue 1) > > > > > > When I run the application, rfnoc appears to initialize correctly and I can sr_read sr_write. However, after receiving one pulse (4096 samples), I begin to see errors similar to: > > > > > > Error: EnvironmentError: IOError: 0/Radio_0 user_reg_read64() failed: EnvironmentError: IOError: [0/Radio_0] sr_read64() failed: EnvironmentError: IOError: Block ctrl (CE_00_Port_10) packet parse error - EnvironmentError: IOError: Expected packet index: 0 Received index: 890 > > > > > > If I do not read/write any FPGA registers before sending another pulse, I see timeouts after a few thousand samples have been received. > > > > > > I have tried changing the rate (as low as 1 MHz) and increasing the wait time between pulses – neither has any effect. After the first pulse, the usrp starts to freeze up. I have also tried adding a FIFO block between the Radio RX and host with no improvement. > > > > > > > > > > > > > > > > > When you receive a pulse, are you only calling recv() or are you doing anything else? This looks like UHD expected the response packet to have a sequence number of 0, but the radio replied with a sequence number of 890. This could happen if the radio block got reset. You said this code works fine when running on the X300 though right? > > > > > > > > > > > > > > > > > > Issue 2) > > > > > > The data I am receiving in the analog loopback configuration is essentially junk. However, if I set the ‘loopback’ register in the radio_core (SR_LOOPBACK = 132), I receive the exact samples that are being send by the AWG with the correct time coherence, etc. So the tx samples going out of the radio_core appear to be correct. > > > > > > > > > > > > > > > > > Can you do an external loopback with something simple like a tone? The AD9361 is a fairly complicated device and starting off with a simpler test case might give us a better clue. > > > > > > > > > > > > > > > > > > Questions: > > > > > > Are there additional uhd calls needed to setup the E310 RF frontend beyond what is necessary for the X300? > > > > > > > > > > > > > > > > > Not that I'm aware of. > > > > > > > > > > > > > > > > > > I am sort of scratching my head here because I have been using noc_block on the X300 successfully for a while and the E310 fpga image I built met timing, etc. > > > > > > Are there any obvious culprits for this sort of behavior? My noc_block uses a timekeeper (and the sync_in and pps signals on the X300). On the E310, however there is no sync_in signal and the pps generation is different. Could this be the source of the issues that I am seeing? > > > > > > > > > > > > > > > > > I wouldn't completely rule it out, but I doubt it. Have you tried sending the pulse immediately / ignoring the timekeeper? > > > > > > > > > > > > > > > > > > What is the proper way to set the gpsdo as the time and clock source for a device3 based usrp? Is there anything analogous to what is used for multi_usrp in the sync_to_gps.cpp example? > > > > > > > > > > > > > > > > > I believe we expose what you need in the radio block controller (radio_ctrl_impl.cpp). Take a look at https://github.com/EttusResearch/uhd/blob/rfnoc-devel/host/examples/rfnoc_rx_to_file.cpp (https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_EttusResearch_uhd_blob_rfnoc-2Ddevel_host_examples_rfnoc-5Frx-5Fto-5Ffile.cpp&d=DwMFaQ&c=clK7kQUTWtAVEOVIgvi0NU5BOUHhpN0H8p7CSfnc_gI&r=opIuWAKmywF059tAs2i3Pg&m=IWOx0Sf14MtR13I1-3EQGbqNozqYYSVIBwXsk5J5trE&s=2v9R6qJ7n2WxD0Iebu7ojXhkAS12red_2SKJaGwsfnQ&e=) > > > > > > > > > > > > > > > > > > And lastly, is it possible to use a dma_fifo block directly on the E310? Or does custom firmware have to be written in order to use the dram memory on board? > > > > > > > > > > > > > > > > > The DmaFIFO block would be compatible, but you need to generate a MIG with an AXI4 interface. Luckily, we already have IP for the MIG that is built when you run the 'E310_dram_test' make target. You could try starting with that. > > > > > > > > > > > > > > > > > > >