[time-nuts] GPS message jitter (was GPS for Nixie Clock)

Bob Camp kb8tq at n1k.org
Mon Jul 18 17:40:45 UTC 2016


Hi

> On 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.
> ==============================
> 
> Scott,
> 
> 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.


….. but …. 

It’s been a long time since 9600 baud was a fast baud rate. It is pretty common these
days to run at 115K baud on something like this. Indeed a number of GPS modules will only
run at that speed or faster if you want the full feature set to work. Most modern modules 
will run much faster than 115K if you want them to. The simple fact that they need the higher
baud rate to get all the data out forces a better serial i/o approach in a modern module. 

In order for sawtooth correction to work, the relation of the serial message to the pps
needs to be pretty well defined. It either is talking about the *next* pps or about the
*prior* pps edge. If it is ambiguous relative to the pps, you can not be sure of what it
is relating to. 

If the module has a pps out and has sawtooth correction (or uses the same code base
as one that does), the serial timing string is not going to be all over the place. They no 
longer are running itty bitty CPU’s in these things. ARM’s running at >= 400 MHz
are the typical approach these days.  Running out of clock cycles to get it all
done went away at least 5 years ago and more like 10 years for the “usual suspects” that
you see in timing applications. 

Can you still find a 20 or 30 year old module on eBay that has issues? Sure you can. It’s
not what I would call a modern part, even if it is being sold as “new in box”. Can you find
modules that simply do not keep time at all? Sure you can. That’s not the serial port’s fault. 
It’s the fact that that specific module is broke. Don’t use that one, move on. 

Bob

> 
> Cheers,
> David
> -- 
> 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 https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.




More information about the Time-nuts_lists.febo.com mailing list