Following the release of the Android N Preview for App developers, we took the chance of implementing a simple app to fetch the GNSS raw measurements, something that was not possible before this OS release. Before that, only the position fixes and some basic information on the satellites in view were available. A note on this announcement done at the Google I/O 2016 was published in GPS World, last June 2016. For the time being, this feature will be only available in Android powered devices, as Apple has not made any similar announcement in this direction as of today.
Google makes it easy now to process the GNSS raw measurements in Android powered devices. The question “how to obtain GPS pseudoranges from smartphones?” can be easily answered if one looks at the Android N API documentation.
The data shown in this post corresponds to a test done in the rooftop of Rokubun’s office building which offers a clear sky visibility with an elevation mask of ca. 20 degrees in the North side. We tested the app in a Motorola Nexus 6 and a LG Nexus 5X, that were placed side by side, with a separation of 25cm. These two devices feature the following System-On-Chip (SoC) from Qualcomm:
Nexus 6 SoC Qualcomm Snapdragon 805 (GPS chipset Qualcomm® IZat™ Gen8B)
Nexus 5X SoC Qualcomm Snapdragon 808 (GPS chipset Qualcomm® IZat™ Gen8C)
GNSS satellite visibility
The first check on the measurements that has been done is related to the satellite visibility. This check can already be done with any current version of Android, which include the satellites in view as well as their azimuth and elevation. In looking at the viewed satellites, the following relevant points are noted:
– The collection of raw measurements reported by the preview Android N API
getMeasurements() contains only GPS measurements on the tested devices. Neither GLONASS nor satellites for other constellations are reported by this method, despite the fact that the specs for both devices indicate that they are capable of tracking GLONASS. It is still unclear if this is due to the API itself or related to the hardware.
– In general the Nexus 5X tracks a higher number of satellites than the Nexus 6 (see plot), this might be due to the fact that, as shown below, the Nexus 5X tracks satellites with lower C/N0.
The time tag associated to the measurements can be obtained by calling the method
gpsClock(). The clock is expressed as a
long int for the number of nanoseconds since the GPS time scale origin (6th January 1980 00:00:00) and a
double with the sub-nanosecond value, which is being set to not-a-number in the two devices that have been studied.
It is interesting to note that the measurements are never delivered at integer time tags (i.e. fractional part of the second is not 0), as done usually by dedicated GPS receiver. Moreover, the pattern of this fractional part differs substantially between the two devices. In the following plot, the fractional part of the seconds have been plotted for all measurements for the two devices. In the case of the Nexus 5X, there is a very clear drift (of ca. 12 microseconds per hour) that can be easily modelled by a linear fit. The case of Nexus 6 is more erratic and very difficult to predict.
At first the authors thought that this might be due to the GPS chipset clock alone. However an additional explanation might be found in the differences of the Task Scheduler of the two devices. In general, the interruption raised by the GPS chipset when a new measurement is received (and served by the Callback method that processes those measurements) will come at a time defined by the Operating System, after other interruptions with more priority are served. The fact that the Nexus 5X was operated just after being unpackaged (without additional apps installed, as opposed to the Nexus 6 device) might have some impact on this feature. More details on the GPS chipset might clarify this point. Unfortunately, the authors do not have more details on the device hardware.
Due to this, it is advised then to try to integerize the time tags (and rebase the raw measurements to this integer time tag accordingly) to ease any later process that might be later performed with those ranges.
If one has a look at the Android N GnssMeasurement class description, there are a bunch of methods that seem to refer to the phase measurements. However, when using the method
toString() to printout the measurements that are actually available, no carrier phase measurements are present neither for Nexus 6 nor for the newer Nexus 5X.
Also, there is no direct method to obtain the code pseudorange. The method
getReceivedSvTimeNanos() has to be used to compute the code pseudorange using its basic definition: the time difference between the reception and transmitted time (scaled by the speed of light).
In order to have a first peek on how the pseudoranges look like (noise, biases and other features), the observed ranges have been modelled and the residuals (i.e. observed – modelled) have been obtained (see attached figure). The simple model for the range is as follows:
- the geometry at each observed epoch has been simulated using IGS rapid orbits (in SP3 format),
- satellite clocks have been obtained also from the IGS rapid products (SP3 format)
- the ionosphere has been modelled using the Vertical Total Electron Content (VTEC) extracted from IONEX maps. This VTEC is later converted to Slant Total Electron Content (the integrated electron density along the line-of-sight) using a geometric mapping function
The following terms are missing in this simulation:
- Total Group Delay (TGD) and code biases between C1, P1 and ionosphere free combination (PC) have not been included. These are necessary however due to the use of IGS clocks (computed using PC combination)
- Usage of 5s clock instead of 900s clocks (IGS rapid products) to reduce clock interpolation error
- antenna mean phase center of GPS satellites (IGS orbits are relative to center of mass)
- other smaller error terms such as e.g. relativity.
These terms are left for further analysis.
Differences between devices
The two main differences between the devices, from the pseudorange residual plots:
- The Nexus 5X shows periodic clock jumps that amount to ca. 50m (166.7ns) at an irregular but similar intervals. This feature is not present in the Nexus 6 device
- The standard deviation of the range residual in the case of Nexus 5X is in general smaller (ca. 10m, without the clock drift and jumps) than the Nexus 6 smartphone (ca. 20m). These figures are likely to change when a better range model is used. However, since the same model has been used for both devices, it is safe to state that, from the results of this preliminary analysis, the quality of the pseudo ranges is in general better in the newer Nexus 5X than Nexus 6.
Range rate (Doppler shift)
In order to easily compute the velocity of the device, the two devices provide the value of the range rate, presumably based on the raw Doppler shift obtained from the coarse Frequency Locked Loop (FLL). When plotting the range rate of the satellites in view, one of the most relevant features are the spikes in the Doppler observables in the Nexus 5X device, which occur when the C/N0 value drops. This is common to all satellites seen by this device. As an example, the range rate for PRN 20 is provided. Despite these spikes in the range rate, the variance is lower in the Nexus 5X than Nexus 6.
Besides the Range and range rate estimates, the C/N0 (
getCn0DbHz()) and the range rate error estimate (
getPseudorangeRateUncertaintyMetersPerSecond()) are available. These two parameters can give certain information on the tracking loops of the device.
The C/N0 values reported by both devices are in general very similar. Note that the phone manufacturer differs, but the processor manufacturer is Qualcomm in both cases. The authors made thus the assumption that the method of computing the C/N0 in both cases might be the same. From these values, it is clear that the Nexus 5X tracks lower C/N0 (up to ca. 10 dB-Hz) compared to the Nexus 6 (up to ca. 20 dB-Hz). This also explains why Nexus 5X tracks a higher number of satellites.
Tracking loop error
Finally, if the range rate uncertainty is plot against the C/N0, it is possible to extract some information on the tracking loop settings (filter bandwidth as well as integration times).
Since we are looking at the error in the range rate (i.e. Doppler shift), we should look for the FLL error model (Misra and Enge, 2006, Equation 12.66, pages 494 and 495). The following plot shows the tracking loop error model for the FLL for high values of C/N0. The green line corresponds to the Misra and Enge 2006 model with the following typical values:
- BW (filter bandwidth) is 10Hz,
- N (number of integrated non-coherent samples) is 10
- k (factor that multiplies the GPS message bit duration, 20ms, to obtain the coherent integration time) is 0.1.
The picture shows that FLL tracking loop model does not fit the data from the phones: the C/N0 needs an exponent (which changes the slope in the logarithmic scale). Unfortunately, the authors do not have access to any details on the hardware of the GPS chipsets. This makes it difficult to obtain an explanation of this discrepancies in the tracking loop modelling.
The following tasks will be done to provide more insights in this preliminary analysis:
- Refine the pseudorange model (with the missing terms mentioned earlier) to obtain a better assesment of the pseudorange errors.
- Perform Precise Point Positioning (PPP) with a tool such as gLAB, RTKlib or similar to obtain position and clock estimates.
If you have additional suggestions, please drop us a note!
- Cameron Alan, “Google opens up GNSS pseudoranges“, GPS World 2016.
- Misra, Pratap, and Per Enge. “Global Positioning System: Signals, Measurements and Performance Second Edition”. Lincoln, MA: Ganga-Jamuna Press, 2006