Weighting of Multi-GNSS Observations in Real-Time Precise Point Positioning

Abstract

The combination of Global Navigation Satellite Systems (GNSS) may improve the accuracy and precision of estimated coordinates, as well as the convergence time of Precise Point Positioning (PPP) solutions. The key conditions are the correct functional model and the proper weighting of observations, for which different characteristics of multi-GNSS signals should be taken into account. In post-processing applications, the optimum stochastic model can be obtained through the analysis of post-fit residuals, but for real-time applications the stochastic model has to be defined in advanced. We propose five different weighting schemes for the GPS + GLONASS + Galileo + BeiDou combination, including two schemes with no intra-system differences, and three schemes that are based on signal noise and/or quality of satellite orbits. We perform GPS-only and five multi-GNSS solutions representing each weighting scheme. We analyze formal errors of coordinates, coordinate repeatability, and solution convergence time. We found that improper or equal weighting may improve formal errors but decreases coordinate repeatability when compared to the GPS-only solution. Intra-system weighting based on satellite orbit quality allows for a reduction of formal errors by 40%, for shortening convergence time by 40% and 47% for horizontal and vertical components, respectively, as well as for improving coordinate repeatability by 6%.

1. Introduction

A dynamic development of Global Navigational Satellite Systems (GNSS), namely GPS, GLONASS, Galileo, and BeiDou, constantly increases the number of operational spacecraft and the amount of provided frequencies. The main idea of all GNSS is uniform. Nevertheless, currently available systems are different in many aspects. Satellite constructions and on-board equipment vary not only between systems but also between satellite blocks. Besides commonly used medium earth-orbit (MEO) satellites, geostationary satellites (GEO), and inclined geosynchronous orbit (IGSO) satellites are encountered in the BeiDou constellation. There are also two Galileo satellites launched into incorrect, elliptical orbits [1]. Receiver Independent Exchange Format (RINEX) 3.03 supports 11 unique frequencies, and only some of them are shared between systems. World Geodetic System (WGS) 84, Parametry Zemli 1990 (PZ-90), Galileo Terrestrial Reference Frame (GTRF), and China Geodetic Coordinate System (CGCS) 2000 are reference frames of GPS, GLONASS, Galileo, and BeiDou, respectively. Each system has its unique time scale, as well.

In order to benefit from multi-GNSS and multi-frequency observations, all the system-dependent calibration parameters must be delivered to the user [2]. Therefore, a great effort is being made by scientific community and industry to improve GNSS processing algorithms, techniques, and related models. The International GNSS Service (IGS) established a multi-GNSS experiment (MGEX) to track, collate, and analyze all of the available GNSS signals [3]. Currently, MGEX analysis centers (ACs) provide precise satellites products, including satellite orbits and clock corrections, for all GNSS. MGEX triggered an update of data formats and improvements in hardware development. It also provided many valuable models, such as satellite phase center offsets, code, and phase biases [4]. IGS products are currently expressed in IGS14, which is the latest in a series of GNSS reference frames adopted by the IGS, thus IGS14 aligns orbit products with the International Terrestrial Reference Frame 2014 [5].

Recent developments in GNSS and a common access to GNSS data stimulate a growth of GNSS-based applications. In addition to positioning, navigation, and timing (PNT) based applications, a wide scope of scientific and sophisticated applications can be found, e.g., space weather modeling [6], water vapor monitoring [7,8], radio-occultation [9], soil moisture determination [10], and snow height measurements [11]. In many areas, such as geodynamics or see level climatology, the latency of results reaching even tens of days is highly acceptable and does not decrease its usefulness. On the other hand, there are more and more applications demanding precise positioning in real-time, e.g., unmanned aerial vehicle photogrammetry [12], tsunami warning systems [13], precision agriculture [14], and monitoring performance of athletes [15].

