On 10/13/08 8:54 PM, "Mike Monett" <XDE-L2G3@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. >