Introduction

Since Malys and Jensen (1990), Héroux and Kouba (1995), and Zumberge et al. (1997) introduced the concept, Precise Point Positioning (PPP) has become a well-established technique for determining the user’s position and other valuable parameters like atmospheric delays (Kouba et al. 2017). Thanks to the continuous development of GNSS constellations, PPP typically utilizes observations from multiple GNSS nowadays, improving its performance in all regards (Tegedor et al. 2014; Pan et al. 2017; An et al. 2020). Furthermore, researchers investigate observation models handling three GNSS frequencies (Geng and Bock 2013; Pan et al. 2019; Naciri 2021). Additionally, PPP with integer ambiguity resolution (PPP-AR) has proven as an effective method for reducing or possibly eliminating the convergence time to centimeter-level accuracy (Ge et al. 2008; Teunissen 2020). Due to its characteristics and flexibility, PPP faces a promising future. However, the convergence time of PPP is still a central topic in scientific research and its limiting factor compared to other relative positioning methods (Choy et al. 2017). In the last years, several open-source PPP software packages have become available: RTKLIB (Takasu 2010, 2012), GAMP (Zhou et al. 2018), PPPH (Bahadur and Nohutcu 2018), PRIDE PPP-AR (Geng et al. 2019), MG-APP (Xiao et al. 2020), PPPLib (Chen and Chang 2021), and SUPREME (Zhao et al. 2021). Each software package offers its own advantages and different features. Note that user-friendliness and documentation vary considerably, complicating the installation and first steps.

The Vienna VLBI and Satellite Software (VieVS) offers various software packages for VLBI applications (Böhm et al. 2018), ionosphere models (Magnet 2019; Boisits et al. 2020), and a tropospheric ray-tracing package (Hofmeister and Böhm 2017). In the following, we introduce a MATLAB PPP software named raPPPid — the PPP module of VieVS (VieVS PPP). Contrary to most other PPP software, raPPPid supports PPP-AR for GPS, Galileo, and Beidou with various satellite products available and shows outstanding user-friendliness thanks to its graphical user interface (GUI) and documentation (e.g., wiki). Furthermore, raPPPid achieves remarkable convergence times and can handle high-quality to low-cost GNSS observations due to a flexible program structure, various options, and highly adaptable processing settings. For example, users can directly define a weighting function for the observations in the GUI. VieVS PPP accepts the most common file format standards of the GNSS community (e.g., SINEX BIAS, ORBEX) and supports parallel processing of multiple observation files. The processing results are available in various output formats. Finally, the user can choose from an extensive plot section to illustrate the results, convergence period, quality of the observations and models, and satellite geometry. The figures presented in this article are only an excerpt of the graphical capabilities offered by raPPPid.