For many years real-time precise PNT applications were dominated by differential techniques such as real-time kinematics (RTK). In RTK, by forming between-satellite differences of between-receiver single differences, the following error sources are eliminated: satellite orbit and clock errors, ionosphere and troposphere signal delays, and hardware biases. The serious drawback of RTK is that it is area limited because a GNSS reference station nearby the rover receiver is required [16]. The distance to the reference station can be extended up to 100 km when supported by ionosphere corrections [17] and in network RTK (RTN) [18], or up to hundreds of kilometres in Wide Area RTK (WARTK) concept [19], but it is still far away from a global technique.

The dependence on the reference station can be overcome by Precise Point Positioning (PPP) technique [20]. PPP is a single-receiver, autonomous technique that takes advantage of precise clocks and orbits, so the obtained results are strongly related to the quality of used products. GNSS products of the highest quality are obtained with combined solutions of contributing ACs, but they are obtained in a post-processing mode and are delivered with a latency of few weeks [21]. This eliminates their usefulness in real-time applications. Fortunately for real-time PPP users, in 2013, IGS established a Real-Time Service (RTS) that provides precise products for GPS and experimental products for GLONASS in real-time via Internet streams [22]. Currently, there is only one IGS AC, namely, Centre National d’Études Spatiales (CNES), which freely provides corrections to GPS, GLONASS, Galileo, and BeiDou [23], thus supporting all of the currently available systems. This allows for performing real-time multi-GNSS PPP. Moreover, ionosphere corrections, code, and phase biases are provided in CNES streams, which allows for ambiguity resolution in zero-differenced processing. With official IGS RTS corrections only float ambiguity solution is possible.

Real-time float GPS PPP can provide sub-decimeter accuracy of positioning [24,25] and improves the solution RMS by about 50% when compared with the solution obtained from the predicted part of the IGS ultra-rapid products [26]. The fusion of multiple GNSS results in more stable coordinate time series, thus, a few centimeter accuracy is possible even with 40 degrees cut-off elevation [27]. However, adding GLONASS to GPS has a negative or marginal effect on real-time static PPP [28], while kinematic PPP may be improved especially under reduced visibility scenarios [29]. It was also found that multi-GNSS solutions accelerate the initialization time by up to 27% and improve the positioning accuracy by up to 22% [30].

Unfortunately, the quality of real-time products is not homogenous among systems and it depends on many factors, such as satellite constellation, Sun elevation above the orbital plane (β angle), or orbit type [31]. Moreover, there are many deficiencies in satellite orbit models, especially for modernized blocks and emerging systems, which additionally deteriorate the quality of orbits and clocks. For these reasons, a special attention should be paid on the proper weighting of observations. Many weighting approaches have been proposed for observation weighting of the same type, e.g., carrier-to-noise ratio [32] and elevation-depending weight models [33]. For weighting different types of observations, which is the case of processing multi-GNSS data, the rigorous Helmert variance component estimation method is widely used [34], but it requires a postprocessing of high redundant observations [35]. For real-time multi-GNSS application both intra- and inter-system weights should be known in advance, which optimize the processing of a variety of observations. Therefore, the goal of this study is to develop and compare several observation weighting schemes that are suitable for real-time multi-GNSS PPP.

The paper is structured as follows. After the introductory Section 1, GNSS data processing strategy and the development of stochastic models are described in detail in Section 2. Afterwards, results of multi-GNSS processing with different weighting schemes are analyzed by means of formal errors, coordinate repeatability, and convergence time. Section 4 provides the discussion and conclusions.

2. Data and Methods

2.1. GNSS Data

We process GPS, GLONASS, Galileo, and BeiDou observations from 12 IGS stations distributed worldwide (Figure 1). Several multi-GNSS receivers and antenna types are installed at selected stations that represent the most popular equipment within the IGS network. Detailed information about hardware configuration and signals used in this study is listed in

Table 1. Station equipment and observations types used; originally leading C and P letters (denoting pseudorange and carrier-phase observation type, respectively) were replaced by a letter indicating the Global Navigational Satellite Systems (GNSS): G for GPS, R, for GLONASS, E for Galileo, and C for BeiDou (see RINEX 3.03 for signal specification [36]).

