[time-nuts] GPS message jitter (preliminary results)
Tom Van Baak
tvb at LeapSecond.com
Thu Jul 21 12:10:03 EDT 2016
> 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...
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.
More information about the time-nuts