GPS module with clock output?

Mar 29, 2013 26 Replies

You don't have to have an Internet connection to run NTP on Linux (ntpd). ntpd can get a time reference from two kinds of sources. The first kind, which is the way most people with desktop Linux machines probably use, is some other server that is accessed over a network connection (local or Internet). The second kind is an external piece of hardware that is directly connected to the machine running ntpd: a GPS/GLONASS receiver, a WWV/DCF77 receiver, an atomic clock, etc. This second kind is less common, but is how all the public time servers eventually derive their time.

As I understand it, the way ntpd does it on Linux, the 1PPS output from the GPS receiver is connected to one of the flow control lines on the serial port. When the 1PPS output goes high, the kernel is able to report the time it went high to ntpd. ntpd compares that timestamp to the previous one to decide if the system clock is running fast or slow, and steers the system clock accordingly.

The NMEA data from the GPS receiver comes through the "normal" RxD line on the serial port, and gets parsed to find out *which* second of the day it is. The reference for *when* the second starts is the 1PPS signal.

Most GPS modules will have some specification about how soon the NMEA data starts being transmitted after the 1PPS pulse, but as you noted, it takes time to receive and parse the NMEA data. This extra time probably doesn't make any difference if all you want is 1-second or so accuracy, but if you need finer resolution than that, you need to watch for the 1PPS signal.

If you are playing this game, you should also know about leap seconds. Basically, there is an offset between the time the GPS satellites report and UTC, currently 16 seconds. The current offset is transmitted in the GPS data stream, so it is possible for a GPS receiver to give you GPS time or UTC time; you have to pay attention to which one you are asking for and/or getting.

Every so often, this offset is increased by 1 second. Once every couple of years, the time as reported by a GPS receiver in NMEA will count

23:59:58, 23:59:59, 23:59:60, 00:00:00. If your parser isn't set up to accept 60 as a valid second, or if you've implemented your own clock- steering algorithm based on GPS data, your software can get very confused very fast. (It's also possible for there to be a negative leap second, which I think is done by skipping 23:59:59, but I don't think this has happened since GPS service started.)

Matt Roberds

guess

Interesting paper.

With the worst coaxial cables more than 100 ppm/C, you would quickly need some two way ranging method to measure the actual length of the cable at a given time and temperature :-). Of course, NASA has used two way ranging at least since the Apollo era to measure the distance to the spacecraft. Those measurements are nearly a quarter of a century old, so no modern types or some types common today, such as RG-58 and CAT6 and multimode fibers for Ethernet.

Interesting note, TCD was expressed in ppm/C, while TPD in ppm/psi :-)

not all, pool.ntp.org invites anyone with a reliable internet connection to participate.

formatting link

?? 100% natural --- news://freenews.netfront.net/ - complaints: news@netfront.net ---

At least the NTP contains the LI (Leap Indicator) flags that tells "The last minute the last day this month contains 59/60/61 s". Thus, you have 30 days to adjust your clock so that the clock is 0.5 s early/late at the end of the month and one more month to drop the error back 0 s. This corresponds to a 0.2 ppm frequency error during two months, but each minute is exactly 60 s long and you do not have to worry, how the software in the system would react to 59 or 61 second minutes.

On a sunny day (Sun, 31 Mar 2013 06:29:41 +0000 (UTC)) it happened snipped-for-privacy@att.net wrote in :

There is a problem with that. Even the serial port interrupt has latency in Linux, especially in the simple Raspberry Pi I think, although it comes standard with a pre-emptive kernel IIRC, Interrupt latency has been measured to be up to 10 us:

formatting link
\u03bcs/

Interesting. Fortunately I am not in need of a that precise accuracy, I use the GPS module for auto-pilot way points (and return to base):

formatting link
(PC C code), and am now rewriting all that in PIC18 asm as I want to save weight and current consumption in a model airplane. That soft does a whole lot more, air pressure, magnetic compass, temperature, gyro,

3 axis stabilization etc. gpspc can set the time of the PC, but just uses only the serial signal. 100 ms late for work does not bother me, although I once worked in a place where we used to joke about that.

The 1 PPS would be pretty damn pointless if it doesn't match the time rollover.

Rick

Perhaps so. Nevertheless, some GPS receivers provide a 1PPS signal that is sync'd to their internal Kalman cycle and then supply a "time mark data message" that includes (among other things) a field that gives the GPS and UTC times for the leading edge of the pulse.

On any GPS receiver that provided a 1PPS output, I'd read the data sheet carefully for guaranteed performance specs. Microseconds may not matter in some applications, nanoseconds will in others.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required