Station	Receiver Type	Antenna Type	Pseudoranges	Carrier-Phases
MIZU	JAVAD TRE_G3TH DELTA	JAV_RINGANT_G3T NONE	G1W G1C G2X G2W R1P R1C R2P R2C E1X E5X C2I C7I	G1C G2W R1C R2C E1X E5X C2I C7I
REYK	LEICA GR25	LEIAR25.R4 LEIT	G1C G2W G2S R1C R2P E1C E5Q C2I C7I	G1C G2W R1C R2P E1C E5Q C2I C7I
WROC			G1C G2W G2S R1C R2P R2C E1C E5Q C2I C7I
UCAL	TRIMBLE NETR9	TRM57971.00 NONE	G1C G2X G2W R1P R1C R2P R2C E1X E5X C2I C7I	G1C G2W R1C R2C E1X E5X C2I C7I
AREG		TRM59800.00 NONE
CHPG
JFNG
PNGM
KZN2		TRM59800.00 SCIS
NKLG
NNOR	SEPT POLARX4	SEPCHOKE_MC NONE	G1W G1C G2W G2L R1C R2P R2C E1C E5Q C2I C7I	G1C G2W R1C R2C E1C E5Q C2I C7I
YEL2	SEPT POLARX4TR	LEIAR25.R4 NONE

.

We process GNSS data stored in RINEX 3.03 files from two different periods, one week long each. The first period is 6–12 February (day of year DoY 37-43), 2017. The second period is 15–21 July (DoY 196-202), 2017. We use real-time corrections and broadcast ephemeris provided by CNES on the mountpoint CLK93 that are stored using BKG Ntrip Client v 2.12 (BNC) in ASCII files. During processing, the mean number of observations for multi-GNSS solutions is about 2–3 times larger than when compared to GPS-only solutions.

2.2. Functional Model

GNSS data processing is done using the in-house developed GNSS-WARP software [28], in the simulated real-time mode, in order to reproduce the same conditions for each weighting scheme. We define the combined GPS + GLONASS + Galileo + BeiDou observation model as:

$$P_{IF}^s+c\delta t^s-{\rho }_r^s-m_h^s·Z_h-{\Delta }_P^s=\frac{X_r-X^s}{{\rho }_r^s}\delta X_r+\frac{Y_r-Y^s}{{\rho }_r^s}\delta Y_r+\frac{Z_r-Z^s}{{\rho }_r^s}\delta Z_r+c\delta t_{r,S}+m_w^s·Z_w$$

(1)

$$L_{IF}^s+c\delta t^s-{\rho }_r^s-m_h^s·Z_h-{\Delta }_L^s=\frac{X_r-X^s}{{\rho }_r^s}\delta X_r+\frac{Y_r-Y^s}{{\rho }_r^s}\delta Y_r+\frac{Z_r-Z^s}{{\rho }_r^s}\delta Z_r+c\delta t_{r,S}+{\lambda }_{IF}^s·B_{IF}^s+m_w^s·Z_w$$

(2)

where: S denotes the GNSS system and s denotes the satellite number; $P_{IF}^s$ and $L_{IF}^s$ are iono-free combinations of pseudorange and carrier-phase measurements, respectively; c is the speed of the light; $\delta t^s$ is satellite clock correction; ${\rho }_r^s$ is the geometric distance between receiver and satellite; $m_h^s$ and $m_w^s$ are the hydrostatic mapping function and wet mapping function, respectively; $Z_h$ and $Z_w$ are the zenith hydrostatic delay and zenith wet delay, respectively; ${\Delta }_P^s$ and ${\Delta }_L^s$ are satellite, receiver, and site displacement effect corrections [37] for pseudoranges and carrier-phase measurements, respectively; $X_r$, $Y_r$, and $Z_r$ are the receiver a priori coordinates; $X^s$, $Y^s$, and $Z^s$ are the satellite coordinates; $\delta X_r$, $\delta Y_r$, and $\delta Z_r$ are the receiver position increments relative to the a priori position; $\delta t_{r,S}$ denotes receiver clock error; ${\lambda }_{IF}^s$ is the iono-free wavelength; $B_{IF}^s$ is the ionosphere-free ambiguity (bias) parameter.

