What is your most accurate measurement so far?

[issey sandei]

This is the most accurate location I've been able to get, so far (OnePlus Nord 2 5G).
Is it possible to get better, or is this the best you can get from a smartphone without using specific equipment?

[Sean Barbeau]

Issey,

Trying measuring your device GNSS accuracy using the "Accuacy" screen instead of depending on the estimated accuracy values shown on "Status". See more here:

https://barbeau.medium.com/measuring-gnss-accuracy-on-android-devices-6824492a1389

Sean

--
You received this message because you are subscribed to the Google Groups "GPSTest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gpstest_andro...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gpstest_android/e79695ad-1d10-497f-86d7-0843117bbf66n%40googlegroups.com.

[Валерий Заподовников]

.

Yep. Galaxy S22 Ultra snap, model 0. Triple-band.

[lodrog...@gmail.com]

What is your most accurate measurement so far?

this title is inaccurate itself. The user that read the follow specs can't cover his personal needs. According to the different conditions of navigations types, we must make the suitable measurements. Does the device can support them ?

There are a few conditions. Those are

- static measurements
- moving measurements
- what speed ? walking, slow car, fast car, into the city, mountain, into the sky, open sky, high buldings, etc
of course the device must be 100% with satellite access only. The use of sim card is forbidden, to let user have accurate measurements. Also the device must be to airplane mode. There are also a few settings to must done into the android settings

today typical GNSS chips inside the android devices have 1m static accuracy with Mediatek and 3m static accuracy with Qualcomm. Both of them are with 1Hz sample rate

in theory all are good. But the design of a device must to be measure even to different models share the same GNSS chip. The local design can have issues, to hardware or at software of a smartphone model.

[Валерий Заподовников]

Okay, I tested it further. It is apparently impossible to get lower value than 3.8/2.5, and that number you get in 30 seconds or so. So that says me it should be a bug. Values decrease fast until you get 3.8/2.5. But I would imagine snapdragon on 4nm is superiour to mediatek with its 1 m. Tested on September patch of Android 12 I installed yesterday. After installing armv8 GnssLogger I was shocked to see it has 4 sources of geoposition: GNSS, WLS, NLP, FLP. Maybe Gpstest takes some wrong number? Or Qualcomm private blob has a bug.

[Sean Barbeau]

GPSTest shows location info from the GPS_PROVIDER, which comes from the GNSS chipset.

This is equivalent to the "GNSS location" shown in GnssLogger, which also comes from the GPS_PROVIDER and the GNSS chipset. In GnssLogger, WLS is a weighted least squares solution implemented in the app source code (see https://github.com/google/gps-measurement-tools/tree/master/GNSSLogger/pseudorange), FLP is the fused location provider which is a black box that comes from Google Play Services (see https://developers.google.com/location-context/fused-location-provider), and NLP is the network location provider, which I believe also comes from Google Play Services in the latest iterations and uses Wi-Fi access points and cellular data info to provide a position.

If you're benchmarking GNSS chipset accuracy in GPSTest using the "Accuracy" feature, please see this article I wrote for details, best practices, and caveats:

https://barbeau.medium.com/measuring-gnss-accuracy-on-android-devices-6824492a1389

Sean

On Mon, Oct 3, 2022 at 4:49 AM Валерий Заподовников <val.za...@gmail.com> wrote:

Okay, I tested it further. It is apparently impossible to get lower value than 3.8/2.5, and that number you get in 30 seconds or so. So that says me it should be a bug. Values decrease fast until you get 3.8/2.5. But I would imagine snapdragon on 4nm is superiour to mediatek with its 1 m. Tested on September patch of Android 12 I installed yesterday. After installing armv8 GnssLogger I was shocked to see it has 4 sources of geoposition: GNSS, WLS, NLP, FLP. Maybe Gpstest takes some wrong number? Or Qualcomm private blob has a bug.

--

You received this message because you are subscribed to the Google Groups "GPSTest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gpstest_andro...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gpstest_android/59840157-5f99-43dc-99af-5ad08fb5e869n%40googlegroups.com.

[Валерий Заподовников]

The biggest problem with "If you're benchmarking GNSS chipset accuracy in GPSTest using the "Accuracy" feature, please see this article I wrote for details," is that ground truth Google map will not use G2139 WGS 84 or even any WGS 84 or even same ITRF in all places, like in France or Australia. So I would not be able to check 30 cm anyway. Unless I go to some known location with G2139 coordinates known. Or ITRF2014 or ITRF2020. I wrote the whole new topic on it. https://groups.google.com/g/gpstest_android/c/vSyqMYUL504

I think I have two places in my city... So may go there.

[Sean Barbeau]

>So I would not be able to check 30 cm anyway. Unless I go to some known location with G2139 coordinates known. Or ITRF2014 or ITRF2020.

Correct - I wrote that in the article 😀. To do a high precision and accuracy testing, you need to be at a location that's been independently precisely and accurately benchmarked.

Sean

On Tue, Oct 4, 2022, 1:50 AM Валерий Заподовников <val.za...@gmail.com> wrote:

The biggest problem with "If you're benchmarking GNSS chipset accuracy in GPSTest using the "Accuracy" feature, please see this article I wrote for details," is that ground truth Google map will not use G2139 WGS 84 or even any WGS 84 or even same ITRF in all places, like in France or Australia. So I would not be able to check 30 cm anyway. Unless I go to some known location with G2139 coordinates known. Or ITRF2014 or ITRF2020. I wrote the whole new topic on it. https://groups.google.com/g/gpstest_android/c/vSyqMYUL504

I think I have two places in my city... So may go there.

--

You received this message because you are subscribed to the Google Groups "GPSTest" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gpstest_andro...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/gpstest_android/8fb79ef6-158f-4899-b76e-141468066aafn%40googlegroups.com.

[Mark Palmer]

I realize that most of the discussion in here concerns the location accuracy and accessibility of GNSS chipsets, but my 

main interest is in accessing the GPS timestamps!   Why do vendors not use the GPS time to set the phone device time,

or at least allow API access to the GPS clock?  

This would allow smartphone clocks to be synchronized to within 1ms easily, enabling many applications.

Without GPS clock access, apps have to rely on services like NTP, which can be off by 30ms and typically more.

Is there any particular reason why phone clocks don't use the nanosecond clocks within their GPS chips?

To view this discussion on the web visit https://groups.google.com/d/msgid/gpstest_android/CAEkVq%2BgoFS%2B670%2Buh6fnYX8xMYgOOupYT2QwSE7pnSSk-tsrNw%40mail.gmail.com.

[lodrog...@gmail.com]

On Tuesday, October 4, 2022 at 11:04:33 PM UTC+3 manfmna...@gmail.com wrote:

I realize that most of the discussion in here concerns the location accuracy and accessibility of GNSS chipsets, but my 

main interest is in accessing the GPS timestamps!   Why do vendors not use the GPS time to set the phone device time,

or at least allow API access to the GPS clock?  

This would allow smartphone clocks to be synchronized to within 1ms easily, enabling many applications.

Without GPS clock access, apps have to rely on services like NTP, which can be off by 30ms and typically more.

Is there any particular reason why phone clocks don't use the nanosecond clocks within their GPS chips?

because humans using the smartphones most at interior of houses , metro , at work, etc . GNSS receiver consume a lot of energy

[Валерий Заподовников]

They do since Android 12. But that requires that someone uses gnss API (imagine Google maps) and be near the window at least. https://source.android.com/docs/core/connect/time/gnss-time-detection

As for nanosecond precision, it is actually picosecond precision. The problem is it is no atomic clock. It drifts up to a second per 24 hours and it may drift backward the next day. It will depend on how you hold your phone, upside down...  There is also NITZ, LTE time. It is sometimes unreliable, so Android people decided to make NTP (every 24 hours, in Android 13 will be every 18 hours https://android-review.googlesource.com/c/platform/frameworks/base/+/2007251/2#message-4960e34a8665b45b984e1eb71408d3a52d0ae87f ) default. You can still trigger NTP if you first set tomorrow date and then select use auto time. The problem with NTP is it is never Stratum 0. 0 just means unspecified in NTP. GNSS IS STRATUM 0. You can also use this to see your ms difference with GNSS https://play.google.com/store/apps/details?id=com.pautinanet.smartgpstime

There are two problems with NTP too. 1) you really need multiple NTP servers 2) you must have a server close to you with a stable ping, so that paths are the same, if they are not... All bets are off. And of course ms accuracy. Not even microsecond.

