On 3 Feb, 2012, at 05:07 , Hal Murray wrote: >>> I thought the 4th satellite was needed to determine the time. Wouldn't >>> it take a 5th satellite to also determine the frequency of the local clock? > >> Not really. There are two ways to get the postion and time derivatives. One >> is to either use two fixes which give you each a (x,y,z,t) tuple, while you >> know what your expected delta-t is, you can calculate the "real" delta-t and >> get from that your frequency offset. > > That's the sort of thing I'm looking for, but I don't quite get it yet. > > I have 4 satellites. If I know f, I can solve for x, y, z, and t. If I don't > know f, I'm short an equation.
If you are using an undisciplined free-running oscillator, as most cheap receivers do, you never know f. What you know is the frequency written on the oscillator's package (call it fn, the nominal frequency), but the actual f is a mystery. Whatever f is, however, you assume f=fn and use that oscillator to generate a local timescale to measure signal phases against. When you solve for x, y, z and t from data generated by measuring the phase of the incoming signals against your oscillator, the `t' you compute is actually a delta_t with respect to the local time scale generated from that oscillator. The value of delta_t tells you the phase error of your local timescale, so the rate of change of delta_t from sample to sample tells you the error in the fn you assumed, that is (f/fn) integrated over the sample interval. > If I get two samples, I have 8 equations and I need to solve for: > x0, y0, z0, t0, and f0 > x1, y1, z1, t1, and f1 > That's 10 unknowns with 8 equations. I get a 9th equation by setting t1 = t0 > + 1. I'm still short one equation. > > Can I do something like assume f0 = f1? That would make sense if the change > in frequency is small relative to the noise/error in all the other > calculations. I suspect that if the local oscillator does not exhibit fairly good short term stability there is no hope of any of this working. That doesn't matter, though, since the GPS `t' you compute is actually a delta_t from whatever your local time scale is, so (delta_t1 - delta_t0) directly tells you how the rate of your local time scale differs from the rate of the GPS timescale. The GPS receiver in fact has no knowledge of the GPS `t' other than as a function of the local time scale. The GPS time scale is purely a paper time scale from the receiver's point of view unless the receiver does the additional work of somehow using that information to generate a real timescale out of the paper. Dennis Ferguson _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
