Introduction

Precise point positioning (PPP) is the technique that enables centimeter- or decimeter-level positioning accuracy with only one receiver on a global scale (Zumberge et al. 1997; Kouba and Héroux 2001). Over the last decade, PPP has attracted considerable attention within the GNSS (Global Navigation Satellite Systems) community due to its exceptional benefits such as operational simplicity, cost-effectiveness, elimination of base station requirement. PPP has been widely used in many GNSS applications that mostly require high positioning accuracy. Although PPP satisfies the positioning accuracy demands for most of GNSS applications, it still requires a quite long observation period to achieve a specific positioning accuracy. This period is typically called convergence time and mostly requires 50 min to reach 10 cm or better horizontal accuracy (Choy et al. 2017). Relatively long convergence time is still the main drawback of PPP, which restricts its widespread adoption. In addition to the user environment and geographical location of the receiver, convergence time to reach a specific accuracy level mainly depends on the number and geometry of visible satellites. In recent years, the restoration of the full orbital constellation for GLONASS and the emergence of new satellite systems, such as Galileo and BeiDou (BDS), have provided additional frequencies and satellite resources for PPP. Consequently, the combinations of different GNSS constellations, namely, multi-GNSS, strength the number and geometry of visible satellites, and therefore, presents the opportunity to improve the PPP performance in terms of positioning accuracy and convergence time (Cai and Gao 2013; Yiğit et al. 2014; Togedor et al. 2014; Cai et al. 2015).

The demand for GNSS analysis software, which can perform multi-GNSS PPP analysis, has been rising in parallel to the importance of PPP in positioning and navigation applications. However, the combinations of multi-GNSS observations entail more complex models and algorithms compared with the traditional PPP approach that includes GPS observations only. Therefore, the multi-GNSS PPP processing requires more advanced software solutions to take advantage of the new satellites and frequencies. There are a few GNSS data processing software packages frequently used by GNSS users such as Bernese, GAMIT/GLOBK, and GIPSY/OASIS. Although these packages are not essentially specialized in precise point positioning, they still provide a PPP solution as well as other functionalities. However, they may not be an optimal solution for a standard user who is seeking for PPP analysis because of their complicated structure and comprehensive processing functionalities. Alternatively, some universities and research institutes have developed PPP processing services and released them online via the internet (APPS, GAPS, CSRS-PPP, Magic-PPP) in recent years (Guo 2015). These online services are commonly utilized for PPP processing. Nevertheless, very few of them are able to process multi-GNSS data. On the other hand, some researchers have recently started to develop open source software packages for multi-GNSS PPP analysis. For example, an open-source software (GAMP), which is a modified version of RTKLIB, has been developed to perform multi-GNSS PPP based on undifferenced and uncombined observations (Zhou et al. 2018). However, it may be stated that the installation and usage of the software are not quite easy for a standard user. Taking all these into account, it could be argued that there is a requirement for a multi-GNSS PPP analysis software which is easy to use for every user level, provides a reliable solution, and is open to user’s preferences at each processing step.

To benefit from multi-constellation and multi-frequency GNSS better, we developed a user-friendly GNSS analysis software named PPPH. PPPH is able to perform multi-GNSS PPP analysis by processing GPS, GLONASS, BeiDou and Galileo data, in post-processing mode. Thanks to its graphical user interface (GUI), PPPH allows users to load GNSS data sources, determine a variety of processing options and parameters and evaluate the results from many perspectives. The MATLAB environment has been preferred to develop PPPH since its matrix-based structure and its built-in graphics are highly suitable for technical computing, programming, and data visualization. Additionally, MATLAB is one of the programming environments frequently employed by scientists and engineers worldwide, which means that many people can access the software and extend its functionalities easily. Except for MATLAB core files, PPPH does not utilize any toolbox or function distributed with MATLAB. However, MATLAB version 2016a or newer is needed since the graphical user interface (GUI) of the software was developed using the MATLAB App Designer which is a special environment to design and develop the visual components of a user interface.

In the following sections, the mathematical models of multi-GNSS PPP are described first. Afterward, a brief introduction of PPPH is given. Then, the experimental tests and results conducted to evaluate and validate the performance of PPPH are presented. Finally, the conclusions drawn from the study are provided.

