Connect with us

GPS module with clock output?

Discussion in 'Electronic Design' started by Davej, Mar 29, 2013.

Scroll to continue with content
  1. Davej

    Davej Guest

    I'm wanting to accurately time-stamp some outdoor events. This is a
    stationary outdoor situation so I thought a GPS module might be a good
    approach for accurate time. If I could find a GPS module with a clock
    output rather than a 1PPS output maybe I wouldn't need to consider an
    additional disciplined oscillator module -- since I don't expect to
    lose the GPS signal lock. Any low-cost suggestions?

  2. Davej

    Davej Guest

    Well, it isn't the serial update rate that is the issue. It is
    synchronizing a counter-timer or RTC with the GPS. I would like to
    achieve something approaching 10 millisecond accuracy. Thanks.
  3. Should be fairly easy with a GPS-disciplined oscillator. If you clock
    your microcontroller from its 10 MHz output and use the same
    controller to monitor the 1-pps output, you can timestamp events to
    within +/- 100 ns or so.

    For a one-off project you can get a surplus Trimble Thunderbolt GPSDO
    on eBay for a couple hundred bucks, while for anything commercial the
    Jackson Labs modules would be ideal.

    -- john, KE5FX
  4. Davej

    Davej Guest

    Well, for a cheaper solution what if I considered an OCXO module
    driven by a microcontroller DAC pin? The microcontroller runs on the
    OCXO and captures the 1PPS from the GPS? Would that be practical?
  5. Guest

    One thing to look out for: the GPS module will have a local clock in the
    few tens of MHz range. It usually has to put the 1PPS edge on one of
    its local clock edges, instead of exactly at the start of the second.
    For 10 millisec resolution, you probably don't care, but for higher
    precision, you have to take this into account. The GPS receivers that
    are optimized for timing can tell you (via the serial port) the offset
    between the most recent 1PPS pulse and when the second actually started,
    so you can apply a correction.

    Trimble makes some GPS modules optimized for timing applications; the
    Resolution T and Resolution SMT are a couple of examples. (Trimble also
    did the genius move of depending on some unspecified bits in the GPS
    data frames to have certain values, causing most Trimble GPS receivers
    worldwide to glitch out when the Air Force uploaded new software to the
    satellites a couple of years ago. Guess who got the single-source
    emergency contract to fix it...)

    Some newer GPS modules can give you position updates at a 5 Hz rate,
    instead of the 1 Hz that is currently standard. I don't know if these
    also have a 5PPS or other faster "clock" output available.
    You will. Maybe for a second or two once a day, but you will. If your
    application can tolerate this, OK, but if it can't, you need some kind
    of local clock slaved to the GPS that will let you "ride through" brief
    For a good time, call (303) 494-4774, assuming you have a phone line and
    a modem available.

    In theory, you should be able to get a 1PPS signal from a WWV receiver,
    but I don't know if anyone makes these as an easy-to-use module like a
    GPS module.

    Also in theory, you should be able to get a reasonably accurate time
    from the cell-phone networks. I know you can get GSM modem modules but
    I don't know if they have an easy way to report what the network thinks
    the time is.

    What other computing resources do you have? Can you do NTP over wi-fi
    to either a public or local dedicated NTP server? The public server
    *might* allow you to hit 10 ms accuracy; a local dedicated NTP server,
    maybe with a local GPS input, should work better.

    This probably doesn't qualify as "low cost", but you could do all of
    the above on board. You need a GPS receiver, a Linux kernel, and an NTP
    server on something like an Atom single-board computer can probably give
    you this level of accuracy. (Basically, NTP listens to the 1PPS and
    turns the system clock into a kind of a GPSDO.)

    Standard disclaimers apply; I don't get money or other consideration
    from any companies mentioned.

    Matt Roberds
  6. miso

    miso Guest

    It is far less work to just buy a used GPSDO. Look into Lady Heather

    Trutime, Symetricom, etc. They are all over ebay. I bought a couple at
    the flea market as NOS.

    These GPSDO units like high gain active antennas. Not that hard to find
    used. You need about 30dB gain. Some marine antennas do this, and of
    course there are Trimble, Sytemtricom, etc. antennas on ebay.
  7. miso

    miso Guest

    I have some NTP data. I have peak time offsets of about 50ms. Most the
    time the error is below 15ms. I think 10ms will be hard to do with NTP.

    This is sample of one, and I suppose it is a matter of the stability of
    your RTC.

    I may have said you could do 5ms in some older post, but looking at the
    charts, it was more like 5PPM frequency error, not absolute time error.
    [My bad.]

    NTP monitoring software is available for free here:
  8. Sure. It wouldn't need to be anything fancy, or even an OCXO at all,
    to achieve 10-millisecond timing.

    As Matt R. says, you do need to plan for "holdover" timing in the
    event of temporary signal loss. Holdover performance is mandated by
    telecom standards, so it's a solved (or at least specified) problem if
    you go with a commercial GPSDO.

    -- john, KE5FX

  9. Our systems have synching networks of 1pps driven from just such a
    purpose specific 1U gps device and 10Mhz. That gets distributed
    throughout all the racks involved in the gateway, or other such system
    where event timestamps are part of the SOP.
  10. Fiber modules are $1000 a pop now, and are running at 10Gb/s.

    Things are being synched up pretty tight these days.

    I'd bet they are on some symetricom gear or some such now.
  11. Jasen Betts

    Jasen Betts Guest

    the pulse per second output presumably indicates when the
    NMEA time is most exact.
    it's probably also the start bit on the dollar sign.
  12. rickman

    rickman Guest

    When you say OCXO, do you mean a VCXO or maybe OCVCXO? I think you
    intend to use the DAC output to tweek the oscillator rate until it
    matches the 1 pps signal? That will be difficult to do accurately. If
    you consider the degree of timing accuracy you are trying to get from
    the oscillator (I'm not actually sure what you think you need, but an
    OCXO is <1 ppm territory) it will take an *exceedingly* long time of
    operation to get the oscillator sync'd to the 1 pps.

    On the other hand, if you just design a conventional real time clock
    from a more conventional oscillator, even one at 20 ppm which is
    commonly available without special consideration, you can do all the
    adjustments in software and easily get <10 ms timing accuracy with only
    a few seconds of synchronization.

    I am assuming you intend to have an MCU in your design. I would set up
    not a timer in the conventional sense, but rather use a timer to drive
    an NCO. The MCU clock is divided down to some reasonable interrupt
    rate, like maybe 100 kHz, you can use that with some very terse code to
    drive an NCO. At the rollover of the NCO it indicates 1 pps. Initially
    it would be sync'd to the external signal by resetting the accumulator
    value when the external 1 pps occurs. Then the time between the
    internal 1 pps and the external 1 pps can be captured and used to update
    the step size for the NCO. It will fairly quickly settle to a
    reasonably close synchronization. I've done this simulation and if the
    adjustment is proportional to the error measurement, the approach to
    sync is asymptotic and can be scaled to be fairly rapid.

    Once in sync the internal 1 pps can be used with good accuracy. If the
    external 1 pps signal goes missing, this can be detected and the rate of
    the internal NCO can be clamped. The short term variation should be
    small relative to your needs.

    The internal 1 pps can be used to drive a real time clock which is also
    sync'd to the external serial information during initialization. Then
    you have the real time to whatever resolution you need.

    I would use an FPGA for this where it would all be a snap to design.
    You could even use a decimal counter for the NCO which would give you
    time in decimal without converting.
  13. Guest

    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

    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
  14. Guest

    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 :)
  15. Jasen Betts

    Jasen Betts Guest

    You don't have to have an Internet connection to run NTP on Linux
    not all, invites anyone with a reliable internet connection to
  16. Guest

    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.
  17. rickman

    rickman Guest

    The 1 PPS would be pretty damn pointless if it doesn't match the time
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day