Preliminary Results on Tropospheric ZTD Estimation by Smartphone

Abstract

The Global Navigation Satellite System (GNSS) receiver is one of the many sensors embedded in smartphones. The early versions of the Android operating system could only access limited information from the GNSS, allowing the related Application Program Interface (API) to obtain only the location. With the development of the Android 7.0 (Nougat) operating system in May 2016, raw measurements from the internal GNSS sensor installed in the smartphone could be accessed. This work aims to show an initial analysis regarding the feasibility of Zenith Total Delay (ZTD) estimation by GNSS measurements extracted from smartphones, evaluating the accuracy of estimation to open a new window on troposphere local monitoring. Two different test sites have been considered, and two different types of software for data processing have been used. ZTDs have been estimated from both a dual-frequency and a multi-constellation receiver embedded in the smartphone, and from a GNSS Continuously Operating Reference Station (CORS). The results have shown interesting performances in terms of ZTD estimation from the smartphone in respect of the estimations obtained with a geodetic receiver.

1. Introduction

The applications exploiting Global Navigation Satellite System (GNSS) positioning have increased in recent years [1,2]. The first GNSS-derived Zenith Total Delay (ZTD) estimates were carried out for scientific purposes using a post-processing strategy; the influence of ZTD was then considered in real-time applications to guarantee high-quality positioning, and it is now tackled in a Precise Point Positioning (PPP) strategy [3,4].

The development of networks of Continuously Operating Reference Stations (CORSs) for Network Real-Time Kinematic (NRTK) positioning and the increasing diffusion of PPP strategies allow one to obtain a centimetric accuracy in a much shorter time with respect to relative post-processing. The first methodology (NRTK) has been investigated and considered for many purposes, where precision farming [5], autonomous navigation, maritime survey [6], and meteorological monitoring [7,8,9,10,11] are only a few examples. This positioning technique has allowed the attainment of impressive accuracy, even for single-frequency GNSS receivers [12], and it has permitted the increased performance of the low-cost ones [13,14,15,16] since the implementation of studies into the potentialities of the GNSS system embedded in the smartphones [17]. Thus, the spread of low-cost technologies such as smartphones and tablets, with their rapid evolution in terms of the quality of their installed sensors, has increased the interest in these systems and the management of emergency scenarios. One primary advantages of using portable devices, such as those previously cited, is the possibility of completing a rapid survey and exploiting their embedded sensors, which results in them being useful for multidisciplinary teams cooperating in a coordinated manner on a common task, e.g., reconnaissance, inspection, and the survey of unstable structures.

Starting in 2016, with the Android Nougat 7.0 Operating System (OS) development, Google has permitted direct access to the GNSS chipset raw measurements mounted on some Android-based smartphones. The possibility to manage pseudo-range and carrier-phase measurements from the GNSS chipset installed on smartphones and tablets with an Android OS has changed the concept of precise positioning with portable devices. Several studies have been conducted to verify the feasibility [18] and positioning accuracy [19,20] of smartphones for different purposes, from urban [21,22,23,24,25] to pedestrian positioning applications [26,27], always facing the problems related to the high-level Application Programming Interface (API) and the filtered measurements provided by the GNSS chipset.

In [28], the authors demonstrated that it is possible to reach a decimeter level of accuracy in terms of positioning performances following the post-processing approach, made by double differencing raw smartphone observations. Meanwhile, the authors of [29] first focused their attention on single-base RTK positioning and then demonstrated the possibility of obtaining a centimeter-level accuracy through the use of NRTK corrections [30].

Recently, attention has been moved to PPP for obtaining the absolute position of a single receiver without the use of corrections or base stations [31]. However, to the best of our knowledge, nobody has focused their attention on the derivate products of GNSS positioning, such as the estimation of ionospheric or tropospheric delays.

Recently, ZTD has been estimated using the PPP strategy [32,33], but it was initially estimated within the GNSS station network adjustment to allow it to extend the local estimates to the entire area covered by the network through interpolation.

