Hi Mark,

As one example of what you'll see, scroll down to the NMEA Latency/Jitter plot at:
http://leapsecond.com/pages/MG1613S/

In that 900 sample (15 minutes) run, the mean latency was 350.2 ms with a standard deviation (jitter) of 10.7 ms. I'll dig out some other data I may have. It will be quite different depending on receiver make/model.

For this plot I made TIC measurements between the leading edge of the 1PPS and the leading edge of the start bit of the first byte of the first NMEA sentence.

BTW, on Windows use QueryPerformanceCounter if you want granularity-free millisecond or even microsecond time interval resolution.

/tvb

----- Original Message -----
From: "Mark Sims" holrum@hotmail.com
To: time-nuts@febo.com
Sent: Saturday, July 16, 2016 12:13 PM
Subject: [time-nuts] GPS message jitter (was GPS for Nixie Clock)

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.

On Sat, Jul 16, 2016 at 3:13 PM, Mark Sims holrum@hotmail.com wrote:

Hi

….. 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

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@blueyonder.co.uk> wrote:

On 7/18/16 8:51 AM, Scott Stobbe wrote:

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
sheet.
( 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.

On Mon, 18 Jul 2016 11:43:32 -0700, you wrote:

Long ago I remember seeing a circuit design or application note using
an 8250 or similar where the UART start bit was gated so that the
leading edge could be used for precision synchronization.

Well, I suppose in the case of USB, the host hardware (consumer PC) is not
going to have any special hardware. But, if a gps receiver implements a USB
interface, in addition to standard NEMA data, it could also report the
phase and frequency error of your USB clock (since it has to recover it
anyways to get the usb data).

I don't have the answer here, but usb-audio ICs suffer similar problems in
clock distribution. The gist of it seems to be locking on the hosts SOF
packets. PROGRAMMABLE CLOCK GENERATION AND SYNCHRONIZATION FOR USB AUDIO
SYSTEMS http://www.cypress.com/file/122521/download

On Mon, Jul 18, 2016 at 2:43 PM, jimlux jimlux@earthlink.net wrote: