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 <mailto:rkoss...@nd.edu>> wrote:The DRAM is 2GB, I think. On Tue, Oct 30, 2018 at 10:34 AM Daniel May <danielma...@gmail.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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