In this context, this paper aims to investigate the possibility of retrieving ZTD estimates from smartphones and to evaluate their accuracy. To evaluate their quality, ZTD values obtained from smartphones have been compared to those estimated with a geodetic GNSS receiver settled a few meters away from the smartphone. Two different types of software (one online, the CSRS-PPP [34], and one open-source, RTKLIB 2.4.3 b33 [35]) and two different test sites have been considered to make the analyses as general as possible. The positioning solutions have been computed to verify that the improvements in the ZTD estimations do not negatively affect the coordinate estimations, because both have been estimated from the same observations.

The remainder of this paper is organized as follows. Section 2.1 describes the ZTD estimation from GNSS observations, while Section 2.2 presents the case studies. Section 3 highlights the results of ZTD estimations regarding both smartphones and geodetic receivers. Section 4 provides the discussion on the research outcomes, and Section 5 reports the conclusions and gives some ideas for future research activities and investigations.

2. Materials and Methods

2.1. ZTD Estimation from GNSS

It is widely understood that GNSS was initially designed to determine the position, expressed by cartesian coordinates (X, Y, Z) of a receiver by means of pseudo-range or carrier-phase measurements. Both these approaches are affected by biases, primarily produced by the Earth atmosphere, which increases the real distance between satellite and the receiver, and by instrumental (both receiver and satellites) and site-specific causes: receiver and satellites clock errors, multipath, etc.

The basic GNSS carrier-phase observable, in units of length, can be written as follows [36]:

$${\mathsf{\phi }}_{\mathrm{R}}^{\mathrm{S}}\left(\mathrm{t}\right)= {\mathsf{\rho }}_{\mathrm{R}}^{\mathrm{S}}\left(\mathrm{t}\right)+\mathrm{c} \cdot \left({\mathsf{\delta }}_{\mathrm{R}}\left(\mathrm{t}\right)-{\mathsf{\delta }}^{\mathrm{S}}\left(\mathrm{t}\right)\right)+ \lambda {\mathrm{N}}_{\mathrm{R}}^{\mathrm{S}}\left(\mathrm{t}\right)-{\mathrm{I}}_{\mathrm{R}}^{\mathrm{S}}\left(\mathrm{t}\right)+ {\mathrm{T}}_{\mathrm{R}}^{\mathrm{S}}\left(\mathrm{t}\right)+\mathrm{MP}\left(\mathrm{t}\right)+\mathsf{\epsilon }$$

(1)

where λ is the wavelength of the carrier-phase, ${\mathsf{\rho }}_{\mathrm{R}}^{\mathrm{S}}$ is the geometric satellite-receiver distance (obtained by the satellite and the receiver coordinates), c is the speed of light, δ_S and δ^R are the satellite and receiver clock errors, respectively, ${\mathrm{N}}_{\mathrm{R}}^{\mathrm{S}}$ is the unknown initial phase ambiguity, ${\mathrm{I}}_{\mathrm{R}}^{\mathrm{S}}$ is the ionospheric (slant) delay, ${\mathrm{T}}_{\mathrm{R}}^{\mathrm{S}}$ is the tropospheric (slant) delay, MP is the multipath effect, and ε contains all the remaining unmodelled errors.

Most of the terms in Equation (1) can be neglected by means of appropriate precautions during the installation of the instrumentation and expedients when the GNSS receiver is operative. For example, ${\mathsf{\rho }}_{\mathrm{R}}^{\mathrm{S}}$ estimation can be improved through accurately known satellite and receiver positions, δ_S and δ^R can be eliminated using the double differences strategy or can be modelled in PPP, ${\mathrm{N}}_{\mathrm{R}}^{\mathrm{S}}$ is resolved in the initialization phase, and ${\mathrm{I}}_{\mathrm{R}}^{\mathrm{S}}$ can be eliminated using the iono-free dual frequencies combination for double-frequency receivers, or it can be modelled for single-frequency receivers. The multipath effect MP can be mitigated by choosing an antenna position that is far from reflecting objects, installing special antennas (e.g., choke-ring antennas), masking low elevation signals, or by using techniques and models designed to recognize the reflected signals and discard them [37].