All of the multi-GNSS observations are processed together in one common least square estimator. The details of the processing strategy are presented in

Table 2. Summary of the Precise Point Positioning (PPP) processing strategy.

Observables	ionosphere-free pseudorange and carrier-phase
Frequencies (RINEX 3.03 notation)	GPS: L1/L2, GLONASS: G1/G2, Galileo: E1/E5a, BeiDou: B1/B2
Inter-system weighting	elevation e dependent weighting: sin(e)
Elevation cut-off angle	5°
Sampling rate	30 s
Troposphere delay modeling	UNB3m mapping functions [38] and a priori value for hydrostatic delay, wet delay estimated as 4 mm/√hour random walk process
Receiver clock	estimated as white noise, individual clock for each GNSS
Satellite orbits and clocks	fixed from real-time CNES stream (mountpoint CLK93)
Code and phase biases	absolute, from real-time CNES stream (mountpoint CLK93)
Solution type	daily static with float ambiguities
Correction models	phase wind-up, relativistic delays, solid earth tides, receiver antenna phase center offset and variation [37]

.

2.3. Development of Stochastic Model

2.3.1. Stochastic Model for GPS

In majority of GNSS software implementations, pseudoranges are treated as 100 times noisier than carrier phases, and the a priori standard deviation of raw pseudoranges ${\sigma }_P$ is set between 2.0 m to 3.0 m by default. However, [39] use ${\sigma }_P$ for GPS equal to 0.3 m and set the standard deviation of GPS raw carrier phase ${\sigma }_L$ to 3 mm. During the development stage of the WARP software, we have adopted ${\sigma }_P$ = 0.3 m, which corresponds to 0.9 m for pseudorange ionosphere-free observable. We have also calibrated the least square adjustment of both pseudoranges and carrier phases in real-time processing with an empirical approach to obtain the a posteriori error of unit weight m0 close to 1. We have resulted with ${\sigma }_L$ equal to 10 mm.

In order to check how this stochastic model for GPS observation suits to GPS data from our test stations, we analyze the m0 values from different solutions. First, we perform code-based GPS only positioning using ${\sigma }_P$ from 0.1 m to 0.5 m (Figure 2a). We noticed that results are station dependent, without any clear relation with station hardware configuration. We suspect that this is rather caused by station environment and software configuration e.g., pseudorange tracking mode or pseudorange smoothing algorithm with carrier phases. All of the stations except UCAL, which is equipped with the relatively old antenna, result in m0 smaller than 1 for ${\sigma }_P$ = 0.3 m. This indicates that ${\sigma }_P$ can be set even smaller in code-based only solutions if state-of-the art, modern geodetic hardware is used. We found that ${\sigma }_P$ = 0.235 m results in the station-averaged m0 equal to 1.

Secondly, for each ${\sigma }_P$ we perform GPS-only PPP using ${\sigma }_L$ from 2 to 50 mm (Figure 2b). We noticed that for small ${\sigma }_P$ it is not possible to obtain m0 = 1. In general and as expected, we found that the larger the ${\sigma }_P$ is, the smaller ${\sigma }_L$ should be in order to achieve m0 = 1, and for unrealistically small ${\sigma }_P$ it is not possible to obtain m0 = 1 at all. We also found that for ${\sigma }_P$ = 0.3 m and ${\sigma }_L$ = 10 mm, the average m0 is very close to 1, which justifies the use of this GPS stochastic model in further processing. For ${\sigma }_P$ = 0.235 m, in order to achieve m0 close to 1 in PPP, ${\sigma }_L$ should be set to 50 mm.

2.3.2. SISRE

