Introduction

Precise point positioning (PPP) is one of the existing techniques for determining a point’s coordinates using the Global Positioning System (GPS). With this technique, observations produced by a single receiver are used to determine its three coordinate components, as well as other parameters such as the receiver clock error and the total neutral atmosphere delay of the observations. The technique is said to be “precise” because precise a priori information, such as satellite orbits and clock errors, is used in the data processing and because the resulting position coordinates are precise (and accurate). We demonstrate that PPP can be used not only for positioning, but for a variety of other tasks, because the observation model must take into consideration the several effects present in GPS signals and undifferenced observations. The observations are undifferenced because observations from only one receiver are used. Single-difference observations between two receivers, as are commonly used in relative positioning, are not formed. While it is still possible to form between-satellite single-differences in PPP, the common approach avoids this. The primary advantage of PPP is that a user does not need observation data from other receivers to determine the position of their own receiver.

The PPP application developed at University of New Brunswick (UNB), which is called GAPS (GPS Analysis and Positioning Software), has proven to be very versatile. In addition to position, receiver clock error, and neutral atmosphere delay, parameters such as ionospheric delays, code biases, satellite clock errors, and code multipath, among others can be estimated. In all cases, the procedures were developed to be suitable for real-time as well as post-processing applications. GAPS provides state-of-the-art conventional PPP results in either static or kinematic mode. The application is available online through the UNB Geodesy and Geomatics Engineering Research and Learning Resources web page (UNB—http://gge.unb.ca/Resources/Resources.html. Accessed 29 December 2009).

Before discussing the features and algorithms in detail, we note some of the novel features that were implemented in GAPS.

  • The ionospheric delay estimation uses a spherical ionospheric shell model, in which the vertical delays are described by means of a zenith delay at the station position and two horizontal gradients. This estimation makes use of carrier-phase measurements only.

  • The code multipath estimation is based on the assumption that non-multipath errors are common to both code and carrier-phase observations. Therefore, these effects can be removed from code measurements, and the leftover effect is essentially the code multipath plus receiver noise.

  • One of the implemented analysis tools produces values of the satellite code biases based on a positioning observation model, rather than a satellite clock estimation observation model as is usually the case when bias values are provided to users.

  • Regarding satellite clock error estimates, we enhanced our PPP software in order to provide estimates of satellite clock offsets. This tool was created aiming at a suitable approach for real-time satellite clock estimation from carrier phases.

PPP and GAPS, the GPS data analysis and positioning software

The GPS community appears to have reached a consensus regarding a standard PPP observation model. Several authors (Leandro and Santos (2006), Tétreault et al. (2005), Gao and Chen (2004), Zumberge et al. (1997)) have published work using similar observation models, with ionosphere-free combinations of code and carrier phase. A few differences can be found among them, such as the estimation process for neutral atmosphere delay; e.g., a random walk stochastic process versus constant values for given time intervals. Ignoring multipath, receiver noise, and other unmodeled effects, the basic PPP observation model is given by:

$$ P_{\text{if}} = \rho + c\left( {d{\it{T}} - d{\text{\it{t}}}} \right) + T $$
(1)

and

$$ \Phi_{\text{if}} = \rho + c\left( {d{\it{T}} - d{\text{\it{t}}}} \right) + T + \lambda_{\text{if}} N_{\text{if}} $$
(2)

where P if is the ionosphere-free combination of code measurements; Φ if is the ionosphere-free combination of carrier-phase measurements in metric units; ρ is the geometric distance between satellite and receiver antenna phase centers; c is the vacuum speed of light; T is the neutral atmosphere delay (where T stands for troposphere); dT and dt are the ionosphere-free receiver and satellite clock errors, respectively; λ if is the ionosphere-free effective carrier-phase wavelength; and N if is the ionosphere-free carrier-phase ambiguity parameter. This last term is not simply the combination of ambiguities, but the combination of a few terms, including ambiguities; this is the reason why it is being called here the “ambiguity parameter.”

We do not discuss the ambiguity term in (2), but for several reasons, this term is not an integer value, as happens in the case of double-differenced observations. This aspect has made it virtually impossible to fix ambiguities in the case of conventional PPP.

The description of GAPS contained in this section has been also partially presented in Leandro and Santos (2006). The package has been configured to accept an observation file in the RINEX 2.10 or 2.11 formats. IGS product files necessary for processing the observations are automatically retrieved from one of the IGS global data centers.

The main goal in developing GAPS was to come up with a state-of-the-art positioning tool; however, GAPS showed itself to be much more versatile than that, allowing innovative data analysis and quality control procedures. The GAPS PPP engine uses the functional model given by (1) and (2). The data processing is done on an epoch-by-epoch basis, according to:

$$ P_{\text{if}} - \rho + c \cdot dt - m \cdot T = A_{X} \delta_{X} + A_{Y} \delta_{Y} + A_{Z} \delta_{Z} + c \cdot dT + m\delta_{T} $$
(3)

and

$$ \Upphi_{\text{if}} - \rho + c \cdot dt - m \cdot T - \lambda_{\text{if}} N_{\text{if}} = A_{X} \delta_{X} + A_{Y} \delta_{Y} + A_{Z} \delta_{Z} + c \cdot \delta_{dT} + m\delta_{T} + \lambda_{\text{if}} \delta_{N} $$
(4)

where δ X, δ Y, δ Z, δ dT, δ T, and δ N are the computed updates for receiver coordinates (X, Y, and Z), receiver clock, neutral atmosphere delay, and the ambiguity parameter, respectively, and m is the neutral atmosphere non-hydrostatic delay mapping function (Niell 1996). The parameters can be set as:

  1. a)

    constants—one single value is computed for the whole dataset. Example: ambiguities and coordinates in static positioning;

  2. b)

    stochastic parameters—the computed values are allowed to change over time but the rate of change is limited and dictated by a process noise that is added to the parameter every epoch. Example: neutral atmosphere delay;

  3. c)

    white noise parameters—the parameter is allowed to freely change from one epoch to another. Example: receiver clock and coordinates in kinematic positioning.

