[time-nuts] Testing frequency using NTP Bruce GPS ps

[Lux, James P]

On 10/13/08 8:54 PM, "Mike Monett" <XDE-L2G3 at myamail.com> wrote:

>
>
>> Mike,
>
>>> 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
second epoch.

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

Yes.

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


>