It is a common practice to down-weight observations from other GNSS when compared to GPS due to mis-modelling of satellite orbits and clocks. The contribution of orbit and clock error to range measurements can be expressed as signal-in-space ranging errors (SISRE) [40] using the following formula:

$$SISRE=\sqrt{{\left[RMS\left(w_R·\Delta r_R-\Delta cdt\right)\right]}^2+w_{A,C}^2·\left(A^2+C^2\right)},$$

(3)

where $w_R$ and $w_{A,C}^2$ are GNSS-dependent SISRE weight factors for statistical contribution of radial (_R), along-track (_A), and cross-track (_C) errors to the line-of-sight ranging error, $\Delta r_R$ and $\Delta cdt$ are the residuals for radial and clock components, respectively, A and C are the RMS of along- and cross-track orbit components, respectively. We use orbit and clock residuals from the comparison of real-time multi-GNSS CNES products with final products [31]. Values of all the parameters required in SISRE computation are presented in

Table 3. Values used in SISRE computation.

	$\mathit{R}\mathit{M}\mathit{S}\left({\mathit{w}}_{\mathit{R}}·\Delta {\mathit{r}}_{\mathit{R}}-\Delta \mathit{c}\mathit{d}\mathit{t}\right)$ [mm]	A [mm]	C [mm]	${\mathit{w}}_{\mathit{R}}$	${\mathit{w}}_{\mathit{A},\mathit{C}}^2$
GPS	30.0	36.2	29.2	0.98	1/49
GLONASS	85.2	104.0	68.5	0.98	1/45
Galileo	95.8	133.2	131.6	0.98	1/61
BeiDou IGSO	115.3	315.9	350.0	0.99	1/126
BeiDou MEO	107.0	188.4	123.7	0.98	1/54

. Figure 3 presents SISRE computed individually for each satellite, as well as a single RMS of SISRE for each GNSS, with an additional division to MEO and IGSO satellites for BeiDou. We found that only for some GLONASS and BeiDou IGSO satellites individual SISRE values significantly differ from the system SISRE, and therefore we use system values for simplicity. For missing BeiDou GEO satellites, we use BeiDou MEO SISRE multiplied by a factor of 10, following the fact that RMS of the BeiDou GEO orbit differences between IGS analysis centers show up to a few meters in the along-track direction, whereas for BeiDou MEO the RMS is at the level of a few decimeters [41].

2.3.3. Observation Noise

Another factor that influences the quality of GNSS observables is their noise, which caused by characteristics of individual signals and related propagation errors. Significant differences in signal noise between systems and satellite blocks are reported, but the differences between the frequencies are relatively small [42].

Table 4. Standard deviation of carrier phase and code receiver noises.

System	Block	Noise StdDev
		Carrier Phase [mm]	Pseudorange [m]
GPS	IIR	1.100	0.155
	IIR-M	1.100	0.150
	IIF	1.033	0.150
GLONASS	M	1.250	0.235
Galileo	IOV	1.400	0.068
BeiDou	GEO	1.467	0.130
	IGSO	1.400	0.143
	MEO	1.133	0.117

presents the generalized results, in which the noise standard deviations for observables at each frequency are replaced by a frequency mean value of the noise. Because the results do not contain information on some of the satellite types, namely GLONASS K and Galileo FOC, we assume that they have the same system noise as other satellites of the same system.

The application of frequency mean value is a simplified approach, in which the noise difference among frequencies and codes are ignored. As an alternative, one can additionally differentiate raw carrier phase noise by assuming the accuracy of 0.01 cycle [43]. However, it is hard to discriminate pseudoranges because of the lack of knowledge regarding the actual performance of the individual pseudo-range measurements depending on modulation, receiver, correlator type, and so on [44].

2.3.4. Multi-GNSS Weighting Schemes

