I added the ability for Lady Heather to measure a plot the difference of the arrival times of each timing message (actually the time when Lady Heather receives the last byte of the timing message from the operating system). The end-of-message arrival time is time stamped to nominally nanosecond resolution using either the Windows QueryPerformanceCounter() value or the Linux nanosecond res clock function... (actual resolutions are system depenent). I measured several different receivers in both NMEA mode and their native binary mode. A few generalizations: most receivers get the time messages out within a window less than 50 milliseconds wide with a standard deviation of less than 10 milliseconds. Timing receivers tend to do a better job of it. The Trimble Thunderbolt and Resolution-T receivers are particularly good (5 msec window, 1 msec standard deviation). The Z3801A is also rather good (10 msec window, 1.2 msec standard deviation). There is usually not much difference the performance of the NMEA messages and the native binary messages. The Navspark Venus based receivers have the greatest differences.. their NMEA messages are about twice as consistent than the binary messages. Occasionally you see a minor hicccup in the message time when the operating system goes off and does something else (particularly like when waking up from a screen saver mode). The number of messages the receiver sends during each timing interval does not seem to make much difference. I have a Ublox 8M tracking 20+ satellites and sending over a dozen NMEA messages each second. It gets the timing message out within a 30 msec window, 6.5 msec standard deviation. Surprisingly, the communications channel type is not that important. I've seen little difference between hardware serial ports and a USB / RS-232 adapter. Even running a TCP/IP link between Dallas and Seattle gave surprisingly consistent messages (with a couple of spike to +/- 100 millisecond or so differences. All of the tested receivers were running at 9600 baud, the Navspark at 115,200, the Z3801A at 19,200. Attached is a plot of the Trimble Thunderbolt running on a 3 GHz, single core Windows XP box.

Yo Mark! On Mon, 18 Jul 2016 18:30:08 +0000 Mark Sims <holrum@hotmail.com> wrote: > A few generalizations: most receivers get the time messages out > within a window less than 50 milliseconds wide with a standard > deviation of less than 10 milliseconds. How long did you run your tests? My experience is that the GPS may be stable for hours, then have a sudden shift in offset to a new stable offset. I would hope your tests were at lesat 24 hours long. > The Navspark Venus based receivers have the greatest differences.. Yes, they can be horrible. But there is a soultion. There is a configuration option to tell the Navspark GPS to try to output near the top of the second. Then the results are much better. > Surprisingly, the communications channel type is not that > important. I've seen little difference between hardware serial > ports and a USB / RS-232 adapter. How long did you run your tests? I have also found that USB 1.1 NMEA can be very stable. Maybe +/-100 microSeconds or better instead of the expected +/- 500 microSeconds. This is because the 1024/samples per second on the USB port is linked to the system clock. But after a few days of solid performence the USB serial time may shift 1/1024th of a second and stay at this new stable point. You will find when mearusing the PPS that the Serial/USB difference is much larger. Maybe 1,000x or more. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem@rellim.com Tel:+1 541 382 8588

> most receivers get the time messages out within a window less than 50 milliseconds > wide with a standard deviation of less than 10 milliseconds. Hi Mark, For comparison with your data, attached is the ADEV+MDEV plot [1] for the SkyLab / MG1613S GPS board [2], the one with the 350 ms offset and 11 ms stdev. The results are impressive. But I'd still recommend people use 1PPS instead of NMEA edges for clock timing. And, because I've seen it myself sometimes on some receivers, I will agree that these NMEA timings are not necessarily consistent over long periods, especially over episodes with significantly varying reception quality, including loss and reacquisition of lock. /tvb [1] http://leapsecond.com/pages/MG1613S/log167.gif [2] http://leapsecond.com/pages/MG1613S/