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<mailto: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<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
