Analysis of a High Accuracy Service based on JPL’s Global Differential GPS

3.1 Comparison against CODE final products

One way to analyze the quality of the orbit and clock corrections and to ensure consistency with other similar products is to compare orbits and clocks to those provided by independent IGS analysis centers. In this case, the GPS+GLO and GPS+GAL products are compared against final products from the Center for Orbit Determination in Europe (CODE) (Dach et al., 2020).

The CODE products are file-based, with orbits referring to the satellites’ centers of mass and clocks referring to the ionosphere-free combination of L1/L2 for GPS, E1/E5a for Galileo, and G1/G2 for GLONASS. In contrast, GDGPS HAS orbits refer to the ionosphere-free antenna phase center at the primary frequencies, and GDGPS HAS clocks refer to the ionosphere-free combination of the primary frequencies. The primary frequencies for GDGPS HAS are L1/L2 for GPS, E1/E5b for Galileo, and G1/G2 for GLONASS. However, to compare the GDGPS HAS corrections to CODE, these differences in definitions must be accounted for. The CODE orbits are therefore moved to the respective antenna phase centers using the Antenna Exchange Format (ANTEX) IGS20 file (Villiger, 2022). The clock corrections are similarly aligned by applying differential code biases from the Chinese Academy of Sciences (CAS), which provides all the biases necessary for the alignment (Wang et al., 2016).

After the orbits are aligned, they can be transformed from an Earth-centered Earth-fixed (ECEF) frame to a satellite radial, along-track, and cross-track (RAC) frame. In this frame, the along-track component is the unit vector ϵ_A following the satellite velocity; the cross-track component is the unit vector ϵ_C formed from the cross product of the satellite position and velocity; and the radial component is the unit vector ϵ_R that completes the orthogonal frame. The RAC (δA, δC, and δR, respectively) frame can be computed based on the GDGPS HAS and CODE ECEF differences using Equation (1):

[δRδAδC]=[ϵRϵAϵC]T[XGDGPS−XCODEYGDGPS−YCODEZGDGPS−ZCODE]1

After the clock corrections are aligned, the clock comparison is simply the difference between the two sets of clocks: δCLK = CLK_GDGPS – CLK_CODE. However, clock references can be different between network providers, leading to shifts in the overall clock level for all satellites within each constellation. To counteract this effect, a mean clock per constellation is computed for each epoch and then removed from each satellite’s individual clock. This approach results in an overall clock shift that reduces any common bias between each constellation’s satellites. Such common biases do not affect user positioning because they get absorbed by receiver clocks. In addition, GLONASS is known for the presence of inter-signal biases (Håkansson et al., 2017), which appear as biases between individual satellites. To remove such inter-signal biases, the mean of the clock for each satellite on each day is subtracted from each satellite’s clocks.

An additional metric used to compare products is the URE, which relates the quality of products to their potential impact on user positioning. While a site-specific URE metric already exists, the global average URE can be derived (Chen et al., 2002). The URE computation is detailed in Equation (2):

URE=(δR−δCLK)2+0.0192(δA2+δC2)2

Table 1 summarizes the rms of the differences between GDGPS HAS and CODE in the radial, along-track, and cross-track components, as well as clocks and UREs. Each element in the table is generated based on seven days of data collected in late September and early October 2024 at five-minute intervals. Table 1 shows good performance from all products, with rms values below the decimeter level. However, a select few satellites (R730, R806, and R861 for SSRA21JPL0 (GPS+GLO) and R730 for SSRA22JPL0 (GPS+GLO)) had either higher radial or clock differences, leading to higher overall rms in the table. These outlier values are discussed in more detail in relation to Figure 2 below, and the rms values after these outliers were removed are shown in parentheses in Table 1.

• Download figure
• Open in new tab
• Download powerpoint

FIGURE 2

URE rms of the GDGPS HAS products compared against final CODE products for a seven-day period, shown separately for each satellite.

