Pretty much what the title says, our goal is to sync the timestamps to the rising edge of the 1PPS signal such that they get reset exactly on the rising edge of the 1pps signal, and increment the count of a custom metadata tag, to the outgoing stream to the UHD application that we are working on.

anant.tripathi@technosci.com wrote: > Pretty much what the title says, our goal is to sync the timestamps to the rising edge of the 1PPS signal such that they get reset exactly on the rising edge of the 1pps signal, and increment the count of a custom metadata tag, to the outgoing stream to the UHD application that we are working on. --- Hey,\ \ If you are using the existing PPS in port, [there are already existing functions that can set the timestamps to an arbitrary value on the next PPS edge.](https://uhd.readthedocs.io/en/latest/classuhd_1_1rfnoc_1_1mb__controller_1_1timekeeper.html#a7a33e5c85c32cfb8c23937eb29b51a84)\ \ Since you did not specify which USRP device you are using I am just going to give the general approach.\ \ Via RFNoC Python API you should be able to access these via the timekeeper on the motherboard:\ \ `graph = uhd.rfnoc.RfnocGraph("addr=<Address of your device>") # Set pps source to external here if you need it, depending on device this would be the time_source=external argument.` `tk = graph.get_mb_controller().get_timekeeper(0) # Some devices have more then one timekeeper, using 0 as default.` `tk.set_ticks_next_pps(0) # Sets timestamp counter to 0 on next pps edge, you can also set it to an arbitrary value here.` \ Regarding getting GPIO access from within your custom RFNoC block, that is dependent on the device you have, and can be a little bit more complicated. Hope this helps a little. Regards, \ Niels

If you are looking to get the radio time and the 1PPS into your block using the icores yaml definitions, then check the timekeeper and pps broadcast-listener here: https://github.com/EttusResearch/uhd/blob/c354764c93b49c90be08958f942b9bcb7704cbd5/host/include/uhd/rfnoc/core/io_signatures.yml Then check the BSP files in that same path for the BSP connection name. You'll need to make some BSP connections like: - { srcblk: _device_, srcport: pps0, dstblk: yourblock, dstport: pps } - { srcblk: _device_, srcport: time0, dstblk: yourblock, dstport: time } That should give you the 64-bit time and the 1PPS. Good luck. Brian On Fri, Jun 13, 2025 at 6:12 AM <anant.tripathi@technosci.com> wrote: > Pretty much what the title says, our goal is to sync the timestamps to the > rising edge of the 1PPS signal such that they get reset exactly on the > rising edge of the 1pps signal, and increment the count of a custom > metadata tag, to the outgoing stream to the UHD application that we are > working on. > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-leave@lists.ettus.com >

Sorry, I misread your question as PPS via GPIO instead of GPSDO as you specified.\ \ As mentioned in my code example you can set the time_source to gpsdo instead of external I am not sure if you can get access to the actual internal PPS rising edge coming from GPSDO, but what you might be able to do is add the timestamp clock as an input to your custom block and then using the tickrate estimate the 1 second intervals starting from the point when after you reset the timekeeper ticks.\ This of course would be susceptible to clock drift, so if you need the high accuracy of the GPSDO within your metadata counter than this might not be the way to go.

If you really need the PPS/timestamp, this is the right answer, but 4/5 times when users ask for access to PPS/time, they don't really need, so make sure you're in the right category. Does your block also consume data with timestamps? Then you probably don't want this. If you're tracking some real (wall clock) time, then you likely do. --M On Fri, Jun 13, 2025 at 3:21 PM Brian Padalino <bpadalino@gmail.com> wrote: > If you are looking to get the radio time and the 1PPS into your block > using the icores yaml definitions, then check the timekeeper and pps > broadcast-listener here: > > > https://github.com/EttusResearch/uhd/blob/c354764c93b49c90be08958f942b9bcb7704cbd5/host/include/uhd/rfnoc/core/io_signatures.yml > > Then check the BSP files in that same path for the BSP connection name. > > You'll need to make some BSP connections like: > > - { srcblk: _device_, srcport: pps0, dstblk: yourblock, dstport: pps } > - { srcblk: _device_, srcport: time0, dstblk: yourblock, dstport: time } > > That should give you the 64-bit time and the 1PPS. > > Good luck. > > Brian > > On Fri, Jun 13, 2025 at 6:12 AM <anant.tripathi@technosci.com> wrote: > >> Pretty much what the title says, our goal is to sync the timestamps to >> the rising edge of the 1PPS signal such that they get reset exactly on the >> rising edge of the 1pps signal, and increment the count of a custom >> metadata tag, to the outgoing stream to the UHD application that we are >> working on. >> _______________________________________________ >> USRP-users mailing list -- usrp-users@lists.ettus.com >> To unsubscribe send an email to usrp-users-leave@lists.ettus.com >> > _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-leave@lists.ettus.com >

Thanks a ton for the replies!! I guess I don’t need the 1PPS directly.\ \ I do have some other questions for RFNOC blocks and software configurability, I’ll create a separate thread for that.