GPS Control Plane settings.. Possible GPS fix

Control Plane is an alternative method of accessing the AGPS server from User Plane (SUPL). Control Plane goes over the cellular providers Control Plane (fancy that!) whereas SUPL goes out over the GPRS network (HSPA, 3G, etc.)

For Control Plane to work, the cellular provider has to have in place specific technology intended for use with AGPS. All older AGPS solutions prior to the deployment of SUPL use Control Plane. Basically it's "the old way"

Note that you can obtain the exact same AGPS data through a SUPL connection to the same set of servers AT&T maintains. This is the default setting for "Server FQDN Type" - AUTO Config.

Basically, setting it to AGPS Mode - Control Plane (regardless of other server settings) is the same as setting AGPS Mode - SUPL, SUPL Secure Socket - ON, Server - h-slp.mnc410.mcc310.pub.3gppnetwork.org, Server Port - 7275. AND is also the same as using "Server FQDN Type" - AUTO Config, providing your cellular provider is AT&T (MNC 410 MCC 310).

Note that the specifications for AUTO Config will read the MCC/MNC of your network provider (in my example above, AT&T) and change the mncXXX.mccYYY part to match your providers MNC/MCC. Per the 3gpp SUPL spec, when in a home network, the URL to access for SUPL services is h-slp.mncXXX.mccYYY.pub.3gppnetwork.org, which breaks down to:

h-slp - Home SUPL Location Platform
mncXXX - MNC of the current network the phone is parked on
mccYYY - MCC of the current network the phone is parked on
pub.3gppnetwork.org - A (purposefully) un-registered domain name free for use by cellular providers.

When you are roaming, the URL changes to:
v-slp.mncXXX.mccYYY.pub.3gppnetwork.org
where v-slp instead means Visiting SUPL Location Platform.

So, to sum that up, if your cellular provider is following 3gpp SUPL recommendations properly, when you attempt a SUPL connection to h-slp.mncXXX.mccYYY.pub.3gppnetwork.org, your cellular provider should connect you to THEIR provided SUPL server. In the case of AT&T this is fully functional. Note that this will NOT work on Wi-Fi, the DNS will not resolve (since you aren't connected to a cellular network, the ISP you're on will not maintain a SUPL server for you, unless they are just THAT nice)

Note that if you use a program like MarketAccess to change your MNC/MCC to allow access to other markets, the SUPL address will also change (to reflect the altered MNC/MCC) and thus be broken in automatic mode.