The following section introduces the basic workflow and general program structure of raPPPid. The third section presents the implemented PPP models. The fourth and fifth sections show processing results for high-quality data and smartphones, respectively. Our conclusions are drawn in the final section. In addition to this article, the raPPPid wiki (https://vievswiki.geo.tuwien.ac.at/en/raPPPid) explains all options and settings provided in the GUI, and Glaner (2022) presents more theoretical background and results achieved with raPPPid. Furthermore, various publications document applications of raPPPid (Boisits et al. 2020; Glaner and Weber 2021; Hohensinn et al. 2022; Aichinger-Rosenberger et al. 2023).

Program structure

The MATLAB software package of raPPPid can process up to three frequencies from all four globally working GNSS (GPS, GLONASS, Galileo, and BeiDou) in various PPP models presented in the next section. The main characteristics and features are the following:

  • The program design allows combining all GNSS and signals, processing different frequencies for each GNSS, and handling static and kinematic observation data with any interval.

  • User-friendliness due to a straightforward GUI and a wiki providing processing examples and detailed descriptions

  • Automatic download of input data (e.g., a large number of satellite products and models).

  • Support of present GNSS file formats (e.g., ORBEX) and self-explanatory output data.

  • Numerous processing options and features are available. For example, several quality checks of the observations (e.g., cycle slip detectors) and a wide range of atmospheric corrections.

  • Quasi-real-time processing using stream archives or real-time correction streams recorded with the BKG Ntrip Client (BNC).

  • Batch processing of observation files optionally using parallelization (MATLAB parfor loop). The processing name and manually selected input data can be designed adaptively (e.g., depending on the day to process).

  • A remarkable amount and variety of plots. So-called multi-plots are specifically designed for analyzing the convergence period.

Figure 1 presents the main workflow of raPPPid. The processing can be divided into four major steps. First, the user has to select a RINEX observation file and configure the processing settings in the GUI. After the user starts the processing from the GUI, raPPPid performs the calculations automatically. All needed input data is downloaded and read in during the pre-processing phase. Then, the epoch-wise processing runs as a loop over the selected epochs of the RINEX observation file. Note that it is possible to insert resets of the PPP solution in specific epochs useful to study the convergence behavior (e.g., multi-plots). When raPPPid reaches the last epoch to process, the epoch-wise calculation of the PPP solution is completed, and raPPPid creates the output data used for visualization.

Fig. 1
figure 1

Overview of the workflow of raPPPid

Full size image

Table 1 shows an overview of the program-internal order of GNSS and frequencies. The order of GNSS is relevant, for example, for estimating the receiver clock offsets. Furthermore, Table 1 presents the used GNSS acronyms (e.g., variable names) and the internal satellite numbering, which is used additionally to common satellite naming (e.g., G01 or E32). A multiple of a hundred is added to the satellite's PRN depending on the GNSS satellite to obtain the raPPPid internal satellite number. This strategy allows storing satellite-specific data in a specific epoch in vectors and saving the data from the whole processing in matrices.

Table 1 Program-internal acronyms, satellite numbering, and order of GNSS and signal frequencies
Full size table

PPP models

The PPP models implemented in raPPPid mainly differentiate in the handling of the ionospheric delay. The two main options are the conventional PPP model based on two signal frequencies for building the ionospheric-free linear combination (IF LC) and the uncombined model managing any number of frequencies (Schönemann 2013). Furthermore, VieVS PPP can process a single 3-frequency IF LC built with the formulas provided by Pan et al. (2019). For simulated data, raPPPid also offers the possibility to ignore the ionospheric delay completely or correct the raw GNSS observations with an ionosphere model. Note that Inter-frequency clock biases (IFCBs) are not considered currently.

$${P}_{i}=\rho +c\left({\mathrm{d}t}_{R}-{\mathrm{d}t}^{S}\right)+\mathrm{dTrop}+{\mathrm{dIono}}_{i}+{B}_{R,i} -{B}_{i}^{S}+ \varepsilon$$
(1)
$${L}_{i}=\rho +c\left({\mathrm{d}t}_{R}- {\mathrm{d}t}^{S}\right)+\mathrm{dTrop}-{\mathrm{dIono}}_{i}+\left({N}_{i}+ {b}_{R,i}- {b}_{i}^{S}\right){ \lambda }_{i}+\varepsilon$$
(2)

These two principal PPP models are introduced starting from the GNSS observation equations (Teunissen and Montenbruck 2017) presented in units of meters in (1) and (2) for the code observable \({P}_{i}\) and phase observable \({L}_{i}\), respectively, on frequency \(i\). No index for the GNSS is included to improve the readability. The geometric distance between the satellite and receiver is denoted as \(\rho\). The receiver clock error \({\mathrm{d}t}_{R}\) and satellite clock error \({dt}^{S}\) are both multiplied by the speed of light \(c\). \(\mathrm{dTrop}\) and \(\text{dIono}\) denote the tropospheric and ionospheric delays. Receiver and satellite code hardware delays represented as \({B}_{R}\) and \({B}^{S}\), respectively, are converted to the range, and \(\varepsilon\) includes random and other negligible errors. The ambiguity term of the phase observable comprises the integer term \(N\) and carrier phase hardware delays from the receiver \({b}_{R}\) and the satellite \({b}^{s}\) and is multiplied by the wavelength \({\lambda }_{i}\).

Fundamentally, PPP relies on precise satellite orbits, clocks, and biases. Therefore, the PPP observation equations presented in the following do not include a satellite orbit error, satellite clock error, or satellite code hardware delays. Furthermore, raPPPid models various error sources, such as the hydrostatic part of the tropospheric delay, relativistic effects, phase wind-up, satellite and receiver phase center offset and variations, deformation of the solid earth surface, group delay variations (GDVs), and ocean loading (Glaner 2022). For the so-called float solution, phase hardware delays originating from the receiver and satellite are lumped together with the integer term of the ambiguity to the float ambiguity, denoted as \(\widetilde{N}\) below.

$${P}_{\mathrm{IF}}=\frac{{f}_{1}^{2}}{{f}_{1}^{2}-{f}_{2}^{2}}{P}_{1}-\frac{{f}_{2}^{2}}{{f}_{1}^{2}-{f}_{2}^{2}}{P}_{2}$$
(3)
$${L}_{\mathrm{IF}}=\frac{{f}_{1}^{2}}{{f}_{1}^{2}-{f}_{2}^{2}}{L}_{1}-\frac{{f}_{2}^{2}}{{f}_{1}^{2}-{f}_{2}^{2}}{L}_{2}$$
(4)
$$P_{{{\text{IF}}}} = \rho ~ + ~c\left( {{\text{d}}t_{R}^{{{\text{GNSS}}_{{\text{1}}} }} + \delta t_{R}^{g} } \right) + {\text{dTrop}}^{{{\text{wet}}}} + ~\varepsilon$$
(5)
$$L_{\mathrm{IF}} = \rho + c\left( {{\text{d}}t_{R}^{{{\text{GNSS}}_{{1}} }} + \delta t_{R}^{g} } \right) + {\text{dTrop}}^{{{\text{wet}}}} + \widetilde{N}_{{{\text{IF}}}} \lambda_{{{\text{IF}}}} + \varepsilon$$
(6)

The IF LC denoted by the subscript \(IF\) is built for GNSS signals on two frequencies and the corresponding frequencies \({f}_{1}\) and \({f}_{2}\) with (3) and (4) for the code and phase observable, respectively. This approach eliminates the first-order ionospheric delay and is widely used for PPP by neglecting higher-order terms of the ionosphere (Hadas et al. 2017). Accordingly, this approach is called the conventional PPP model, and (5) and (6) present the corresponding PPP observation equations.

$${P}_{i}=\rho + c\left({\mathrm{d}t}_{R}^{{\mathrm{GNSS}}_{1}}+\delta {t}_{R}^{g}\right)-DC{B}_{1i}+{\mathrm{dTrop}}^{\mathrm{wet}}+{\upgamma }_{1\mathrm{i}}{\mathrm{dIono}}_{1}+ \varepsilon$$
(7)
$${L}_{i}=\rho + c\left({\mathrm{d}t}_{R}^{{\mathrm{GNSS}}_{1}}+\delta {t}_{R}^{g}\right)-DC{B}_{1i}+{\mathrm{dTrop}}^{\mathrm{wet}}-{\upgamma }_{1\mathrm{i}}{\mathrm{dIono}}_{1}+{\widetilde{{N}_{i}}\lambda }_{i} + \varepsilon$$
(8)

The PPP observation equations of the uncombined PPP model are presented in (7) and (8) for the code and phase observation, respectively. The uncombined model is a modern and more direct application of the GNSS observation equations suitable for any number of frequencies. Since the raw measurements are processed, the original observation noise is maintained and not increased through the coefficients of a LC, which is usually beneficial for the convergence time of PPP (Lou et al. 2016; An et al. 2020).

VieVS PPP uses an Iterative Extended Kalman Filter for the float solution to estimate the unknown parameters. Both introduced PPP models determine the receiver’s coordinates (implicitly included in \(\rho\)), wet tropospheric delay \({\mathrm{dTrop}}^{\mathrm{wet}}\), float ambiguities \(\widetilde{N}\), receiver clock error \(\delta {t}_{R}^{GNS{S}_{1}}\), and receiver clock offsets \(\delta {t}_{R}^{g}\). The receiver clock error is estimated for the first processed GNSS (Table 1), usually GPS. Furthermore, a receiver clock offset is added for each additionally processed GNSS. For example, raPPPid estimates the GPS receiver clock error and receiver clock offsets for GLONASS and BeiDou in a GRC processing. In the case of the uncombined model, receiver DCBs (\(DC{B}_{1i}\)) and slant ionospheric delays on the first frequency for each satellite \(\text{dIon}{\text o}_{\text 1}\) are additionally estimated. Thereby, the ratio of the squared frequencies \({\upgamma }_{1\mathrm{i}}={f}_{1}^{2}/{f}_{j}^{2}\) is used for converting ionospheric delays to the first frequency (e.g., from Galileo E5b to E1). Note that raPPPid also allows for correcting receiver DCBs.

$${\mathrm{dIono}}_{\mathrm{pseudo}}= \text{dIon}{o}_{1}+ \varepsilon$$
(9)

VieVS PPP optionally allows including ionospheric pseudo-observations in the uncombined model (9), leading to the uncombined model with ionospheric constraint. Therefore, the ionospheric delay on the first frequency is modeled for each satellite with an arbitrary ionosphere model and added as pseudo-observation. In this way, the rank deficiency between the receiver DCBs and the ionospheric delay is removed, leading to uncontaminated estimates. VieVS PPP uses a linear approach for increasing the variance of the ionospheric pseudo-observations over time (Boisits et al. 2020). This strategy allows raPPPid to optimally integrate ionosphere models and their imperfections into the PPP solution and has proven beneficial regarding the convergence time.

$$\widetilde{N}= \overline{N }+{\mathrm{b}}_{\mathrm{R}}-{\mathrm{b}}^{\mathrm{S}}$$
(10)

For integer ambiguity fixing, raPPPid corrects satellite hardware phase delays \({\text b}^{\text S}\) with a suitable bias product and eliminates the receiver hardware phase delays \({\text b}_{\text R}\) by choosing a reference satellite for each GNSS and building satellite single differences (SD). Remember that for the float solution, these phase delays were lumped together with the integer term \(\overline{N}\) to the float ambiguity \(\widetilde{N}\) as indicated in (10). By taking the estimated float ambiguities and the corresponding covariance matrix from the float solution, raPPPid can fix GPS, Galileo, and BeiDou ambiguities to integers and calculate an ambiguity fixed coordinate solution. Apart from that, the float and fixed solution are entirely separated. The fixed coordinates are estimated in a Least-Squares-Adjustment adjustment by introducing the fixed ambiguities as highly weighted pseudo-observations.

In the fixing process of the conventional model, the SD ambiguities of the Wide-Lane (WL) and Narrow-Lane (NL) are resolved consecutively using the Hatch-Melbourne-Wübbena LC and partial ambiguity resolution of the LAMBDA algorithm (Teunissen 1995), respectively (Glaner and Weber 2021). In addition to ambiguity fixing with the conventional model, raPPPid supports an experimental approach for PPP-AR with the uncombined model introduced in Glaner (2022). For this purpose, satellite products allowing integer ambiguity fixing the raw ambiguities model are necessary.

High-quality data

The high-quality GNSS observations of 24 globally distributed IGS MGEX stations recorded with an interval of 1 s on August 1, 2022, are processed with raPPPid (Fig. 2). These stations were randomly selected to cover the entire globe, but only stations with complete data and daily IGS coordinate estimation were considered eligible. The PPP solution is restarted every 15 min to comprehensively study the convergence behavior, resulting in around 2300 convergence periods. In the following, IGS products are used as a reference to assess the PPP results (e.g., final station coordinates, troposphere product, and final global ionosphere map (GIM)). The convergence time of the float coordinates is defined as the period until the 2D position difference is under the threshold of 10 cm and stays there for the entire remaining processing period. For the fixed solution, convergence is defined as the time to correct fix (TTCF), which is achieved when the 2D position difference of the fixed coordinates stays under the threshold of 5 cm until the remaining processing period.

Fig. 2
figure 2

Distribution of the 24 IGS MGEX stations

Full size image

Table 2 shows an overview of the processing settings. Settings only valid for the uncombined model are written in italic. Furthermore, PPP-AR and ambiguity fixing are only performed with the conventional model (underlined). For this test case, the IGS MGEX satellite products (satellite orbits, attitude, clocks, and biases) generated by the Center of Orbit Determination Europe (CODE) and Wuhan University (WUM) are selected to give an impression of raPPPid’s PPP performance. Both analysis centers provide the satellite attitude in the upcoming ORBEX format. CODE MGEX satellite products have proven to perform best regarding ambiguity fixing (Glaner and Weber 2021) and are applied with the corresponding ANTEX file, the conventional model, and ambiguity fixing. On the other hand, the MGEX satellite products of WUM are used for processing three-frequency observations in the uncombined model with ionospheric constraint. For comparison, a float solution with the conventional model is calculated with WUM products. Typically, the processing time of one processing period on a standard desktop PC ranges from 45 to 60 and 60 to 75 s with the conventional and uncombined model, respectively. The observation ranking (Table 2) decides the processed observations for stations tracking multiple signals on a specific frequency (e.g., GPS C1W is preferred over C1C). Due to the unique characteristics of the BeiDou system and the varying approaches applied by IGS analysis centers, BeiDou proves to be the most challenging system for PPP. Please note that raPPPid can process BeiDou (Glaner 2022), although its observations are not included in this test case.

Table 2 Overview of processing settings
Full size table

Figure 3 shows a bar plot illustrating the convergence behavior of the three processing configurations. The uncombined model with ionospheric constraint (UC) performs better than the conventional model (IF) in the first few minutes. This faster convergence results from using the uncombined approach keeping the raw observation noise, applying an ionosphere model for constraining, and including a third frequency. This improvement would increase in the case of complete three-frequency processing. In this test case, the number of three-frequency observations is considerably reduced because only a limited number of satellites currently emit GPS L5 and raPPPid did not process GLONASS G3 due to missing satellite biases. The difference between the conventional and uncombined approaches decreases over time (Fig. 3). After 10 min, no significant difference between WUM IF and WUM UC is visible. On the other hand, CODE IF and WUM IF perform similarly in the initial period. However, the difference between these two solutions increases over time, and CODE IF outperforms WUM IF after 7.5 min. Most likely, this results from more consistent satellite products.

Fig. 3
figure 3

Bar plot of the float solution convergence. The bars indicate the percentage of convergence periods converged at a specific time after the last reset

Full size image

Table 3 lists the mean convergence times of all cases achieving convergence, the percentage of processing periods without convergence, the median 3D position after 15 min, and the median ZTD difference. For reasons of comparison, Table 3 provides these numbers also for processing two frequencies in the uncombined model with ionospheric constraint. The numbers suggest that the uncombined model performs slightly better in terms of convergence but slightly worse regarding the percentage of not converged cases and the position accuracy after 15 min. Among other things, this can be explained by missing receiver PCOs and PCVs for the third frequency. Currently, raPPPid replaces these with the first frequency values, which are less accurate than calibration values.

Table 3 Statistics of the float solution applying satellite products from CODE or WUM in the conventional model (IF) or the uncombined model with ionospheric constraint using two or three frequencies (UC2 and UC3, respectively)
Full size table

Figure 4 illustrates the TTCF’s distribution of the complete test case. Grey bars depict the percentage of already correctly fixed convergence periods (cumulative distribution function), and blue bars indicate the percentage of correct fixes happening at this point in time (probability distribution function). Consequently, the height of a specific grey bar equals the height of all blue bars previously or simultaneously in time. The majority of TTCFs takes place within the first minute of processing. The median TTCF (33 s) and mean TTCF (1.36 min) underline this fixing performance. Note that the percentage of cases without a correct fix within 15 min (2.61%) is considerably lower than the corresponding percentage of float convergence periods not reaching convergence (10.0%). The presented numbers underline the significant improvement in convergence behavior through ambiguity fixing, despite applying more strict convergence criteria. Furthermore, the fixed coordinates are more precise than the float coordinates after 15 min (2.81 cm versus 5.86 cm, median 3D position difference).

Fig. 4
figure 4

Distribution of the TTCF during the first 5 min. Grey: Cumulative distribution function (CDF). Blue: probability distribution function (PDF)

Full size image

During the float solution, raPPPid usually estimates the residual zenith wet delay. The total tropospheric delay (ZTD) can then be calculated with the modeled values and compared with the IGS final troposphere product. Figure 5 shows the resulting ZTD difference for station UNB3 (Fredericton, Canada, North America). The choice of satellite product and PPP model does not significantly affect the results, and raPPPid estimates the ZTD at the centimeter level or even below after a convergence time of a few minutes (e.g., five minutes).

Fig. 5
figure 5

95% quantile (upper lines) and 68% quantile (lower lines) of the ZTD difference for station UNB3. The black dotted line represents the 1 cm level

Full size image

The slant ionospheric delay is estimated for each satellite during the PPP solution using the uncombined model with ionospheric constraint and WUM products. The resulting values can be compared with values modeled using the final IGS GIM. Figure 6 shows the resulting histogram of the ionospheric delay differences for the stations MAYG (Dzaoudzi, Mayotte, Africa) and UNB3. The corresponding standard deviations are 0.97 and 0.52 m, respectively. The station MAYG is much closer to the earth equator and, therefore, within an ionospheric more active region, indicating a latitude dependency of the ionospheric delay differences. The corresponding bias is negligible and at the size of a few centimeters (− 6 cm and − 7 cm, respectively). Since the final IGS GIM usually has an accuracy of 2–8 TECU (Hernández-Pajares et al. 2009), corresponding to a delay error of 0.3–1.3 m on the L1 frequency, and because the presented standard deviations are at this level or below, it is not straightforward to assess the precision. We can expect that the slant ionospheric delay from the PPP solution achieves a higher accuracy than values modeled with a GIM.

Fig. 6
figure 6

Histogram of the ionospheric delays’ difference for the stations MAYG and UNB3

Full size image

Typically, ambiguity fixing significantly reduces the convergence time. The fixed coordinates can jump to their proper values as soon as enough ambiguities are correctly fixed due to calculating the fixed solution with a Least-Squares-Adjustment in raPPPid. However, they also have reached their final precision due to this approach. On the other hand, the float solution converges considerably slower but, thanks to the Kalman Filter, continues increasing the accuracy of the estimated parameters.

Figure 7 shows the horizontal position difference (top part) and ZTD difference (bottom part) for the station AREG using the conventional model and CODE MGEX products. For this example, a reset of the solution is performed only every three hours to investigate the long-term behavior of the float solution, leading to eight convergence periods. Please note that the y-axis of the shown 2D position difference and ZTD difference ranges only up to 5 and 3 cm, respectively. The horizontal position difference is around or below the one-centimeter level (black dashed line) after an extensive convergence period of about 30 min. The associated 3D position difference shows similar convergence behavior and is at the size of 1–2 cm. The corresponding ZTD difference with respect to the IGS troposphere product is at the millimeter level, underlined by the corresponding standard deviation of 0.57 cm and bias of 0.35 cm. This example shows that raPPPid can achieve a reasonably stable and precise performance of the long-term float solution on the edge of the physical limits of GNSS.

Fig. 7
figure 7

Long-term behavior of the 2D position difference (top) and the ZTD difference (bottom) for the station AREG (float solution, conventional model, CODE MGEX products, reset every 3 h). The black dashed line represents the one-centimeter level

Full size image

Smartphone data processing

Since the release of Android 7.0 in 2016, Android users have had access to the raw GNSS measurements of their smartphones (Zangenehnejad and Gao 2021). Therefore, it is possible to use self-developed positioning algorithms to calculate the smartphone position (Shinghal and Bisnath 2021; Wang et al. 2021; Suzuki 2023). However, smartphones are equipped with simple, cost-effective chips and antennas, typically providing low-quality single-frequency measurements and various challenges (Zhang et al. 2018; Liu et al. 2019; Wanninger and Heßelbarth 2020). Experience showed that the GNSS observations of different smartphone devices behave diversely and unpredictably.

Using thirty minutes of data from two customary smartphone devices (Huawei Nova 5 T and Samsung Galaxy S20FE) recorded on geodetic reference points, we want to demonstrate that raPPPid can smoothly handle such data without going into the details of raw GNSS data from smartphones. Usually, the phase observations of smartphones cannot be easily used in the processing because they behave unpredictably and are affected by cycle slips (e.g., duty cycling) and inconsistencies of the logger applications (Zangenehnejad et al. 2023) if accessible at all. In the presented tests, the recorded RINEX files do not include GLONASS data (Huawei Nova 5 T) or phase observations at all (Samsung Galaxy S20). Figure 8 shows the triple time-differenced phase observations of four consecutive epochs for a specific GPS, Galileo, and BeiDou satellite (Huawei Nova 5 T). Building the third time difference with high-rate observations typically eliminates nearly all effects and can be used, for example, for cycle slip detection. Clearly, the phase does not show the expected steady behavior, and regular jumps do not allow an estimation of a constant float ambiguity.

Fig. 8
figure 8

Triple time-differenced phase observations of the Huawei Nova 5 T for three exemplary satellites. The first minute of the investigated data is shown

Full size image

Table 4 shows raPPPid's processing options suitable for RINEX files recorded with a smartphone application like the Geo++ RINEX Logger. Adapting these settings to a specific smartphone device might improve the results. Generally, weighting the observations based on the SNR performs better than elevation weighting for smartphones, and a basic approach for SNR weighting is used accordingly. The predicted version of the GIOMO model (Magnet 2019) is used for ionospheric pseudo-observations with constant variance in all epochs, stabilizing the estimation of the ionospheric delay and the PPP solution. Furthermore, the complete tropospheric delay is corrected using GPT3 (Landskron and Böhm 2018a, b). Note that due to the applied CNES real-time correction stream data and the selected atmosphere models, the processing framework is capable of real-time.

Table 4 Overview of used smartphone data and processing settings
Full size table

Figure 9 shows the convergence behavior of the horizontal position for the Galaxy S20 and Nova 5 T. VieVS PPP achieves a 2D position accuracy at the one-meter level or below for both devices after a convergence time of a few minutes. In the case of the Nova 5 T, raPPPid successfully processes single-frequency code observations from all four major GNSS (GPS C1C, GLONASS C1C, Galileo C5Q, and BeiDou C2I) plus GPS L5. On the other hand, solely GPS C1C was processed for the Galaxy S20 because including additional GNSS into the PPP solution introduced a considerable bias in the coordinate estimation (at the several-meter level). The logged observations seem to be influenced by an effect the observation model currently does not cover in multi-GNSS processing.

Fig. 9
figure 9

Convergence behavior of the horizontal position difference for the Samsung Galaxy S20 (red) and Huawei Nova 5 T (green). The black dashed line represents the one-meter level

Full size image

Figure 10 shows the long-term behavior of the smartphone’s topocentric coordinate differences over the entire 30 min for the Galaxy S20 (no resets, ZWD estimated). A stable position at the sub-meter is achieved after convergence, underlined by the RMS values provided in the caption of Fig. 10. The convergence period was excluded from calculating these RMS values (14 min for the height and 3 min for the north and east components). These results achieved with smartphone data collected under static and favorable conditions (e.g., open sky) demonstrate that raPPPid can handle low-cost data from smartphones.

Fig. 10
figure 10

Height, north, and east coordinate difference over 30 min for the Samsung Galaxy S20. After convergence, the corresponding RMS values are 0.25, 0.30, and 0.24 m, respectively

Full size image

Summary

We have introduced a user-friendly MATLAB PPP software package named raPPPid (also known as VieVS PPP, available under https://github.com/TUW-VieVS/raPPPid). The corresponding wiki (https://vievswiki.geo.tuwien.ac.at/en/raPPPid) provides details on the GUI, models, and processing settings. VieVS PPP regularly achieves coordinate convergence times of around 1 min or below with high-quality and high-rate observations by utilizing integer ambiguity fixing. The float solution usually converges within 6–7 min to centimeter-level accuracy. Furthermore, VieVS PPP estimates the ZTD at the centimeter level or below and provides an accurate ionospheric delay estimation in the uncombined model case. Beyond that, the float solution shows a highly stable and precise long-term behavior with up to millimeter accuracy.

Besides high-quality data, raPPPid can handle GNSS observation data from low-cost and smartphone devices. A 2D position accuracy at the meter level or below is achieved with smartphone data after two to three minutes under good conditions. Due to the variable characteristic of GNSS measurements from smartphones, more adaptions and refinements of the observation model are subject to further studies.

Future software developments will focus on improved kinematic data processing, including the Doppler shift into the Kalman Filter and the currently experimental fixing approach in the uncombined model. Extensive tests of raPPPid are still carried out to identify and correct remaining bugs in the software and to improve the robustness of the resulting PPP solutions.

Additional information

Software support is provided via rapppid@geo.tuwien.ac.at.