[time-nuts] Testing frequency using NTP Bruce GPS ps
Lux, James P
james.p.lux at jpl.nasa.gov
Tue Oct 14 04:11:56 UTC 2008
On 10/13/08 8:54 PM, "Mike Monett" <XDE-L2G3 at myamail.com> wrote:
>>> So where did the 1ns granularity come in?
>> For example, Motorola receivers output the sawtooth correction as
>> an 8-bit signed binary field in the @@En/Hn TRAIM message. The
>> range of said byte is -128 to +127; the scale, the granularity,
>> the units of that field are 1 ns. Make sense now?
> Thanks, but I still can't make the connection. I have studied every
> site I can find on GPS architecture. Some are very good, but I can't
> find anything that relates a 1 second GPS message to the 1PPS pulse.
The Nav message is transmitted from the satellite, synchronized to the 1
> I can understand how the sawtooth is generated from a crystal that
> doesn't have a convenient division factor to get to 1 Hz. I believe
> similar pulse-swallowing techniques are used in synthesizers to
> generate arbitrary division ratios. Unfortunately these have poor
> phase noise.
> In any event, my system ignores all the timing and quantization
> errors in the 1PPS signal. What I am really interested in is how the
> GPS receiver can identify the correct time messages from many
> different satellites at wildly different distances, with huge and
> changing doppler shift, and old satellites constantly leaving and
> new ones appearing. That is a complete mystery.
Actually, that's the easy part. Given that you know your position and
velocity (state vector) and the position and velocity of the satellites
(that's in the ephemeris message), you can calculate the range and range
rate (doppler) for each satellite (visible or not).
The receiver actually measures apparent range (PN code phase) and range
rate for each of the signals its tracking. That range and range rate is
offset by the local clock error (and clock error rate).
The nav solution is done by setting up a set of simultaneous equations to
solve for the position and local clock offset and clock offset rate.
In reality, most receivers actually do an iterative solution where an
estimate of the receiver's state vector (position, velocity, and clock error
(frequency and rate of frequency)) is updated using a Kalman filter. The
filter can also use the carrier frequency offset (since the PN code is
coherent with the carrier).
Knowing an approximate position makes it easier to acquire the PN code in
the first place by reducing the search space before you get lock, because
you can calculate approximately what the phase should be.
>> The hump around 1000 seconds is characteristic of quartz-based
>> GPSDO. It is related to the "cross-over point" where the
>> instability of the XO meets the stability of GPS on an ADEV plot
>> and to the time-constant of the PLL.
> OK, thanks. That seems similar to the phase noise shelf in PLL loops.
> But why can't the GPS correct the oscillator faster? Why is the loop
> time constant so long?
Because the GPS solution has short term variability from a variety of
sources: multipath and movement of the phase center with respect to look
angle are both on the order of several millimeters, if not centimeters. As
the satellite moves across the sky, the fact that your GPS receive antenna
isn't a perfect point source and that the spacecraft antenna isn't either
changes the apparent length of the path. There are also short term
ionospheric propagation effects. In fact, there's a whole raft of factors
all in that tens of millimeters area that add up. SO what you have is a
nice stable Cs clock in orbit, with a path from that clock to you that
screws up the Allan deviation for short tau.
More information about the time-nuts