Q: How Important Is It to Synchronize the Code and Phase Measurements of a GNSS Receiver?
A: Precise timing lies at the heart of GNSS implementation and operation and is generally well understood in terms of synchronizing individual satellites and/or receivers. Recent results, however, have demonstrated that timing of code and phase measurements in a receiver can have significant implications for the timing community in particular.
Q: How Important Is It to Synchronize the Code and Phase Measurements of a GNSS Receiver?
A: Precise timing lies at the heart of GNSS implementation and operation and is generally well understood in terms of synchronizing individual satellites and/or receivers. Recent results, however, have demonstrated that timing of code and phase measurements in a receiver can have significant implications for the timing community in particular.
Specifically, papers presented to the 2015 joint meeting of the International Frequency Control Symposium and the European Forum on Time and Frequency (see Further Reading section at the end of this article for details) demonstrated that a one-microsecond delay between the times of code measurements and of phase measurements will appear as a 30 picosecond/ day drift in the clock solution based on the analysis of these code and phase measurements. This explained observations that for certain geodetic receivers a frequency bias seemed to exist between code and phase clock at the level of 100s of picoseconds per day.
The Problem
Precise point positioning (PPP) is often used for remote atomic clock comparisons, as well as for the generation of coordinated universal time (UTC). PPP determines the difference between the GNSS receiver’s clock frequency and time and a reference time scale by modeling code and carrier phase measurements using externally provided satellite clock and orbit products.
The difference between the PPP clock solutions of two stations yields the difference between their two clocks. The average of the clock differences is determined by the code measurements, because only the code data are unambiguous. The clock frequency solution (shape/derivative of the time curve) is derived from the carrier phase data because, although ambiguous by an integer number of wavelengths, they are about 100 times more precise than the code data.
The high timing precision of PPP, at the level of tens of picoseconds over averaging times from a few minutes to a few hours, can unfortunately be marred by noticeable receiver-based frequency offsets. Figure 1 (for all figures and equations, see inset photo, above right) shows an example of this, corresponding to the difference between two daily PPP clock solutions of two receivers connected to a common clock and common antenna. We would expect the differences to be zero, with white noise superimposed, and in fact the averages over a day are nearly zero. However, a sawtooth pattern also appears that repeats each day.
We will show that this sawtooth pattern is due to the satellite motion during a microsecond-level difference between the latching times (effectively the measurement times) for the code measurements and the phase measurements in one of the two receivers. Because the receivers report these as simultaneous observations, the effect is to add a systematic frequency offset to the phase data.
Figure 2 shows the between-receiver difference of the slopes of a linear fit on the ionosphere-free linear phase combination over each complete satellite track (i.e., from when a satellite rises above the horizon until it sets below it), and the non-zero values show that the frequency offset is present during each track. The slope difference of 200 picoseconds/ day was strongly reduced after MJD 56015, coincident with a firmware change that reduced the latching offset between the code and phase measurements by five microseconds.
To explain why having the same latching time is important, we start with the fact that only the unambiguous code measurements can be used to determine the actual emission time of the signals; therefore, the phase data will use a code-determined satellite position in the modeling, based on the code data latching time instead of the phase latching time. Neglecting all satellite-based and propagation error sources, the code and carrier phase measurements are essentially the sum of the geometric range from the antenna to the satellite and the receiver clock bias multiplied by the speed of light.
Consider two receivers connected to the same frequency reference and the same antenna that take their measurements with a short time offset of Δt. The receivers’ code and carrier phase measurements will differ by a term due to a clock bias difference (c.Δt) and a term that accounts for the fact that the satellite has moved during the short interval Δt and that its geometric range has changed as a result. The rate of change of the geometric range is equal to the satellite Doppler in hertz multiplied by the carrier wavelength.
The differences in code and phase measurements of two co-located receivers r1 and r2, driven by a same frequency but de-synchronized by an offset Δt, can therefore be expressed as:
Pi,r1(t,sat) – Pi,r2(t,sat) = Li,r1(t,sat) – Li,r2(t,sat) + A
= c Δt + fD,i(t,sat)λI Δt + A Equation (1)
where the term A accounts for the carrier phase ambiguities.
Let us consider as an example two receivers using the same atomic clock frequency, but offset in time by 201 microseconds. Figure 3 presents the differences between the code and phase measurements for several satellite tracks, as well as the theoretical value from Equation (1). In the carrier phase differences, the ambiguity over each track was removed, so that all the tracks have an average of zero.
Let us now consider a single receiver in which the phase measurements are made after the code measurements with delay τ. To fully remove ionospheric effects, we work with the dual-frequency ionosphere-free combination of codes (P3) and phases (L3). In this case, the differences between the code and carrier phase data will contain a satellite-independent constant clock-bias and a satellite-dependent term corresponding to the integrated Doppler frequency over the interval τ. Specifically, the difference between code and phase measurements at the time t for a satellite, in cycles, is given by:
Equation (2) (for all figures and equations, see inset photo, above right)
where A(sat) is the ambiguity and w(t,sat) is the carrier phase windup. (More information on carrier phase windup is available in Sunil Bisnath’s GNSS Solutions article in the July/ August 2007 or in the Additional Resources section near the end of this article.)
The correction associated to the latching offset (or bias) Δ(t,sat) is what needs to be applied in a PPP analysis. It is unfortunately never applied in normal receiver operation, and for most receivers the value of the latching offset is not even known to the users. Note also that only the second term of Δ(t,sat) is relevant as the first term is constant and absorbed by the carrier ambiguity estimate.
The effect of code-carrier latching biases on a PPP clock solutions has been simulated with the PPP software Atomium developed by the Royal Observatory of Belgium using artificial code-phase latching biases of 2, 5, and 10 microseconds (Figure 4). Based on the differences from the original PPP solution, we concluded that a code-phase latching bias causes a frequency bias directly proportional to the offset, with an offset of one microsecond creating a 30 picosecond/ day frequency bias for mid-latitude stations. This is consistent with Figures 1 and 2 that were generated from a receiver having a latching bias of about 5 microseconds.
Origins of Code-Phase Latching Offsets
A code-phase latching offset in receivers can have two different origins. One is a firmware-fixed offset applied to the code measurements to compensate for group delay effects in the reception chain. This will appear as a code-phase latching bias, and, therefore, the associated Doppler term must be added to the carrier phase data. It should theoretically also be added to the code data, but it is very small with respect to the code noise and has a zero average over the satellite track. Hence, provided each track is completely observed, the Doppler term does not influence the average of the code measurements, which gives the average of the PPP clock solution.
A second cause of code-phase bias is the delays in the receiver’s digital correlation process. Signal tracking involves maximizing the correlation between the incoming signal and local signal replicas generated by code and carrier generators implemented in the receiver’s digital circuits (Figure 5).
Due to the delays δtC and δtφ from the code and carrier generators to the correlator, the code and carrier generators must run slightly in advance of the incoming GNSS signal. If δtC and δtφ differ, one of the generators will run ahead of the other, and this will have the same effect as a code-phase latching offset.
Estimation of Code-Phase Latching Offsets
Although a code-phase latching offset can be very dramatic when observed in common-clock and common-antenna mode, as in Figure 1, it is often small enough to be missed in the timing data of isolated receivers. Non-recognition of the problem would result in a mis-measurement of the frequency difference between precise clocks, such as masers, atomic fountains, or optical clocks.
Instead, differencing the code data residuals from the phase residuals removes the effects of the reference time scale and all effects common to both the phase and code. This leaves the second-order ionosphere effect, the ambiguities, and the latching bias. The second-order ionosphere effect is below the 10-picosecond level and thus insignificant, and the ambiguities are estimated explicitly.
We then computed the slope of code-minus-phase residuals — which represents the frequency bias and, in turn, the latching bias — for each satellite track, and the average slope was estimated over different batch lengths. Note that errors in estimating ambiguities can affect the frequency determination quantitatively, depending upon the relative code and phase weights (during PPP processing).
The approach that we have described here requires very long data sets in order to estimate the frequency bias with sufficient precision. The effect is readily observed over periods of a few days or less, but monthly solutions require reducing the code’s weight to reveal the effect.
Figure 6 shows the estimated frequency biases from the monthly PPP solutions of October, November, and December 2014, for all seven types of receivers that contributed data to the BIPM (Bureau International des Poids et Mesures).
To generate these results, the code was down-weighted by 10 billion. The formal errors in the slope determinations are about 4.4 picoseconds/day, or about the size of the circles in the plot. The fact that the points differ for the various months can be explained largely by differences in the ambiguity determination.
We can see that the non-zero mean slope of the code-minus- phase residuals is widespread among receiver types. However, it should be possible to design receivers with minimal difference between the code and phase latching times.
Outcome
In September 2015, in view of these considerations, the Consultative Committee on Time and Frequency passed a resolution calling upon manufacturers of geodetic receivers to reduce their latching time biases to less than 100 nanoseconds, after due allowance is made for all receiver hardware, software, and firmware delays.
The sidebar, “CCTF Recommendation on GNSS Receiver Design,” (below) suggests a change that could improve the performance of receivers for time and frequency applications.
SIDEBAR: CCTF Recommendation on GNSS Receiver Design
The following 2015 Recommendation from the Consultative Committee for Time and Frequency addresses suggested modifications in the design of GNSS receivers used for timing applications:
Considering that
- The use of a combination of code and carrier phase GNSS measurements enables time and frequency transfer with sub-nanosecond precision,
- This technique is routinely used for UTC generation,
- GNSS measurements are expected to be used by a greater number of applications that require greater precision, such as the comparison of optical frequency standards and atomic fountains,
- The precision of the GNSS time and frequency transfer solution relies on the accurate knowledge of the lathing time (effective reception times) of each measurement; noting that
- while considered as synchronous, the latching times of phase and code data can be systematically offset by several microseconds,
- some receiver produce code measurements corrected for a constant bias to account for internal hardware delays, inducing an apparent latching time offset between the code and carrier phase measurements,
- the difference between the latching times of code and phase induces a Doppler increment in the carrier phase measurements relative to the codes, causing a frequency bias in the phase data and hence in the clock solution obtained from GNSS analysis,
- this frequency bias results in a laboratory clock’s frequency appearing to be biased by 30 ps/day for every microsecond of latching offset; recommends that
- Manufacturers design future receivers and firmware upgrades so that the absolute value of the latching time offset between code and carrier phase measurements provided in the observation files is less than 100 ns, taking into account all relevant receiver internal delays, and include this information in the receiver specifications.
Further Reading
For information on about the link between code-phase latching offset on frequency bias, refer to the following:
[1] Defraigne, P., and J-M. Sleewaegen, “Correction for Code-Phase Clock Bias in PPP”, Proceedings Joint Meeting of the International Frequency Control Symposium and European Forum on Time and Frequency, Denver, Colorado USA, 2015
[2] Matsakis, D., Z. Jiang and W. Wu, 2015, “Carrier Phase Biases in Receivers Used for UTC Generation”, Proceedings Joint Meeting of the International Frequency Control Symposium and European Forum on Time and Frequency, Denver, Colorado USA, 2015
[3] Matsakis, D., and Z. Jiang and W. Wu, “Carrier Phase Biases in Receivers Used for UTC Generation,” Proceedings Institute of Navigation Pacific PNT Meeting, Honolulu, Hawaii USA, 2015
[4] Weiss, M. A., and J. Yao and Y. Li, 2013, “In Search of a New Primary GPS Receiver for NIST” in Proceedings of the 44th Annual Precise Time and Time Interval (PTTI) Systems and Applications Meeting, Reston, Virginia USA, December 2012
For information on phase windup and second-order ionosphere effects, refer to the following:
[5] Pireaux, S., and P. Defraigne, L. Wauters, N. Bergeot, Q. Baire, C. Bruyninx, “Higher-Order Ionospheric Effects in GPS Time and Frequency Transfer,” GPS Solutions, 14(3), 267-277, 2010
[6] Wu, J., and S. Wu, G. Jahh, W. Bertiguer, and S. Litchen, “Effects of Antenna Orientation on GPS Carrier Phase Measurements,” Manuscripta geodaetica, 18, pp. 91-98, 1993
