[time-nuts] GPS message jitter (was GPS for Nixie Clock)
jimlux at earthlink.net
Mon Jul 18 14:43:32 EDT 2016
On 7/18/16 8:51 AM, Scott Stobbe wrote:
> I suppose it is one of those cases where, the GPS designers decided you
> shouldn't ever use the serial data for sub-second timing, and consequently
> spent no effort on serial latency and jitter.
> Most UARTs I have come across have been synthesized with a 16x baud clock
> and included flow control. It would not have been too much effort to spec
> latency as some mu ±100 ns and jitter of ±1/(16*baud).
> For 9600 baud, the jitter on the start bit would be ±6.5 us.
> If CTS was resampled a 1 full bit time (9600 baud), the jitter would
> be ±104 us.
except that virtually every UART in use today has some sort of buffering
(whether a FIFO or double buffering) between the CPU interface and the
bits on the wire, which completely desynchronizes the bits on the wire
from the CPU interface.
Determinism in UART timing between the CPU bus interface and the "bits
on the wire" has never been something that is specified. You can go
back to venerable parts like the 8251, and there's no spec in the data
( there's a tCR specified as 16 tCY for the read setup time from CTS*,
DSR* to READ* assert. And tSRX (2 usec min) and tHRX (2 usec min) for
the setup and hold of the internal sampling pulse relative to RxD. And
20 tCY as a max from center of stop bit to RxRDY, and then whatever the
delay is from the internal RxRDY to the bus read)
There's "what we observed in a running circuit" or "what we inferred
from knowing the internal design".
Since a huge number of serial ports these days are implemented with a
USB interface, the timing uncertainty is even greater, because you're
dealing with the 8kHz frame timing on USB.
This is why PTP compatible interfaces added time tagging to the PHY layer.
More information about the time-nuts