The update vector is computed using the least-squares technique, according to:

$$ {\varvec\delta} = \left( {\mathbf {A}^{\text t} {\mathbf{PA}} + {\mathbf{C}}_{x}^{ - 1} } \right)^{ - 1} {\mathbf{A}}^{\text t}{\mathbf{Pw}} $$
(5)

where δ is the update vector, A is the design matrix, P is the weight matrix, C x is the covariance matrix of the parameters, and w is the misclosure vector. At each epoch, the covariance matrix is updated according to:

$$ {\mathbf{C}}_{x} (t) = \left( {{\mathbf{A}}^{\text t} {\mathbf{PA}} + {\mathbf{C}}_{x}^{ - 1} (t - 1)} \right)^{ - 1} + {\mathbf{C}}_{n} $$
(6)

where C n is the process noise matrix, for which the values vary depending on the type of parameter. The values of C n are usually not a function of time. Symbols (t) and (t − 1) are epoch indicators for C x . The misclosure vector is computed in the same way as on the left-hand side of (3) and (4), with the addition of all necessary model components: earth tides, antenna phase center offset and variation, satellite code biases (in cases when the C/A-code is used), phase wind-up, relativistic effects, and so on. A description of most of these effects can be found in Kouba (2003) and Tétreault et al. (2005). A similar solution approach to (5) and (6) is used in other parts of GAPS, as will be discussed in later sections.

Figures 1, 2, 3 show results from a series of 24-h solutions for IGS station UNBJ over the year 2008, using GAPS in static mode (meaning GAPS is considering UNBJ as a stationary station) with IGS final orbits and clocks. The data sample interval used was 5 min. The plot shows the difference between the GAPS solutions and the reference solution, in this case, the IGS cumulative solution from GPS week 1539 (considered as “true” here). For each day of analysis the coordinates from the IGS solution were transformed to the respective epoch using the site velocities.

Fig. 1
figure 1

GAPS 24-h position errors in X, Y, and Z for IGS station UNBJ

Full size image
Fig. 2
figure 2

GAPS 24-h position 2D and 3D errors for IGS station UNBJ

Full size image
Fig. 3
figure 3

Horizontal position error convergence in static mode (station UNBJ, 2008)

Full size image

