Is there a way to query the amount of data in the FIFO so that I can wait until it clears?
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 list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
