The tracking function is at the heart of the GPS software and is the module that consumes the most CPU. It is called by an interrupt routine every 505(approx) microseconds, controlled by a hardware driven timing signal, the interrupt routine determines which of the device hardware correlator channels have new results that need to be read for ongoing processing.
The satellites produce a Gold code that is repeated every millisecond, with a small variations due to doppler effects, the first task of the signal tracking process is to look for correlations between these codes and local copies produced by the receiver.
In this particular unit and in most currently available units this is done in hardware and a device accumulator register is set when a correlation completes, this data needs to be read by software before the next correlation completes in another millisecond.
The correlations complete at different times due to the differing transmission delays between satellites.
It is possible for the correlations to complete on all channels at the same time if they are started at the same time with appropriately offset Gold codes, but this unit does not do that.
Anyway back to the details of the tracking module, the accumulator ISR (interupt service routine) is called when an accumulator hardware interrupt occurs ,this function reads the correlator accumulator registers and then calls the tracking DSR (delayed service routine) function, which does most of the work in the tracking module.
The tracking dsr calls a function to process the correlation data for each channel dependent on the mode of the particular receiver channel, if phase lock has been achieved a function to process the navigation data stream will also be called.
If all the Gold code chips have been checked then what happens next depends on the allocation mode of the receiver.
If the receiver is in cold allocation mode then the doppler offset is set to a new value, this goes from 0 to +/-5000Hz in 250Hz steps, first positive then negative, ie 0, +250, -250, +500 until -5000Hz is reached, at that point the channel is de-allocated and waits for the next run of the Allocation module to assign a new satellite.
If the allocation mode is warm, this means the receiver has a valid almanc for the satellite allocated to the channel and has calculated it's doppler frequency offset. Then the doppler remains unaltered and the sweep through code chips begins from the first chip.
If WAAS functionality is enabled and this channel is allocated to a WAAS satellite the doppler offset is always set to zero as the satelite is geostationary with no significant doppler offset.
After a correlation measurement has crossed the detection threshold, then a check is made that this is a real signal and not just a spurious large noise spike.
In confirmation mode the next 20 correlation measurements are monitored and if more than 2 of them fall below the detection threshold then this means that the presence of a valid satellite signal has not been confirmed and the channel switches back to acquisition mode. If however the presence of a valid satellite signal is confirmed then the channel switches to the first of the tracking modes , the FLL mode.
The Frequency Locked Loop is used before the switch to the Phase Locked Loop to eliminate or significantly reduce the rate of occurence of false locking. For the PLL configuration used in this receiver the PLL will false lock if it is at an offset of 250Hz or a multiple thereof from the true satellite signal. It has been found that the introduction of the FLL has virtually eliminated the occurance of false locking in the PLL.
The PLL mode uses a Phase Locked Loop to track the doppler offset and a DLL to track the code offset. In this step as the tracking error is reduced below a certain level then the bandwidth of the loop filter is also reduced. This is done in 3 steps and once both loops are at the narrowband value synchronisation to the data stream begins.
This starts with data bit synchronisation, bit synchronisation looks for 20 correlations with the same sign and then a switch to the opposite sign, once bit synchronisation is achieved with the navigation data stream the function looks for the occurence of the preamble bit pattern Again if the signal strength drops below the detection threshold before this happens then the channel is switched back to the previous mode.
The structure of the data sent by the Navstar GPS satellites is well described in many places including the defining document issued by the USAF and also know as NATO Standardization Agreement (stanag) 194.
The message is sent at a data rate of 50 Hz, this means in order to achieve bit lock the software looks for 20 bits with the same sign and then a bit with the opposite sign, when this condition is detected the 20ms counter in the receiver is set to 0 and the bit sync flag is set.
Next the PREAMBLE at the start of every data frame must be located, a check is made every time a new data bit(20ms) is received to see if the last 8 databits match the PREAMBLE or it's inverse.
When the preamble is detected the frame_sync status is set to PREAMBLE and the frame counter is set to 0.
At the end of the 30 data bit word that contains the PREAMBLE, word 1 of the FRAME, a further check is made to ensure that the word passes the parity check, at this point the frame_sync status is set to FRAME_LOCKED and this channel can then be added to the channels used by the measurement and position calculation routines.
These checks are repeated every frame to make sure the channel stays locked to the data frame.Once all the data bits for an entire frame have been received and the parity check passed then the Ephemeris thread is alerted that there is a navigation data frame available to be decoded.
Decoding the WAAS data signal is more complicated than the NavStar data as it incorporates FEC coding and CRC parity coding as well as a frame and preamble.
For WAAS the FEC coding must first be decoded using a viterbi algorithm and then the preamble located before the parity check can be made.
However since the FEC consists of symbol pairs transmitted at 500 Hz per symbol, we first need to achieve bit lock. However it is not possible to know the correct order of the symbols until further decoding is done.
For this reason two viterbi decoders are run in parallel until the correct symbol pairing can be determined.
The viterbi channels are processed identically but are fed with symbol pairs one symbol bit out of synch.
The output of the viterbi decoder is fed into a shift byte that holds the last 8 data bits and checks this for one of the PREAMBLEs with every new data bit. The output of the shift byte is moved into a fifo structure that contains the last 250 data bits.
This means when a PREAMBLE is detected that the fifo contains the whole of the previous frame allowing the CRC parity check to be completed in one operation.
At this point frame_lock is achieved and only one viterbi channel continues to be processed.
Preamble and parity checks are repeated every frame to make sure the channel stays locked to the data frame.