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> wrote: > > > On Mon, Sep 25, 2023 at 9:26 AM Marcus D. Leech <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 >> To unsubscribe send an email to 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 >
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
