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
