DGPS corrections on Android

DGPS corrections on Android

I am developing a project that is intended to use the GPS capabilities of an Android phone and a nearby station to compute positioning to a much more precise degree (cm), using RTK DGPS technology.
So far, I haven’t been able to see anyone saying they actually managed to perform a similar task (apart from @GPSmaster, who doesn’t explain how), and the APK doesn’t seem to offer any information from the GPS chip other than location and NMEA message updates. I need, if possible, pseudo-ranges and carrier phases.
I was wondering if:

It would be possible to look for lower level hooks on my phone using native code, or other lower level snooping;
It would be possible to send RTCM corrections to the GPS chip present on one of these devices;

Any ideas?

Solutions/Answers:

Solution 1:

No, it is not practical to get any lower level access to the GPS device by an Android application. This has several reasons:

  • The application has no other means of accessing the GPS device as through the Java based API. Native code is forbidden to use most devices and usually needs a Java wrapper to tunnel through the sandbox for Android sensor devices. This makes up the main security concept.

  • If native code would have access to the GPS device on a lower level, it would have to cope with several different manufacturers protocols now not abstracted by the API. Best chances are to get access to custom NMEA codes, which may still have device dependent caveats.

  • Even if lower level access would be possible, one loses the integrated merging of other location sources like WLAN and cellphone carrier, that are presumably merged in native code below the Java API but above the NMEA protocol.

Related:  Fully change package name including company domain

Solution 2:

Generally speaking DGPS is a technique that improves real position accuracy by canceling out most of the atmospheric effects on the GPS signal. In a typical direct GPS measurement there is about a random error in the ranges computed to the satellites due to atmospheric effects. This is why a GPS receiver that is left collecting data in a fixed location will seem to wander with in an error ellipse. For two receiver stations in the same area the atmospheric effects are almost identical and they will wander in parallel within their similarly sized and oriented error ellipses. If one of the two receivers is at a know location then the differences in their apparent GPS locations can be taken and plotted from the true location of the known station to find the true location of the unknown station.

Back in the day (circa 1992) when we had to accomplish DGPS by “post processing” we used to take the raw NEMA data collected at the two stations match up the times, compute the baseline vector and apply it to the known point to find the unknown point. I think the NEMA data we were using was only recorded to the nearest 10 sec. The math isn’t really that hard.

Related:  Unable to execute dex: Multiple dex files define

I suspect that NEMA GPS messages [http://developer.android.com/reference/android/location/GpsStatus.NmeaListener.html ] from a tablet at a known point (with a clear sky view) could probably be sent over an internet socket to a smart phone (also with a clear sky view), which could then compute the difference and achieve a sub-meter relative location over a distance of few km, even if the assumed Internet transit times were ignored. This technique would probably still work even if the tablet and smart phone were both applying broadcast DGPS adjustments.

Solution 3:

With the andvent of Android 7.1, the raw data from GPS chips will be available to developers. (http://gpsworld.com/google-to-provide-raw-gnss-measurements/)

Others seem to have done something similar to what you wish to accomplish (http://gpsworld.com/innovation-precise-positioning-using-raw-gps-measurements-from-android-smartphones/)

Solution 4:

Umm. Your android probably has such a crap GPS antenna that achieving cm accuracy is impossible. Maybe if you average the position for days.. usually DGPS support is not published and not many chipsets support it. Last time I saw DGPS implemented it involved hacking the actual GPS chip firmware to add support. Even getting A-GPS to work on a random chipset is iffy since they might not support a documented way of feeding the assistance data.

Related:  Converting pixels to dp

Solution 5:

You can use DGPS corrections in Europe via custom application for SISnet receiving correction signals from EGNOS augmentation satellites(http://egnos-portal.gsa.europa.eu/news/egnos-gets-invite-your-smartphone-11). It does however need a subscription (which isn’t really open to public yet) to SISnet to obtain username and password for connection to their servers. There’s some of SDK published which you may find useful. Just remember that you are limited to C/A signals only (pseudoranges) and you CANNOT get phase data (L1/L2) from those cheap chips inside smartphones.You’d need a precision GNSS receiver such as Trimble BD910 (http://www.trimble.com/gnss-inertial/bd910.aspx?dtID=overview) to be able to access L1 carrier phase signal for GPS & GLONASS. There are however cheaper chips that support SBAS but none are yet installed natively in phones.

Solution 6:

It should be related with the hardware implementation , rather than the software implementation.

In the reality, GPS is usually accompanied with Wi-Fi or 3G to assist in searching the current position.

Solution 7:

RTCM correction can be sent to your android phone using NTRIP 'provider'. Then you need to apply it to your raw GPS in your android.

References