# Cloud-Based Single-Frequency Snapshot RTK Positioning
## 2 Methodology
### Measurement Generation
#### 2.3.2 Carrier Phase Half Cycle Compensation  
As mentioned in Section 2.2, the in-phase and quadrature components of the CAFs are computed for a certain data bit hypothesis. It can be observed that when a series of data bits that are exactly opposite to the actual ones is used, the resulting CAF magnitude remains the same. If we replace \(H_{v}^{(u)}\) by \(-H_{v}^{(u)}\) in Equation (3), the same acquisition results of code delay and Doppler offset will be found; this indicates that there are two sets of solutions with different data bit hypotheses which will meet the requirement; this is why it is named as data bit ambiguity. This can also be explained by Equation (5), the output of an _arctan_ function is actually a series of values separated by multiples of \(\pi\). That is:  
\[\phi=\phi_{a}+k\cdot\pi,\quad k\in\mathbb{Z}. \tag{9}\]When \(k\) is an even number, the integer part forms whole phase cycles and this can be assimilated to the carrier phase integer ambiguities without influencing the IAR procedure in the RTK filter, leaving \(\hat{\phi}_{a}\) as the only valuable phase information from the acquisition. Similarly, when \(k\) is an odd number, it leaves the other phase candidate of the acquisition result: \(\hat{\phi}_{a}+\pi\), denoted by \(\hat{\phi}_{b}\). This compensated half cycle distance between \(\hat{\phi}_{a}\) and \(\hat{\phi}_{b}\) implies a possible phase measurement error of half a wavelength, approximately 10 cm for GPS L1 C/A signals. This error is large enough to totally prevent the SRTK engine from achieving IAR. As a result, it is critical for open loop architecture receivers to make the correct choice between \(\hat{\phi}_{a}\) and \(\hat{\phi}_{b}\). The data bit ambiguity issue only happens to some certain satellites at some certain epochs. This is because the actual data bits are unknown and we can only make a guess between the two hypotheses that are exactly opposite. If we can make a correct guess for all the satellites, then the resulting phase measurements will be valid and can be fed to the RTK filter for further processing. On the other way around, if all our guesses are wrong, it means all phase measurements are offset by half a cycle, and then the DD measurements will still be valid because the common offset will be cancelled out in the differencing process between satellites. The scenario that impedes the SRTK processing is when some guesses are correct while others are wrong. In closed loop receivers, the data bit ambiguity issue can be tackled by comparing the decoded bits with a priori known bit sequences appearing within the navigation message telemetry words, as described in [24]. However, this method will not work for snapshot positioning due to the limitation of the signal duration. Fortunately, there are organizations distributing these data bit information as a service, for example the German Research Centre for Geosciences (GFZ) [22]. Once we know the exact transmission time of the signal, we can find the corresponding data bits and compare them with the bits referred by the result hypothesis. If these bits are exactly opposite, then \(\hat{\phi}_{b}\) should be chosen as the right carrier phase, otherwise \(\hat{\phi}_{a}\) should be used. As for how to obtain an exact transmission time, the next subsection provides more details. Besides using external data sources, it must be pointed out that, for some GNSS signals with known secondary codes, the data bit ambiguity issue disappears when a longer integration time is used. As an example, Galileo E1C signal is free from such issues when the integration time used in acquisition is longer than 24 ms, equivalent to 6 primary code periods. This is because the secondary code pattern of Galileo E1C signal is known a priori; there is a maximum of 25 possible hypotheses for the received signals, with each hypothesis containing a data bit sequence of \(ceil(T_{i}/0.004)+1\) digits, where \(T_{i}\) denotes the integration time.