[time-nuts] UBLOX LEA-5T Programming?
dave.martindale at gmail.com
Sat Oct 10 01:08:11 EDT 2015
(Long-term members of the list can skip this; you've seen it many times
before. But it sounds like Clint is new, and could use some basic
explanation. I was in his position once too).
It sounds like you are assuming that the GPS receiver's internal oscillator is
locked to GPS time. In most cases, it isn't - it's a free-running local
oscillator. So its frequency isn't terribly accurate. The GPS receiver, as
part of its operation, can determine what the local clock frequency is and
compensate for it. For the 1 PPS output, the receiver can calculate which
local clock edge is closest to being the correct location for the next 1 PPS
pulse, and arranges to change the output state at that time. But the divisor
between the internal clock and the 1 PPS output is not constant - it is
adjusted as necessary to place the 1 PPS as close as possible to the correct time.
For example, suppose the local oscillator is nominally 10 MHz, but it is
actually 10 PPB fast. If it was simply divided by 1e7 to get the 1 PPS, the 1
PPS would also be 10 PPB fast. So the GPS receiver will arrange to (on
average) divide by 10,000,000 for 9 seconds out of every 10, but divide by
10,000,001 every 10th second. This slows the PPS, on average, by one extra
oscillator cycle in every 100 million, compensating for the long-term error.
But now some "1 PPS" periods are actually 100 ns longer than others. The very
best the GPS receiver can do at keeping the 1 PPS "on time" as well as "on
frequency" is to always place the 1 PPS somewhere within 50 ns of the correct
time. With this example, the error will drift from 50 ns late to 50 ns early
over a span of 10 seconds, then abruptly jump to 50 ns late again due to the
extra-cycle 1 PPS period. So the time error looks like a sawtooth when graphed.
If you have a timing-grade GPS, the receiver will generally tell you the
residual error of each 1 PPS pulse, and you can compensate for that when
comparing an external oscillator to the 1 PPS output. Essentially, it gives
you a timing reference with a somewhat-random error, but it tells you the
amount of the error, so you can subtract it out of your calculations. That's
easy if you're using a digital PLL to lock another oscillator to the
(corrected) 1 PPS. Someone was even talking about designing a delay line to
remove the sawtooth error from the 1 PPS in hardware. If you don't do one of
these things, the 1 PPS output has a lot of jitter. (And it doesn't
necessarily average out in 10 seconds, like in the example above. If the local
oscillator is close to the correct frequency, you can get 1 PPS outputs that
are on one side or the other of "correct" for hundreds or thousands of
seconds. The phenomenon is called "hanging bridges" from the way they look on
On 09/10/2015 10:16, Clint Jay wrote:
> I am still learning and want to understand, if the PPS is good then why is
> the programmable output bad, as I understand it thus far, the PPS is
> derived from the same clock source or have I got that badly wrong?
More information about the time-nuts