I personally use https://time.is it is more simple and they have enough servers.

[Валерий Заподовников]

"As I understood it, UTC is an error-correcting average of Cesium clocks hosted on the GPS satellites.  

So, I don't see how the reading could drift much from one fix to the next? "

No, gps uses its own time with constant amount of leap seconds. It is not UTC, GPS is ahead by 18 seconds. See: http://www.leapsecond.com/java/gpsclock.htm

As for drift I was talking about NTP only scenario. Or even no sync, if no internet.

BTW, technically there is Stratum -1. It is what is called optical lattice clocks fountain. Those are atomic optical clocks with 24 attoseconds precision and accuracy (10^-18), https://www.bipm.org/en/-/2020-optical-clocks while GPS is just 1 microseconds, that is why it is corrected often to get to 3 nanoseconds (or more for GPS III satellites, they also get no adjustment when you go to a new frame realisation, like G2139).

Also see https://webtai.bipm.org/database/show_psfs.html and https://www.bipm.org/en/-/2021-12-21-record-tai

[Валерий Заподовников]

Guys, I found quite a horrible fact about my Galaxy S22 Ultra. Without THE internet, AND I mean LTE/5g one (finally got 5G NR NSA here, yeah) you will not be able to get the needed files to catch L5 of GPS and E5a of Galileo. Also B1C band of Chinese Baidu disappeared. I have 8 Gen 1.

[Jim bell]

     Even if we don't know exactly where we are, to the centimeter, it would be very useful to have a plot of the as-calculated position, as your GPSTest app creates in the Accuracy function.  After all, a device can be no more 'accurate' than it is 'stable'.   But if you discover that a GPS device produces a good 'stability', that is at least a clue that the result could also be 'accurate'. 

     What I'd like to see is a mathematical treatment of the distribution of results shown by the GPStest Accuracy function.  First, of course, an averaged value taken over minutes or hours, to allow a person to determine with more precision (and, hopefully, accuracy) where that device actually is.  But secondly, a mathematical statement of the quantity of 'scatter' as displayed by the device.  

For example, you can imagine there are two GNSS devices:  Placed at a fixed location, one creates a scatter with a diameter of one meter.  The second creates a scatter with a diameter of ten meters. Over enough time, if their results were averaged, they both might produce the same result.  But you'd prefer to use the second unit, presumably  because you wouldn't need to average its results for quite as long to get a stable, precise reading. 

     I'm not a math buff, nor a statistician.  But I suspect that programs, subroutines, to handle this problem have been available for 50++ years. 

 

To view this discussion on the web visit https://groups.google.com/d/msgid/gpstest_android/59840157-5f99-43dc-99af-5ad08fb5e869n%40googlegroups.com.b