The presence of the atmosphere introduces effects on the signal crossing that influence the antenna positioning. At the same time, these effects may be a starting point to monitor the troposphere itself, representing a useful knowledge base for meteorological purposes. Since the early 1990s, GNSS has also been used for meteorological purposes [38] because of its high accuracy, all-weather operation capability, high temporal resolution, and compatibility with other observation systems, e.g., radiosondes, water vapor radiometers, and lately, environmental satellites. GNSS meteorology exploits the delay of electromagnetic GNSS signal transmission in the atmosphere due to water vapor, dry gases, hydrometeors, and other particulates [39,40]. As already stated, GNSS observations are affected by different sources of bias, one of which is caused by tropospheric refractions during the crossing of the atmosphere by the electromagnetic GNSS signal. The tropospheric effect is frequency-independent, and it cannot be reduced, but it produces a bias in each satellite-receiver observation that can be related to the so-called ZTD. The estimation of ZTD helps to enhance the positioning precision and represents a contribution to meteorological studies.

ZTD can be estimated by GNSS CORSs network adjustments to correct the computed delay, thus exploiting a tropospheric model that can be adopted in atmospheric conditions that are not standard. Several approaches have been carried out: the investigation of the vertical column of the atmosphere over a single station [41], the exploitation of existing national GNSS networks [42,43,44,45], and the implementation of specifically designed GNSS networks [46,47,48,49]. One element of innovation in this field was introduced by [8], who proposed to use existing regional, national, and international GNSS CORSs for the retrieval of ZTD, to be used in meteorological and climatological applications and studies.

2.2. Case Study: Materials, Methods and Processing

The Broadcom 47755 dual-frequency GNSS chip embedded in Xiaomi Mi8 smartphones was considered for these tests. It is capable of tracking GPS L1 C/A, GLONASS L1, BeiDou (BDS) B1, QZSS L1, Galileo (GAL) E1, GPS L5, Galileo E5a, and QZSS L5 signals. Regarding the geodetic receivers, two GNSS CORSs were considered to guarantee the highest quality in terms of collected signals and frequencies, as well as the number of tracked satellites.

Two different types of software have been employed and considered for this work: the CSRS-PPP and a modified version of RTKLIB 2.4.3 b33.

CSRS-PPP is an online application for GNSS data post-processing, allowing users to compute higher accuracy positions from their raw observation data. CSRS-PPP uses precise GNSS satellite orbit ephemerides to produce the corrected coordinates of a user located on a generic point, regardless of proximity to available base stations. The software can process RINEX observation data from single or dual-frequency receivers operating in static or kinematic mode. CSRS-PPP uses the best available ephemerides, and it allows the users to select final (+/−2 cm, combined weekly and available 13–15 days after the end of the week), rapid (+/−5 cm, available the next day), or ultra-rapid (+/−15 cm, available every 90 min) ones, as it is possible to see in the specific IGS website section [50]. With the new version, the software includes PPP with ambiguity resolution (PPP-AR) for data collected on or after 1 January 2018. The output of the processing is sent to the user in a compressed folder. In particular, a tropospheric zenith delay file (with .tro extension) is created, containing hydrostatic and wet zenith path delays and tropospheric gradients for each processed epoch. For all measurement campaigns considered in this research activity and all the employed receivers, the following parameters have been selected for the data processing, considering the CSRS-PPP software: a cut-off angle equal to 7.5°, the Vienna Mapping function as the a priori tropospheric model, and the a posteriori variance factor used to scale the covariance matrix equal to 1.

