[eqvinox]

It is worth mentioning that you can set up your own RTK installation buy grabbing 2 higher-end GNSS receivers¹, installing one of them in a fixed location with reasonable sky view, and measuring it in for a week or two. You can then feed correction data from that to your 2nd receiver. Search for RTKlib. (Some GNSS receivers even have built-in source & sink handling.)

Also, the GNSS software in most phones is sadly unable to accept the correction data from any of these systems, regardless of whether it's a nationwide network or your personal setup. This is purely a software limitation on the vendor GNSS stack, but sadly there is not enough demand for this. (An app will not fix this, we're talking vendor specific low level system code here.)

[¹] e.g. u-blox T/R series, but check specific descriptions about raw output/RTK capabilities, it changes between generations. You also want recent ones with RTCMv3, not RTCMv2.x.

[skzv]

> Also, the GNSS software in most phones is sadly unable to accept the correction data from any of these systems, regardless of whether it's a nationwide network or your personal setup. This is purely a software limitation on the vendor GNSS stack, but sadly there is not enough demand for this. (An app will not fix this, we're talking vendor specific low level system code here.)

I don't think that's true. Android surfaces raw GNSS measurements including carrier phase (sub wavelength measurements) to do centimeter level positioning through the raw measurements API [0].

There's even an API to specify the phone antenna phase pattern to correct the carrier phase measurements (source: I implemented it [1]). For those that aren't familiar, the idea is that the antenna pattern on phones isn't perfectly symmetrical, and depending on the direction of the incoming signal, it may appear longer. Knowing the antenna pattern, you can correct for this.

[0] https://developer.android.com/reference/android/location/Gns...

[1] https://developer.android.com/reference/android/location/Gns...

[Anunayj]

I wanted to play around with this! But too bad I have a Samsung Snapdragon :(

And it doesn't expose ADR/carrier phase.

[lxgr]

Is that true even for the relatively new Android "raw GNSS" API? https://developer.android.com/develop/sensors-and-location/s...

I believe Google are using that themselves for their "urban canyon" GPS improvements: https://android-developers.googleblog.com/2020/12/improving-...

[wibr]

The API would provide pseudoranges and also the carrier phase on some phones, so it should be possible to calculate a solution with corrections.

[aantix]

Does this api improve on GPS drift?

Or is it up to the engineer to decide how to best to use these improvements?

[skzv]

The raw measurements API provides raw GNSS measurements so that somebody can implement their own position engine, and do things like RTK.

The corrections mentioned in the blog post are calculated by the phone (in Google Play Services, using Google's 3D building models) using the raw GNSS measurements, and provided back to the chipset to improve its position estimate (correcting for reflections and interference).

[cyanydeez]

From what I can deduce, phone GPS just doesn't measure the proper signal data to do the correction. It's something like the offset of the signal frequency and timing.

It's not the software, it's the hardware.

[bendauphinee]

Just like this https://news.ycombinator.com/item?id=38820616