Breaking the One-Meter Accuracy Level with Smartphone GNSS Data †

: Smartphones are usually equipped with simple, cost-effective GNSS chips and antennas. They provide mainly single-frequency, low-quality, and challenging GNSS measurements. We demonstrate the difﬁculties of processing raw GNSS data from Android devices and introduce solutions to break the one-meter accuracy level with smartphones and Precise Point Positioning. With the logged data of a Samsung Galaxy S23+ and a Google Pixel 7 smartphone, a horizontal position accuracy of around one meter and a few decimeters was accomplished, respectively. These results were achieved after about two minutes of convergence time with our open-source software raPPPid in quasi-real-time settings. Furthermore, the corrections provided by the Galileo High-Accuracy Service proved to be sufﬁcient to achieve sub-meter accuracy with smartphones.


Introduction
Before Android 7.0 was officially released in 2016, it was only possible to read out the position solution of a smartphone's internal algorithm [1,2].Nowadays, everyone can access raw GNSS measurements tracked by Android smartphones and directly use the smartphone's GNSS observations to estimate the user's position [3][4][5].Therefore, developing specialized algorithms and applying correction data can enhance positioning performance.However, smartphones are typically equipped with simple, cost-effective chips and antennas and, consequently, provide low-quality, single-frequency measurements with various challenges [6][7][8].Altogether, experience has shown that the GNSS measurements of different smartphone devices behave diversely and unpredictably.To successfully process raw GNSS measurements from smartphones, we must study and understand their characteristics and differences from data recorded with geodetic equipment.
Precise Point Positioning (PPP) is characterized by applying precise satellite products (e.g., satellite orbits, clocks, and biases) and complex models to estimate the user's position [9].PPP is a well-established processing technique for multi-frequency GNSS data from geodetic receivers and allows reaching accuracies at the centimeter level, or even below, after a notable convergence period [10].Reducing or eliminating this convergence period is a major topic in scientific research.Usually, high-quality GNSS observations on two frequencies are used for PPP to build the ionosphere-free linear combination (IF LC), and researchers have found ways to integer fix the phase ambiguities [11,12].Several adjustments of the PPP technique are necessary to process the challenging GNSS measurements from smartphones in an adapted PPP mode [13,14].The approaches presented in the following are implemented in our open-source PPP software raPPPid [15,16], available at https://github.com/TUW-VieVS/raPPPid(accessed on 24 November 2023).Additionally, the raPPPid wiki (https://vievswiki.geo.tuwien.ac.at/en/raPPPid (accessed on 24 November 2023) provides documentation and processing examples (e.g., with smartphone GNSS data).
The following section introduces the difficulties presented by using raw GNSS data from smartphones and an adapted PPP approach.Afterwards, Section 3 presents processing examples and Section 4 discusses the results.The final section provides a summary and outlook.

Challenges
Android devices significantly differ in their capabilities regarding raw GNSS measurements [17,18].Considerable differences exist between smartphone devices of the same model, for example, sold in different regions.Access to the raw GNSS measurements might be limited (e.g., phase measurement) even on the most recent smartphone models [19].Furthermore, a specific smartphone might not provide dual-frequency (DF) measurements due to, most likely, software restrictions, although it has a DF chip installed.Apart from that, DF capability means that the smartphone tracks signals on the L1 and L5 bands, and this frequency is currently not covered by all GNSS satellites (e.g., GPS modernization).
Naturally, Android repeatedly powers the GNSS hardware on and off to save battery energy, called duty-cycling [1].This behavior causes non-continuous signal tracking and, for example, destroys the constant property of the phase ambiguity.Since Android 9, the user can force full GNSS measurements to deactivate duty-cycling and track all GNSS and frequencies in the developer settings [20].On Android 12 or higher, this key configuration for precise positioning is available as an in-app setting.Figure 1 shows the triple-timedifferenced GPS C1C code measurements of four consecutive epochs of a Samsung Galaxy S20 FE without deactivating duty-cycling.Building the triple-time difference with GNSS measurements recorded at a one-second observation interval typically nearly eliminates all effects, and the residuals represent the measurement noise.Consequently, the resulting code and phase residuals of geodetic GNSS equipment are usually the size of a few decimeters and a few millimeters, respectively.In Figure 1, the code residuals are significantly larger, and discontinuities occur due to non-deactivated duty cycling around epochs 82 and 116.These jumps also appear for other GNSS (same epochs, different magnitude) and complicate the processing of multiple GNSS in the PPP solution.However, they disappear when deactivating duty-cycling.
The following section introduces the difficulties presented by using raw GNSS dat from smartphones and an adapted PPP approach.Afterwards, Section 3 presents pro cessing examples and Section 4 discusses the results.The final section provides a sum mary and outlook.