Following the considerations mentioned above, we propose five different multi-GNSS weighting schemes (Figure 4). In two schemes, namely GREC_L10 and GREC_L50, equal ${\sigma }_P$ and ${\sigma }_L$ are applied for all GNSS, and therefore there are actually no inter-system differences in observation weighting. The GREC_L10 scheme represents the stochastic model developed for GPS (${\sigma }_P$ = 0.30 m and ${\sigma }_L$ = 10 mm). GREC_L50 represents the scheme for which the station averaged m0 is close to 1 in GPS code-base only solution (${\sigma }_P$ = 0.235 m and ${\sigma }_L$ = 50 mm). Therefore, in the GREC_L50 scheme, slightly larger weights are put on pseudoranges and significantly smaller weights are put on carrier phase when compared to the GREC_L10 scheme.

In the next two schemes, namely GREC_GxN and GREC_GxS, the stochastic model developed for GPS is also used, but for other GNSS ${\sigma }_P$ and ${\sigma }_L$ are multiplied proportionally to the signal noise of each system (Table 4. Standard deviation of carrier phase and code receiver noises. or general SISRE results (Figure 3), respectively. Compared to the GREC_L10 scheme, in the GREC_GxN scheme GLONASS pseudoranges are downweighted, Galileo pseudoranges are upweighted and BeiDou pseudoranges are slightly upweighted as well. Carrier phases of other GNSS are only slightly downweighted when compared to GPS. In the GREC_GxS scheme both pseudoranges and carrier-phases of other GNSS are downweighted compared to GPS, and the smallest weights are put on BeiDou GEO observations, due to the poor quality of orbit and clocks products for GEO satellites.

Finally, a GREC_N&S scheme is proposed in which the a priori error of observable $\sigma$ is calculated as a cumulative error of the corresponding orbit quality expressed by SISRE and signal noise N, as follows:

$$\sigma =\sqrt{N^2+SISR{E}^2}$$

(4)

In this scheme we found Galileo pseudoranges to have the highest weights among all GNSS, while GLONASS and BeiDou GEO pseudoranges are downweighted when compared to other pseudoranges. For carrier phases the smallest ${\sigma }_L$ are obtained for GPS satellites and they are more than two times larger for GLONASS, more than three times larger for Galileo. Carrier phase weights are four and almost five times larger when compared to GPS for BeiDou MEO, and BeiDou IGSO, respectively. For BeiDou GEO ${\sigma }_L$ is 10 times larger than for BeiDou MEO, which means that in this scheme carrier phase observations to BeiDou GEO carrier phases have weights at the level of pseudoranges, so consequently they have a limited contribution to the solution.

3. Results

We process data from all of the test stations during two selected test periods in five multi-GNSS solutions using the proposed weighting schemes, as well as in one GPS only solution G_L10 using the same weights as in GREC_L10 scheme. Exemplary coordinate time series and respective formal errors are presented in Figure 5. Centimeter level differences between solutions can be noticed and the impact of weighting on convergence time is also found.

We evaluate the results by analyzing formal errors of estimated coordinates, day-by-day repeatability of coordinates, and solution convergence time. The formal errors of coordinates are understood here as the a posteriori errors of each coordinate component obtained at the last epoch of each daily solution. Day-by-day repeatability was calculated as a standard deviation of coordinates obtained at the end of each daily solution. We assume that the convergence is reached in a specific epoch if the formal error of the coordinate component remains below the 0.01 m for at least 15 min afterward.

3.1. Formal Errors

Figure 6 shows three-dimension (3D) coordinate formal errors for all of the solutions in two test periods independently and

Table 5. Mean formal errors of coordinates for all stations during both test periods.

	G_L10	GREC_L10	GREC_L50	GREC_GxN	GREC_GxS	GREC_N&S
North [mm]	0.9	0.7	3.5	0.8	0.6	2.4
East [mm]	2.0	1.5	5.0	1.7	1.2	3.8
Up [mm]	3.8	3.0	14.7	3.3	2.3	9.9
3D [mm]	4.4	3.5	15.9	3.8	2.7	10.9

shows the mean formal error of coordinates for all stations in both test periods together. The presented results show that multi-GNSS solutions can reduce formal errors, however, the improper weighting may significantly affect the results. This is the case in the GREC_L50 scheme in which the mean of the formal error equals about 16 mm, while for other solutions, it is below 5 mm. When compared to G_L10 solution, 3D formal errors are decreased by 21%, 14%, and 40% for GREC_L10, GREC_GxN, and GREC_GxS solutions, respectively. On the other hand, in the GREC_N&S solution coordinate formal errors are multiplied by a factor of 2.5 on average.

We found that the GREC_GxS scheme results in the smallest formal errors for all stations and all days. On average the formal errors are 0.6, 1.2, and 2.3 mm for the North, East, and Up component, respectively. In the GREC_GxS solution, formal errors for all of the coordinate components are reduced at the similar 40%-level when compared to the G_L10 solution, while in other multi-GNSS solutions the reductions vary among components and are mainly observed for the East component.

3.2. Coordinate Repeatability

Figure 7 illustrates a boxplot of 3D coordinate repeatability for all of the solutions in two periods independently and

Table 6. Mean coordinate repeatability for all stations during both test periods.

	G_L10	GREC_L10	GREC_L50	GREC_GxN	GREC_GxS	GREC_N&S
North [mm]	4.2	6.5	9.2	5.7	3.9	6.5
East [mm]	8.4	14.0	28.8	15.6	8.0	22.5
Up [mm]	11.0	16.1	27.9	13.6	10.1	19.6
3D [mm]	15.2	22.8	42.4	22.2	14.2	31.5

contains mean coordinate repeatability values for all the stations during both test periods together. Once again GREC_L50 delivers significantly worse results in comparison with other solutions, with the maximum standard deviation of 3D coordinate repeatability reaching almost 90 mm for equatorial station NKLG in the first test period and 55 mm for the Canadian station UCAL in the second test period. We noticed that the coordinate repeatability in the majority of multi-GNSS solutions is degraded when compared to GPS only solution. The 3D coordinate repeatability is worse by 50%, 46%, and 110% for GREC_L10, GREC_GxN, and GREC_N&S, respectively. In GREC_GxN, we noticed a 4% improvement in the Up component, which is not the case in other abovementioned solutions.

Compared to the GPS only solution, the improvement in all of the components is visible only in the GREC_GxS solution. The mean 3D coordinate repeatability in GREC_GxS is 14.2 mm, which gives a 6% of improvement when compared to 15.2 mm obtained with G_L10. Only for station AREG in the first time period, the 3D repeatability of coordinates was degraded, by less than 2 mm.

3.3. Convergence Time

Figure 8 and Figure 9 show the convergence time to the level of 0.01 m in both test periods for horizontal and vertical coordinate components, respectively. Additionally, mean convergence times for both test periods are listed in

Table 7. Mean convergence time in hours to reach 0.01 m level for all of the stations during both test periods.

	G_L10	GREC_L10	GREC_L50	GREC_GxN	GREC_GxS	GREC_N&S
Horizontal [h]	3:34	2:31	10:03	2:44	2:11	7:16
Vertical [h]	5:43	3:34	18:17	4:12	3:01	16:52

. Again, the GREC_L50 solution provides the worst results, with the convergence time exceeding 18 h for the horizontal component and some sessions with the vertical component not converging below the level of 0.01 m at all. Other multi-GNSS weighting schemes result in a significantly shortened convergence time for the majority of stations and days both in the horizontal and vertical component. The convergence time of the horizontal component is reduced by 30%, 24%, and 39% for GREC_L10, GREC_GxN, and GREC_GxS, respectively, when compared to the GPS-only solution. The convergence time of the vertical component is reduced by 37%, 26%, 47% for GREC_L10, GREC_GxN, GREC_GxS, respectively. In the GREC_N&S solution, the convergence time elongates by a factor of 2 and 3 for horizontal and vertical component, respectively.

One can see again that the GREC_GxS weighting scheme leads to the best results, with a mean convergence time to 0.01 m level of about 2 and 3 h for the horizontal and vertical component, respectively. When compared to the GPS-only solution, this is an improvement of 39% for the horizontal components and 47% for the vertical component. The obtained convergence times are still too long for real-time PPP application or the anticipated error level of 0.01m is too strict. On the other hand, there are some fields, such as tsunami detection systems or precision agriculture, for which convergence time is not an issue.

4. Discussion

We propose five different GPS + GLONASS + Galileo + BeiDou weighting schemes, including two schemes with no intra-system differences i.e. the same weights were applied for all the systems, and three schemes that are based on signal noise and/or quality of satellite orbits expressed using SISRE. For 12 diverse IGS stations distributed worldwide, we obtained six different PPP solutions over two test periods, one week long each. We performed the GPS-only solution as well as five multi-GNSS solutions representing each weighting scheme. Then, we analyzed formal errors of coordinates, coordinate repeatability, and solution convergence time, in order to assess the quality of each solution, and, consequently, the correctness of weighting schemes.

The performed analyses show that using observations of a multi-GNSS constellation in real-time PPP allows for us to significantly reduce formal errors of estimated coordinates and to greatly shorten the convergence time. The improvement of the coordinate repeatability is limited, which is consistent with the post-processing case, in which the addition of other GNSS to GPS static PPP does not significantly improve the daily coordinate repeatability. The reason is that the quality of 24 h GPS-only PPP is already at the centimeter level, and the addition of new constellations does not improve the accuracy significantly [45]. On the other hand, we noticed that improper weighting of multi-GNSS observations leads to a significant degradation of the coordinate repeatability, even though there is still an improvement in convergence time and formal errors of coordinates. It proves that the improved satellite geometry is the main factor reducing formal errors of estimated parameters, and, consequently, solution convergence time, as it simply gives much more observations into the system of normal equations. However, only with a proper weighting scheme the precision of the daily multi-GNSS solutions can be at least maintained at the level when compared to the GPS-only solution.

We found that the simplest approach, in which equal weights are applied for all the systems, is incorrect and in the best case causes a degradation of coordinate repeatability by 50% when compared to the GPS-only solution. Additionally, if pseudorange to carrier-phase weighting rate is too small, e.g., pseudoranges are overweighted, the solution will totally fail, leading to the degradation of all measures: formal errors, convergence time and coordinate repeatability. It proves that the optimum stochastic model for real-time multi-GNSS solutions should take into account both intra-system and intra-observation diversity.

5. Conclusions

Among all of the tested weighting schemes, the GREC_GxS is the best. In this scheme, a stochastic model developed for GPS is scaled for other GNSS using SISRE information. When compared to the GPS-only solution, this weighting scheme improves all criteria of the assessment: formal errors, convergence time and coordinate repeatability. Moreover, these improvements are found during both test periods as well as for each station. We noticed an average reduction of formal errors of about 38% in each coordinate component. The mean formal error of 3D coordinates is reduced from 4.4 mm to 2.7 mm. The mean convergence time is reduced from 5 h 43 min to 3 h 1 min (47%), and from 3 h 34 min to 2 h 11 min (39%) for the horizontal and vertical component, respectively. GREC_GxS is the only scheme that improves the coordinate repeatability, however, the improvement is not spectacular. The coordinate repeatability in 3D in GPS-only solution is 15.2 mm and in GREC_GxS is 14.2 mm, which gives a 6% improvement of the precision.

The presented results allow us to recommend GREC_GxS as the best weighting scheme for multi-GNSS real-time PPP processing. Nevertheless, we have to be aware that the scheme uses information about the quality of the real-time products (orbits and clocks) expressed with SISRE. The ongoing development and the continuous improvement of the orbital models used in real-time services may change the SISRE values that are presented in this paper, and therefore make the developed scheme obsolete. Thus, another suggestion is to prepare some kind of a service for regular monitoring of SISRE values for real-time products, which could be applied in future works connected with multi-GNSS real-time positioning. Real-time users have to mindfully take advantage of the multi-GNSS constellation whose integration is not direct and origins from the differences between all of the systems.