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
