DGPS corrections on Android

Question

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

Answer 1

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.

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.

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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.

Answer 6

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.