SelectiveSatelliteUse

[Matthew Schoen]

Mr. Barbeau,

Thanks for your quick turn around on my membership request.

I had a question about the satellite usage for GPSTest. I was wondering whether or not it was possible to disable GLONASS satellites used in the GPS fix. I considered disallowing PRNs that were between certain values however this would not stop the GPS machine from utilizing non-NAVSTAR. What are your thoughts? I am attempting to correct a GPS fix with higher level corrections yet this would require me to only use NAVSTAR satellites. There are other other avenues to accomplish the goal yet disabling GLONASS is the best option.

Very respectfully,

Matt

[Sean Barbeau]

Matt,

Good question!  

To my knowledge you can determine which satellites are used to produce a location fix (the "U" flag, in the far right column), but you can't restrict the location engine from using particular satellites in its position calculation.  These calculations happen at the firmware level, and there is no way to communicate this type of filtering to native code.  I believe your only option is to get a hold of a phone that doesn't have a dual GPS/GLONASS chipset - there should be plenty of these floating around on Ebay at low prices.

I'm curious as to what type of calculations you're attempting - why would you want to eliminate GLONASS satellites from the position calculation?

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.
For more options, visit https://groups.google.com/d/optout.

--

Sean J. Barbeau, Ph.D.

sjba...@gmail.com

http://www.linkedin.com/in/seanbarbeau

[Matthew Schoen]

Thanks for your thoughts, Sean. Our current project is to correct GPS positions with DGPS corrections obtained using software defined radio. The method we are using to apply these corrections would only account for NAVSTAR satellites. We have been discussing the same conclusion that you arrived at, a different phone. We also just realized that we would have to disable WAAS satellites as well; seeing as how GLONASS can't be disabled we are guessing WAAS will also be a roadblock. Our other solution is to temporarily use a false GPS sky signal to force which satellites the phone sees. Even if we could buy a phone with only GLONASS, the WAAS might become a future problem. We are currently looking into other methods to use the GLONASS and WAAS as part of our calculations.

Any input would be much appreciated!

Matt

[Sean Barbeau]

Matt,

It's been awhile since I've been directly in the loop with the implementation of location technologies on Android, but my understanding is that Android devices don't observe WAAS signals directly.  Any assistance information comes over IP, as either gpsOneXTRA or SUPL.  An extensive discussion of my understanding of Android gpsOneXTRA and SUPL is here:

https://groups.google.com/d/msg/gpstest_android/wOgMdQ0N_vU/DSSChbotJJcJ

IF a handset did directly observe WAAS satellites, in theory they should show up with PRNs 33-64:

http://www.catb.org/gpsd/NMEA.txt

I haven't yet seen any PRNs in this range on Android devices I've worked with.

You can try to isolate a handset from assistance information over IP by turning off all Internet access (i.e., put it in Airplane mode), and then doing "Clear aiding data" in GPSTest.  In theory, this should clear any assistance data on the device, and if the device supports autonomous mode, it should do a cold start fix purely off of GPS signals (if its a NAVSTAR-only chipset).

I say "in theory", as I'm not sure this works on all Android devices.  Per the documentation, the framework is supposed to return true if the command was processed, and false if it wasn't.  But, if I execute this on a LG G4, it returns true but in Logcat I see:

LgeGpsLocationProvider: SPR Framework Carrier App Extra Command : delete_aiding_data

10-20 21:42:05.104 1180-4383/? E/LgeGpsLocationProvider: invalid SPR Framework Extra Command : delete_aiding_data

So it looks like the underlying native code is rejecting the command.  However, I know this definitely worked on older Android devices.

An alternate method is to put the device in Airplane mode, and then restart it.  On some devices this would also clear the assistance data.

So, unfortunately a lot of this behavior isn't standardized across devices.  Your best best is probably to hook up a device up to Logcat and see what the log output looks like when doing the "Inject XTRA data" and "Clear aiding data" commands in GPSTest.

Let me know what you're able to find, I'm curious too as to the behavior of other devices out there.

In regards to spoofing the GPS signal, this can be difficult due to assistance data coming over IP, as well as the time reference on the device (this is also related to the "Inject time data" command in GPSTest).  In other words, any spoofed signal has to match up with these other reference data, or the device can't calculate a position.  Also, I believe you still technically need a license from the FCC to do this ;).  I think your best bet is to try and force autonomous mode on the device by deleting the assistance data.

Sean

[Sean Barbeau]

On a related note, here's a good description of the differences between autonomous, assisted, and ephemeris extension (EE) GPS fixes:

http://gpsworld.com/innovation-faster-higher-stronger/

gpsOneXTRA is an example of EE GPS fix.

Sean

[Matthew Schoen]

All the extra info is very much appreciated! We were started to assume that the difference between a wifi provider and gps provider was directly related to the cold/ hot starts but this article is extremely useful. As far as progress goes we have fixed some test data with dgps beacon data. There are a couple problems we are debating on. We're waiting on a new phone to get rid of GLONASS. We seem to be correcting to ~ 10-15 meters but are skeptical about our data. One main concern is how the altitude is calculated on the phone. We are testing our calculations in MATLAB before we transfer to the phone; upon doing this we realized that we are ~30 m above sea level in our building but the phone is reading -2 to 2 m. While we understand that GPS is inherently finicky in the Z direction, we are trying to mitigate this. Another problem is finding an exact GPS point to know if our calcs are correct. We are going to use ONUS to find an exact location and test all our data from there.

Matt

[Sean Barbeau]

Yeah, the NETWORK_PROVIDER on Android is something completely different from GPS.  It's Google Magic (TM), which produces a location based on observed WiFi hotspots and cell towers.  The device dumps this WiFi/cell data to a Google server, and the Google server responds with a location.

I've seen accuracy of altitude on Android devices be absolutely horrendous, so that doesn't surprise me.  Some newer phones are actually using barometric pressure sensors to help determine altitude - see:

http://stackoverflow.com/questions/12336463/can-be-located-which-floor-we-are-via-smart-phone-gps

It's not clear to me at this point if any firmware is fusing barometric pressue info when calculating GPS provider.

What's ONUS? :)

If it helps, we did some analysis of A-GPS positions from Java ME phones a while back - methodology is outlined in this paper:

http://bit.ly/A-GPS-Analysis

On a related note, you may want to check out another app I created called GPS Benchmark:

https://play.google.com/store/apps/details?id=com.gpsbenchmark.android

I previously assumed you had already seen this, but just in case... :)

Sean