Comparing rms values among different streams shows consistent performance across the streams. In the case of GPS, radial differences are ~2.7 cm across all four correction streams, and clock differences are ~7.5 cm. Likewise, the GPS UREs range between 6 cm and 6.4 cm across all four corrections streams. Such URE values are equivalent to GPS UREs for BeiDou’s PPP-B2b service, as shown in Tang et al., 2022, though this previous study did not account for satellite clock differences in their URE computation and only focused on orbital corrections. The GPS URE values for GDGPS HAS reported here are also better than the signal-in-space range error (SISRE) values for Galileo HAS shown in Naciri et al., 2023. Note that these comparisons against BeiDou PPP-B2b and Galileo HAS are provided only to contextualize GDGPS HAS UREs among other similar, published values; rigorous URE comparison on the same data has not been performed.

In the case of Galileo, the quality of the corrections is also comparable between the two GPS+GAL streams (SSRA11JPL0 and SSRA12JPL0), with radial and clock differences of approximately 8 cm. The along-track and cross-track differences are higher for the SSRA12JPL0 stream compared to SSRA11JPL0, though these individual orbit and clock components nevertheless translate to a similar GAL URE of 6.9 cm in both correction streams. While the values reported here for some of the individual GAL components are higher than those reported in Naciri et al., 2023, the URE is nevertheless slightly better than the SISRE values for Galileo HAS, which were reported to be 10.8 cm. (Note that SISRE and URE are equivalent metrics used to quantify product quality).

The GLONASS corrections are more difficult to compare between different correction streams due to the presence of inter-frequency biases caused by the FDMA structure used by the constellation. These biases often appear as satellite-specific biases in the satellite clocks, which would affect comparisons of GLONASS clocks between two different correction streams. To mitigate this effect, a mean GLONASS clock per satellite was removed per day, based on the assumption that inter-frequency biases vary slowly over the course of a day. However, one consequence of this removal is that the clock differences essentially become standard deviations and only contain the variability between correction streams. This undesired but necessary consequence explains the lower GLONASS clock differences and UREs compared to GPS and Galileo in Table 1. Nonetheless, the two GLONASS streams performed similarly after the outlier satellites were removed, with an rms of approximately 4.8 cm.

These product quality analyses show that all four streams are equivalent after outlier removal and that the GPS and Galileo corrections are comparable to, or even better than, corrections from BeiDou PPP-B2b and Galileo HAS. However, the results in Table 1 are consolidated across all satellites. To understand the performance of each satellite and identify outliers, Figure 2 shows the rms of each satellite’s URE over the same seven-day period in autumn 2024 for each correction stream.

Figure 2 complements the results in Table 1, as it shows consistent performance not only across the different correction streams but also across satellites. In the case of GPS, which is the only common constellation among all four streams, each satellite performs similarly across all four streams. GPS also exhibits similar performance among satellites, showcasing the high quality of GPS corrections. In the case of GLONASS, UREs are also low and consistent across satellites and correction streams, as the satellite-dependent biases were removed from each satellite’s clock. However, three exceptions can be seen: both GLONASS streams have a higher URE for R730, and the SSRA21JPL0 stream has higher UREs for R806 and R861. The higher R730 UREs arose due to a mismatch in the satellite antenna calibration with CODE and will be fixed in future iterations of the streams. The higher UREs for SSRA21JPL0 for R806 and R861 are well understood and will also be fixed in future iterations of the streams. Finally, the performance of Galileo mirrors that of GPS: for each satellite, both streams perform similarly, and for each stream, UREs are consistent across different satellites. Overall, this comparison of GDGPS HAS to CODE shows that the GDGPS HAS streams exhibit good, consistent performance across streams and satellites, even when compared to similar services such as BeiDou PPP-B2b and Galileo HAS.

3.2 Long-term analysis of URE

