Unfortunately, we have not tried the Benq Aquaris X5 plus. We have successfully recorded measurements with both a Nexus 5X and Nexus 6.
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
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,
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!
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?
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?
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!
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.
>>Unfortunately, open source packages such as RTKLIB cannot make code-only differential positioning (as far as I know)
Hi Isaac! Yes please! keep us posted on your progress! Many thanks!
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
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
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.
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/
Thanks for sharing this. I am wondering which brand and type phone will support the carrier phase measurements access now?
Thanks a lot! Edward
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!
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!
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
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?
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.
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:
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
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!
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
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.
Do you think we could perform the tests with the simulator without modifying the device (e.g. without external antenna)?
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.