> 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 _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
