The delay is from the time it takes to drain the DMA FIFO. The DMA FIFO default size is 32 MB. It can be controlled through the property tree or, if using RFNoC, through the DMA FIFO block control. The time to drain is a simple function of size and sample rate.
We have been making improvements in the clearing/flushing during initialization, but there may still be some bugs to work out. Regards, Michael On Tue, Oct 30, 2018 at 8:36 AM Daniel May via USRP-users < usrp-users@lists.ettus.com> wrote: > Marcus, > > Thanks for the info. Waiting is what we do now, but it's not ideal. > > The "skip_dram=1"argument fixes the issue for low sample rates, but causes > underflows for higher sample rates, as expected. > > Thanks, > Daniel > > > > On Tue, Oct 30, 2018 at 10:25 AM Marcus D. Leech via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> On 10/30/2018 10:42 AM, Daniel May via USRP-users wrote: >> >> Is there a way to query the amount of data in the FIFO so that I can wait >> until it clears? >> >> I don't believe so. >> >> You could simply wait an amount of time, based on empirical data, that is >> commensurate with your sample rate. >> >> But the whole "the next run causes fatal errors" thing does need to be >> investigated, I agree. >> >> >> >> On Tue, Oct 30, 2018 at 9:37 AM Rob Kossler <rkoss...@nd.edu> wrote: >> >>> The DRAM is 2GB, I think. >>> >>> On Tue, Oct 30, 2018 at 10:34 AM Daniel May <danielma...@gmail.com> >>> wrote: >>> >>>> Thanks, I'll give that a try. I thought it might be the FIFO clearing, >>>> but it takes longer than I would expect. There's only 512kB of FIFO, >>>> correct? It takes up to several seconds to finish at a 1 Msps rate. >>>> >>>> Restarting the radio before Tx completes causes the radio to enter an >>>> unrecoverable error state. This is a UHD or Firmware bug, correct? >>>> >>>> Thanks, >>>> Daniel >>>> >>>> On Tue, Oct 30, 2018 at 9:12 AM Rob Kossler <rkoss...@nd.edu> wrote: >>>> >>>>> It sounds like the DMA FIFO is just emptying out. For fast sample >>>>> rates, the FIFO empties quickly, but for slow sample rates, it empties >>>>> slowly. Perhaps you could supply the arg "skip_dram=1" so that the >>>>> streaming goes directly to the DUC rather than through the FIFO. This >>>>> will >>>>> probably work fine for slow sample rates (i.e., perhaps a FIFO is not >>>>> needed for such rates). >>>>> Rob >>>>> >>>>> On Mon, Oct 29, 2018 at 4:17 PM Daniel May via USRP-users < >>>>> usrp-users@lists.ettus.com> wrote: >>>>> >>>>>> All, >>>>>> >>>>>> Can anyone else reproduce this issue and/or suggest a solution? >>>>>> >>>>>> This is happening over the Ethernet interface as well. Application >>>>>> exits, Tx light stays on, relaunching application causes X310 to enter an >>>>>> unrecoverable state and requires power cycling. It looks like an issue >>>>>> with >>>>>> initializing DMA. Tested using v3.13.0.1. >>>>>> >>>>>> Thanks, >>>>>> Daniel >>>>>> >>>>>> On Wed, Oct 10, 2018 at 10:55 AM Andrew Toomey via USRP-users < >>>>>> usrp-users@lists.ettus.com> wrote: >>>>>> >>>>>>> All, >>>>>>> >>>>>>> >>>>>>> >>>>>>> I am using an Ettus x310 over PCIe and am noticing that there is a >>>>>>> delay from when my program finished sending to the radio and when the >>>>>>> radio >>>>>>> tells me that transmission as ended ( the red Tx light turning off). >>>>>>> >>>>>>> As I bump up the sample rate I notice this delay decreases until it >>>>>>> is nonexistent. Is this intended behavior or have I done something >>>>>>> wrong in >>>>>>> my tests? The procedure to test this is listed below: >>>>>>> >>>>>>> >>>>>>> >>>>>>> 1. Download a copy of the official UHD example scripts from >>>>>>> https://github.com/EttusResearch/uhd/tree/master/host/examples >>>>>>> >>>>>>> 2. Ensure that UHD is installed correctly on your testing >>>>>>> device and build the example programs above >>>>>>> >>>>>>> 3. Run the following command “ ./tx_waveforms - -rate=1000000 >>>>>>> - -freq=1500000000 >>>>>>> >>>>>>> 4. Stop the program at any time (how long the radio is >>>>>>> running does not affect the delay) >>>>>>> >>>>>>> 5. Observe the radio and notice that the red light under the >>>>>>> Tx/Rx port is still lit on the RF A channel >>>>>>> >>>>>>> 6. If you start another transmission while the light is still >>>>>>> red, the console output contains hundreds of thousands of L’s and the >>>>>>> radio >>>>>>> will not receive data until the USRP object is recreated. >>>>>>> >>>>>>> >>>>>>> >>>>>>> I am also curious if there is a hard stop functionality for this >>>>>>> radio. All the examples I have seen send an End of Burst packet but is >>>>>>> there a way to completely halt the radio without doing this? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks for the help! >>>>>>> >>>>>>> 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 >>>>>> >>>>> >> >> _______________________________________________ >> 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 >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