Multi-GNSS PPP modeling

Since each navigation system utilizes its own spatial reference frame, timescale, and signal structure, the differences between the navigation systems should be considered for multi-GNSS PPP processing. Typically, the interoperability of the navigation systems is ensured with the coordinate and/or time transformations. However, when the precise orbit and clock products generated in the same reference system and timescale, such as the International GNSS Service (IGS) products, are utilized for PPP data processing, there is no need for any reference transformation between the systems. Although the use of precise products eliminates the differences in coordinate and time references, it is still required to handle the hardware biases for both the receivers and the satellites (Cai and Gao 2013).

For multi-GNSS PPP, the code pseudo-range (P) and carrier phase (L) observation equations can be written as follows:

$$P_{{i,r}}^{{s,j}}=\rho _{r}^{{s,j}}+{\text{cdt}}_{r}^{s} - {\text{cd}}{{\text{T}}^{s,j}}+T_{r}^{{s,j}}+I_{i}^{{s,j}}+b_{{i,r}}^{s} - b_{i}^{{s,j}}+\varepsilon (P_{{i,r}}^{{s,j}})$$
(1)
$$L_{{i,r}}^{{s,j}}=\rho _{r}^{{s,j}}+{\text{cdt}}_{r}^{s} - {\text{cd}}{{\text{T}}^{s,j}}+T_{r}^{{s,j}} - I_{i}^{{s,j}}+\lambda _{i}^{s}N_{i}^{{s,j}}+B_{{i,r}}^{s} - B_{i}^{{s,j}}+\varepsilon (L_{{i,r}}^{{s,j}}),$$
(2)

where subscripts \(r\) and \(i\) indicate the receiver and the frequency index of navigation signal, respectively; superscripts \(s\) and \(j\) indicate the GNSS index (G:GPS, R:GLONASS, E:Galileo and C:BeiDou) and the satellite number, respectively. Moreover, \(\rho _{r}^{{s,j}}\) is the geometric range, \(c\) is the speed of light; \({\text{cdt}}_{r}^{s}\) and \({\text{cd}}{{\text{T}}^{s,j}}\)are the receiver and satellite clock offsets, respectively; \(T_{r}^{{s,j}}\) is the tropospheric delay; \(I_{i}^{{s,j}}\) is the first-order ionospheric delay on frequency \(i\); \(~b_{{i,r}}^{s}\) and \(b_{i}^{{s,j}}\)are the receiver and satellite hardware code biases on frequency \(i\); \(B_{{i,r}}^{s}\) and \(B_{i}^{{s,j}}\) are the receiver and satellite hardware phase biases on frequency \(i\), respectively; \(N_{i}^{{s,j}}\) is the integer ambiguity parameter; \(~\lambda _{i}^{s}\) is the wavelength of the corresponding frequency; and \(\varepsilon\) is the observation noise.

Traditionally, PPP relies on the precise products obtained from the IGS network to eliminate the satellite orbit and clock offsets. IGS precise satellite clock products are generated using the ionospheric-free (IF) linear combination of code pseudo-range observations. The related clock offsets include the hardware code biases (Kouba and Héroux 2001). Therefore, the satellite hardware code biases can be assimilated into the satellite clock offset and removed by applying the precise products in IF linear combination. Similarly, receiver hardware code biases can be integrated into the receiver clock offset as it is not estimable for undifferenced observation equations due to its high correlation with the receiver clock. On the other hand, it is not possible to correct the receiver and satellite hardware phase biases using IGS products. For this reason, they are usually ignored when the requirement of positioning accuracy is low or they can be assimilated into the ambiguity parameter. For the second option, the ambiguity parameter is not an integer anymore as it contains the hardware biases (Defraigne and Baire 2011). Considering all these, IF combinations of dual frequency (\(i=1,~2\)) code pseudo-range and phase observations can be formed from (1) and (2) as:

