Yes, I believe you will need to ensure monotonically increasing times in the Radio command queue. Since we have a multi-threaded application, we cheated and simply inserted a "delay" in the thread that sets the GPIO pulse in order to ensure that the command entered the queue after all of the streaming commands. Rob
On Thu, Sep 21, 2023 at 5:06 PM David Raeman <da...@synopticengineering.com> wrote: > Hi Rob, > > Thanks for the pointer, I hadn’t considered trying set_gpio_attr() with a > command time. I will experiment with this approach.. > > > > My only minor hesitation is that my software also does other interactions > with the radio during transmission (specifically, updating registers in > other RFNoC blocks), and it’s unclear to me whether those pokes could get > blocked in a queue behind a timed command. Assuming so, I might be able to > sequence interactions to avoid that case. > > > > Thanks again, > > -David > > > > > > *From:* Rob Kossler <rkoss...@nd.edu> > *Sent:* Thursday, September 21, 2023 4:26 PM > *To:* David Raeman <da...@synopticengineering.com> > *Cc:* usrp-users@lists.ettus.com > *Subject:* Re: [USRP-users] Toggling a panel GPIO at a specific time (via > RFNoC or otherwise) > > > > Hi David, > > It may be the case that this functionality already exists in the radio > block such that you don't need a custom block. The function > radio_control->set_gpio_attr() respects the command time. Here is a > portion of one of my applications that outputs a gpio pulse after a > specified delay relative to the streaming 'start_time'. Would this work > for your case? > > Rob > > > > uhd::time_spec_t gpio_on = start_time + gpio_start; > this->set_command_time(gpio_on, gpio_mb); > this->set_gpio_attr(gpio_pulse_bank, "OUT", -1, gpio_mask, gpio_mb); > this->set_command_time(gpio_on + gpio_duration, gpio_mb); > this->set_gpio_attr(gpio_pulse_bank, "OUT", 0, gpio_mask, gpio_mb); > this->clear_command_time(gpio_mb); > > > > On Thu, Sep 21, 2023 at 4:01 PM David Raeman < > da...@synopticengineering.com> wrote: > > Hello, > > > > I'm looking for advice on toggling an E320 GPIO pin at a specific > uhd::time_spec_t. My use case is a UHD application that starts a long > transmit burst at a known timespec, then later toggles a pin at a time > corresponding to the Nth sample being transmitted. The pin controls an > external RF switch. I recognize there will be some amount of group delay > through the RFIC and internal analog components – my goal is just to be > roughly synchronous with samples clocked out of the radio block. > > > > As a first pass, I have a custom RFNoC block that counts valid samples > from the start of burst and toggles the pin after the Nth sample (where N > is provided in a user register). This is a poor solution because there is > deep buffering downstream in the radio block, so my block sees “sample N" > and toggles the pin several thousand sample-periods before it's > transmitted. It isn’t a fixed lag that can be added as a constant – > consider that if N is small and “sample N” is observed when the FIFO is > initially being filled, the toggle would occur while the corresponding > sample is sitting in the back-pressured FIFO waiting for the transmit start > time. > > > > Since this is synchronous manipulation of external state, and not just > samples, I don’t believe it will be sufficient to use CHDR header > timestamps – the block would also need to know current radio_time, and I’m > not sure how to get that in an RFNoC block.. > > > > Just wondering if I might be overlooking some simpler approach, or any > advice on how to plumb this into a custom RFNoC block. > > > > Thank you, > > -David > > > > _______________________________________________ > 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