Challenges
Android devices significantly differ in their capabilities regarding raw GNSS meas urements [17,18].Considerable differences exist between smartphone devices of the sam model, for example, sold in different regions.Access to the raw GNSS measurement might be limited (e.g., phase measurement) even on the most recent smartphone model [19].Furthermore, a specific smartphone might not provide dual-frequency (DF) meas urements due to, most likely, software restrictions, although it has a DF chip installed Apart from that, DF capability means that the smartphone tracks signals on the L1 and L bands, and this frequency is currently not covered by all GNSS satellites (e.g., GPS mod ernization).
Naturally, Android repeatedly powers the GNSS hardware on and off to save batter energy, called duty-cycling [1].This behavior causes non-continuous signal tracking and for example, destroys the constant property of the phase ambiguity.Since Android 9, th user can force full GNSS measurements to deactivate duty-cycling and track all GNSS and frequencies in the developer settings [20].On Android 12 or higher, this key configuratio for precise positioning is available as an in-app setting.Figure 1 shows the triple-time differenced GPS C1C code measurements of four consecutive epochs of a Samsung Galax S20 FE without deactivating duty-cycling.Building the triple-time difference with GNS measurements recorded at a one-second observation interval typically nearly eliminate all effects, and the residuals represent the measurement noise.Consequently, the resultin code and phase residuals of geodetic GNSS equipment are usually the size of a few deci meters and a few millimeters, respectively.In Figure 1, the code residuals are significantl larger, and discontinuities occur due to non-deactivated duty cycling around epochs 8 and 116.These jumps also appear for other GNSS (same epochs, different magnitude) and complicate the processing of multiple GNSS in the PPP solution.However, they disappea when deactivating duty-cycling.The IF LC is commonly used for PPP, requiring observations on two frequencies t eliminate the ionospheric delay from the observation model.However, smartphones typ ically only provide single-frequency observations or a limited number of DF observations Therefore, the uncombined PPP model with ionospheric constraint was chosen to connec the measurements and unknown parameters.This flexible PPP approach effectively han dles the variable nature of smartphone GNSS observations by managing any number o The IF LC is commonly used for PPP, requiring observations on two frequencies to eliminate the ionospheric delay from the observation model.However, smartphones typically only provide single-frequency observations or a limited number of DF observations.Therefore, the uncombined PPP model with ionospheric constraint was chosen to connect the measurements and unknown parameters.This flexible PPP approach effectively handles the variable nature of smartphone GNSS observations by managing any number of frequencies, maintaining the raw observation noise, and including ionospheric pseudo-observations.For example, the uncombined model can consider different numbers of frequencies for each satellite since missing observations are easily excluded from the parameter estimation process.
In the case of a single-frequency smartphone, Equations ( 1) and ( 2) present the observation equations of the uncombined model for the code observation C and the phase observation L, respectively.The geometric distance between the satellite and the smartphone is denoted as ρ and includes the unknown user position.The GPS receiver clock error dt r and receiver clock offset δt g for GNSS g are multiplied by the speed of light c.Furthermore, dTrop wet denotes the wet part of the tropospheric delay, and dIono 1 corresponds to the ionospheric delay.Equation ( 2) includes the float ambiguity N, which absorbs satellite and receiver phase biases and is multiplied by the corresponding wavelength λ.For readability reasons, these observation equations do not have an index to differentiate between GNSS or discriminate the term ε, containing noise and other errors.These observation Equations ( 1) and ( 2) comprise the unknown parameters, estimated with a Kalman filter in the PPP solution.Other error sources are modeled, like solid Earth tides, relativistic effects, and satellite phase center offsets.
In the case of a DF smartphone, Equations ( 3) and ( 4) are added to the parameter estimation for the corresponding satellites.DCB 12 denotes the smartphone's differential code bias between the first and second processed frequency (e.g., GPS L1 and L5).The squared ratio of the signal frequencies f 1 2 /f 2 2 converts the ionospheric delay to the first frequency.
Furthermore, the uncombined model can integrate ionosphere models into the parameter estimation by adding the modeled ionospheric delays to the first frequency as pseudo-observations for each satellite (dIono pseudo, Equation ( 5)).In this way, the inevitable imperfections of the ionosphere model can be adequately considered.Therefore, this socalled ionospheric constraint adds valuable information to the PPP solution, strengthens parameter estimation, and shortens the convergence time.
The phase measurements of smartphones are usually affected by ambiguity jumps and cycle slips.Detecting all these events is essential for PPP but complex, especially in single-frequency data, and not always feasible.Moreover, smartphones often do not provide access to the phase measurement.In such cases, a code-only solution has to be calculated by omitting Equations ( 2) and ( 4).Even such a code-only PPP approach allows a horizontal position accuracy around the one-meter level, as shown in the results section.However, by deactivating duty-cycling and considering the inconsistencies of some logger applications [21], the phase measurements of state-of-the-art smartphones can significantly contribute to breaking the one-meter accuracy level.Thereby, reliable cycle-slip detection is crucial, and the following approach based on Doppler observations proved to be effective.
The phase observation of the previous epoch L old is used with the Doppler observations of the previous and current epoch (D old and D now , respectively) to predict the phase observation of the current epoch L now .For this method, the observation interval dt has to be sufficiently small, which is usually the case for smartphone data (1 s).The predicted phase observation is compared with the actual phase measurement and a suitable threshold (e.g., 0.5 or 1 cycle).
The quality of GNSS observations from smartphones is generally worse than that of geodetic receivers.The carrier-to-noise density (C/N0) is typically around 10 dB.Hz lower and more variable (Figure 2).Furthermore, the code and phase observation noise is 10 to 100 times larger than for geodetic equipment (Figure 3).Anomalies like multipath or cycleslips are usually much more pronounced due to the incorporated ultra-low-cost equipment.Therefore, the PPP processing should use a cutoff angle higher than usual (e.g., 10 • ) and exclude observations below a certain C/N0 threshold (e.g., 20 dB.Hz).Furthermore, the software should carefully check the measurements to eliminate suspicious observations.For example, the triple-time-differenced code measurements and the difference between the code measurement and observation model can be compared with reasonable thresholds (e.g., 50 and 25 m, respectively).
Eng. Proc.2023, 54, 16 4 of be sufficiently small, which is usually the case for smartphone data (1 s).The predicted phase observation is compared with the actual phase measurement and a suitable thresh old (e.g., 0.5 or 1 cycle).The quality of GNSS observations from smartphones is generally worse than that o geodetic receivers.The carrier-to-noise density (C/N0) is typically around 10 dB.Hz lowe and more variable (Figure 2).Furthermore, the code and phase observation noise is 10 to 100 times larger than for geodetic equipment (Figure 3).Anomalies like multipath or cy cle-slips are usually much more pronounced due to the incorporated ultra-low-cost equip ment.Therefore, the PPP processing should use a cutoff angle higher than usual (e.g., 10° and exclude observations below a certain C/N0 threshold (e.g., 20 dB.Hz).Furthermore the software should carefully check the measurements to eliminate suspicious observa tions.For example, the triple-time-differenced code measurements and the difference be tween the code measurement and observation model can be compared with reasonabl thresholds (e.g., 50 and 25 m, respectively).Generally, the inaccurate weighting of the observations extends the convergence pe riod or introduces biases to the parameters estimated with PPP.An elevation-based weighting approach (e.g., sin 2 (e)) is typically used in PPP since the observations' residual are correlated with the elevation in the case of geodetic GNSS equipment.However, no such relation usually exists for smartphones, but it can be found between the observations residuals and the C/N0 (Figure 4).Therefore, weighting the smartphones' measurement based on the C/N0 usually significantly improves the performance and should be adjusted to the specific smartphone device.A simple CN/0 weighting function is used in the fol lowing (Table 1), leading to decent results in our experience.Eng.Proc.2023, 54, 16 be sufficiently small, which is usually the case for smartphone data (1 s).The pre phase observation is compared with the actual phase measurement and a suitable old (e.g., 0.5 or 1 cycle).
The quality of GNSS observations from smartphones is generally worse than geodetic receivers.The carrier-to-noise density (C/N0) is typically around 10 dB.Hz and more variable (Figure 2).Furthermore, the code and phase observation noise 100 times larger than for geodetic equipment (Figure 3).Anomalies like multipath cle-slips are usually much more pronounced due to the incorporated ultra-low-cost ment.Therefore, the PPP processing should use a cutoff angle higher than usual (e. and exclude observations below a certain C/N0 threshold (e.g., 20 dB.Hz).Furthe the software should carefully check the measurements to eliminate suspicious ob tions.For example, the triple-time-differenced code measurements and the differe tween the code measurement and observation model can be compared with reas thresholds (e.g., 50 and 25 m, respectively).Generally, the inaccurate weighting of the observations extends the convergen riod or introduces biases to the parameters estimated with PPP.An elevation weighting approach (e.g., sin 2 (e)) is typically used in PPP since the observations' re are correlated with the elevation in the case of geodetic GNSS equipment.Howe such relation usually exists for smartphones, but it can be found between the observ residuals and the C/N0 (Figure 4).Therefore, weighting the smartphones' measure based on the C/N0 usually significantly improves the performance and should be ad to the specific smartphone device.A simple CN/0 weighting function is used in t lowing (Table 1), leading to decent results in our experience.Generally, the inaccurate weighting of the observations extends the convergence period or introduces biases to the parameters estimated with PPP.An elevation-based weighting approach (e.g., sin 2 (e)) is typically used in PPP since the observations' residuals are correlated with the elevation in the case of geodetic GNSS equipment.However, no such relation usually exists for smartphones, but it can be found between the observations' residuals and the C/N0 (Figure 4).Therefore, weighting the smartphones' measurements based on the C/N0 usually significantly improves the performance and should be adjusted to the specific smartphone device.A simple CN/0 weighting function is used in the following (Table 1), leading to decent results in our experience., with a = 20 or 10 Ionosphere model GIOMO predicted [24] as ionospheric constraint, constant/released after 1 min Troposphere model GPT3 [25,26], ZWD not estimated/estimated Correction models Solid Earth tides, relativistic effects Satellite exclusion criteria C/N0 < 20 dB.Hz or elevation < 10° Data quality checks (thresholds) Observed minus computed (code: 25 m, phase 5 m), code triple-time difference (1 m), cycle-slip detection with Doppler (0.7 cy)

Results
This section presents position coordinate results obtained with two state-of-the-art smartphones (Google Pixel 7 and Samsung Galaxy S23+) and our open-source PPP software raPPPid [15,16].The smartphones were placed on geodetic reference points on the rooftop of TU Wien, ensuring suitable reference coordinates.Considering the imperfections introduced by various logger applications to the code and phase observations [21], the raw output of all sensors was logged with the Google GnssLogger application for 30 min on two different days.The GNSS measurements of the resulting text files were converted to the RINEX format using UofC CSV2RINEX, available at https://github.com/Far-zanehZangeneh/csv2rinex(accessed on 24 November 2023).
The PPP processing was performed in quasi-real-time (Table 1), applying real-time capable atmosphere models and satellite products (recorded real-time correction stream data from CNES [22] or the Galileo High-Accuracy Service (HAS) [23]).The PPP solution was reset every 6 min during the PPP processing.Such a reset corresponds to a restart of the PPP calculations, and the resulting ten convergence periods can be used to assess the convergence behavior and accuracy of the coordinates., with a = 20 or 10 Ionosphere model GIOMO predicted [24] as ionospheric constraint, constant/released after 1 min Troposphere model GPT3 [25,26]

Results
This section presents position coordinate results obtained with two state-of-the-art smartphones (Google Pixel 7 and Samsung Galaxy S23+) and our open-source PPP software raPPPid [15,16].The smartphones were placed on geodetic reference points on the rooftop of TU Wien, ensuring suitable reference coordinates.Considering the imperfections introduced by various logger applications to the code and phase observations [21], the raw output of all sensors was logged with the Google GnssLogger application for 30 min on two different days.The GNSS measurements of the resulting text files were converted to the RINEX format using UofC CSV2RINEX, available at https://github.com/FarzanehZangeneh/csv2rinex(accessed on 24 November 2023).
The PPP processing was performed in quasi-real-time (Table 1), applying real-time capable atmosphere models and satellite products (recorded real-time correction stream data from CNES [22] or the Galileo High-Accuracy Service (HAS) [23]).The PPP solution was reset every 6 min during the PPP processing.Such a reset corresponds to a restart of the PPP calculations, and the resulting ten convergence periods can be used to assess the convergence behavior and accuracy of the coordinates.
Generally, GPS, GLONASS, Galileo, and BeiDou (GREC) observations are processed for both devices.The variance of GLONASS and BeiDou observations is increased by a factor of 1.25 because their real-time satellite products are usually less accurate.Since the Galileo HAS provides real-time corrections for GPS and Galileo, a GPS and Galileo (GE) solution was calculated with these satellite orbits, clocks, and code biases.Unfortunately, the Samsung Galaxy S23+ does not provide access to the phase measurements.Therefore, a code-only solution is calculated for this device.On the other hand, code and phase measurements are processed in the case of the Google Pixel 7. Due to the different characteristics of code-only and code + phase PPP processing, some settings must be modified (listed twice in Table 1).For example, the ZWD is estimated only for the Google Pixel 7 because the phase observations substantially improve the accuracy of the solution.
Figure 5 shows the convergence behavior of the horizontal position error for the Samsung Galaxy S23+ and the Google Pixel 7, applying real-time corrections from CNES.Table 2 presents the corresponding statistics.Convergence is defined as the period until the horizontal position difference is below 1 m for the whole remaining period.The introduced PPP approach achieves a 2D position accuracy around the one-meter level after a convergence time of 2-4 min using only code observations from the Galaxy S23+.In the case of the Google Pixel 7, the 2D position accuracy is clearly below one meter, thanks to the phase observations, and the convergence time is typically 1-2 min.After 6 min, even the 3D position error is at the one-meter level for this device (Table 2).
Eng. Proc.2023, 54, 16 6 of 9 Generally, GPS, GLONASS, Galileo, and BeiDou (GREC) observations are processed for both devices.The variance of GLONASS and BeiDou observations is increased by a factor of 1.25 because their real-time satellite products are usually less accurate.Since the Galileo HAS provides real-time corrections for GPS and Galileo, a GPS and Galileo (GE) solution was calculated with these satellite orbits, clocks, and code biases.Unfortunately, the Samsung Galaxy S23+ does not provide access to the phase measurements.Therefore, a code-only solution is calculated for this device.On the other hand, code and phase measurements are processed in the case of the Google Pixel 7. Due to the different characteristics of code-only and code + phase PPP processing, some settings must be modified (listed twice in Table 1).For example, the ZWD is estimated only for the Google Pixel 7 because the phase observations substantially improve the accuracy of the solution.
Figure 5 shows the convergence behavior of the horizontal position error for the Samsung Galaxy S23+ and the Google Pixel 7, applying real-time corrections from CNES.Table 2 presents the corresponding statistics.Convergence is defined as the period until the horizontal position difference is below 1 m for the whole remaining period.The introduced PPP approach achieves a 2D position accuracy around the one-meter level after a convergence time of 2-4 min using only code observations from the Galaxy S23+.In the case of the Google Pixel 7, the 2D position accuracy is clearly below one meter, thanks to the phase observations, and the convergence time is typically 1-2 min.After 6 min, even the 3D position error is at the one-meter level for this device (Table 2).6 shows the convergence behavior using Galileo HAS corrections in a GPS and Galileo processing, and Table 3 presents the corresponding statistics.Naturally, these results based only on GPS and Galileo observations are worse than the GREC results (Table 2) due to significantly fewer satellites and observations.Furthermore, when comparing Table 2 with Table 4, the real-time clock corrections provided by the Galileo HAS seem slightly worse than the corresponding real-time corrections from CNES.Nevertheless, the Galileo HAS is sufficient to achieve sub-meter accuracy with smartphones.Furthermore, Figure 6 shows the convergence behavior using Galileo HAS corrections in a GPS and Galileo processing, and Table 3 presents the corresponding statistics.Naturally, these results based only on GPS and Galileo observations are worse than the GREC results (Table 2) due to significantly fewer satellites and observations.Furthermore, when comparing Table 2 with Table 4, the real-time clock corrections provided by the Galileo HAS seem slightly worse than the corresponding real-time corrections from CNES.Nevertheless, the Galileo HAS is sufficient to achieve sub-meter accuracy with smartphones.

Discussion
The presented results were accomplished under good conditions since the smartphones were statically placed on geodetic reference points, ensuring an open sky.Notably, they were achieved using quasi-real-time processing, and the smartphones could perform these PPP calculations directly.Therefore, sub-meter accuracy is possible with smartphones and PPP after a convergence time of 2-3 min, even when only GPS and Galileo observations are processed with corrections from the Galileo HAS.More complex modeling approaches, like a high-quality ionosphere model or more sophisticated observation weighting, might improve the results and are the subject of future investigations.Furthermore, smartphone phase center offsets are not considered due to a lack of calibrations, introducing an uncertainty of several centimeters.If possible, including smartphones' phase observations significantly improves the PPP performance.They proved the key to achieving a 2D position accuracy at the decimeter level.Unfortunately, not all Android devices currently provide access to phase measurements.Furthermore, several key issues must be considered to ensure consistency between the code and phase observations.

Summary
This article describes the key challenges of processing the GNSS measurements from Android smartphones and introduces solutions to achieve decimeter-level accuracy with PPP.The presented approaches are implemented in our open-source software raPPPid, available at https://github.com/TUW-VieVS/raPPPid(accessed on 24 November 2023).

Discussion
The presented results were accomplished under good conditions since the smartphones were statically placed on geodetic reference points, ensuring an open sky.Notably, they were achieved using quasi-real-time processing, and the smartphones could perform these PPP calculations directly.Therefore, sub-meter accuracy is possible with smartphones and PPP after a convergence time of 2-3 min, even when only GPS and Galileo observations are processed with corrections from the Galileo HAS.More complex modeling approaches, like a high-quality ionosphere model or more sophisticated observation weighting, might improve the results and are the subject of future investigations.Furthermore, smartphone phase center offsets are not considered due to a lack of calibrations, introducing an uncertainty of several centimeters.If possible, including smartphones' phase observations significantly improves the PPP performance.They proved the key to achieving a 2D position accuracy at the decimeter level.Unfortunately, not all Android devices currently provide access to phase measurements.Furthermore, several key issues must be considered to ensure consistency between the code and phase observations.

Summary
This article describes the key challenges of processing the GNSS measurements from Android smartphones and introduces solutions to achieve decimeter-level accuracy with PPP.The presented approaches are implemented in our open-source software raPPPid, available at https://github.com/TUW-VieVS/raPPPid(accessed on 24 November 2023).With the GNSS data from two state-of-the-art smartphones recorded under good conditions,

Figure 1 .
Figure 1.Triple-time-differenced code observations (GPS C1C, color-coded by satellite) for a Sam sung Galaxy S20 FE when duty-cycling is not deactivated.Discontinuities due to duty-cycling ar marked in dark ellipses.

Figure 1 .
Figure 1.Triple-time-differenced code observations (GPS C1C, color-coded by satellite) for a Samsung Galaxy S20 FE when duty-cycling is not deactivated.Discontinuities due to duty-cycling are marked in dark ellipses.

Figure 2 .
Figure 2. The carrier-to-noise density of three simultaneously observed GPS satellites tracked with a Trimble Spectra SP80 (thicker lines) and a Google Pixel 5 (thinner lines).

Figure 3 .
Figure 3. Triple-time differenced code (a) and phase (b) observations of a Google Pixel 7 (GPS C1C and L1C, color-coded by satellite).The corresponding standard deviations are 8.45 m and 12.9 cm.

Figure 2 .
Figure 2. The carrier-to-noise density of three simultaneously observed GPS satellites tracked with a Trimble Spectra SP80 (thicker lines) and a Google Pixel 5 (thinner lines).

Figure 2 .
Figure 2. The carrier-to-noise density of three simultaneously observed GPS satellites track a Trimble Spectra SP80 (thicker lines) and a Google Pixel 5 (thinner lines).

Figure 3 .
Figure 3. Triple-time differenced code (a) and phase (b) observations of a Google Pixel 7 (G and L1C, color-coded by satellite).The corresponding standard deviations are 8.45 m and 1

Figure 3 .
Figure 3. Triple-time differenced code (a) and phase (b) observations of a Google Pixel 7 (GPS C1C and L1C, color-coded by satellite).The corresponding standard deviations are 8.45 m and 12.9 cm.

Figure 4 .
Figure 4. Code residuals (color-coded by satellite) over carrier-to-noise density for a Samsung Galaxy S20 FE.

Figure 4 .
Figure 4. Code residuals (color-coded by satellite) over carrier-to-noise density for a Samsung Galaxy S20 FE.

Figure 5 .
Figure 5. Horizontal position difference applying real-time corrections from CNES in a GREC processing for (a) Samsung Galaxy S23+ and (b) Google Pixel 7.

Figure 5 .
Figure 5. Horizontal position difference applying real-time corrections from CNES in a GREC processing for (a) Samsung Galaxy S23+ and (b) Google Pixel 7.

Figure 6 .
Figure 6.Horizontal position difference applying corrections from the Galileo HAS in a GE processing for (a) Samsung Galaxy S23+ and (b) Google Pixel 7.

Figure 6 .
Figure 6.Horizontal position difference applying corrections from the Galileo HAS in a GE processing for (a) Samsung Galaxy S23+ and (b) Google Pixel 7.

Table 1 .
Quasi-real-time processing settings of raPPPid for processing raw GNSS measurements of smartphones.Options listed twice differentiate for the Galaxy S23+ and Pixel 7, respectively.

Table 1 .
Quasi-real-time processing settings of raPPPid for processing raw GNSS measurements of smartphones.Options listed twice differentiate for the Galaxy S23+ and Pixel 7, respectively.

Table 2 .
Accuracy and convergence time applying real-time corrections from CNES in a GREC processing.

Table 2 .
Accuracy and convergence time applying real-time corrections from CNES in a GREC processing.

Table 3 .
Accuracy and convergence time applying corrections from the Galileo HAS in a GE processing.

Table 4 .
Accuracy and convergence time applying real-time corrections from CNES in a GE processing.

Table 3 .
Accuracy and convergence time applying corrections from the Galileo HAS in a GE processing.

Table 4 .
Accuracy and convergence time applying real-time corrections from CNES in a GE processing.