[time-nuts] GPS message jitter (was GPS for Nixie Clock)
scott.j.stobbe at gmail.com
Mon Jul 18 13:44:20 EDT 2016
I am happy to hear you issue was resolved. What I meant to say is the
problem could also be mitigated using the UART's flow control, this could
be done by the original GPS designers or by an end user if the CTS line is
pined out. Gating the UART with a conservative delay, say 500 ms from the
time mark or PPS signal. The serial string would just sit in the transmit
buffer until the fixed delay expires and the UART starts transmitting.
On Mon, Jul 18, 2016 at 12:19 PM, David J Taylor <
david-taylor at blueyonder.co.uk> 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.
> You're right about the design priorities (and we have had to take Garmin
> to task on this, but they did fix the problem), but it's not the UART which
> is the major problem, but that the tiny CPU inside is taking a variable
> amount of time to have the serial data ready. We're talking tens, possibly
> hundreds of milliseconds peak-to-peak jitter.
> SatSignal Software - Quality software written to your requirements
> Web: http://www.satsignal.eu
> Email: david-taylor at blueyonder.co.uk
> Twitter: @gm8arv
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> and follow the instructions there.
More information about the time-nuts