The products analysis in the previous section focused on data collected over a one-week period spanning late September and early October 2024, but long-term performance is also important for understanding the quality of the GDGPS HAS products. Comparisons between URE values and high-precision GipsyX rapid products have been routinely generated and saved over months and can therefore provide a long-term analysis of product quality. In general, CODE orbits and clocks and the GipsyX rapid orbits and clocks are expected to yield similar URE values for real-time correction streams. The box-and-whisker plot in Figure 3 summarizes the long-term behavior of UREs for GPS, as data for other constellations has not been saved. The figure is based on eight months of data, ranging from January 1st, 2024 to September 1st, 2024. Each color represents a different correction stream, as in Figure 2. For each satellite and stream, the URE distribution is represented by: 1) a minimum URE: the bottom whisker, 2) a maximum URE: the top whisker, 3) a median: the horizontal line inside the box, 4) the first quantile, or 25th percentile: the box’s bottom boundary, and 5) the third quantile, or 75th percentile: the box’s top boundary.

• Download figure
• Open in new tab
• Download powerpoint

FIGURE 3

Box-and-whisker plot showing the URE for GPS satellites from all four streams. The figure is based on eight months of data between January 1st, 2024 and September 1st, 2024. The UREs are computed at 5-minute intervals relative to GipsyX rapid GPS products.

Overall, Figure 3 shows that URE distributions are comparable between all filters and satellites. With the exception of a select few satellites with higher medians and maximums, the satellites are generally well-behaved, as the median and most third quantile UREs are below 10 cm. These distributions attest to the stability and high quality of GPS products in all four correction streams, agreeing with the earlier comparison against final CODE products. The high quality of the GPS products, along with the high quality of the Galileo and GLONASS products as shown in section 3.1, should directly translate to high-quality user PPP performance.

3.3 Latency analysis

The correction streams described in this research are all intended for real-time processing rather than file-based processing. As such, the latency of the corrections becomes important, as large delays in the generation and reception of the corrections would lead to higher positioning errors for users (Martin et al., 2015). Quick generation and dissemination of the products is therefore of the utmost importance, with latencies below ten seconds considered optimal for precise positioning (Hadas & Bosy, 2014). Figure 4 shows the latency distribution for each of the correction streams, with the different streams colored as before. In the top panel, POD latency is the time between the nominal observation time and the time at which the precise products are generated by the POD filter, while in the bottom panel, total latency is the time between the nominal observation time and the time at which the precise products are received by the user as broadcast through the IGS.

• Download figure
• Open in new tab
• Download powerpoint

FIGURE 4

Histograms showing the latency from correction generation (top) and the total latency at the user side (bottom) for each individual stream between September 27th, 2024 and October 10th, 2024.

Overall, Figure 4 shows that the GDGPS HAS corrections have a desirably low latency. With the exception of some outliers for the SSRA12JPL0 stream, the latency for correction generation is largely below five seconds. For three of the four streams, the bulk of each latency distribution is slightly over four seconds, and for SSRA22JPL0, most latencies are below four seconds. Moreover, the total latencies from all four streams are between 7 and 8 seconds, which is very reasonable for real-time processing. These distributions demonstrate the low correction latency even at the user level, which is well below the ten-second threshold mentioned above. Assuming any reasonable transfer over the internet or other media, these latencies are sufficiently low to enable precise real-time user positioning.

4.1 User engine and model

The York-PPP engine is a user positioning engine developed at the GNSS Laboratory in York University, Toronto, Canada. The engine is capable of multi-constellation, multi-frequency processing of GNSS data with the possibility of real-time positioning (Aggrey, 2015; Naciri, 2023; Seepersad, 2018). The engine also has additional processing capabilities, such as an inertial measurement unit and odometer integration or smartphone processing, that are beyond the scope of the current study. The engine supports real-time, simulated real-time, and post-processed data processing using a variety of measurement correction formats. Figure 5 shows a high-level description of the software.

• Download figure
• Open in new tab
• Download powerpoint

FIGURE 5

High-level diagram of the capabilities of the York-PPP engine used for user processing.

