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
