A GNSS timestamp is not the event time

A 1-PPS edge tells the payload when a second begins, to whatever accuracy the receiver provides. It does not know that the event it is about to timestamp took time to get there: the detector responds, the amplifier has latency, the comparator has propagation delay, the cable has delay, the capture and the firmware each add their own. All of that sits between the interaction in the crystal and the number that gets written down, and a perfectly disciplined clock records it faithfully as part of the event time.

I wrote latency calibration as a separate requirement from synchronisation. Amplifier, comparator, cable and firmware latency are each to be measured, and corrected timestamps then have to meet the timing requirement. The distinction that matters is between a fixed delay and its variation: a fixed delay can be measured once and subtracted, and stops being an error; variation cannot be subtracted, because there is no single number to subtract.

The method is a split pulse — one pulse sent to both the payload and reference timing equipment, so the difference between the two records is the payload's own delay. Synchronisation is to be verified separately against a GNSS-disciplined reference, against the 10 microsecond absolute requirement.

That variation is also the reason the capture has to be in hardware. A software interrupt responds after a delay that depends on what the processor happened to be doing, which is not a fixed number and therefore cannot be calibrated away. The 1 microsecond electronic-timing-variation requirement is what forces the comparator onto a timer-capture input.

Route the comparator output to a hardware timer-capture input — item 4 on the Rev B list — and then measure every delay in the chain. A delay that has not been measured is an error that cannot be removed.