GPS Atomic Time Sync

Discussion in 'Mac Apps and Mac App Store' started by alexkrishnan, Oct 15, 2009.

  1. alexkrishnan macrumors newbie

    Oct 15, 2009
    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.


  2. old-wiz macrumors G3

    Mar 26, 2008
    West Suburban Boston Ma
  3. alexkrishnan thread starter macrumors newbie

    Oct 15, 2009

    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 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 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 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!

  4. TechExaminer macrumors newbie


    May 6, 2018
    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?
  5. davidmartindale macrumors regular


    Jan 28, 2011
    PNW, USA
    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?
  6. TechExaminer macrumors newbie


    May 6, 2018
    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.
  7. alvindarkness macrumors 6502a

    Jul 11, 2009
    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     2 u   60   64  377   32.416   -0.204  35.117
    +ec2-13-55-50-68   3 u   29   64  377   35.820   -0.585  13.024
    + (d    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.
  8. jasnw macrumors 6502a


    Nov 15, 2013
    Seattle Area (NOT! Microsoft)
    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.

Share This Page