$$P_{{IF,r}}^{{s,j}}=\rho _{r}^{{s,j}}+\widetilde {{{\text{cdt}}}}_{r}^{s} - {\widetilde {{{\text{cdT}}}}^{s,j}}+T_{r}^{{s,j}}+\varepsilon (P_{{IF,r}}^{{s,j}})$$
(3)
$$L_{{IF,r}}^{{s,j}}=\rho _{r}^{{s,j}}+\widetilde {{{\text{cdt}}}}_{r}^{s} - {\widetilde {{{\text{cdT}}}}^{s,j}}+T_{r}^{{s,j}}+\lambda _{{IF}}^{s}\tilde {N}_{{IF}}^{{s,j}}+\varepsilon (L_{{IF,r}}^{{s,j}}),$$
(4)

where \(\widetilde {{{\text{cdt}}}}_{r}^{s},~~{\widetilde {{{\text{cdT}}}}^{s,j}}\) and \(\tilde {N}_{i}^{{s,j}}\) demonstrate the reformed receiver clock offset, satellite clock offset and ambiguity parameter, respectively, which are described as \(\widetilde {{{\text{cdt}}}}_{r}^{s}=({\text{~cdt}}_{r}^{s}+b_{{IF,r}}^{s}~)\), \({\widetilde {{{\text{cdT}}}}^{s,j}}=({\text{cd}}{{\text{T}}^{s,j}}+b_{{IF}}^{{s,j}})\) and \(\tilde {N}_{{IF}}^{{s,j}}=N_{{IF}}^{{s,j}}+(B_{{IF,r}}^{s} - b_{{IF,r}}^{s}) - (B_{{IF}}^{{s,j}} - b_{{IF}}^{{s,j}})\).

Unlike GPS, Galileo, and BeiDou, GLONASS utilizes Frequency Division Multiple Access (FDMA) signals, which means that each GLONASS satellite has a different frequency channel and hardware bias (Wanninger 2012). Thus, for GLONASS, the hardware biases are expressed as a sum of an average term and a frequency-dependent term. The frequency-dependent terms are also referred to as inter-frequency biases (IFBs). Herein, since the satellite hardware code biases are eliminated by the precise products and the satellite and receiver phase biases are estimated together with the ambiguity parameter, it is required to take only the IFBs of receiver hardware code biases into consideration. The code IFB terms can be estimated as additional unknowns in the PPP processing, which causes a significant increase in the number of unknown parameters. Since too many parameters weaken the model structure, it is usually preferred not to estimate the code IFBs in the processing. Instead, a much smaller weight compared with the carrier phase observations is designated for the code pseudo-range observations. Therefore, the code IFB terms can be neglected and their effects show up in the code pseudo-range residuals (Cai and Gao 2013).

In (3) and (4), a receiver clock offset parameter is assigned for each navigation system separately. Instead of estimating different receiver clock offsets, a more convenient way is to introduce the system time difference parameters for GLONASS, Galileo and BeiDou with respect to GPS clock offset. Considering that the reformed clock offsets also include the hardware biases, the system time difference parameter is a sum of the actual system time difference between the related navigation system and GPS and the hardware biases (Cai and Gao 2013; Li et al. 2015). After applying the precise products and introducing the system time difference parameters for each system with respect to the GPS receiver clock offset, the IF observation equations for GPS, GLONASS, Galileo and BeiDou can be written as follows:

