GNSS receivers determine their position and clock bias by measuring the arrival times of satellite signals. Delay lock loops (DLLs) are used in traditional receivers to measure the arrival times of the signals.

GNSS receivers determine their position and clock bias by measuring the arrival times of satellite signals. Delay lock loops (DLLs) are used in traditional receivers to measure the arrival times of the signals.

A DLL processes the raw satellite signals and passes its estimates of the signal arrival times to a navigation processor, which then estimates the receiver’s position/clock bias, see the upper diagram in **Figure 1** *(at the top of this article)*. A detailed explanation of this process can be found in the **January/February 2012 GNSS Solutions column** by M. Rao and G. Falco.

GNSS receivers that use a vector delay lock loop (VDLL) also estimate their position and clock bias from the satellite signal arrival times. However, individual delay lock loops are not present in the VDLL. Instead, the navigation processor itself is used to track the satellite signals, see the lower diagram in Figure 1.

This means that the navigation processor must predict the arrival times of the satellite signals based on its estimates of the receiver’s position and clock bias in order to generate the local signal. The goal of this article is to explain how the satellite signals are predicted and tracked by the VDLL.

We make several assumptions to facilitate explaining how the VDLL works. First, we assume that the VDLL uses an extended Kalman filter (EKF) as the navigation processor. Furthermore, we assume that the state vector of the EKF contains the position and clock bias of the receiver (i.e. the EKF directly estimates these values). An alternate and less common form of the VDLL uses the received pseudoranges as the elements of its state vector. This variant of the VDLL is not discussed here.

Second, assuming a specific signal structure helps when explaining how the VDLL works, and we use the civilian GPS *L*_{1} C/A code here. However, the techniques used to predict the C/A code signals can be easily modified for the other GPS signals and GNSS constellations. We will review structure of the C/A code briefly before explaining the VDLL mechanization.

The civilian GPS *L*_{1} signal consists of a carrier at *L*_{1}, a pseudo-random noise (PRN) sequence, and a low rate navigation (Nav) message. The PRN sequences (i.e. C/A codes) consist of 1,023 chips that repeat every millisecond. The Nav message is broadcast at 50 bits per second and contains satellite ephemeris, almanac, and other data.

The timing of the C/A code and Nav message is critical to receiver operation. The rising edge of any navigation bit coincides with the rising edge of the first chip of the C/A code. Furthermore, embedded in the navigation message is the approximate time that the rising edge of the Nav message bit is transmitted. (Actually, the time of the start of a sub-frame is provided, but the receiver can use this to determine the time of any bit within the sub-frame.)

The actual GPS time when the Nav message is transmitted differs from the (ideal) time contained in the Nav message. This difference is caused by errors in the clock of the broadcasting satellite. However, the Nav message also contains the coefficients of a satellite clock correction polynomial that a receiver uses to correct the time offset of the satellite clock. Corrections are also applied for relativistic effects and group delay (*T _{GD}*).

We should also note that all satellites broadcast their signals synchronously. This means that in the absence of satellite clock offsets, all the Nav bits would be broadcast at the same time.

GPS receivers track the C/A code and maintain precise estimates of its phase (i.e., the code phase). The phase of the C/A code can be directly related to the signal’s time of transmission because of the known timing relationship between the C/A code and Nav bits. Consequently, predicting the arrival time of the Nav bits is equivalent to predicting the C/A code phases, assuming the navigation message can be extracted from the receiver. The case where the received signal is too weak to extract the Nav message data is not considered here.

The VDLL exploits the structure of the GPS signals to predict the code phases of the received signals based upon its state vector. It is assumed that the Nav messages from all the satellites have been decoded and that at least one set of pseudoranges have been processed (i.e. the VDLL has been initialized, or equivalently, that a position has been computed). The state vector of the VDLL is then time referenced to a specific sample of the IF data.

Point A in **Figure 2** corresponds to the sample to which the state vector is referenced and is the current time.

For convenience, we assume that the current time at point A is at the end/beginning of a Nav bit. From the Nav message, the receiver can easily determine the satellite time corresponding to when the rising edge of bit *k* was transmitted.

The VDLL now needs to predict when the rising edge of Nav bit k+1 is going to arrive, labeled point D in Figure 2. Because sampled data is being used, this prediction will correspond to a particular sample index. The locally generated C/A code for the satellite will then start at this index.

Step one in Figure 2 is to determine the sample index in the past that corresponds to when the rising edge of Nav bit k was transmitted, that is, point B in Figure 2. The sample index corresponding to point B (*S _{B}*) is calculated from the transit time of the signal (

*t*) and the current reference reception sample (

_{tm,A}*S*):

_{A}
**Equation 1 ***(see inset photo, above right, for all equations)*

