PPP with Smartphones: Are We There Yet?

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...


EDIT: Read the full article published in the November 2016 issue of GPS World

Write a comment

Comments: 12
  • #1

    Ahmed El-Mowafy, Curtin University, Australia (Tuesday, 20 September 2016 22:08)

    Very interesting. I think you better team up with Frank and put an article on this subject in one of the professional magazines.
    question: when you used the carrier-phase data was that with a float solution or carrier-phase smoothing the code (what about cycle slips then?).
    Assuming all the technical issues have been resolved, from the application point of view how one can utilise the wished for cm or decimeter position from a smart phone in real life. It is a mobile device that does not have a centering system. Perhaps we can make mobile phones with class 1 laser pointing capability for this purpose.

  • #2

    Michele Bavaro (Thursday, 22 September 2016 04:17)

    Very interesting, thanks! Could I ask which chipset was the S7 with? I see it comes with either Broadcom and Qualcomm tech inside. Given the past of Frank, I am guessing the former?
    I have tested a Nexus 5X which has a Qualcomm IZat Gen8C and it does not report Doppler but "DeltaRange" thus delivering large spikes when the epoch time intervals jump a little. Would be interesting to also compare with numbers obtained from QPST-QXDM as the same chipset might report differently on Nougat and its proprietary telemetry software.

  • #3

    Simon Banville (Thursday, 22 September 2016 12:27)

    @Ahmed I did not smooth the code using carrier-phase measurements, but rather used uncombined observations directly into the PPP filter. Cycle slips were accounted for by resetting the ambiguity parameters.

    Reaching new levels of precision will highlight further issues to be resolved. I have not given these issues much thought yet!

  • #4

    Simon Banville (Thursday, 22 September 2016 12:37)

    @Michele I did not inquire about the chipset but it would be a good question to ask Frank.

    Concerning the Doppler measurements, the Android.location API provides access to the function getPseudorangeRateMetersPerSecond(), see:


    According to the description, it is related to the Doppler shift. Unfortunately, I did not process enough data yet to confirm if problems are sometimes encountered with this observable.

  • #5

    Miquel Garcia (Friday, 23 September 2016 05:22)

    @Simon As from my experience, the getPseudorangeRateMetersPerSecond() delivers, as @Michele points out, the delta pseudorange. It does not look as actual Doppler. I have not been able to successfully derive from it something that resembles the carrier phase...

    As for the processor, the Samsung Galaxy S7 has a Snapdragon 820 which features the same IZAT processor as the Nexus 5X (Qualcomm IZAT Gen 8C, see http://www.gsmarena.com/samsung_galaxy_s7-7821.php)

  • #6

    Simon Banville (Friday, 23 September 2016 08:29)

    @Miquel Thanks for the clarifications on the processors.

    The carrier-phase measurements can be obtained directly (on phones supporting it) using getAccumulatedDeltaRangeMeters(). They should not be derived from getPseudorangeRateMetersPerSecond() which has a much larger noise (cm- to dm-level).

    Still the noise from getPseudorangeRateMetersPerSecond() is much smaller than computing the differences of actual pseudorange measurements between epochs, which is at the meter level.

  • #7

    Zhang,Liang (Tuesday, 27 December 2016 09:01)

    It seems that getAccumulatedDeltaRangeMeters() is related with carrier-phase, as it state in android API document.

    Adr = -k * carrier-phase

    However, I can't find k's value in API document. So Could tell me how did you solve it?

  • #8

    Simon Banville (Wednesday, 28 December 2016 12:07)

    @Zhang,Liang: A value of k = 1 worked for me. You can also determine this value by plotting the time variation of the pseudorange and carrier-phase observations. Apart from a small divergence due to the ionosphere, the time series of both observables should be quite similar.

  • #9

    Steve Hancock (Tuesday, 18 April 2017 05:41)

    Do we yet know what devices are capable (off the shelf) to provide the carrier-phase measurements? So far our Google Pixel is able to log the pseudorange based observations, but not the carrier-phase.

  • #10

    Simon Banville (Tuesday, 18 April 2017 11:17)

    @Steve As far as I know, only the Nexus 9 tablet with Android 7.1 (or newer) equipped with a GNSS chip manufactured in 2016 or later can provide raw carrier-phase measurements at the moment. Hopefully, the list of devices will be updated in a near future!

  • #11

    Mario Rossi (Tuesday, 24 April 2018 05:09)

    Hi @Simon, I found your analysis very interesting. In this period I am looking at the GNSS raw measurements coming from a smartphone and I am trying to obtain good positioning results working with the pseudorange. In this paper you talk about the use of Doppler and Carrier phase observations to obtain smoother solutions with respect to the use of only pseudorange observations. Are you using a doppler or carrier phase smoothing of raw pseudorange measurements?

  • #12

    Simon Banville (Tuesday, 24 April 2018 19:33)

    @Mario I am not explicitly using a smoothing algorithm. I am instead adding all measurements into a Kalman filter and estimating additional states such as the receiver velocity, carrier-phase ambiguities and slant ionospheric delays. I hope this helps, good luck!