# An Approach to Speed up Single-Frequency PPP Convergence with Quad-Constellation GNSS and GIM
## 2 Approach of Single-Frequency PPP with Quad-Constellation GNSS and GIM  
The code and carrier-phase observations on a single frequency can be expressed as:  
\[P^{g}=\rho^{g}+cdT-cdt^{g}+d^{g}_{orb}+d^{g}_{trop}~{}+d^{g}_{ion}~{}+b^{g}+ \varepsilon^{g}_{P} \tag{1}\]  
\[\Phi^{g}=\rho^{g}+cdT-cdt^{g}+d^{g}_{orb}+d^{g}_{trop}~{}-d^{g}_{ion}~{}+~{}B^{ g}+\epsilon^{g}_{\Phi} \tag{2}\]  
where the superscript \(g\) represents a GPS satellite, \(P\) is the measured pseudorange in meters, \(\Phi\) is the measured carrier phase in meters, \(\rho\) is the geometric range in meters, \(c\) is the speed of light in meters per second, \(dT\) is the receiver clock offset in seconds, \(dt\) is the satellite clock offset in seconds, \(d_{orb}\) is the satellite orbit error in meters, \(d_{trop}\) is the tropospheric delay in meters, \(d_{ion}\) is the ionospheric delay in meters, \(B\) is a bias term in meters, including the phase ambiguity and the phase hardware delay bias, \(b\) is the code hardware delay bias at satellite and receiver ends in meters, and \(\epsilon_{\Phi}\) and \(\epsilon_{\Phi}\) are the code and phase observation noises including multipath errors in meters, respectively. In the PPP parameter estimation, the code hardware delay at the receiver end will be absorbed by the receiver clock offset and, thus, only the code hardware delay bias at the satellite end needs to be considered. Since the precise satellite clock corrections to be used contain the ionosphere-free linear combinations of the satellite code hardware delays on two frequencies, single-frequency users must apply the satellite DCB to obtain the proper code hardware delay on the chosen frequency [18]. Since GPS, GLONASS, BeiDou, and Galileo systems have their respective time systems, a receiver clock parameter with respect to their own time scale should be introduced for each constellation although there is a unique physical receiver clock for the positioning model [17]. Alternatively, the system time difference parameters with respect to a reference time scale may be introduced [3]. If the GPS time scale is chosen as a reference, the GLONASS, BDS, and Galileo observation models can be depicted by:  
\[P^{j}=\rho^{j}+cdT+cdT^{j,g}_{sys}-cdt^{j}+d^{j}_{orb}+d^{j}_{trop}\ +d^{j}_{ ion}+b^{j}+\epsilon^{j}_{p} \tag{3}\]  
\[\Phi^{j}=\rho^{j}+cdT+cdT^{j,g}_{sys}-cdt^{j}+d^{j}_{orb}+d^{j}_{trop}\ -d^{j}_{ ion}+B^{j}+\epsilon^{j}_{\Phi} \tag{4}\]  
where \(j\) represents GLONASS, BeiDou, and Galileo satellites, \(dT_{sys}\) is the system time difference with respect to the GPS time scale. In Equations (1)-(4), the ionospheric delay and the code hardware delay are lumped together and thus they can be estimated as a single unknown parameter, namely \(d_{\rm{HID}}=d_{\rm{ion}}+b\). If there is no restriction to be imposed on the unknown parameter, the uncombined single-frequency PPP model is practically equal to the GRAPHIC ionosphere-free model. In order to reduce the PPP convergence time, the ionospheric delay and code hardware delay derived from the GIM product and multi-GNSS DCB product are applied as pseudo-observables to constrain the \(d_{\rm{HID}}\) parameter, as seen below. \[I_{slant}+b_{hd}=d_{IHD} \tag{5}\]  
\[I_{slant}=40.28\times\frac{m\cdot VTEC_{GIM}}{f^{2}} \tag{6}\]  
\[m=\left[1-\frac{\sin^{2}z}{(1+{{I_{ion}}}/{R})^{2}}\right]^{-1/2} \tag{7}\]  
\[b_{hd}=\frac{{{f_{2}}^{2}}}{{{f_{1}}^{2}-{f_{2}}^{2}}}DCB_{{{P_{1}}}{{P_{2}}}} \tag{8}\]  
where \(I_{slant}\) is the pseudo-observable of the ionospheric delay, which can be derived by Equation (6). \(b_{hd}\) is the pseudo-observable of the code hardware delay, which can be acquired through DCB by Equation (8) [18]. In Equation (6), \(m\) is the ionospheric mapping function as expressed in Equation (7), \(f\) is the carrier frequency, \(VTEC_{\rm{GIM}}\) is the interpolated total electron content (TEC) value along the zenith direction from the TEC map data [20].