[time-nuts] GPS message jitter (preliminary results)

[Tom Van Baak]

> On another note,  I did some jitter measurements on  Jupiter-T and Jupiter-T Pico receivers.
> I can't imagine how they do it, but those things are insanely good.   Running at 9600 baud,
> their message jitter into a hardware serial port is less than a millisecond peak-peak!
> Somebody paid a LOT of attention to getting the message timing consistent...

Mark,

Here's another data point for all you modern serial oversampling UART jitter people --

The cute little 8-pin 12F675 PIC's that I use for my picPET and picDIV projects don't even have a UART. So all RS232/TTL serial output or input is done with bit-banging in assembly code. You may laugh at that. But one advantage is that serial processing is accurate down to 1 cycle. That is, you can output the start bit on the exact cycle you want. And for input, you can timestamp the start bit down to 1 cycle.

I agree this approach has limited appeal these days, but my point is that old-style bit-banging serial IO does have certain time nut advantages. You can effectively treat serial IO like IRIG; that is, both the alignment of the start bits (clock edges) and the content of the bytes (ascii data) are used to transfer the time.

Again, this is why I can make sub-us measurements of NMEA jitter by just using a picPET. The start bit of the first byte of the first NMEA sentence is an edge and the picPET happily converts it to a precise UTC timestamp.

/tvb