GNSS Solutions • November/December 2015
How Important Is It to Synchronize the Code and Phase Measurements of a GNSS Receiver?"GNSS Solutions” is a regular column featuring questions and answers about technical aspects of GNSS. Readers are invited to send their questions to the columnist, Dr. Mark Petovello, Department of Geomatics Engineering, University of Calgary, who will find experts to answer them. mark.petovello@ucalgary.ca
Share via: Slashdot Technorati Twitter Facebook 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 onemicrosecond 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 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 receiverbased 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 microsecondlevel 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 betweenreceiver difference of the slopes of a linear fit on the ionospherefree 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 nonzero 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 codedetermined satellite position in the modeling, based on the code data latching time instead of the phase latching time. Neglecting all satellitebased 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 colocated receivers r1 and r2, driven by a same frequency but desynchronized by an offset Δt, can therefore be expressed as:
P_{i,r1}(t,sat) – P_{i,r2}(t,sat) = L_{i,r1}(t,sat) – L_{i,r2}(t,sat) + A 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 dualfrequency ionospherefree combination of codes (P3) and phases (L3). In this case, the differences between the code and carrier phase data will contain a satelliteindependent constant clockbias and a satellitedependent 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 codecarrier latching biases on a PPP clock solutions has been simulated with the PPP software Atomium developed by the Royal Observatory of Belgium using artificial codephase latching biases of 2, 5, and 10 microseconds (Figure 4). Based on the differences from the original PPP solution, we concluded that a codephase 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 midlatitude 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 CodePhase Latching Offsets A second cause of codephase 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 δt_{C} 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 δt_{C} and δt_{φ} differ, one of the generators will run ahead of the other, and this will have the same effect as a codephase latching offset.
Estimation of CodePhase Latching Offsets 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 secondorder ionosphere effect, the ambiguities, and the latching bias. The secondorder ionosphere effect is below the 10picosecond level and thus insignificant, and the ambiguities are estimated explicitly. We then computed the slope of codeminusphase 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 downweighted 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 nonzero mean slope of the codeminus 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 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
Further Reading
For information on about the link between codephase latching offset on frequency bias, refer to the following:
For information on phase windup and secondorder ionosphere effects, refer to the following: ManufacturersThe receivers that provided data to the BIPM as shown in Figure 6 include the following: Ashtech ZXII3T, formerly Ashtech now a part of Trimble Integrated Technologies, Sunnyvale, California USA; GTR50 from DICOM spol. s r.o., Uherské Hradiště, Czech Republic; the JPS Eurocard from Javad Positioning Systems, now part of Topcon Positioning Systems, Inc., Livermore, California USA; JAVAD E_GGD and JAVAD TRE_G3T from JAVAD GNSS, San Jose, California USA, and Moscow, Russian Federation; OEM4G2, OEM638, OEM638, OEMV3, and OEMV3G receivers from NovAtel, Inc., Calgary, Alberta, Canada; PolaRx2, PolaRx3ETR, and PolaRx4TR receivers from Septentrio, Leuven, Belgium; and TTS4 receivers from Piktime Systems, Poznań, Poland.Copyright © 2017 Gibbons Media & Research LLC, all rights reserved. 
