# Optimizing the Use of RTKLIB for Smartphone-Based GNSS Measurements
## 2 Strategies
### Code Changes to the RTKLIB Demo5  
In order to get high levels of performance from the RTKLIB PPK processing, changes were made to the demo5 b34e version of RTKLIB. The demo5 code is an open-source, publicly available fork from the RTKLIB 2.4.3 code, and it is maintained on GitHub [21]. It is focused on improving solution performance, reliability, and robustness, particularly for low-cost single and dual frequency receivers. It is kept closely synchronized to the 2.4.3 code version, and all updates from that code are generally ported into the demo5 code. The vast majority of the code is common between the two versions, but some of the more significant differences between them are in the ambiguity resolution algorithms, particularly in the approach to partial ambiguity resolution and the options for dealing with the GLONASS inter-channel biases. However, it should be noted that ambiguity resolution was disabled for this solution, so the differences between the two versions of code are less significant in this case. The changes made to the demo5 b34e code specifically for this experiment fell into one of two categories. The first and most important is the approach to cycle slip detection. The unmodified RTKLIB code has three methods for detecting cycle slips. The cycle slips can be flagged by the receiver, they can be detected as a Kalman filter error larger than a specified \"outlier\" threshold, or if dual frequency measurements are available, by using geometry-free linear combinations to detect phase jumps. Cycle slips in the smartphone observations are much more frequent than is typical from higher quality receivers. In addition, the reliability of the receiver cycle-slip flags appears to be much lower, both for false-positives and for false-negatives. In order to compensate for the large number of cycle slips and the low confidence in the receiver to accurately flag them, it was required to improve RTKLIB's ability to detect the cycle slips through other means. The method used in this solution leveraged changing the demo5 code to enable the ability to detect cycle slips using doppler measurements. By checking the difference between the doppler measurement and the change in carrier phase measurement, as carrier phase is essentially the accumulated doppler range, the cycle slips can be detected. This method is included in the open-source versions, but is commented out due to a clock jump issue. By making changes to the code that allow it to process all satellites at an epoch in one call as opposed to processing all of them individually, the common-mode effect of the clock jump can be minimized. If there is a jump in all satellite channels, this would be classified as a clock discontinuity, and if it is present in a subset of channels, it would be identified as a cycle slip. Other changes were made to reduce the number of observations that were unnecessarily discarded, allowing the solution to degrade more gracefully for poor data sets. An example of this was the adjustment of a check for valid observation data. For this check, instead of discarding any data that contained only pseudorange measurements, the code kept this incomplete data. Due to the fact that some of the Google data could be poor and often included incomplete measurement sets that lacked the carrier, changing this observation check was able to prevent good pseudorange data from being discarded. Additionally, another check in the code that sought to identify valid epoch solutions by ensuring that all epochs had four or more valid carrier phase double differences was changed. Almost all the epochs had at least four valid pseudorange double differences, it was considered restrictive to simply reject these; instead, we chose to use the float solution derived from the pseudoranges when the epoch did not have four or more carrier phase double differences.