Anywho, all of this only affects the initial lock time, when set to MS-Based. (Defaults on the stock ROM to standalone, which doesn't use AGPS at all, and sane people will use MS-Based)

Tracking once you have a lock should NOT be affected by any of these changes.

In case you're wondering where I got my information, it's not my first go-round to this particular party. I did all the legwork for this a bit over a year ago, and put up a compendium post about it in March 2009: http://xdaforums.com/showthread.php?t=489887 All the info I reference from the SUPL specifications is obtained by spending hours reading the actual, incredibly boring whitepapers.

I haven't had time to properly devote to the GPS problem for captivate like I have for previous WM devices (I just got the cappy), but i'm guessing there's some errors in either the satellite correlation done in the baseband, or in the driver's interpretation of the output in the kernel code. It might also be the case that the phone is relying on a clock generator that isn't putting out the exact cycles they have it programmed for, thus introducing clock drift into the correlation algorithm. The clock has to be precise and synced up to the GPS clocks in order to properly trilaterate location. This might explain the drift over time and then snapping back to a real location once the clocks are properly synced again. (GPS satellites send the complete information required to sync a clock accurately every 12.5 minutes.)

Do note that the clock i'm referring to is the internal GPS reference clock, which is not related in any way to the time set on the device. Internally, the device does keep track of the offset between GPS time and Device Time, but Device Time is not used in the GPS calculations (a different internal clock is used, and synced to the satellites themselves with each transmission) - Previously it has been suggested that ensuring the phones clock is as accurate as possible would make a difference, but that is not the case (due to it not being the same clock)

Either way, any changes to gps.conf or secgps.conf aren't gonna cut the mustard with this particular issue. Initial fix time and number of initial sats, sure. But once the GPS is fired up and running, and has time to pick up a constellation update from the satellites, you're in the same boat as anyone else.

BTW. You can read the adb logcat output to easily see if your phone is utilizing AGPS. You will get an initial fix with an accuracy of appx. 1500m and the log will show that it is not a GPS fix but instead a network provided location. It will then show this location being injected into the GPS driver (AGPS)

Hi guys, did the promised side-by-side GPS test today. I didn't get a chance to capture raw NMEA this time, just used google my tracks. "Use Wireless networks" was turned off, "Use sensor aiding" off. Note that I had to turn on SUPL for the phone GPS as I was not able to get a lock at all under the stock ROM standalone configuration. Otherwise running stock. That change should only affect the lock times.

2 AT&T Captivates, similar "born on" dates, similar internal GPS performance signal-wise, etc. Both set up to JH7 + "GPS Fix" from market. I'll see if I can collect raw NMEA data tomorrow. Both GPS were set up side by side on the dashboard, as close as possible.

AT&T Captivate Track:
http://maps.google.com/maps/ms?hl=e...26965825393652.000496745b69eeef7de5f&t=h&z=14

BT338 GPS Tethered to Captivate Track:
http://maps.google.com/maps/ms?hl=e...26965825393652.00049673fd50c60e8d690&t=h&z=14

Both Tracks overlaid (anyone know how to get one track as a different color for better visibility? I know you can in g earth..)
http://maps.google.com/maps/ms?hl=e...09,-117.346945&spn=0.053451,0.065746&t=h&z=14

The BT GPS can be considered an accurate reference, most of the time it's spot on down to the lane of traffic i'm in. Note that the timestamps on the BT GPS track are off by 3 hours as it's set to eastern time and the other cappy was set to pacific (whoops!)

Looks to me like there is an overzealous interpolation algorithm at play, which tends to yield good results on a straight and narrow path with good signals, but otherwise not the best results.

Just got back from going on a ride trying to do simultaneous NMEA captures from both devices.
What a nightmare that turned out to be I only found one app that will save NMEA data free on
the market (Aspara), and it's got some horrible programming for the NMEA log buffer.. looks
like it's doing a copy/dealloc/realloc each NMEA packet to grow the buffer or something, after
a short period of time the program was entirely non responsive and I lost all that NMEA data.
:X

Also the Bluetooth GPS providers send location data directly to the LocationProvider as a Mock
Location (lat, long, alt), pulled from the NMEA strings rather than sending the NMEA strings
irectly. That means whatever Bluetooth GPS Provider app i'm using would need to support it's
own saving of the NMEA logs to SD (none of the ones I tried do)

So i'll definitely have to travel with the laptop to collect that from the BT GPS. I'll need to
find a better app to save raw NMEA data from the captivate's GPS as the Aspara app definitely
does not work well for that purpose. It does however work fine as long as you don't allow the
buffer to grow to a point that your phone implodes, and save the NMEA log to SD. I'll see if I
can get some shorter tracks to work with that. Might be easier to write my own app to capture
the raw data from the exposed char device

So, lacking the raw data for this go-round to anaylze I decided to use what I had to work with,
my eyeballs! Stuck the BT GPS on the dash and held the Captivate right next to it, monitored
the BT GPS SV SNR levels with the BT GPS app on another cappyand used GPS Test to monitor the
same levels on the first cappy. Here's what I observed after about 15 minutes of staring
intently while on the move:

Signal levels are quite similar, with the BT338 edging the captivate out across the board. The
difference isn't incredible however, the cappy is still getting more than enough signal to
perform properly. There's an average difference of perhaps 3dB. Fluctuating between 0 dB
difference and 6dB difference. On the dB scale that is a significant amount however, for each
3dB you are doubling the signal. So at a 6dB difference the BT338 is receiving 4x the amount of
signal that the captivate is. These signal levels fluctuate fast enough that judging it with
the eye isn't a good measure however, really I need to collect raw NMEA data from both devices
side by side on a trip with varying circumstances and average it out to get a good idea of the
signal differences. But my eyeball tells me "negligable"

Interestingly, the small bit of google My Tracks I did today had the Cappy GPS spot on. No
changes from when I ran the same test yesterday, except that I was tinkering with lbstestmode.

I noted previously that lbstestmode initializes the GPS with a testmode = 1 flag set, that
isn't set during normal operation. This flag may in fact alter some behavior on the GPS in a
desirable way! Need more data.

I'll go outside in clear sky view with the laptop, BT GPS, and 2 cappies later today, and see
if I can collect some NMEA data to look at. I did observe the NMEA output from the captivate is
non-standard (there are date and timestamps present in the output before the actual $GP****
NMEA data, and there are a few $P**** proprietary GPS strings that show data such as fixed or
not, and some record of Tx/Rx counts.)

So to sum this post up, interesting results, NEED MOAR DATA (especially on tracking with
test mode initialized to true)

[Edit: I'm going to start a new thread shortly just for holding raw GPS data (no anecdotal observations) and instructions how to collect that data. That way we can get a more objective look on whats happening rather than the piles of anecdotal data floating around.]