The symbols *c* and* f _{s}* in the preceding equation are the speed of light and the sampling frequency of the receiver, respectively. The values needed in (1) should have already been calculated, because they are all required to process pseudorange measurements.

After determining the sample index corresponding to when the rising edge of Nav bit k was transmitted (point B), step two is to determine the satellite position and sample index when bit k+1 would have been transmitted (point C). This is done by adding 20 milliseconds to the satellite clock time and then calculating the satellite’s position at this new time.

The sample index when Nav bit k+1 was transmitted is then found by taking the sample index when bit k was transmitted, and adding to it the elapsed time (in samples) between the consecutive Nav bits. The true GPS time when Nav bit k+1 was transmitted is calculated when computing the satellite position at the next transmission. The elapsed time should be very close to 20 milliseconds since the drift in the satellite clocks is very small over the Nav bit interval.

Step 3 in the VDLL mechanization is to add the transit time of Nav bit k+1 (*t _{tm,B}*) to point C. The time of transit is calculated using the satellite position at transmission (

*P*), the atmospheric delays for the signal (

_{SV}*d*), and the position of the receiver at reception

_{atmos}
**Equation 2**

The position of the receiver at reception is determined by taking the state vector of the VDLL at point A and propagating it forward 20 milliseconds. This also yields the clock bias of the receiver at reception. Calculation of *t _{tm,B} *typically requires iteration because the satellite position in the ECEF frame is a function of the transit time.

Finally, point D (*S _{D}*), the sample index when Nav bit k+1 will arrive, is calculated by adding the transit time and clock bias of the receiver at reception (

*d*) to point C:

_{clkbias}
**Equation 3**

The sample index SD is when the rising edge of the first chip of the C/A code should occur.

Note that the propagation of the VDLL’s state vector ahead by 20 milliseconds is an approximation, because it is assumed that the next Nav bit will arrive 20 milliseconds after the previous one — which is not exactly correct because of clock errors and relative motion between the receiver and satellite.

We can evaluate the effects of relative motion on the accuracy of this assumption by first considering that the maximum observed Doppler shift by a stationary receiver on the Earth’s surface is about +/- 5 kilohertz at *L*_{1}. This translates to a line-of-sight velocity of about 952 m/s, or 2130 mph. The change in the period of the Nav bits caused by this magnitude of line of sight velocity is:

**Equation 4**

If the receiver is assumed to have the same line-of-sight velocity toward the satellite, the change in the Nav bit period is then 126 nanoseconds. The approximate pseudorange error incurred by assuming the Nav bit interval to be 20 milliseconds is then:

**Equation 5**

This error is quite small, even for an extremely high dynamic platform.

A second method of predicting the satellite signals for the VDLL is shown in **Figure 3**. There, the receiver first processes a full set of pseudoranges at point A. The state vector of the VDLL is then referenced to point A, and the receiver needs to predict the arrival times of the k+1 Nav bits, shown arriving to the right of point A. The receiver first calculates the sample (point B) corresponding to GPS system time when the k Nav bits would ideally have been transmitted. Point B is when all the Nav bits labeled *k* would be transmitted if all the satellite clock offsets were zero.

The receiver then adds 20 milliseconds to point B to yield point C, which corresponds to the sample when all the satellites would ideally transmit the k+1 Nav bit. GPS system time at point C is then the value of satellite time used to calculate the satellite positions at the transmission of the k+1 Nav bits.

The sample indexes corresponding to the time of transmission for the satellites will generally not be the same as point C because of the satellite clock errors. The actual sample index of transmission for each satellite is determined by taking the satellite clock correction and subtracting it from point C. This is shown graphically in Figure 3 by the slewed transmission times of the signals.

The receiver’s position and clock bias at reception are again calculated by propagating the VDLL’s state vector forward. However, the propagation times are different for each channel due to the different signal arrival times. After propagating the state vector forward to the appropriate time, Equations 2 and 3 are again used to calculate the sample index when the next (k+1) Nav bit will arrive. It should be emphasized that the transmission sample indexes have been adjusted for the satellite clock errors.

This second method of predicting the C/A code phases is the actual technique used by the authors. Further details on processing the satellite signals with the VDLL are given in articles cited in the Additional Resources section.

**Additional Resources**

**[1] **Lashley, M., “Modeling and performance analysis of GPS vector tracking algorithms,” Ph.D. dissertation, Auburn University, December 2009.

**[2]** Lashley, M., and D. M. Bevly, “Comparison in the performance of the vector delay/frequency lock loop and equivalent scalar tracking loops in dense foliage and urban canyon,” in *Proceedings of the 2011 International Technical Meeting of The Satellite Division of the Institute of Navigation*. Portland, Oregon: Institute of Navigation, September 2011.