As can be seen in Figs. 1 and 2, the coordinate estimates from GAPS using 24-h datasets from UNBJ agree with the coordinates published by IGS to within 1 cm horizontally and to within 2 cm in 3D. The formal uncertainties given by the software for those coordinates are usually optimistic with respect to the actual errors. According to our experience, the main factor for that behavior is the lack of time-correlations in the observation stochastic model used in GAPS.

Figures 3 and 4 show the position error convergence derived from all 24-h solutions from Figs. 1 and 2 at three confidence levels (95, 68, and 50%). In these plots the position solution provided by IGS is also the reference. As can be seen, in 95% of the cases, horizontal coordinates better than 5 cm are achieved with less than 3 h of observation in static mode. It takes longer (about 4 h) for the 3D position error to achieve the same error level. It can be seen that after 12 h of observation there is little improvement in the coordinates as more data are processed.

Fig. 4
figure 4

3D position error convergence in static mode (station UNBJ, 2008)

Full size image

Figure 5 shows the neutral atmosphere delay (NAD) estimates from all 2008 24-h solutions (same as Figs. 1 and 2). The delay parameter was modeled as a random walk with process noise of 5 mm/h0.5. The delay provided by the UNB3 m model (Leandro et al. 2008a) was used as the a priori value, with a given uncertainty of 10 cm (1-sigma).

Fig. 5
figure 5

Neutral atmosphere total zenith delay estimates over 24 h for each day of the year (station UNBJ, 2008)

Full size image

As expected, the neutral atmosphere delay estimates converge to different values on each day, making it difficult to visualize the actual amount of time needed to achieve the stabilization of the parameter. It can be noticed that the NAD estimates are somewhat stable over the day, for most of the runs. This might be due to NAD stochastic modeling that is too tight in the current implementation of GAPS. Other potential causes are as follows: (a) in GAPS, the station height and the tropospheric delay are estimated at the same time, while an optimal NAD estimation is achieved when a known height is constrained in the data processing; and (b) the elevation angle cutoff used in the data processing was 10 degrees, which might not be low enough for a proper de-correlation between NAD and height, since the non-hydrostatic mapping function is only around 1.8% different from 1/sin(elevation) for this elevation angle (values of 5.657 and 5.759, respectively). In summary, the current settings of GAPS concerning neutral atmosphere modeling might not optimize the delay estimation and will be investigated further. For a better illustration of the stabilization of the NAD parameter, Fig. 6 shows the difference of the estimation between two consecutive epochs (spaced by 5 min), where it is easy to notice that it usually takes about 1 h for the estimates to vary less than a centimeter over a time span of 5 min.

Fig. 6
figure 6

GAPS neutral atmosphere delay estimate epoch-to-epoch differences (station UNBJ, 2008, data rate of 5 min)

Full size image

One of the main concerns related to PPP is the convergence time required to produce meaningful estimates. Even though the final accuracies that can be achieved with this technique are certainly very good, as shown here, the time required to achieve them (usually around several tens of minutes) is currently a bit of a impediment in the use of PPP for real-time applications. We will comment further on this deficiency and potential remedies in the concluding section of this paper.

PPP-based ionosphere activity estimation

GPS receiver networks have been used for monitoring the ionosphere for some time, but our method was created to be suitable for single receiver operation. The filter used to estimate ionospheric delays is connected to the PPP filter within software (not as a pre- or post-processing stage). This filter only uses carrier-phase measurements to avoid unwanted effects present in code measurements. Details about this technique can be found in Leandro et al. (2007b).

The ionospheric estimation is performed using the following model:

$$ \Phi_{\text{gf}} = \left( {1 - \gamma } \right){\text{MF}}\left( {I_{v,0} + \nabla_{\varphi } \left( {\varphi_{p} - \varphi_{0} } \right) + \nabla_{\lambda } \left( {\lambda_{p} - \lambda_{0} } \right)} \right) + Nb'_{\text{gf}} $$
(7)

