During Google’s I/O 2016 conference held in May 2016, Google announced that raw GNSS measurements from smartphones running the Android N operating system would be made available to developers. Following this announcement, I registered to a tutorial held last week at the ION GNSS+ 2016 meeting entitled “Raw GNSS Measurements from Android Phones,” given by Frank van Diggelen and colleagues from Google. Since I am a precision junkie, there is a question I needed to answer: can we do cm-level positioning with a smartphone?
For smartphones to provide quasi-instantaneous positions after initialization, pseudoranges are often computed without decoding the time of week (TOW) from the navigation message. For this reason, the Android Location APIs do not provide direct access to pseudorange measurements. Instead, users have to build their own pseudorange data from various timing information provided by the APIs. While this can be slightly confusing, once it is coded, we don’t have to worry about it. Concerning carrier-phase measurements, they are not yet available from all phones, but the ones we had access to (a special build of the Samsung Galaxy S7) did provide this observable directly.
One of the major challenges for smartphone manufacturers is to increase battery life. Since continuous use of a GNSS receiver would be draining the battery, the receiver tracks GNSS data for 200 ms before shutting down for 800 ms, a process called duty cycling. As you can imagine, this is not good for carrier-phase tracking and leads to cycle slips on all satellites at every epoch! There is however an exception to this process: the receiver remains continually active while decoding the navigation message. From a cold start, it takes 12.5 minutes to decode the full message, leaving us with a short duration of continuous carrier-phase tracking! As Frank puts it, if we can show that carrier phases are useful, then perhaps that there might be an option on the phones to deactivate duty cycling in the future.
During the tutorial, we were provided with phones containing a GNSS data logger app that could write GNSS measurements to a flat file. To be able to use this data in my PPP software, I wrote a rudimentary awk script that converts the Android format to the RINEX 3 format. I found it surprising that the Android format uses time stamps in nanoseconds, which leads to huge numbers when trying to express the time since 6 January 1980 (the start of GPS time). To avoid (large) roundoff errors, my script reads data fields as strings and then separates seconds from nanoseconds. Hence, arithmetic operations are carried out separately for seconds and nanoseconds, and then combined, which I found leads to more numerically stable results.
In order to evaluate the quality of the GNSS data from a smartphone, I used a 3-min data set provided to us as an example during the tutorial, collected on the Google campus in California. Duty cycling had not yet been activated by the phone, meaning that continuous carrier phase observations were available. Using precise satellite orbit and clock products as well as a global ionospheric map computed at NRCan, I first processed a pseudorange-only solution in kinematic mode, shown in Fig 1. As you can see, the noise level of the pseudorange measurements is quite high, providing a precision of a few meters at best. Note that the plotted estimates are differences with respect to the mean position since the true position is not available.
Fig. 1: Position estimates using code data only
I then added the Doppler measurements to the solution, which basically smoothed the pseudorange solution (see Fig 2, Left). After figuring out that Doppler measurements were not that noisy, I decided to further deweight the pseudorange observations. As a result, I obtained a much smoother time variation of the solution as shown in Fig 2, Right.
Fig. 2: Position estimates using code and Doppler data
Left: before deweighting; Right: after deweighted code observations
I then added the carrier-phase observations and estimated slant ionospheric delay parameters with process noise. Even though we are not expecting carrier-phase observations of the highest quality due to the type of GNSS antenna used in a smartphone, the solution was greatly improved with this additional observable (notice the change in scale in Fig 3). At this point, I should stress that the solution is becoming precise, but by no means accurate. With noisy pseudorange measurements and only 3 minutes of data, we are still expecting an accuracy of a few meters. Nevertheless, the displacement measured by the GPS data is starting to look decent.
Fig. 3: Position estimates using code, Doppler and carrier-phase data
To further improve the quality of the solution, I computed precise slant ionospheric delays from nearby UNAVCO-PBO station SLAC, located about 10 km away. When introducing these additional constraints in the solution, the stability of the estimates again considerably improved (see Fig 4). I am not aware of how the data was collected, but the standard deviations coming out of the PPP filter indicate no apparent position quality degradation at the beginning and end of the data set. My hypothesis is then that the phone could have been moved, while staying stationary in the middle of the observation session (if not, then there is some room for improvements!)
Fig. 4: Position estimates using code, Doppler and carrier-phase data, along with external ionospheric information
From the previous analysis, I tend to conclude that the quality of the carrier-phase observations is actually quite decent. Still, it is obvious that duty cycling should be optional since carrier phases are a must for high-precision applications. Back to my initial question: can we do PPP with smartphones? Currently, with a maximum of 12.5 minutes of continuous phase tracking, only a precise but definitely not accurate solution can be obtained.
Looking at Fig 4, my thinking is that a smartphone might eventually be a good candidate for densifying permanent GNSS networks for earthquake monitoring. Since smartphones already contain a GNSS receiver, MEMS and communication capabilities, they seem like a decent low-cost option for such an application. But the more I think of it, the more I start to see that applications are actually endless...