[time-nuts] Checking the Frequency of a Rubidium Oscillator

[Lux, James P]

> -----Original Message-----
> From: time-nuts-bounces at febo.com
> [mailto:time-nuts-bounces at febo.com] On Behalf Of Hal Murray
> Sent: Tuesday, November 11, 2008 10:10 AM
> To: Discussion of precise time and frequency measurement
> Subject: Re: [time-nuts] Checking the Frequency of a Rubidium
> Oscillator
>
>
> > All the satellites are at the same frequency, and they are
> CDMA (each
> > satellite has a different PN sequence on its signal)
>
> What's the bandwidth of an individual satellite?
Megahertz (the 1 MHz C/A code + the 10MHz P/Y code)

>
> It may have been a different thread, but the Doppler shift is
> up to 2 KHz.
> Even if you could tune to an individual satellite signal, you
> still have to go through the whole GPS calculation in order
> to correct for Doppler.

A GPS receiver actually solves for the state vector of the receiver (including the local clock error) using the raw observables from the tracking loop (code phase).  The nav equations calculate (apparent) range and range rate from the known state vector of each satellite and the (estimated) state vector of the receiver.  Range rate is the doppler.

The 1.xxx Megachip/second C/A code is 1023 bits long, so the classical approach is to step the receiver through all possible phases of the code, integrating at each one to see if it can detect the signal.  If your integration time is, say, 10 milliseconds, it takes 10 seconds to step through them all. Once the signal is detected, the PN tracking loop tracks that signal.

If you have some a-priori knowledge of the expected code phase, that reduces your search space quite a bit.
You can also search for multiple codes at once with parallel receivers (really, parallel code tracking loops, because the RF receiver is usually just a single bit quantizer, and the same bits go to all loops), either acquiring different satellites in parallel, or speeding up the acquisition of a single satellite.

This is where the proprietary nature of each manufacturer really comes in, because time spent acquiring is time not deriving a nav fix, and in a energy sensitive design (which many GPS receivers are.. E.g. in cell phones or battery powered), time is of the essence.

For instance, if you know your approximate position and date/time, you can not bother trying to search for satellites that aren't above the horizon. If you've characterized your local oscillator properties, you might be able to do a more clever acquisition by modeling the drift.

If the cellular system can tell the receiver in the phone an approximate position and estimated range/range rate, it can greatly reduce the acquisition time. (in fact, most phones don't actually implement a full GPS receiver.. They use assistance from the cell site to acquire, and just return the raw observables, and the centralized system turns that into a position)

All very interesting stuff..

Jim