First look at Android N GNSS raw measurements

First look at Android N GNSS raw measurements

Android NFollowing 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:

Number of satellites
Number of satellites

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

 

Measurement timetags

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.

Time tag fractional second
Variation of the fractional part of the second in the measurement time tag

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.

Pseudoranges

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

Pseudorange modelling

Range residuals
Range residuals (the geometry, satellite clocks and ionosphere has been removed)

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

Range rate for GPS PRN20 satellite
Range rate for GPS PRN20 satellite
PRN20 C/N0
PRN20 C/N0

 

 

C/N0

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.

C/N0 of all satellites for Nexus 5X
C/N0 of all satellites for Nexus 5X
C/N0 of all satellites for Nexus 6
C/N0 of all satellites for Nexus 6

 

 

 

 

 

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.

 

 

Range rate uncertainty against C/N0
Range rate uncertainty against C/N0

 

 

Further tasks

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 gLABRTKlib or similar to obtain position and clock estimates.

If you have additional suggestions, please drop us a note!

References

  • 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

Miquel Garcia

28 COMMENTS
  • Miquel Garcia

    Hi Muhammed,

    Unfortunately, we have not tried the Benq Aquaris X5 plus. We have successfully recorded measurements with both a Nexus 5X and Nexus 6.

    Miquel

  • Miquel Garcia

    Hi! My understanding, from what I could see in the measurements from Nexus 5X and Nexus 6, is that the Accumulated Delta Range is basically the accumulation of the code pseudorange differences. Therefore the result is a measurement that resembles de code (not the phase). In theory, if the actual Doppler measurement would be provided, by integrating it, the carrier phase could be obtained.

    Another issue is the Nexus 9 issue (which we have not tried yet), which with the proper Android version it is possible to deactivate the duty-cycling of the device, which is the element that prevents having continuous carrier phase. Due to the duty-cycle, the GNSS chipset is turned on and off every second, which causes a cycle slip in the phase measurement every second, thus rendering the carrier phase useless..

    Hope this helps

    Miquel

  • Muhammed

    Hello everyone,

    I have an issue on my Benq aquaris X5plus running with Android 7.1.1.
    When I am trying to get the raw measurement using GNSSLogger, I have an log message indicating that the raw measurement are unsupported.
    I don’t understand why it is not compatible. Please, Have you an explanation ?

    What are the smartphones recommended to get the raw measurement?

    Thank you in advance,

    Regards,
    Muhammed

  • Qiang Wen

    Hi Miquel, have you tried nexus 9 to access the raw data recently? In Simon Banville’s paper ( GPS WORLD 2016.11 ) he said the “accumulated delta range” is carrier-phase
    measurement in the raw data file, And meanwhile he emphasized that nexus 9 is suitable for collecting continuous carrier-phase measurements. Do you know the difference between “accumulated delta range” and “continuous carrier-phase measurement”? Aren’t they the same thing?
    Cheers!

  • Miquel Garcia

    Hi Roman,

    We tried several Nexus models for which we had no problem with the measurements. These Nexuses use Snapdragon SoCs, but I could not find which chipset the Samsung Galaxy XCover 4 is using. It could be that the GPS chipset does not deliver those measurements, but I am afraid I cannot confirm this point. By the way, have you enabled high accuracy settings in your device?

    Miquel

  • Roman

    Hi (Miquel || reader of this comment),

    I have a question regarding the availability of GNSS raw data on smartphones. I am currently trying to receive raw data from a Samsung Galaxy XCover 4 device with API Level 24. I am able to register the GnssMeasurementsEvent.Callback and also the returned status is STATUS_READY, however, onGnssMeasurementsReceived( ) is never called (regular position fixes are available through LocationManager and LocationListener as expected). I’ve also tried another device, which returned STATUS_NOT_SUPPORTED.

    Is it possible that even though STATUS_READY is returned, the built-in chip is not capable of providing GNSS measurements?

    Regards,
    Roman

  • Miquel Garcia

    Hi Derek,

    We have not yet tried working with Nexus 9, but we have this test in our pipeline in the (hopefully near) future.

    Thanks for your comment!

    Miquel

  • Derek

    Has there been any updates on getting the Nexus 9 tablet to work with the new API? I read the other articles discussing getting carrier-phase with the Nexus 9, but I have not been able to get mine to work properly with the GNSSLogger code from github.
    I’ve tried the changes to gps.conf mentioned above.

  • Emanuele Ziglioli

    >>Unfortunately, open source packages such as RTKLIB cannot make code-only differential positioning (as far as I know)

    Actually, goGPS can do code only RTK as well as code/phase::
    http://www.gogps-project.org/
    https://github.com/goGPS-Project/goGPS_MATLAB
    https://github.com/goGPS-Project/goGPS_Java

    See here for a recent pubblication using goGPS:
    https://www.slideshare.net/paller/costefficient-localisation-system-for-agricultural-use-cases
    https://www.researchgate.net/publication/313891088_Cost-efficient_localisation_system_for_agricultural_use_cases

  • Miquel Garcia

    Hi Isaac! Yes please! keep us posted on your progress! Many thanks!

  • Isaac zafarani

    Hi Miquel,

    No worries, and many thanks for your response!

    I was hoping to do exactly what you said, use the code only. My team has recently started coding this. I would love to hear how it turns out for you and am happy to share our progress as well. Happy to chat about this further if you are interested.

    My best,
    Isaac

  • Miquel Garcia

    Hi Isaac,

    Thanks for your message, and apologies for the late reply.

    Currently, unless you can get the carrier phase somehow, I am afraid you will only be able to apply differential techniques using the code. Even though we plan to do that at Rokubun in the near future (hopefully), we cannot tell you for sure how much you will improve the solution, but I guess is worth trying. Unfortunately, open source packages such as RTKLIB cannot make code-only differential positioning (as far as I know), so I am afraid you will have to find another package or code it yourself

    Good luck!

    Miquel

  • Isaac

    Hi!

    I am interested in applying differential corrections to a Smartphone to improve positioning, specifically in RTCM2.3 format due to the inability to use carrier phase measurements. I can obtain the corrections from a local base station and thought to deliver the corrections via Ntrip. Does anyone have any experience with this? I would be vey grateful for any information on the topic.

    Many thanks in advance!

    Isaac

  • Emanuele Ziglioli

    New article from Prof Van Diggelen (who now works for Google) on GPS World:
    http://gpsworld.com/innovation-precise-positioning-using-raw-gps-measurements-from-android-smartphones/

    And app:
    https://github.com/google/gps-measurement-tools/releases

  • Sean Barbeau

    Nice article! Great to see someone digging into data from the new Android Gnss APIs.

    For those looking to experiment themselves, I’ve added support for the new Gnss* APIs to GPSTest, available on Google Play (https://play.google.com/store/apps/details?id=com.android.gpstest) and open-source on Github (https://github.com/barbeau/gpstest).

  • Miquel Garcia

    Hi Edward,

    This is difficult to say. In theory (and as far as I can guess) all GNSS chipsets should be able to process the carrier phase. However, the guys at Google stated that due to the “duty cycle” settings of the Android OS, there is a cycle slip at each measurement, rendering the phase measurement useless. We will all have to wait until Google releases an Android version that allows to modify the “duty cycle” settings. You can have more information in this great post: http://www.blackdotgnss.com/2016/09/20/ppp-with-smartphones-are-we-there-yet/

    Best!

    Miquel

  • Edward

    Hello Miquel

    Thanks for sharing this. I am wondering which brand and type phone will support the carrier phase measurements access now?

    Thanks a lot!
    Edward

  • Miquel Garcia

    Hi Jeff,

    Apologies for the late reply. I hope you have sorted out the issue you were referring in your comment. In case you didn’t, as far as I know I do not anything special on this other than registering the callback (as you correctly point out) and also make sure that I’ve request location updates to the GPS Location provider (method requestLocationUpdates()). Make sure you allow accurate position in the permissions of your app.

    Hope this helps! Good luck!

    Miquel

  • Miquel Garcia

    Hi Nils,

    Apologies for the late reply. Probably you already sorted out the issue. My interpretation is that you should make the difference between the GNSS Clock (obtained with the getClock() method and the per-satellite reception time, that you can access by using the method getReceivedSvTimeNanos().

    Hope this helps!

    Good luck!

  • Nils

    Hello,

    I read your interesting work on the gnss measurements with Android n. I am currently working on a system which analyzes the Pseudo Ranges.
    As shown in your report, those are not directly available but can be calculated with the “receivedSvTimeNanos” and the time of reception. I thought that the time should be available in the GNSS clock which you get from a GNSSMeasurementEvent. But in several tests I made the value of getTimeNanos was always zero. According to the API documentation I thought that the difference between this and getFullBiasNanos is the GPS time which should be the time of reception. Am I mistaken somewhere?
    I am using a Nexus 5x for testing.
    Thanks for your help.

    Kind regards,
    Nils

  • Jeff Wu

    Hi Miquel,

    I am trying this on a Nexus 6 and am having exactly the same problems as Abijith—namely that the onStatusChanged() callback does get invoked, but the onGnssMeasurementsReceived() callback does not. Are you doing anything else other than registering the GnssMeasurementsEvent.Callback on the LocationManager to trigger GPS measurements?

    Thanks,

    Jeff

  • Abijith Kumar

    That is surprising!
    The Nexus 9 has
    CAPABILITIES=0x33

    I changed the value to 0x73 and thats when i see the warning log message –
    07-18 14:58:20.928 654-869/? W/GnssLocationProvider: Invalid size of GpsSvStatus found: 0.

  • Miquel Garcia

    Thanks for sharing your findings!

    Do you think you could post the contents of your gps.conf file? (or at least the part concerning the definition of CAPABILITIES). The one in the Nexus 5X we tested is:

    # GPS Capabilities bit mask
    # SCHEDULING = 0x01
    # MSB = 0x02
    # MSA = 0x04
    # ON_DEMAND_TIME = 0x10
    # GEOFENCE = 0x20
    # default = ON_DEMAND_TIME | MSA | MSB | SCHEDULING | GEOFENCE
    CAPABILITIES=0x37

  • Abijith Kumar

    Hi Miquel,

    Thanks for the response.

    After some searching in gps.h, I found that the GPS Measurements need to be enabled as part of capabilities in gps.conf
    #define GPS_CAPABILITY_MEASUREMENTS (1 << 6)

    And when i looked at the gps.conf in Nexus 9 this was not enabled. I rooted the device and modified the gps.conf to enable this but i am seeing this log constantly –
    07-18 14:58:20.928 654-869/? W/GnssLocationProvider: Invalid size of GpsSvStatus found: 0.

    So, i think the Nexus 9 is still not enabled with this feature. And overall the support for this needs to be enabled from the HAL layer. Will wait to see if future phones get this update.

    Really appreciate this blog.

    Best Regards,
    Abi

  • Miquel Garcia

    Hi Abijith, thanks for your comment!

    You may want to check at these two points:
    (1) Make sure you define a class that extends a GnssMeasurementsEvent.Callback interface (not a GnssMeasurements.Callback)
    (2) Make sure the app has permission to access accurate location: Enable “android.permission.ACCESS_FINE_LOCATION”

    I am still not sure, however, if the API is fully functional for all devices. Still checking.

    Hope this helps. Good luck!

  • Abijith Kumar

    We are trying to get the GnssMeasurements to work in the Nexus 9 tablet but somehow i am not getting the onMeasurementsReceived() callback. Although the onStatusChanged() as STATUS_READY which means that the GnssMeasurements.Callback object is getting registered correctly. Do you think it doesnt work on all the devices at this point? Or is there anything special you had to do to get the measurements outside of the LocationManager’s registerGnssMeasurementsCallback

    The LocationManager requiestLocationUpdates from GPS Provider are working correctly and I am seeing fixes on my LocationLiistener onLocationChanged() callback

  • Miquel Garcia

    Thanks for your comment Michele. We are still working on the app as it is, as of today, more a “quick & dirty” solution rather than a finished product to be uploaded to (and approved by) the Google Play store. Please keep us posted on the analysis you do at EC-JRC.

    By the way, have you seen this fantastic report from Humphreys et al 2006?

    Do you think we could perform the tests with the simulator without modifying the device (e.g. without external antenna)?

    Best! Miquel

  • Michele

    Thanks for sharing your analysis with the community!
    Do you plans to share also the Android application used to log the RAW messages by chance?
    At the EC-JRC, I ordered a Nexus 5X two weeks ago and would like to repeat some of those tests too when it arrives.
    As I have a few RFCSs at disposal (Spirent GSS9000, Spectracom GSG64, R&S SMBV100, …) so I could help with characterization of the residuals in case you are interested.

    Cheers,
    Mic

Leave a Reply

Your email address will not be published. Required fields are marked *