# Relative Positioning in Remote Areas Using a GNSS Dual Frequency Smartphone
## 2 Materials and Methods
### Processing Options  
It is known that the GNSS signals are affected by atmospheric delays, ionosphere, and troposphere, that can be minimized or even eliminated, through the application of relative positioning techniques in the case of short baselines, because the receivers are subject to similar effects. With the increase of the baseline distance, the accuracy in the differential solutions decreases basically by 1 ppm \(\times\) distance. In our case, positioning with the VIGO station, at 121 km, can increase the error by 12 cm, while with CASC and CEUT stations, respectively at 277 and 645 km, may have errors in the order of 28 cm and 65 cm, respectively. \begin{table}
\begin{tabular}{p{42.7 pt} p{42.7 pt} p{42.7 pt} p{42.7 pt} p{42.7 pt} p{42.7 pt}} \hline \hline
**CORS** & \begin{tabular}{c} **Baseline** \\ **Length** \\ **(km)** \\ \end{tabular} & **Receiver** & **Antenna** & \begin{tabular}{c} **GNSS** \\ **Systems** \\ \end{tabular} & **Network** & **Location** \\ \hline GAIA & 0.2 & \begin{tabular}{c} Trimble \\ Alloy \\ \end{tabular} & Trimble GNSS-Ti Choke Ring v2 & \begin{tabular}{c} Galileo, GPS \\ GLONASS \\ \end{tabular} & RENEP & \begin{tabular}{c} Gaia \\ Portugal \\ \end{tabular} \\ \hline VIGO & 121.1 & Trimble NETR9 & Trimble L1/L2 Dorne Margoli Choke Ring & \begin{tabular}{c} Galileo, GPS \\ GLONASS, \\ BeiDou \\ \end{tabular} & ERGNSS & \begin{tabular}{c} Vigo \\ Spain \\ \end{tabular} \\ \hline CASC & 277.2 & Trimble Alloy & Trimble GNSS-Ti Choke Ring v2 & \begin{tabular}{c} Galileo, GPS \\ GLONASS \\ \end{tabular} & RENEP & \begin{tabular}{c} Cascais \\ Portugal \\ \end{tabular} \\ \hline CEUT & 645.5 & Trimble NETR9 & Trimble L1/L2 Dorne Margoli Choke Ring & \
\begin{tabular}{c} Galileo, GPS \\ GLONASS, \\ BeiDou \\ \end{tabular} & ERGNSS &
\begin{tabular}{c} Cetta \\ Spain \\ \end{tabular} \\ \hline \hline \end{tabular}
\end{table} 
Table 1: CORS from the EUREF used in the surveys. Processing dual frequency raw observations, using the new signals E5a and L5, from Galileo and GPS, can improve ambiguity resolution for long baselines (ESA (2018) [16]) and reduce the survey time when compared with the use of single frequency observations. In our processing, we used the Double-Difference (DD) model. The planning of the observations was done using the GNSS Planning online tool from Trimble [17], in order to choose the best Galileo constellation periods. The smartphones used can provide dual frequency E1/L1 and E5a/L5 measurements from Galileo and GPS signals, and single frequency G1/C1 from GLONASS and BeiDou signals. As our objective was to perform relative positioning with dual frequency measurements using distant reference stations (long baselines), only Galileo and GPS signals were considered in the solution processing. A Septentrio PolaRx5 geodetic receiver, with a PolaNt-MF antenna, was also used as a rover for the comparison of signals and solutions obtained. For the objectives of this work, during 2021, three tests were performed. To collect the smartphone's GNSS observations at a rate of 1 Hz, the Geo++ RINEX Logger [18] was used, which can generate RINEX (Receiver Independent Exchange Format) files, version 3.03. Due to the fact that the Galileo constellation is still incomplete, and that the GPS constellation has only half of the satellites with the L5 signal, the best approach to have a higher number of satellites with dual frequency signals is the combination of these two systems, which provides also a better PDOP (Position Dilution of Precision). The 1 Hz raw data from the PolaRx5 was collected in SBF file format, which was converted to RINEX 3.04 files using Septentrio RxTools' SBF Converter [19]. For the processing and analysis of the data the RTKLIB Demo5 software [20], based on the RTKLib [21] software, was used. The analysis of SNR (Signal-to-Noise Ratio), satellite visibility, and geometry was performed using RTKPLOT tools, while Galileo and GPS solutions in a differential mode were computed with RTKPOST.