where Φ gf is the geometry-free carrier-phase (Φ1 − Φ2) observation in length units; MF is the ionosphere mapping function, which is based on a spherical ionospheric shell model as shown in Fig. 7; I v,0 is the vertical ionospheric delay at the station position; ∇ ϕ and ∇ λ are latitudinal and longitudinal gradients, respectively; ϕ p and λ p are the geodetic latitude and longitude of the ionospheric pierce point–the point where the signal path pierces the ionospheric shell; ϕ0 and λ 0 are the latitude and longitude of the station; and \(Nb'_{\text{gf}}\) is an ambiguity parameter that includes the carrier-phase integer ambiguity plus a collection of biases. The mapping function is computed according to:

$$ {{MF}} = {\frac{1}{\sin (\beta )}} = \sqrt {1 - \left( {{\frac{r \cdot \cos (e)}{{r + {{sh}}}}}} \right)^{2} } $$
(8)

where r is the mean radius of earth, sh is the ionospheric shell height (default value is 350 km), β is the satellite elevation angle at the shell height piercing point, and e is the elevation angle of satellite S as seen from station O.

Fig. 7
figure 7

Elements of the ionospheric shell model (not to scale)

Full size image

The ionospheric estimation is performed by means of a least-squares adjustment similar to (5) and (6), where the parameters are the ionospheric model elements (vertical delay and gradients) and the ambiguities. With respect to the noise model (used in (6)), the ionospheric model parameters are treated as stochastic parameters, while the ambiguities are assumed constant (thus no noise is added to them).

Figures 8 and 9 show results of the estimation for station UNBJ/UNB1, for periods of low and high geomagnetic activity. These periods were chosen based on Kp index values, obtained from the National Oceanic and Atmospheric Administration (NOAA) Space Environment Center, Boulder, CO (NOAA—http://sec.noaa.gov/ftpmenu/indices/old_indices.html. Accessed 15 February 2007), as a proxy for ionospheric activity.

Fig. 8
figure 8

Ionospheric delays and code and carrier-phase residuals for station UNBJ, DOY 6 to 10, 2007

Full size image
Fig. 9
figure 9

Ionospheric delays and code and carrier-phase residuals for station UNB1, DOY 312 to 316, 2004

Full size image

During the quiet period (DOY 6-10, 2007), the residuals for UNBJ had values usually within ±2 and ±1 TECU (total electron content units) for slant and vertical values, respectively, while for the disturbed period (DOY 312-316, 2004), the amplitude of the residuals reached approximately 5 TECU at times. The spread of the residuals is reasonably stable over the days of the quiet period, a characteristic not true of the disturbed period where large variations in the residuals spread can be easily seen. In the second plot the station name is UNB1 because the observations were made prior to the station rename from UNB1 to UNBJ in 2006 (Langley 2006). Figures 10 and 11 show a comparison of the ionospheric delays computed by GAPS with those provided by IGS, through the final IGS IONEX map. A comprehensive description of the IONEX format can be found in the document “IONEX: The IONosphere Map EXchange Format Version 1”, which is accessible online at ftp://igscb.jpl.nasa.gov/igscb/data/format/ionex1.pdf.

Fig. 10
figure 10

Comparison of ionospheric delay results provided by GAPS (blue dots) and IGS (red line) for a low ionospheric activity period

Full size image
Fig. 11
figure 11

Comparison of ionospheric delay results provided by GAPS (blue dots) and IGS (red line) for a high ionospheric activity period

Full size image

Notice that the ionospheric delay filter has difficulties in following the ionospheric activity variation at times, e.g. DOY 315, which corresponds with the larger residuals seen in Figs. 8 and 9. Another effect that can be noticed most clearly in Fig. 10, but also in Fig. 11, is the bias between the two solutions. It is not clear why such biases exist and continued research is needed to investigate the differences between the ionospheric delays provided by GAPS and IGS. Among probable reasons we can point out possible differences in the ionospheric shell model, e.g. differing shell height, between the two solutions. Table 1 shows the statistics of the comparison for each of the periods.

Table 1 Statistics of the GAPS and IGS map comparisons (in the sense GAPS-IGS)
Full size table

In general, the values shown in Table 1 are within the accuracy claimed by IGS for its ionosphere maps: 2–8 TECU for the final maps such as those in this analysis. The level of agreement is even more striking when one considers that a station-network technique (IGS) is being compared with a single-station technique (GAPS).

PPP-based code bias estimation

The analysis of this section has been explored in detail in Leandro et al. (2007a). Hardware delay is one of the effects that has to be taken into account when using GPS under certain conditions. These delays can be different for each observable and frequency, which means that depending on the signal used in a given application, accounting for the hardware delays might be a mandatory step to achieve the targeted accuracy. The hardware delay is usually determined in a relative sense, where a given observable and frequency or frequency combination is used as a standard. Because of this, the values that are determined are usually called biases, because they represent the bias between two observable types, and can be represented in time or length units. One can separate the instrumental biases into two general classes: the inter-frequency biases, which are the biases between observables on two or more frequencies; and the intra-frequency biases, which are the biases between two observables from the same frequency.

Intra-frequency biases are of interest for two types of applications: network data processing and single receiver data processing. Sometimes, receiver networks are formed by receivers of several types, collecting different observable types. Currently, the only intra-frequency bias of wide interest for the GPS community is the P1-C1 bias. C1 and P1 observables have to be mixed in networks formed by non-cross-correlation receivers which collect P1, non-cross-correlation receivers reporting C1, and cross-correlation receivers which report only C1 on the L1 frequency. According to the RINEX standard, C1 is the code observable obtained by tracking the C/A-code on L1 and P1 is the code observable obtained by tracking the underlying P-code on L1. On the single receiver side, the need to account for biases depends on whether the receiver is using the same observables that were used to compute satellite clocks or not.

It is important to mention that the delays, and consequently the biases, exist for both receivers and satellites. In a positioning scenario, the receiver’s biases are usually absorbed by the receiver clock error parameter in the adjustment as long as only one type of observable is being used; thus, only the satellite biases explicitly have to be taken into account. In the same sense, instrumental biases are not an issue for relative positioning, because they are eliminated together with satellite and receiver clocks in the double differencing.

One simple way of estimating code biases is to compare two different codes simultaneously observed by the same receiver. This technique delivers the receiver-satellite differential bias, which means the receiver part of the estimated quantity still has to be eliminated in order to obtain the satellite bias. Because the biases can be considered as constant corrections for satellite clock error estimates used for positioning over typical observation periods, it is desirable that these biases are estimated in a way in which the consistency between biases and clock products is assured. This is usually done, since the differential satellite biases are generally estimated together with the satellite clocks. This is the procedure, for example, at the Center for Orbit Determination in Europe (CODE—http://www.aiub.unibe.ch/ionosphere.html. Accessed 1 May 2007). In the PPP-based technique, we match this approach by using the clock products for estimating the satellite differential biases, as will be seen later.

To estimate code biases, we implemented a novel approach inside GAPS (Leandro et al. 2007a). The observational model assumes that IGS clock products are being used; thus, the clocks are referenced to a P1&P2 ionosphere-free combination. However, a combination of C1 and P2 is used, leading to:

$$ P_{\text {if}(\text C1,\text P2)} = \rho + T + c\left( {dT - dt} \right) + \alpha \cdot b_{\text P1 - \text C1} $$
(9)

where, again, ρ is the geometric distance between satellite and receiver antenna phase centers, c is the vacuum speed of light, T is the neutral atmosphere delay, dT and dt are the ionosphere-free receiver and satellite clock errors, respectively, and where α is the coefficient for L1 in the ionosphere-free linear combination equation:

$$ P_{\text {if}(\text C1,\text P2)} = \alpha \cdot C1 - \beta \cdot P2 $$
(10)

where α can computed as

$$ \alpha = {\frac{{f_{1}^{2} }}{{f_{1}^{2} - f_{2}^{2} }}} \cong 2.55 $$
(11)

and β can be computed as

$$ \beta = {\frac{{f_{2}^{2} }}{{f_{1}^{2} - f_{2}^{2} }}} \cong 1.55. $$
(12)

In (9), we have ignored multipath and other effects for the sake of clarity.

The code bias parameter b P1–C1 can then be estimated using a least-squares adjustment, similar to that represented by (5). The observation weights should vary according to the elevation angle of each observation. Assuming the effect of multipath is less critical for higher elevation angles, an elevation angle–based weighting scheme should help to reduce the impact of multipath and receiver noise on the bias estimation.

Data from nine receivers distributed worldwide and observed between 1 and 10 January 2007, inclusive, were used in testing our approach. This dataset was used to estimate satellite differential P1–C1 biases, according to the procedure above. The validation of the estimated P1–C1 biases was carried out by comparing the values from GAPS with values determined by CODE. At the beginning of each month, CODE’s monthly differential code bias (DCB) solutions for the preceding month are computed, automatically archived, and made available. The solution from January 2007 was used in this comparison. Figure 12 shows a comparison of P1–C1 biases determined by CODE and the mean biases from GAPS. The blue bars (on the left side of each bar pair) represent the GAPS solution, while the red bars (on the right side of each bar pair) represent the CODE solution.

Fig. 12
figure 12

Comparison of satellite differential P1–C1 biases determined with GAPS and by CODE in distance units

Full size image

As shown in Fig. 12, there is reasonable agreement between the two solutions. Figure 13 shows the formal uncertainties provided by the two solutions, and for the differences between them.

Fig. 13
figure 13

Satellite differential P1–C1 bias uncertainties determined with GAPS and by CODE in distance units

Full size image

Differential P1–C1 biases of PRNs 12, 17, and 31 were not estimated because the data from these satellites were used for P2–C2 differential biases estimation. A discussion of the P2–C2 bias determination and results can be found in Leandro et al. (2008b). No PRN 15 or 32 satellites were operating at this time. To more easily compare the GAPS and CODE results, Fig. 14 shows the differences between them, in the sense GAPS-CODE.

Fig. 14
figure 14

Differences of the satellite differential P1–C1 biases determined by CODE and with GAPS (mean bias removed)

Full size image

The GAPS and CODE differences are summarized with the statistics in Table 2. From this table, one sees that the one sigma agreement between the two determinations is around 3.6 cm with a maximum difference of approximately 7 cm. These values are reasonably small given typical code measurement errors of tens of centimeters or more. Nevertheless, the differences are large compared to the uncertainties provided by GAPS. This is probably caused by neglecting correlations, especially temporal correlations, in the GNSS data, which can lead to optimistic uncertainties (Leandro and Santos 2007).

Table 2 Statistics of the comparison of P1–C1 bias determinations (GAPS-CODE), before removing a mean bias between the two solutions
Full size table

PPP-based code noise estimation

Inside GAPS, the point positioning model is sufficiently accurate to eliminate most of the effects present in the code measurements leaving residuals that are essentially multipath and other effects such as receiver thermal and oscillator noise. Extending (1) to explicitly show some of the noise sources, we have:

$$ P = \rho + T + I + c\left( {dT - dt} \right) + DCB + m_{P} + e_{P} $$
(13)

where P is the code measurement; ρ is the geometric distance between satellite and receiver antenna phase centers, which can be well determined with precise orbits and PPP-based receiver coordinates and associated antenna phase center models; T is the neutral atmosphere delay, which can be determined by means of a PPP-determined zenith delay coupled with a mapping function; I is the ionospheric delay, which can be accounted for with values from the ionospheric delay filter of GAPS or from IONEX maps; c is the vacuum speed of light; dT is the receiver clock error, computed as one of the parameters of the PPP solution; dt is the satellite clock error, which can be computed by using precise clock products; DCB is the differential code bias, and m P  + e P is the effect of multipath and noise (note that the subscripts distinguish the latter two terms from the neutral atmosphere mapping function and elevation angle, respectively). The DCB term can be eliminated from (13) because the noise observable passes through a moving average filter in GAPS, which makes the software insensitive to such biases. Now, rewriting (13) to isolate the noise observable (hereafter, “code noise”), we are left with:

$$ \left( {m_{P} + e_{P} } \right) = P - \left( {\rho + T + I + c\left( {dT - dt} \right)} \right). $$
(14)

Even though the carrier-phase observable is not directly used in the code noise computation, the latter depends on parameters that can only be well determined using carrier-phase measurements, such as the zenith neutral atmosphere delay.

In order to illustrate the code noise estimation procedure, we processed 1 h of data, 0 h–1 h on 8 January 2007 GPS Time, from IGS station ALGO located in Algonquin Park, Canada. We computed the C1 and P2 code multipath, mp, values using UNAVCO’s TEQC software (Estey and Meertens 1999), which estimates code multipath using a combination of code and carrier-phase measurements. Figures 15 and 16 show the PRN 6 C1 and P2 code noise estimated from GAPS and TEQC.

Fig. 15
figure 15

C1 code noise obtained with GAPS and TEQC for PRN 6 observed at ALGO on 8 January 2007

Full size image
Fig. 16
figure 16

P2 code noise obtained with GAPS and TEQC for PRN 6 observed at ALGO on 8 January 2007

Full size image

Similarly, Figs. 17 and 18 show the PRN 21 C1 and P2 code noise, respectively.

Fig. 17
figure 17

C1 code noise obtained with GAPS and TEQC for PRN 21 observed at ALGO on 8 January 2007

Full size image
Fig. 18
figure 18

P2 code noise obtained with GAPS and TEQC for PRN 21 observed at ALGO on 8 January 2007

Full size image

It is clear that the behavior of the plots above is not exactly the same for GAPS and TEQC. This might be reasonably expected since the approaches used in the two pieces of software are completely different. Nevertheless, the main target of these analyses is to compute the overall noise level of the code, which is shown in Table 3:

Table 3 Code noise level (m)
Full size table

As can be seen from Table 3, the agreement between the two sets of noise level estimates is about 1–7 cm, with GAPS results being systematically smaller than the values provided by TEQC, which include the effects of carrier-phase multipath and noise.

PPP-based satellite pseudo-clock estimation

The idea of estimating satellite-related information with a single reference station is not new, since it is the basis of relative GPS positioning techniques. The different aspect reported here is our use of a PPP engine to derive the satellite pseudo-clock, which can be again used for positioning by another receiver. We are using the term “pseudo” for the estimated satellite clocks because unlike satellite clocks estimated from networks, effects such as residual neutral atmosphere delay, multipath, residual orbit errors and others are strongly present in the data, since they cannot be mitigated or averaged out to a certain degree such as when station networks are used.

One advantage in estimating satellite clock information rather than directly using reference station data is simple: the same satellite clock values can be used for both carrier-phase and code measurements (in relative GPS, it would be necessary to have the two types of observation from the reference station to perform between-station differences for code and carrier). Therefore, using single-station–derived pseudo-clocks might be advantageous in terms of bandwidth for data transfer communication under certain conditions. Another interesting aspect is that the use of reference station–derived pseudo-clocks for positioning may allow the integration of PPP and local structure–based positioning techniques, as these different positioning technologies develop and/or converge. In addition, the fact that a reasonable clock solution could be derived from one single receiver could be used as a basis concept for techniques with federated estimators to be used for improving performance in processing data from large networks. Therefore, the aim of this investigation is not to find a concurrent clock solution mimicking the already existing global network-based techniques, but to bring potentially new (rather simple) concepts to the mind of the reader concerning clock effects within GNSS.

The main equation of the single-station pseudo-clock estimation procedure is:

$$ \begin{gathered} \Phi_{\text{if}} + c_{\text{if}} - R_{0} - T_{0} + \lambda_{\text{if}} N'_{\text{if},0} = \hfill \\ c\left( {dT - dt} \right) + \lambda_{\text{if}} \delta N'_{\text{if}} + \delta R + \delta T + m_{\text{if}} + e_{\text{if}} \hfill \\ \end{gathered} $$
(15)

where the subscript 0 stands for a priori values. Note that this approach does not produce pure clock values, but rather a collection of effects, including ambiguity, residual geometry errors (e.g., orbits), residual neutral atmosphere delay, multipath, and noise. Again, this is the reason why we are calling them pseudo-clocks, rather than simply clocks.

In order to give a brief example of the results that can be achieved by estimating pseudo-clocks and using them for positioning, we have used data from two IGS stations: UNBJ and SHE2. These stations are about 164 km apart.

Figure 19 shows a comparison between GAPS pseudo-clocks derived from SHE2 observations and IGS final clocks for PRNs 24 and 18.

Fig. 19
figure 19

Comparison between GAPS pseudo-clocks and IGS final clocks for PRNs 24 and 18 (DOY 1, 2008)

Full size image

At first, the two solutions look quite different; however, most of the difference comes from the SHE2 station internal clock, the reference clock for the single-station approach, and the ambiguity term. With these effects removed by differencing between satellites, the resulting comparison is as shown in Fig. 20. The important characteristic of clocks for float-phase–based PPP is the double-difference (DD) clock (between satellites and time). Therefore, these effects (i.e., variations in the reference clock and the bias) can be removed for the purpose of quality analysis because most of them are absorbed by some parameters when the pseudo-clock solution is used for positioning.

Fig. 20
figure 20

Comparison between GAPS pseudo-clocks and IGS final clocks for PRNs 24 and 18 differences (DOY 1, 2008)

Full size image

The similarity between the two solutions is achieved only because the same precise orbit product (final IGS orbits) was used either implicitly or explicitly for both of them. The rms of the difference between them is about 9 mm. It should be noted that the two estimates use rather different approaches and quantities of data. Whereas data from a global GNSS network is used for IGS clock solutions, a single station was used for the GAPS approach.

Figure 21 shows a comparison between a static UNBJ PPP solution using IGS final clocks and SHE2 pseudo-clocks, where two aspects can be seen: (1) GAPS pseudo-clocks provide a better convergence; and (2) position values achieved after 2 h are practically the same.

Fig. 21
figure 21

Comparison between the static positioning solutions for UNBJ using IGS final clocks and SHE2 pseudo-clocks (DOY 1, 2008)

Full size image

Figure 22 shows results for the same data, but in kinematic PPP mode, where it can again be seen that convergence is better when using the pseudo-clocks. The horizontal position rms values achieved for IGS clocks and GAPS pseudo-clocks (between 2 h and 5 h) were 2.44 cm and 2.29 cm, respectively, a difference of 1.5 mm. Potential reasons for an improvement in the convergence time are the absorption of nearly all residual orbit errors in the case of the pseudo-clock usage, due to the distance between stations of about 164 km, plus code-related effects such as code biases. Another point is that a perfectly consistent observation model is used for generating the clocks, and for applying them, since GAPS software is used for both tasks. Even though we do not go into detail regarding these aspects, it is important to mention that we are not claiming that the pseudo-clock solution is better than the IGS clock solution. It is actually more affected by errors, which, on the other hand, makes it more correlated with the observations of a station somewhat near to the reference station.

Fig. 22
figure 22

Comparison between the kinematic positioning solutions for UNBJ using IGS final clocks and SHE2 pseudo-clocks (DOY 1, 2008)

Full size image

Conclusions and further work

In this paper we have given an overview of GNSS data analysis capabilities that can be implemented in PPP software. The conclusions and future work activities can be summarized as follows.

In a comparison with IGS IONEX maps, the PPP single-station ionospheric delay estimation results for station UNB1/UNBJ had an agreement of around 1.5 TECU and 3.8 TECU for calm and storm periods, respectively. These results show great potential for estimating precise un-biased ionospheric total electron content with PPP.

When using our PPP package to compute code biases, we have compared results obtained for P1–C1 bias estimation with values provided by CODE. The overall agreement is better than 4 cm, where data of 10 days’ duration observed at 9 GPS stations was used for GAPS estimation. This result shows that, with our PPP-based technique, we can match other bias-estimation techniques at the few centimeter level.

We have compared our code-plus-noise estimation results using this analysis approach with those obtained using software TEQC from UNAVCO. In this comparison, we found an agreement of the code noise level, which usually ranges from a few centimeters to a couple of meters at times, to better than 7 cm. We have also found that GAPS estimates are systematically smaller than TEQC estimates, due most likely to differences in the two techniques rather than to data editing considerations.

When using GAPS for estimating satellite pseudo-clocks and comparing them with final IGS clocks, it was possible to find an agreement for between-satellite clock behavior of about 9 mm. When using pseudo-clocks for positioning with the same software and processing strategies, results show a better convergence time than using IGS clocks, and final accuracies were at about the same level for the two solutions.

Overall, we have shown that a PPP software package can be successfully extended in order to provide results of several kinds, not typically available with position-only products and techniques.

The main target for our further development is the upgrade of the software to handle GLONASS and Galileo data, as well as work on the direction of a real-time solution, in view of potential real-time IGS data streams, which are being made available.