GPS Atomic Time Sync

[alexkrishnan]

Hello, long-time reader, first-time poster around here!

Hey Geeks!

I am out on a nerdy mission tonight! I have recently moved to Santa Cruz, California, USA and I have discovered that the Atomic Clock that I have that syncs via the radio waves from WWVB in Boulder, Colorado does not obtain a strong enough signal to synchronize with atomic time.

I know that GPS can provide an EXTREMELY accurate time stamp (within nanoseconds) if it has a valid time sample of about 24 hours. I have a nice Bluetooth GPS receiver, so I was wondering if anybody knew of some good mac software I could use to read the time stamp from my GPS receiver so that I can obtain accurate time.

Thanks!

-Alex

 

[old-wiz]

the gps receivers output nmea data. See the following post for details

http://www.gpsinformation.org/dale/nmea.htm

some gps units can connect via USB where you can then read the NMEA

 

[alexkrishnan]

Solution

I have figured it out, and the solution is very geeky! For those fellow nerds who are interested and have a bluetooth and/or USB/Serial GPS reciever:

1. Pair your bluetooth receiver using the normal setup assistant
2. Download the cool software from furrysoft called goSerial at http://www.furrysoft.de/?page=goserial. This software can send and receive serial data from any serial port in your mac (including bluetooth serial ports).
3. Launch the app and you should see a configuration dialog. Under the "Port" tab choose the name of your newly-paired BT GPS reciever.
4. Now we must set up the COM port settings as per the NMEA communication standard as detailed at http://www.gpsinformation.org/dale/nmea.htm. This means that we must set the speed (baud rate) to 4800, Data Bits to 8, Parity to none, and Stop Bits to 1.
5. Now click OK and press the button in the top right corner that looks like a plug. You should now see a bunch of text scrolling across the screen (if your GPS receiver has a valid fix).
6. Now pause the readout by pressing the same button so that you can read through the output and interpret it.
7. Read the section at http://www.gpsinformation.org/dale/nmea.htm entitled "Decode of selected position sentences".
8. Read through your output and see which types of data your device is outputting. You will see many different line prefixes, but my bet would be that almost all devices will output a line that starts with $GPRMC, then a number (such as 123519).
9. This first number after the comma is UTC time that is accurate within about a nanosecond, depending on your GPS unit. Of course there is about a 1 second delay before the data is actually transmitted and printed to the computer screen so you will still only see accuracy of about 1 second if you are viewing the live data output of your device.


Post any questions/problems you run into if anyone is interested!

-alex

 

[TechExaminer]

Does anyone know of a easier way to use a USB or bluetooth GPS to sync the time on a mac? perhaps with a simple app?

 

[davidmartindale]

Maybe I am just being naive and cant think of the reason. But, why? Like why not just use the "Set date and time automatically" in Sys pref?

 

[TechExaminer]

I need to be able to run specialized apps on my MacBook Air that require very accurate timing for a few weeks at a time in areas that have no cellular or WiFi internet connection.

 

[alvindarkness]

Solution
9. This first number after the comma is UTC time that is accurate within about a nanosecond, depending on your GPS unit. Of course there is about a 1 second delay before the data is actually transmitted and printed to the computer screen so you will still only see accuracy of about 1 second if you are viewing the live data output of your device.
-alex

Sure a GPS can be accurate to within a handful of nanoseconds, but unless your GPS receiver has a PPS output to coincide with the NMEA strings (or whatever protocol you are using) the time in your software wont be anywhere near that level of accuracy.

A few things to consider. As you are communicating at 4800 bits per second, it takes about 200microseconds for a single bit to be sent. A single character takes a little under 2 milliseconds (considering 9 bits per character due to the stop bit). Then multiply that by the number of characters in whatever string you are receiving. Then depending on what messages your GPS receiver is configured to send, you may have other strings in a queue with the one your software is parsing for UTC being even further out of whack.

I've been using GPS (and PPS) for timing for a bit now, and have seen the difference between the two. This is from my ntp server -:

 remote           refid      st t when poll reach   delay   offset  jitter
==========================================================
oPPS(0)          .PPS.            0 l    6   16  377    0.000    0.001   0.001
+SHM(0)          .GPS.            0 l   52   64  377    0.000    1.243   3.240
+joker.slash31.c 8.145.32.135     2 u   60   64  377   32.416   -0.204  35.117
+ec2-13-55-50-68 203.206.142.65   3 u   29   64  377   35.820   -0.585  13.024
+45.76.113.31 (d 17.253.66.125    2 u   25   64  377   36.593   -0.429  14.670

The SHM (GPS) line is the time derived from strings sent via the GPS receiver over the serial port. You might think its only a 1.2millisecond difference to the PPS, but its not so. In the ntp configuration file itself, I have specificed an offset calibration factor of approx 200milliseconds in order to bring the two into somewhat of an alignment. Otherwise the time would be lagging approx 200ms from the real time.

Now even with the PPS signal, being delivered into an interrupt driven kernel routine specifically written for high precision timing, I still dont get close to nanosecond level precision or accuracy. Its more in the microsecond region.

system peer:        PPS(0)
system peer mode:   client
leap indicator:     00
stratum:            1
log2 precision:     -24
root delay:         0.000
root dispersion:    1.165
reference ID:       PPS
system jitter:      0.000682
clock jitter:       0.001
clock wander:       0.000

As you can see there is a clock jitter of 1microsecond, and a system jitter of 0.7microseconds. Granted this computer isnt used solely for time keeping purposes and I could squeeze a little more out of it if I went down that route, but this should give you an idea of what a typical modern computer is capable of timing wise with a GPS receiver - both with and without a PPS signal.

 

[jasnw]

I need to be able to run specialized apps on my MacBook Air that require very accurate timing for a few weeks at a time in areas that have no cellular or WiFi internet connection.

How accurate is "very accurate"? The complexity and cost of the solution will be strong functions of how accurate you need the computer to be.