RTKLIB is an open-source software widely used by both the academic community and other interested parties. The version considered in this paper is based on an Extended Kalman Filter (EKF) employing Zero-Difference (ZD) measurement equations, such as single point positioning, but also considering the receiver and antenna Phase Center Variations (PCVs), to take into account the Phase Center Offset (PCO), defined as the relative position of the receiver antenna phase center with respect to the antenna reference point (ARP). In this research activity, the ANTEX format for the antenna model, including PCO and PCV data, has been considered and used. Even for the RTKLIB software, the cut-off angle was defined as 7.5°; by using the typical EKF formulation, the unknown parameters, including the receiver position and velocity, the receiver clock bias, the troposphere parameters and the ionosphere-free LC, and carrier-phase biases are estimated. For this work, the RTKLIB version, solid earth tides, Ocean Tide Loading (OTL), and pole tides are modelled and properly considered, the same as for the CSRS-PPP software. In both cases, precise ephemerides and clocks have been used considering MGEX products [51,52], as well as the PPP-AR algorithms as the ambiguity resolution method. To weight the observations, SNR values have been selected. For both types of software, the final solutions have been considered in the ITRF realization to be compliant with the GNSS processing products (e.g., ephemerides, ocean tide loading), considering a forward solution based on EKF.

Table 1. Processing parameters for RTKLIB and CSRS-PPP software for both case studies.

RINEX format	RINEX 3
Cut-off angle	7.5°
Ephemeris	Final (MGEX)
Clocks	Final (MGEX)
Ionosphere	Iono-free
OTL	Based on Chalmers grid solution
Ambiguity resolution	PPP-AR

summarizes the processing settings for both of the considered software. It is important to highlight the fact that the duty cycle was disabled for all the data collected in the two campaigns.

2.2.1. Case Study 1

The acquisition test was performed on 11 December 2018; the smartphone acquisition lasted just over one hour and a half, starting from 11:49 a.m. until 1:30 p.m. UTC. This case study’s chosen location was the rooftop of the Politecnico di Torino, where the TORI GNSS CORS, which belongs to the SPIN3 GNSS network, is installed. A few meters away from that location, a Xiaomi Mi 8 smartphone (referred to as TOSM for this case study) was placed. TORI, used as a reference, is a geodetic-level multi-frequency (L1, L2, and L5) and multi-constellations receiver. The GNSS receiver embedded in the Xiaomi Mi 8 (Broadcom BCM47755) can record multi-frequency (L1 and L5) and multi-constellations GNSS signals. The pseudo-ranges and carrier-phase measurements were collected via the GEO++ RINEX logger app (available on Google Play) and then processed using the previously described software.

2.2.2. Case Study 2

The acquisition test was performed on 25 June 2020, and lasted seven hours, starting from 7:40 a.m. until 2:40 p.m. UTC. The chosen location for this case study was the Genoa University rooftop, and the GNSS receivers involved were GENU, which belongs to the Regione Liguria GNSS CORSs network, and a Xiaomi Mi 8 (referred to as GESM for this case study) smartphone. GENU, used as a reference, is a geodetic-level multi-frequency (L1 and L2) and multi-constellations receiver. The smartphone used in this case study was the same model as the one used for Case study 1. The GEO++ RINEX logger app was also employed for the processing of this dataset.

Figure 1 shows the GNSS receiver layout used in this case study: the GENU CORS is on the left upper corner of the rooftop, while the smartphone is placed a few meters away.

3. Results

In this section, the main results obtained after the data processing phase are shown. Firstly, a comparison between the TORI GNSS station and TOSM (Xiaomi Mi8 smartphone close to TORI) is presented, to show the different ZTD estimations obtained considering both CSRS-PPP and RTKLIB software and these two receivers. Particular attention is paid to the positioning solutions, to not only verify the tropospheric estimation; knowing that the implemented algorithms are based on Kalman filter, this choice has been made to exclude the possibility that a good ZTD estimation produces the detriment of positioning solutions. For this reason, the Up component of the positioning solution has also been considered for investigating this aspect. Considering these stations, the performances obtained using the RTKLIB software are presented, again making the same consideration on the positioning solutions as well as on the ZTD. Moreover, considering only the TOSM station, the obtained results with the two types of software have been compared to highlight the differences in ZTD estimations and make a statistical analysis of these differences. Finally, a second case study has been investigated over a longer time span, considering again both CSRS-PPP and RTKLIB.

3.1. Case Study 1

