I added the ability of Lady Heather to calculate the time offset of the timing message from "wall clock" time. It calculates the difference between the system clock time to the time that the (end of) the timing message arrived. The result is only as good as your system clock, so the system clock really needs to be synced to something like NTP (otherwise it does a decent job of showing how much your system clock is drifting). Heather can plot the results and calculate xDEVs on both the message jitter and the message offset time in real time. 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...

HI > On Jul 20, 2016, at 7:51 PM, Mark Sims <holrum@hotmail.com> wrote: > > I added the ability of Lady Heather to calculate the time offset of the timing message from "wall clock" time. It calculates the difference between the system clock time to the time that the (end of) the timing message arrived. The result is only as good as your system clock, so the system clock really needs to be synced to something like NTP (otherwise it does a decent job of showing how much your system clock is drifting). Heather can plot the results and calculate xDEVs on both the message jitter and the message offset time in real time. > > 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… Just pre-load it all into a big shift register and let the PPS output gate the clock to the beast. There’s not a lot of doubt about what the label on the next second going out will be :) Bob > > > > _______________________________________________ > 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.

To answer about how they get good timing. Many times you run a loop that runs off a timer at say exact 1000 times per second. Having something like a 1KHz loop gives very deterministic timing. Lots of ways to do it. One is to run some RTOS. I had to make all the axis of a machine tool move at exact timing to cut a curve. Not hard just have decide to do it. I'm sure most engineers looked at the NMEA spec and read "with the second" and stopped at that. > On Jul 20, 2016, at 5:40 PM, Bob Camp <kb8tq@n1k.org> wrote: > > HI > >> On Jul 20, 2016, at 7:51 PM, Mark Sims <holrum@hotmail.com> wrote: >> >> I added the ability of Lady Heather to calculate the time offset of the timing message from "wall clock" time. It calculates the difference between the system clock time to the time that the (end of) the timing message arrived. The result is only as good as your system clock, so the system clock really needs to be synced to something like NTP (otherwise it does a decent job of showing how much your system clock is drifting). Heather can plot the results and calculate xDEVs on both the message jitter and the message offset time in real time. >> >> 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… > > Just pre-load it all into a big shift register and let the PPS output gate the clock to the beast. There’s not a lot of doubt about what the label on the next second going out will be :) > > Bob > >> >> >> >> _______________________________________________ >> 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. > > _______________________________________________ > 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.

> 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