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)