The elaboration results carried out for Case study 1 are reported below, starting with the one obtained with CSRS-PPP. In the CSRS-PPP solution, after the initialization phase, lasting about 20–30 min, both the positioning solutions (Figure 2) and the ZTD estimations (Figure 3) become more stable, with a standard deviation of a few millimeters in this last case. As it is possible to see from Figure 2 and Figure 3, there is a lack of measurements of about 13 min at about 12:45 UTC, due to unexpected events. Despite that, after a second initialization phase, the solution converges quicker than the first one.

It is worth highlighting that, considering TOSM, CSRS-PPP is not able to estimate ZTD, but it provides the values coming from the Vienna Mapping Function (VMF) model due to the poor quality of the observation and noisy data collected and saved in the RINEX file, which contains long gaps. To check the behavior of different software, RTKLIB was considered on the same data.

As expected, RTKLIB highlights a poor quality of the solution, obtained from the smartphone observations (TOSM), for both Up positioning component and ZTD (Figure 4 and Figure 5, respectively). The residuals of the three positioning components of TORI and TOSM with respect to the corresponding reference positions, i.e., the convergence solution, are reported in Figure 6 and Figure 7, respectively.

Table 2. Statistical parameters for the position outputs for TORI and TOSM with respect to the corresponding reference positions.

		Average (m)	Standard Deviation (m)	Root Mean Square (m)
TORI	E-W	0.16	0.29	0.33
	N-S	−0.10	0.20	0.22
	U-D	−0.04	0.14	0.14
TOSM	E-W	−0.45	0.56	0.72
	N-S	0.30	0.34	0.45
	U-D	0.85	1.36	1.60

summarizes the statistics deriving from Figure 6 and Figure 7.

The solution instability in the initial time span (approximately the starting 20–30 min) is particularly evident in Figure 4. This corresponds to the solution needing time to converge. After this phase, the positioning solution becomes more stable, and it is coherent with those available in the literature. The average difference between TORI and TOSM is about 0.8 m in the vertical component, while the ZTD estimation is at the order of 0.2 m. In this case, RTKLIB is able to estimate ZTD, for both TORI and TOSM, without introducing the VMF model as CRSR-PPP did.

To analyze the differences of the ZTD estimations with the two types of considered software and to verify the independence of the software used, Figure 8 shows the comparison of tropospheric delay values obtained with the CSRS-PPP (in blue) and RTKLIB (in orange) software. Figure 9 shows the differences in ZTD values for the TOSM station, considering the CSRS-PPP and RTKLIB software.

Concerning the smartphone receiver, the two results are quite different; as already mentioned, if the online software is considered (CSRS-PPP), the solution is smoothed and stable over time because the software is not able to produce an estimation and it provides model-derived ZTD values, whereas considering the open-source one (RTKLIB), the solution is less stable, even if the values are quite reasonable. As shown in Figure 10, the differences between these two solutions vary from −0.04 m to 0.3 m, with a mean value of 0.2 m and a standard deviation of 0.1 m, as summarized in

Table 3. Statistical parameters considering the ZTD residuals on TOSM (CSRS-PPP vs. RTKLIB).

Receiver	Mean (m)	Standard Deviation (m)
TOSM	0.170	0.114
TORI	0.007	0.011

.

Considering the TORI GNSS station, the results are definitely better than in the previous case: again, CSRS-PPP software provides more stable and smoothed ZTD solutions if compared to the RTKLIB ones (Figure 11 and Figure 12), but the ZTD residuals are smaller than for TOSM because they are derived from an estimation process rather than from a model. The range of difference is from −0.01 m to 0.03 m, as seen from Figure 13, with a mean value of 0.007 m and a standard deviation of 0.01 m (Table 3).

For the comparison shown in Figure 13, it should be noted that solutions falling in the convergence time have been excluded. The considered time interval, therefore, is from 11:00 a.m. to 1:00 p.m. UTC. This improvement is undoubtedly due to the quality of raw measurements, which are better in the case of TORI than TOSM. Nevertheless, even using the smartphone, it is possible to reach feasible results and interesting values for ZTD using RTKLIB.

