GPS module with clock output?

[Davej]

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?

Thanks

 

[Davej]

Search for a GTPA010 module. Gives out (obviously) your location, and time
(in UTC) at up to 10Hz rate. You should be able to find it for <$20.

Andy

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.

 

[John Miles, KE5FX]

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.

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

 

[Davej]

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

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?

 

[[email protected]]

This is a stationary outdoor situation so I thought a GPS module might
be a good approach for accurate time.

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.

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.

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
outages.

Any low-cost suggestions?

For a good time, call (303) 494-4774, assuming you have a phone line and
a modem available. http://www.nist.gov/pml/div688/grp40/acts.cfm

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

 

[miso]

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

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.

 

[miso]

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:

 

[John Miles, KE5FX]

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?

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

 

[DecadentLinuxUserNumeroUno]

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?

If the uP has a free-running counter, you can latch a copy of the counter at
each 1 PPS rising edge, and nab other latched copies at each external event.
That timestamps everything happening, to the granuarity of the counter. Do that
with software or some counter capture registers. If all you need is 10 ms
accuracy, the uP clock only needs to be 1% accurate... no OCXO needed.

It would be fun to servo a uP clock cal factor based on sequential timestamps of
the 1 PPS from GPS. That can even be done after the fact, by analyzing the
captured time stamps later. That will get you close to 1 LSB accuracy of
whatever frequency your timestamp counter runs at... 10s of ns, potentially. [1]

Dimensionless measurements (in this case, time ratios) often turn out to be
easy.

[1] using a crystal to clock the uP, of cource. The uPs that have internal
clocks will have a lot of jitter and frequency wobble, not to mention terrible
TCs. Still, 10 ms would be easy.

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.

 

[DecadentLinuxUserNumeroUno]

Fiber time delays are a lot better than electrical cable, numbers like 15 PPM
per degree C delay change for standard stuff. Maybe there's some better stuff
available.

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.

 

[Jasen Betts]

On a sunny day (Sat, 30 Mar 2013 00:55:19 +0000 (UTC)) it happened


I have my EM-411 GPS module working on Raspberry Pi.
The module was something like 25 $, and the Pi maybe 35?
It runs linux and you can do NTP too if yo uwre connected to that thing called 'internet'.

The EM-411 datasheet says:
General
Chipset SiRF Star
Frequency L1, 1575.42 MHz
C/A code 1.023 MHz chip rate
Channels 20 channel all-in-view tracking
Sensitivity -159 dBm
Accuracy
Position 10 meters, 2D RMS
5 meters, 2D RMS, WAAS enabled
Velocity 0.1 m/s
Time 1us synchronized to GPS time <------------------

I dunno however if you get the time via NMEA serial out at 4800Bd,
how much the exact offset of the time field in the NMEA is versus any real time.
So there is always that baudrate delay and parsing time delay error.

the pulse per second output presumably indicates when the
NMEA time is most exact.

For example in the GPRMC message the UTC time is the first field:
$GPRMC,122556.000,A, // ,,,A*6A
-------^^^^^^^^^^

it's probably also the start bit on the dollar sign.

 

[rickman]

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?

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.

 

[[email protected]]

I have my EM-411 GPS module working on Raspberry Pi.
The module was something like 25 $, and the Pi maybe 35?
It runs linux and you can do NTP too if yo uwre connected to that
thing called 'internet'.

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.

I dunno however if you get the time via NMEA serial out at 4800Bd, how
much the exact offset of the time field in the NMEA is versus any real
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

 

[[email protected]]

Yes: under 1 PPM.

http://tmo.jpl.nasa.gov/progress_report/42-99/99E.PDF

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

 

[Jasen Betts]

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.

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

 

[[email protected]]

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.)

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.

 

[rickman]

One needs to be careful when using NMEA sentences. The devil, as they
say, is in the details. In an RMC sentence, the UTC timestamp is the
"time of fix," the time at which the position and other parameters in
the sentence are valid, and has no inherent constraints as to when
that instant is with regards to any element of the transmission.

NMEA 0183 itself is silent with respect to a 1 PPS signal.
Manufacturers often use ZDA to report UTC time as of the leading edge
of the pulse (if a pulse is even provided), but are not required to do
so. There is also no guarantee (in 0183) that the 1PPS pulse occurs at
the UTC rollover. That may be the case but, again, it's up to the
manufacturer to so state.

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