$$P_{{IF,r}}^{{G,j}}=\rho _{r}^{{G,j}}+\widetilde {{{\text{cdt}}}}_{r}^{G}+T_{r}^{{G,j}}+\varepsilon (P_{{IF,r}}^{{G,j}})$$
(5)
$$L_{{IF,r}}^{{G,j}}=\rho _{r}^{{G,j}}+\widetilde {{{\text{cdt}}}}_{r}^{G}+T_{r}^{{G,j}}+\lambda _{{IF}}^{G}\tilde {N}_{{IF}}^{{G,j}}+\varepsilon (L_{{IF,r}}^{{G,j}})$$
(6)
$$P_{{IF,r}}^{{R,j}}=\rho _{r}^{{R,j}}+\widetilde {{{\text{cdt}}}}_{r}^{G}+{\text{cdt}}_{{{\text{sys}}}}^{R}+T_{r}^{{R,j}}+\varepsilon (P_{{IF,r}}^{{R,j}})$$
(7)
$$L_{{IF,r}}^{{R,j}}=\rho _{r}^{{R,j}}+\widetilde {{{\text{cdt}}}}_{r}^{G}+{\text{cdt}}_{{{\text{sys}}}}^{R}+T_{r}^{{R,j}}+\lambda _{{IF}}^{R}\tilde {N}_{{IF}}^{{R,j}}+\varepsilon (L_{{IF,r}}^{{R,j}})$$
(8)
$$P_{{IF,r}}^{{E,j}}=\rho _{r}^{{E,j}}+\widetilde {{{\text{cdt}}}}_{r}^{G}+{\text{cdt}}_{{{\text{sys}}}}^{E}+T_{r}^{{E,j}}+\varepsilon (P_{{IF,r}}^{{E,j}})$$
(9)
$$L_{{IF,r}}^{{E,j}}=\rho _{r}^{{E,j}}+\widetilde {{{\text{cdt}}}}_{r}^{G}+{\text{cdt}}_{{sys}}^{E}+T_{r}^{{E,j}}+\lambda _{{IF}}^{E}\tilde {N}_{{IF}}^{{E,j}}+\varepsilon (L_{{IF,r}}^{{E,j}})$$
(10)
$$P_{{IF,r}}^{{C,j}}=\rho _{r}^{{C,j}}+\widetilde {{{\text{cdt}}}}_{r}^{G}+{\text{cdt}}_{{sys}}^{C}+T_{r}^{{C,j}}+\varepsilon (P_{{IF,r}}^{{C,j}})$$
(11)
$$L_{{IF,r}}^{{C,j}}=\rho _{r}^{{C,j}}+\widetilde {{{\text{cdt}}}}_{r}^{G}+{\text{cdt}}_{{sys}}^{C}+T_{r}^{{C,j}}+\lambda _{{IF}}^{C}\tilde {N}_{{IF}}^{{C,j}}+\varepsilon (L_{{IF,r}}^{{C,j}}),$$
(12)

where \({\text{cdt}}_{{{\text{sys}}}}^{R}\), \({\text{cdt}}_{{{\text{sys}}}}^{E}\) and \({\text{cdt}}_{{{\text{sys}}}}^{C}\) are the system time difference parameters for GLONASS, Galileo and BeiDou with respect to GPS, respectively. Equations (5)–(12) constitute the functional model of combined multi-GNSS PPP that is used in the PPPH software. In the model, the unknown parameters are composed of the three position components, one receiver clock bias, three system time-difference parameters, one tropospheric delay and one real-valued ambiguity parameter for each of the observed satellites. Herein, the position components are assumed to be constant in static mode, while the receiver clock and time-difference parameters are estimated with random walk process. The ambiguity parameters are estimated as floating numbers with the assumption that they are constant for each continuous arc. Moreover, the tropospheric delay is typically separated into a dry (hydrostatic) and a wet (non-hydrostatic) part. The dry component of the tropospheric delay can be easily modeled at zenith direction and projected to the satellite elevation angle using a mapping function (Saastamoinen 1972). Therefore, only the wet component of the tropospheric delay is to be estimated with random walk process.

PPPH: a multi-GNSS PPP software

PPPH was developed in MATLAB environment to integrate multi-GNSS (GPS, GLONASS, Galileo, and BeiDou) data for PPP processing. Fundamentally, PPPH aims to be an easy-to-use, robust and efficient software package. Accordingly, PPPH provides a user-friendly GUI to assist users in selecting the navigation files, determining the processing options and analyzing the results. PPPH consists of five main components, and each component along with its related options is represented by a separate tab in the GUI. Figure 1 presents the operation flowchart of PPPH as including the main components and their functionalities. The first four components utilize related models and theory to provide multi-GNSS PPP solutions, while the last one is employed to evaluate and visualize the results.

Fig. 1
figure 1

Operation flowchart of PPPH with its components

Full size image