For this research, the York-PPP engine is used for simulated real-time processing of geodetic data with GDGPS HAS correction data, in addition to real-time correction data from CNES and Galileo HAS. The processing is performed on dual-frequency observation data for GPS, Galileo, and GLONASS and is limited to float positioning using only orbits and clocks. To ensure that processing can be replayed and that the corrections streams are archived, the real-time data is streamed and logged using the Federal Agency for Cartography and Geodesy (BKG) NTRIP Client (BNC) software (Stürze et al., 2016). SSR and ephemeris data are logged in ASCII files, which are read by the York-PPP engine and processed in simulated real-time. In other words, files are processed in forward mode using only data that would be available to the user at each epoch in a real-time scenario. As is the case for real-time processing, any latency is embedded in the corrections, but the low latencies shown in Figure 4 have limited effect on user solutions.

Although the York-PPP engine is capable of processing with different PPP models, such as the Decoupled Clock Model (Collins et al., 2010; Naciri & Bisnath, 2021) for PPP-AR, this research uses a simple float model. The float model is based on uncombined processing, using only raw measurements on individual frequencies without forming ionosphere-free combinations. The equation models are shown in Equation (3):

{P1s=ρrs+c(dtr−dts)+γ1I1s+Mrs·TrP2s=ρrs+c(dtr−dts)+γ2I1s+Mrs·TrΦ1s=ρrs+c(dtr−dts)−γ1I1s+Mrs·Tr+ λ1N1sΦ2s=ρrs+c(dtr−dts)−γ2I1s+Mrs·Tr+λ2N2s+ϵP1+ϵP2+ϵΦ1+ϵΦ23

In Equation (3), for a receiver r and a satellite s, Pis and Φis are the pseudorange and carrier-phase measurements on frequency f_i, i ∈ {1, 2}, and ρrs is the geometric range between the receiver and the satellite. c is the speed of light in a vacuum, and dt_r and dt^s are the receiver and satellite clock offsets, respectively. γi=f12fi2 is the coefficient that maps the L1/E1/G1 ionospheric delay I1s to each frequency f_i. Mrs is the mapping function applied to the zenith wet tropospheric delay T_r. In the latter two equations, λ_i is the wavelength of the signal on frequency f_i, and Nis is the corresponding carrier-phase ambiguity. Note that carrier-phase ambiguities contain various receiver- and satellite-dependent biases, as is the nature of float models. For instance, the carrier-phase ambiguities contain the satellite phase biases, which are not corrected for in this research. Finally, ϵPi and ϵΦi are the pseudorange and carrier-phase residuals on frequency f_i, respectively.

4.2 Test data description

The model described above is used to process observation data collected from a global set of 40 stations that each support L1/L2 for GPS, E1/E5b for Galileo, and G1/G2 for GLONASS. The stations are part of the IGS network and are distributed across all continents, as shown by the black dots labeled PPP in Figure 6. In addition to the user PPP stations, Figure 6 also shows stations labeled POD, which are used in the network processing to generate the GDGPS HAS SSR corrections. These POD stations are shown to demonstrate the global coverage of the service as well as its high redundancy. Although some PPP stations overlap with the POD stations, most do not. Data from the stations were downloaded from CDDIS in Receiver Independent Exchange (RINEX) format and processed in simulated real-time. The data were collected over the same seven-day period as in the products analysis between late September and early October 2024, and have a 30-second update interval. Each station’s data were split into three-hour long data sets, amounting to a total of over 2,000 datasets that are independent in time. RINEX data were used, rather than real-time observation data, to ensure ease of re-processing and avoid any issues related to observation data transmission affecting the PPP results.

• Download figure
• Open in new tab
• Download powerpoint

FIGURE 6

Locations of the stations used for precise orbit determination (POD) of the GDGPS HAS corrections and for PPP user processing.

4.3 Processing strategies

The observation data described above is processed with the York-PPP engine using the different correction streams. The processing strategy was designed to keep the comparisons fair and equitable between all correction streams given the differences in definitions and reference points among the different streams. The full processing strategies are detailed in Table 2. For example, all GDGPS HAS and the Galileo HAS streams have orbits referring to the ionosphere-free antenna phase center of each constellation’s primary frequency pair, while orbits for the CNES stream refer to the L1/E1/G1 antenna phase center. Such differences are accounted for when processing user data. Similarly, the primary observables for GDGPS HAS are 1W and 2W for GPS but are 1C and 2W for Galileo HAS. The user engine therefore prioritizes 1W for GDGPS HAS (and CNES) and 1C for Galileo HAS.

Parameter estimation is performed using a sequential least-squares filter, and the stochastic modeling strategy is detailed in Table 2. Despite the stations being static, the receiver positions are estimated with large process noise, which enables an analysis of the kinematic performance without imposing large constraints on user dynamics. In addition, given the existence of inter-constellation biases, one receiver clock is estimated per constellation. Similar measurement weights are used for all constellations except GLONASS, for which the post-fit residual rejection threshold is twice that of other constellations to account for GLONASS’s inter-signal biases (Yamada et al., 2010). Other corrections, such as the phase wind-up, relativistic effect, and Earth rotation, are applied following the International Earth Rotation Service (IERS) conventions (Kouba & Mireault, 1998).

5.1 User performance analysis

This section consolidates and summarizes the results from processing the over 2,000 individual three-hour-long datasets for each GDGPS HAS correction stream. User results are analyzed in terms of accuracy and convergence time relative to SINEX reference positions from the IGS. For example, Figure 7 shows the rms time series for each of the GDGPS HAS streams using the same color scheme as before. The figure is generated by computing, on each epoch, the rms of all data sets after removing outliers that have three-dimensional position errors higher than two meters, as these outliers are caused by observation data quality. The removal of such outliers is especially important because no pre-filtering of the observation data was performed prior to PPP processing: in other words, all data from all 40 stations over the seven-day collection window was processed by the PPP engine without prior removal of any problematic observation data. On average, approximately 1% to 2% of the data points were rejected from the rms computation in each epoch. For each stream, Figure 7 compares both a GPS-only solution and a dual-constellation solution. Dashed lines represent the single-constellation solutions, while the same-colored solid lines represent their equivalent dual-constellation solutions.

• Download figure
• Open in new tab
• Download powerpoint

FIGURE 7

rms performance based on all data sets with GDGPS HAS corrections for the GPS+GAL streams (SSRA11JPL0 and SSRA12JPL0) with (a) horizontal and (b) vertical errors, and GPS+GLO streams (SSRA21JPL0 and SSRA22JPL0) with (c) horizontal and (d) vertical errors. For each epoch, each time series is computed as the rms of all horizontal or vertical errors after removal of three-dimensional errors greater than two meters.

Figure 7 demonstrates how comparable each pair of same-constellation streams is. For example, consider the two GPS+GAL streams (SSRA11JPL0 and SSRA12JPL0, shown in blue and orange). For each pair of single-constellation solutions, the solutions can hardly be distinguished from one another. This overlap between pairs of redundant streams is expected, as URE analysis showed comparable values between SSRA11JPL0 and SSRA12JPL0. However, the two streams exhibit small differences in their dual-constellation solutions. This difference arises due to a discrepancy in the quality of the GLONASS corrections, as illustrated in Figure 3. The difference in GLONASS corrections is well-understood and will be corrected in future versions of the streams. Overall, all four GPS-only solutions produced comparable results, while the GPS+GAL solutions perform better than the GPS+GLO solutions in terms of convergence time and position error. The different performances between the two dual-constellation solutions are likely due to the inter-signal biases from GLONASS. Longer convergence times and higher position errors in a GPS+GLO solution relative to GPS+GAL were similarly observed by (Li & Pan, 2021) using real-time CNES products.

Figure 8 quantifies the horizontal and vertical convergence times and rms for all four dual-constellation solutions shown in Figure 7. The convergence times are defined relative to 20 cm and 40 cm horizontal and vertical error, respectively. These convergence time thresholds are the same as defined for Galileo HAS, as specific thresholds for GDGPS HAS have not yet been defined. The rms are computed between hours one and three of the processing to exclude the convergence period. Consistent with the observations from Figure 7, the two GPS+GAL streams perform similarly, as their respective convergence times and rms overlap: convergence times are 12 minutes and 6.5 minutes horizontally and vertically, respectively, and rms are 13.5 cm and 17.5 cm horizontally and vertically, respectively. In contrast, the SSRA22JPL0 GLONASS stream performs better than SSRA21JPL0: the convergence times for SSRA22JPL0 are 24.5 minutes and 9.0 minutes horizontally and vertically, respectively, whereas the vertical convergence time for SSRA21JPL0 is 15.5 minutes. Moreover, SSRA21JPL0 does not converge below 20 cm horizontally, as the solution settles around that threshold. In terms of rms, SSRA21JPL0 has horizontal and vertical rms of 28.4 cm and 28.6 cm, respectively, as opposed to 19.5 cm and 22.2 cm for SSRA22JPL0. Overall, considering that these solutions involve two constellations and do not involve any ambiguity resolution, these results show very good performance. The equivalence between both GPS+GAL streams supports the use of parallel GPS+GAL streams, while the differences between the two GPS+GLO streams are well-understood and will be removed in future iterations of the streams.

• Download figure
• Open in new tab
• Download powerpoint

FIGURE 8

Statistics for the multi-GNSS time series shown in Figure 7. Horizontal (a) and vertical (b) convergence times are relative to 20 cm and 40 cm errors, respectively, and horizontal (c) and vertical (d) rms are computed between the first and third hours of processing.

Figures 7 and 8 show the overall performance based on all data sets, so to better understand the global coverage from the service, Figure 9 shows the performance per station. Figure 9 is generated by (i) computing the total rms of each individual three-hour dataset after removing three-dimensional position errors greater than two meters and then (ii) computing the mean and standard deviation of these rms for each station. Dots represent the mean rms for each station, while error bars represent the standard deviation. Streams are colored as before. As can be seen in the figure, for each stream, performance is consistent across all stations. The GPS+GAL solutions are comparable between the SSRA11JPL0 and SSRA12JPL0 streams and have lower standard deviations compared to the GPS+GLO solutions, showing that, for each station, the GPS+GAL results are consistent over time. The larger standard deviations of the GPS+GLO solutions are likely due to the three GLONASS satellites with high UREs shown in Figure 3.

• Download figure
• Open in new tab
• Download powerpoint

FIGURE 9

Per-station performance of the dual-constellation GDGPS HAS results. Dots represent the mean rms across each station’s 56 data sets, and error bars represent the corresponding standard deviations. Rms are computed over the whole duration of the processing after removal of three-dimensional position errors greater than two meters.

5.2 Direct comparison against external correction streams

To put these different GDGPS HAS results in context, this section compares the GDGPS HAS results against solutions generated from other correction streams: CNES and Galileo HAS. The CNES and Galileo HAS streams are logged in real-time, like GDGPS HAS, and their data are used to process the same observation data as GDGPS HAS. Definition discrepancies such as different reference antenna points, as well as different frequency combinations, are accounted for as discussed in Section 4.3.

5.2.1 Comparison of GPS+GLO streams against CNES

The two GPS+GLO streams are first analyzed by comparison to the real-time CNES stream. CNES provides multi-GNSS (GPS, GLONASS, Galileo, BeiDou) corrections in their SSR streams, so, to allow for a fair comparison, a dual-constellation solution using only GPS and GLONASS was generated using CNES corrections and then compared to the solutions from the two GPS+GLO GDGPS HAS streams, as shown in Figure 10. The figure displays the cumulative distributions of the rms for individual three-hour datasets, for each of the three solutions. The rms are computed between hours two and three of processing for each data set to eliminate any convergence period, and the two GDGPS HAS streams are colored as before. As expected from the user performance analysis described above, the SSRA22JPL0 stream performed better than SSRA21JPL0: approximately 95% of the datasets have horizontal rms below 20 cm and 84% have horizontal rms below 10 cm for SSRA22JPL0, as opposed to approximately 88% and 70%, respectively, for SSRA21JPL0. In comparison, the CNES solution performs similarly to the poorer-performing SSRA21JPL0, with the former having a slightly better distribution. Indeed, only 86% of CNES solutions have horizontal rms below 20 cm, and 74% are below 10 cm. The figure attests to the quality and performance of the GDGPS HAS GPS+GLO streams relative to other well-established products such as those from CNES.

• Download figure
• Open in new tab
• Download powerpoint

FIGURE 10

Comparison of the horizontal (a) and vertical (b) position cumulative distributions using GPS+GLO GDGPS HAS and CNES correction streams on the data described in section 4.2. The distributions are based on the rms of each three-hour dataset between hours two and three to eliminate any convergence period.

5.2.2 Comparison of GPS+GAL streams against Galileo HAS and CNES

Here, the rms distribution for the GPS and Galileo streams is compared to external solutions from both CNES and Galileo HAS. All four solutions (two GDGPS HAS, one CNES, and one Galileo HAS) use the same observation data and similar processing strategies based on GPS+GAL processing. The results are summarized in Figure 11, with the GDGPS HAS streams colored as before.

• Download figure
• Open in new tab
• Download powerpoint

FIGURE 11

Comparison of the horizontal (a) and vertical (b) position cumulative distributions using GPS+GAL GDGPS HAS, CNES, and Galileo HAS correction streams on the data described in section 4.2. The distributions are based on the rms of each three-hour dataset between hours two and three to eliminate any convergence period.

As in the user performance analysis, the two GDGPS HAS streams produced equivalent results with overlapping distributions. Compared to the external solutions, the GDGPS HAS streams were comparable to the CNES solution and better than Galileo HAS. Overall, the results show the high quality of the GPS+GAL solutions, as over 97% and 90% of data sets have a horizontal rms lower than 20 cm and 10 cm, respectively. For the CNES solution, 93% of solutions have a horizontal rms below 20 cm, while 77% have a horizontal rms below 10 cm. In contrast, only 86% of datasets have a horizontal rms below 20 cm horizontally for Galileo HAS, and only 47% are below 10 cm. The considerably better performance of GDGPS HAS and CNES relative to Galileo HAS is attributed to the large number of ground stations used to generate the corrections for GDGPS HAS and CNES. Galileo HAS currently uses only 14 reference stations (Fernandez-Hernandez et al., 2022), though additional Galileo tracking stations will be added in the near future, and some of the user stations in the Pacific region fall outside Galileo HAS’s current coverage area. Overall, these comparisons against CNES and Galileo HAS demonstrate that the GDGPS HAS results are of high quality and perform comparably to other high-quality correction streams. Moreover, because these results are based on float dual-frequency dual-constellation solutions, they could be further improved by incorporating additional frequencies or constellations or even through the use of ambiguity resolution once satellite pseudorange and carrier-phase biases are made available.

5.2.3 Consolidation of PPP results

To summarize the PPP results shown in this paper and provide a single comparison with external correction streams, Figure 12 shows the average time series for each PPP solution described herein together with their standard deviations. The figure for each solution is generated by computing, at each epoch, the mean and standard deviation of the position errors for all 2,100 datasets after removing three-dimensional position errors greater than two meters. The first column shows the GPS+GAL solutions, while the second column shows the GPS+GLO solutions. The first two rows contain the GDGPS HAS solutions, and the third and fourth contain the CNES and Galileo HAS solutions.

• Download figure
• Open in new tab
• Download powerpoint

FIGURE 12

Comparison of the epoch-wise position error means and standard deviations based on all datasets using the various GDGPS HAS and external correction streams. Outliers with three-dimensional position errors greater than two meters are removed.

This overall synthesis reaffirms that each pair of GDGPS HAS solutions performs comparably and that the GPS+GLO solutions have larger means and standard deviations than the GPS+GAL solutions. As noted earlier, the lower GPS+GLO performance can be attributed to the presence of unaccounted-for inter-frequency biases in GLONASS, the absence of code biases in the SSR streams, and the well-known higher UREs for three satellites that will be accounted for in future iterations. The GDGPS HAS streams for both the GPS+GLO and GPS+GAL solutions perform comparably to CNES, as both means and scatters in the CNES solutions are similar to GDGPS HAS. Finally, Galileo HAS has a higher mean and standard deviation compared to the other GPS+GAL solutions, likely due to the more limited number of ground stations it used for correction estimation.