3.2. Case Study 2

As previously stated, for this case study, the analyses have been made considering the use of both CSRS-PPP and RTKLIB software for ZTD estimation. In this case, the two considered stations are GENU and GESM, the geodetic CORS and the smartphone, respectively. As highlighted in Figure 14, the behavior of the two types of software is analogous to what already emerged from the previous case study: CSRS-PPP produces modelled ZTD for GESM whereas it correctly estimates ZTD for GENU.

Similar to Case study 1, GENU and GESM data were processed also using RTKLIB. The ZTD estimations obtained with this elaboration are shown in Figure 15. The positioning outputs for this elaboration are shown in Figure 16, while Figure 17 highlights the differences between the estimated and reference coordinates for GENU and GESM estimated with RTKLIB.

Table 4. Statistical parameters for the positions output for GENU and GESM with respect to the corresponding reference positions.

		Average (m)	Standard Deviation (m)	Root Mean Square (m)
GENU	E-W	−0.03	0.02	0.03
	N-S	0.02	0.01	0.02
	U-D	−0.08	0.04	0.09
GESM	E-W	0.23	0.35	0.42
	N-S	0.07	0.23	0.24
	U-D	0.02	0.18	0.18

shows the statistics of the solution in Figure 17. For the two solutions, the statistics are computed in respect of the reference position, i.e., the convergence solution, and excluding the convergence time (i.e., from 8:15 UTC onwards). The residuals of the three positioning components of GENU and GESM with respect to the corresponding reference positions are reported in Figure 18 and Figure 19, respectively. Finally, Figure 20 shows the ZTD differences between GENU and GESM as computed with RTKLIB software

In order to check the coherence of the ZTD values with official products, the obtained values, both estimated and modelled, were compared with those evaluated from EUREF [53] for the GENO CORS [54], which is a few kilometers away from the considered test site. These results are shown in Figure 21, where it is possible to notice that the estimations made using CSRS-PPP are more consistent with the EUREF solutions than with the ones obtained with the modified version of RTKLIB, although this last one provides promising results.

The same comparison with official estimates has been performed considering GESM. Provided that the previous tests demonstrated the lack of performances of CSRS-PPP in estimating ZTD from smartphone data, only the comparison between the estimates computed with RTKLIB and EUREF is presented in Figure 22.

This demonstrates the software capability to process GNSS measurements extracted from portable devices in a good way, with differences in the order of 5 cm from three hours later than the convergence time (i.e., from about 12:00 UTC onward), and maximum differences in the order of 10 cm in the whole considered time span. This highlights the possibility to exploit raw GNSS measurements obtained from smartphones for ZTD estimations, at the same time guaranteeing the positioning accuracy. This aspect opens new frontiers, not only in positioning solutions with portable devices, but also for atmospheric monitoring.

4. Discussion