PPPH requires that the whole data, which are necessary for performing the PPP process, are imported into the software format appropriately before subsequent operations. Therefore, in PPPH, the process starts with the definition of the related files containing standard navigation data, such as observations, satellite orbits, and clocks, etc. PPPH is able to deal with the standard exchange formats properly, including RINEX, SP3, CLK, and ATX, which should be defined within the Data Importing tab of GUI.

Raw data obtained from the navigation files are handled in a preprocessing step as a precaution to possible gross errors and inconsistencies. Preprocessing step of PPPH is composed of the outlier detection, cycle slip detection, and determination of clock inconsistencies (clock jumps), respectively. Cycle slips are detected and repaired with two different methods, which can be used individually or in combination depending on the user’s preference. The first method utilizes the Hatch–Melbourne–Wübbena combination (Hatch 1982) in accordance with Liu (2011), while the second is based on the geometry-free combination method described in Deo and El-Mowafy (2015). For determining the receiver clock inconsistencies, PPPH makes use of the method proposed by Guo and Zhang (2014a). In addition, code smoothing with phase measurements and elevation mask can be applied in this step depending on the user choice.

Modeling component of PPPH is employed to mitigate the influences of GNSS error sources on the observations. In the modeling step, precise products provided by IGS agencies are utilized to remove satellite orbit and clock errors. The first-order ionospheric effect on GNSS observations is eliminated using the ionosphere-free linear combination. The dry component of the tropospheric delay is corrected by Saastamoinen model (Saastamoinen 1972) with the meteorological data acquired from Global Pressure and Temperature Model 2 (Lagler et al. 2013), while the wet component is estimated as random walk process within the parameter estimation step. Global Mapping Function (Boehm et al. 2006) is employed to project the tropospheric corrections modeled at the zenith direction to the satellite elevation angle for both dry and wet components of the tropospheric delay. The values obtained from the IGS absolute antenna model (e.g., igs08.atx or igs14.atx) are employed to correct the antenna phase center offsets (PCOs) and their variations (PCVs) for GPS and GLONASS satellites, while the conventional PCO values are utilized for Galileo and BeiDou satellites (Rizos et al. 2013). Regarding the receiver antenna, PCO and PCV values acquired from the IGS absolute antenna model are used for GPS and GLONASS signals. However, due to the absence of PCO and PCV values for Galileo and BeiDou signals in the related models, GPS values are employed to correct PCOs and PCVs for these systems. Additionally, the relativistic effects (Kouba 2015), phase wind-up effect (Wu et al. 1993) and site displacement effects including solid Earth tides and ocean loading (Petit and Luzum 2010) are corrected in accordance with the standard models.

As regards to the estimation procedure, the Kalman filter, which provides additional information on how the states, i.e., the vector containing the unknown parameters, change with time and also makes updating the state vector using fewer measurements than the unknown parameters possible, is frequently applied to process the data in navigation problems (Mohinder et al. 2007). PPPH employs the adaptive robust Kalman filtering method, which introduces an equivalent weight matrix to compensate the effect of outliers in observations and also an adaptive factor to balance the contributions of measurement and estimated parameters to estimate the state space vector (Guo and Zhang 2014b). The Kalman filter requires the statistical definition of unknown parameters and measurements because the well-defined statistical properties pave the way to achieve an optimal solution. The default values for initial uncertainties and spectral densities of unknown parameters as well as the measurement noise are defined. However, they can also be specified by users in the Filtering Options tab of the PPPH GUI.

As previously mentioned, GLONASS code observations contain IFBs due to the FDMA signals. It is preferred to assign small weight to GLONASS code observations instead of estimating each IFBs separately in the filtering process. On the other hand, as the orbit and clock products of Galileo and BeiDou have poorer quality than GPS products (Montenbruck et al. 2017; Guo et al. 2017), Galileo and BeiDou observations are assumed less accurate in the filter. Consequently, in the filtering process of PPPH, the standard deviation ratios between GPS, GLONASS, Galileo, and BeiDou observations are set as follows:

$$\begin{gathered} {\sigma _{G,P~~}}:~{\sigma _{R,P}}~:~{\sigma _{E,P}}~:~{\sigma _{C,P}}=1~:2~:2~:2, \hfill \\ {\sigma _{G,L~~}}:~~{\sigma _{R,L}}~:~{\sigma _{E,L}}~:~{\sigma _{C,L}}=1~:1~:2~:2, \hfill \\ \end{gathered}$$

