Hi Devin, If you have some grace time to play with upon getting a reset condition, you could let the queued TX burst(s) finish before proceeding with your reset logic. After you’ve provided a packet to tx_streamer->send() where end_of_burst=true, the radio provides an acknowledgement after the burst has been processed. You can wait for this by calling tx_streamer->recv_async_msg() with a suitable timeout and look for event code EVENT_CODE_BURST_ACK. If you are using multiple transmit channels, I believe you should expect an ACK for each one. With this approach you may need to read and account for ACKs for each burst.
My use case is different, but I have an application that reuses a tx_streamer object for different transmissions, and this approach has worked for me to ensure the sample tail isn’t stuck in a queue between uses. Hope this helps, David From: Devin Kelly <dwwke...@gmail.com> Sent: Monday, September 25, 2023 10:49 AM To: Rob Kossler <rkoss...@nd.edu> Cc: Marcus D. Leech <patchvonbr...@gmail.com>; usrp-users@lists.ettus.com Subject: [USRP-users] Re: TX Streamer Send Time Marcus, Rob, Thanks for the replies. We’ve built an application that we want to run for a brief amount of time (say 5-30 minutes) and then “reset” and run again (or a slightly different configuration). The reset can come at any time though, so it’s important to be able to stop and then start over again with 10-15 seconds. We also might need to stop, wait a few hours and start up again. My thinking was to that when we run the application a second time I want the USRP and all my code to be in the same state as the first time. So I was setting the clock back to 0, among other things. However, that’s when I found this problem where there would be stale bursts on my queue. Sometimes they would sit in the queue for minutes, delaying the rest of the test. I think what I’ll do now is query the current USRP time and use that for each test. Are there any other strategies I should be considering? Thanks! Devin On Mon, Sep 25, 2023 at 10:12 AM Rob Kossler via USRP-users <usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote: On Mon, Sep 25, 2023 at 9:26 AM Marcus D. Leech <patchvonbr...@gmail.com<mailto:patchvonbr...@gmail.com>> wrote: On 25/09/2023 08:57, Devin Kelly wrote: Hello, I have an application where I’m sending many short bursts to a USRP B210 using uhd::tx_streamer.send() (link below) and I occasionally set the PPS time to 0 using set_time_last_pps. Sometimes I set the PPS time to 0 when there’s still a burst in the USRPs queue. When I do this the burst is transmitted much later than I want. Is there a way to clear the queue on the USRP or UHD? That is, if I send a TX burst in the distant future can I cancel it before it gets transmitted? Can I clear everything in the TX queue? I’ve read on this list that calling the stream destructor will do this, is that right? I’ve tried this without success. Thanks! Devin This is an unusual scenario -- what is the reason for constantly resetting the timer to zero? This is not the kind of scenario that was contemplated in the architecture. I don't think there's a "flush pending things in the queue" operation possible--although I admit it might be useful. Like Marcus, I don't know of a way to flush the stream. But, I do want to add my two cents of the utility of such a capability. In many cases, samples get "stuck" in RFNoC blocks. There are a variety of reasons such as the timing reason that is the cause of this post, badly written custom RFNoC blocks (my specialty), and blocks such as FFT that can get a partial vector of samples in the queue. In any case, it is not uncommon to need to power cycle the device for the simple reason of clearing samples out of the queue of one block or another. It seems that there could be an "agreed upon RFNoC standard for 'clear'" or something similar such that a block would be expected to clear its queues (in a similar manner to the way in which an RFNoC block is supposed to respect the 'reset' signal). Rob _______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> To unsubscribe send an email to usrp-users-le...@lists.ettus.com<mailto:usrp-users-le...@lists.ettus.com> _______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> To unsubscribe send an email to usrp-users-le...@lists.ettus.com<mailto:usrp-users-le...@lists.ettus.com>
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