ZTD estimations were analyzed for two different case studies, considering two different applications: an online application (CSRS-PPP) and a free and open-source software (RTKLIB 2.4.3 b33), modified by the authors. Two different types of GNSS receiver were employed for each test site: a smartphone and a geodetic receiver. This latter was considered as a comparison to test and verify if the results obtained from the software could be regarded as reliable. Firstly, attention was focused on the Turin test site (TORI and TOSM GNSS stations); the differences of ZTD estimations were not negligible if the open-source software was considered, even for the TORI GNSS station. This behavior was even reflected in the coordinate estimations, reaching differences of about 1 m for each component after the initialization phase. It is important to highlight the fact that all analyses and comparisons were made after the convergence of the solution, which was reached in approximately 20 min. Considering the CSRS-PPP software, the performances were better than the previous case considering the positioning solutions, whereas nothing can be confirmed concerning the ZTD values because CSRS-PPP was not able to estimate ZTD and it provided ZTD values from the VMF model. Starting from these analyses, it seems that the processing software plays a crucial role not only in the positioning but also in the ZTD estimations. For this reason, another case study was selected, which also extended the duration of the measurement campaign, considering a time interval of about 7 h. Considering the CSRS-PPP software, also in the present case, the ZTD estimations for GESM (smartphone) were not estimated by the software due to the poor quality of observations collected in the RINEX file derived from the smartphone, whereas the software provided ZTD estimates for GENU (CORS). Considering the RTKLIB software, the performances were quite different; in this case, the maximum span between GENU and GESM ZTD estimates was about 15 cm (Figure 15), even excluding the convergence time. In order to better understand how the processing software impacts the solutions, a deep analysis was made, comparing the ZTD estimations obtained for GENU and GESM with RTKLIB (Figure 18), respectively. In Figure 21, a comparison between the ZTD values estimated by these two types of software and those computed by the EUREF service were made for GENU; from this, it was possible to notice that the estimations made using CSRS-PPP were more in accordance with the EUREF ones with respect to the estimates obtained with the modified version of the RTKLIB software. This does not mean the one software is better than the other, because it could be interesting to deeply understand which are the processing strategies for both types of software. If, for RTKLIB, it is possible to make changes in the processing parameters thanks to its open-source state, considering the online one (CSRS-PPP) only a few settings can be modified. Thus, it is not possible to deeply investigate the constraints applied. However, this research aims to verify if a ZTD estimation made using smartphone devices and free software is possible and feasible, and not to evaluate what is the best software in terms of performances. Our work was intended to show what can be obtained with these two free types of software and to test their performances dealing with smartphone data. In both cases, the differences were about 20 cm, even if, in the latter case, the trend was less stable than in the first one. Thus, even if the quality of the data collected and the characteristics of the receivers have great importance for the ZTD estimations, it has been demonstrated that the processing software plays a crucial role and can provide quite different results. Despite that, the ZTD estimations obtained from smartphones can be considered feasible and useful.

5. Conclusions

The spread of low-cost technologies such as smartphones and tablets, with their rapid evolution in terms of the quality of their installed sensors, has increased interest in these systems and their employment for positioning purposes. Of course, because they are not primarily developed for these applications, their performances are not comparable with those obtainable with geodetic receivers. However, starting from 2016 with the advent of the Android Nougat 7.0 OS, their use as positioning tools has been investigated, and attempts have been made to reach a sub-meter accuracy by exploiting different techniques. In this work, one of these devices was employed for the ZTD estimation, comparing the obtained values with those obtainable with geodetic receivers, commonly used for these applications. Two different types of software (one online and one open-source) and two different case studies have been considered to obtain solutions independently from the used processing software and the test site.

The obtained results are encouraging: the ZTD estimations obtained with the smartphone receiver are comparable with those obtained with the geodetic one, especially if RTKLIB is used. Indeed, the online tool (CSRS-PPP) incapable of producing ZTD estimates for smartphone-derived RINEX files, whereas it produces consistent ZTD estimates for geodetic GNSS CORSs, without losing the quality of the positioning solutions. The measurement campaigns considered in this work do not cover an entire day due to the smartphone battery capacity. In the future, we plan to find solutions to extend the session lengths to more than 24 h, mainly by exploiting an external power supply. It is quite challenging to perform measurement campaigns considering different consecutive days because we have not had the possibility to provide a power supply to the smartphones up to now. Furthermore, another improvement will be considering different smartphones to verify the results obtained with the model considered in this research activity. Because there are few GNSS receivers installed inside smartphones, we believe that interesting results could also be obtained with other devices, and our goal is to prove that in the future.

This study represents initial analysis regarding the capability of online software to positively process GNSS measurements extracted from portable devices, exploiting the PPP strategy. Moreover, it has also shown the possibility to exploit raw GNSS measurements obtained from smartphones for ZTD estimations. This aspect opens new frontiers, not only in the positioning solutions with portable devices, but also for the contribution that smartphones could provide for atmospheric monitoring; if used correctly, they could become an interesting and widespread tool that is useful for creating dense sensor networks, even ones that are deployable for atmospheric monitoring. This aspect will be investigated in the future, and it is one of the next steps that the authors want to pursue.