where \({\sigma _P}\) and \({\sigma _L}\) indicate the standard deviations of code and phase observations, respectively. In addition, it is usually suggested to use an elevation-dependent weighting model for the measurements considering that the noise level of measurements is directly related to satellite elevation angle (Hofmann-Wellenhof et al. 2008). PPPH allow users to utilize an elevation-dependent weighting method which based on the sine function.

After completing all process steps, PPPH provides a result file containing the estimated parameters for each epoch. Moreover, through the Analysis tab of GUI, the statistics about the process, such as positioning error, root mean square error and convergence time, can be calculated with respect to user-defined ground truth. To evaluate the epoch-by-epoch variations of estimated parameters and their statistics, PPPH is able to produce several plots, e.g., positioning error, tropospheric zenith total delay, receiver clock estimation, satellite number and dilution of precisions.

Experimental tests and results

Two experimental tests have been conducted to validate and evaluate the performance of PPPH software. The first test aims at validating the results obtained from PPPH compared with PPP estimates of an external source, while the second test is to assess the effect of multi-GNSS combinations on PPP performance. In this section, the data collection procedure used in the experimental tests is described, and then the results are presented in detail.

The 24-h observation datasets, which were collected from eight IGS stations during a 1-week period of July 9–15, 2017, were obtained from the BKG (German Federal Agency for Cartography and Geodesy) data center. The sampling interval of observation data is 30 s. Figure 2 shows the geographical distribution of eight IGS stations, which are MGEX stations equipped with the multi-GNSS receivers to track GPS, GLONASS, Galileo and BeiDou satellites. As a first step, 24-h datasets were processed using PPPH in static mode including GPS satellites only. Simultaneously, the same datasets were processed in GAPS (GPS Analysis and Positioning Software—http://gaps.gge.unb.ca/), which is an online PPP service developed at University of New Brunswick (UNB) (Leandro et al. 2011) to validate PPPH results. The processing strategies employed in both PPPH and GAPS are provided in Table 1.

Fig. 2
figure 2

Geographical distribution of IGS stations used in this study

Full size image
Table 1 Processing strategies applied in PPPH and GAPS
Full size table

The results for the first test were statistically evaluated in three aspects: 3D positioning error, root mean square (RMS) error and convergence time. The positioning error is computed as the difference between the related PPP solution and the ground truth at the end of the related process period (24 h for the first test). IGS weekly solutions, which include very precise station coordinates, were used as the ground truth in this study. On the other hand, the convergence time was determined as the time when a sub-decimeter 3D positioning accuracy is achieved and subsequently sustained for a period longer than 10 min. Finally, RMS error was computed in the local system (north, east, up) for all epochs after the convergence time achieved with respect to the ground truth. Table 2 shows 1-week averaged positioning errors, RMS errors and convergence times acquired from PPPH and GAPS estimates at the end of 24 h processing for all stations included in the study. The averages of positioning errors obtained from PPPH and GAPS for all stations are 13.3 and 15.0 mm, respectively. At this point, the discrepancies between the stations are not surprising as the positioning accuracy may vary depending on the geographical location of the station due to the insufficient estimation of tropospheric wet delay and weak modeling of PPP error sources, such as solid Earth tides and ocean loading. Nevertheless, the results for each model are very consistent with the general acceptance and with each other considering that PPP can provide positional accuracy of a few centimeters using a 24-h dataset in static mode (Seepersad and Bisnath 2014). Regarding the convergence time, in general, approximately 50 min of convergence period is expected to achieve 10 cm or better horizontal accuracy, which may vary depending on user environment (multipath), geographical location and number and geometry of visible satellites (Choy et al. 2017). The averages of convergence times provided by PPPH and GAPS are 38.6 and 40.3 min, respectively, which are reasonable according to the standards. Finally, there exist no significant discrepancies between the results of software packages in consideration with regard to RMS errors. Taking all these into account, it can be concluded that the PPP performance of PPPH software is comparable with both general PPP standards and GAPS online service.

Table 2 1-week-averaged 3D positioning errors, RMS errors and convergence times acquired from the PPPH and GAPS estimates
Full size table

To assess the contribution of multi-GNSS combinations to PPP performance, the same dataset was processed using PPPH in static mode under three different PPP modes, which are GPS-only, GPS/GLONASS and multi-GNSS (GPS/GLONASS/Galileo/BeiDou). However, this time the Kalman filter estimator was restarted every 3 h, providing 8 periods for each day, and 56 periods in 1 week for each station. The precise orbit and clock products provided by GFZ (German Research Centre for Geosciences) were utilized for all systems for the sake of consistency. Similarly, the results of three PPP modes were analyzed in terms of the 3D positioning error, RMS error and convergence time. Table 3 demonstrates the averaged positioning errors, RMS errors and convergence times of three different PPP modes and their improvements with respect to the GPS-only PPP solution.

Table 3 Averaged positioning errors, RMS errors and convergence times of different combinations and their improvements with respect to the GPS-only solution
Full size table

In Table 3, it is clearly noticeable that the use of additional constellations together with GPS considerably enhances the PPP performance with regard to positioning accuracy and convergence time. On average, the GPS/GLONASS and multi-GNSS PPP modes improved the positioning accuracy of GPS-only PPP by 19.5 and 24.6%, respectively. Likewise, it can be observed that the combinations of multi-GNSS had significant improvements on the RMS errors in the north, east, and up directions compared with the GPS-only PPP solution. Additionally, the convergence time of GPS-only PPP mode was lessened by the GPS/GLONASS and multi-GNSS PPP modes with the average improvements of 27.4% and 33.1%, respectively. Although the improvements vary depending on the station, the multi-GNSS PPP mode, which includes GPS, GLONASS, Galileo and BeiDou, has the best performance in each station with regard to both positioning accuracy and convergence time.

Summary and conclusions

A user-friendly MATLAB-based GNSS analysis software called PPPH was developed to integrate multi-GNSS (GPS, GLONASS, Galileo, and BeiDou) data for PPP processing. PPPH is capable of providing PPP solutions for user-specific multi-GNSS combinations. Users can also specify the options, models, and parameters within the GUI of the software. PPPH also provides an output file involving the estimated parameters for each epoch separately and a number of analysis tools to assess the results statistically. Although PPPH has many functionalities for PPP processing, the capabilities of PPPH can be extended to meet the demands of advanced users efficiently considering that MATLAB environment is one of the most popular programming tools among engineers and scientists worldwide.

Two experimental tests were conducted to validate and assess the performance of PPPH. First, 24-h observation datasets obtained from eight IGS stations during 1 week were processed in PPPH and GAPS online service, separately. Comparisons were made between PPPH and GAPS in terms of positioning accuracy, root means square error and convergence time. The results indicate that PPPH is able to provide PPP solutions comparable to both general PPP standards and GAPS. Furthermore, the potential benefits of multi-GNSS combinations on PPP performance were evaluated statistically. Compared with GPS-only PPP solutions, GPS/GLONASS and multi-GNSS PPP (GPS, GLONASS, Galileo, and BeiDou) modes enhanced the positioning accuracy by 19.5 and 24.6% on average. As for convergence time, the average improvements of GPS/GLONASS and multi-GNSS PPP modes with respect to GPS-only PPP solutions are 27.4 and 33.1%, respectively. Eventually, it was concluded that the integration of multi-GNSS significantly improves the PPP performance in both positioning accuracy and convergence time.

Considering that the number of GNSS satellites in view will continue to increase in the near future, the integration of different constellations offers considerable prospect to improve the PPP performance. Accordingly, GNSS analysis software packages, which can perform multi-GNSS PPP gain more and more importance within the GNSS community. PPPH provides an important possibility to benefit from the potential advantages of multi-constellation and multi-frequency GNSS. The MATLAB source code, user manual, and sample data for the PPPH software is available on The GPS Toolbox website at https://www.ngs.noaa.gov/gps-toolbox/PPPH.htm. The contents and functionalities of PPPH will continue to be improved for further applications. If you have any problems or suggestions, please feel free to contact the authors.