Thinking about this, I can do the hardware reset, but that’s the least of what needs to happen.
Just having the receive timestamp go to zero on a PPS doesn’t mean the high level software can tell what sample the PPS occurred on. The software only gets the timestamp once per readStream - you wouldn’t know the clock was zeroed until you noticed the next buffer’s timestamp wasn’t what you expected.
You could work it backward and figure out what sample the PPS occurred on, but that would be a pain. Also, I don’t know what error checking occurs in the driver - will it spot a suddenly changed timestamp? Will it care?
I’m willing, but a real PPS sync capability is going to take some thought.
For now, here’s a kludge that would probably work: run the PPS (yes, the pulse) into the second receive channel. Try through a 20 or 30 dB attenuator at first.
You will see something in the receiver on the rising edge of the PPS - how much, and at what frequency, depends on the risetime of the pulse. That will let you correlate PPS to sample number, which should do for the originally stated application.
In the meantime, should we perhaps start a PPS hack thread?