[FormerPalmOS]

Some general commentary, theory and observations that may help others understand used sats vs. locked sats, etc. But first, one comment. If your GPS tool or viewer or whatever shows used sats, then bored's fix was installed correctly and is working. If the fix failed, you would see zero used sats forever.

1st, how GPS works - the simple version. A number of DoD-launched sattelites orbit the earth. These sats broadcast a "tone" and a time synchronization signal, plus some data (see below). Each sat broadcasts at a different frequency and due to very low signal to noise ratio, the signal takes some effort to find. The receiver can "work" on a finite number of signals at one time.

Once the GPS receiver has locked onto a sat, it uses an algorithm to calculate HOW FAR AWAY it is from that sat. This information creates a sphere with a radius equal to the distance from the sat. Provided you know where the center of the sphere (the sat) is located, your actual position is somewhere on the surface of that sphere. You need multiple such spheres so that intersections can be calculated. Also, this radious calculation is not precise - it has error of up to 30-40 feet due to atmospheric and other conditions which interfere with the received sat signal. And this error is variable - meaning even if you and the sat are stationary, the raduis of the calculated sphere still changes.

Now, you can only calculate the intersection of multiple spheres if you know WHERE the center of each sphere (the sat) is in addition to the radius. Now this part would be easy if the sats never moved, but they do move. They are NOT in geosynchronous orbit - they are in a medium earth orbit and move faster than the earth moves. A data file called an almanac contains the coarse positions of all of the sats. Each sat broadcasts this almanac and it contains the next three days' worth of position information. In addition, each individual sat broadcasts its own exact location. This is called the ephemeris. In general, if the receiver has the ephemeris information for a sat it will be able to find and lock onto that sat again quickly for the next two to four hours.

If your receiver has zero information, it first has to listen for any sat. When it finds one it first waits to download the almanac (which covers all sats) and the ephemeris for the particular sat it found first. Downloading the almanac can take up to five minutes. Once the almanac is loaded, the receiver knows what sats should be overhead based on the location of the one it started with. It then proceeds to focus its search for other sats that should be overhead and attempts to lock. The lock process involves an algorithm whereby the chip decides that it has calculated a "good enough" distance from itself to a particular sat. It then listens for the ephemeris information from each locked sat.

For each locked sat, the receiver has ephemeris (location) data and a distance (radius). From this a sphere is calculated in three dimensional space. The intersection of two spheres creates an ellipse of possible locations. The intersection of three creates two points. The intersection of four spheres creates exactly one point. That point is your location in two dimensions. The accuracy of that fix is a function of the cumulative error in all of the signals.

It is safe to assume that you are standing on the planet earth (a sphere iself) so the earth can be the fourth sphere. Thus with only three sats, you may be able to get a two dimensional fix but not necessarily a good altitude. You need a minimum of four locked sats to get a good fix in all three dimensions. Additional sats serve to reduce the error in the fix.

So, now you know why it can take a long time to lock with no assistance. Two types of assistance are available which can significantly speed up the lock time. First, if the receiver saves sat lock data, ephemeris and almanac (recall the almanac is good for the next three days), then when it is powered back on, it can check how long it has been off and decide to try the same sats again. If it has only been off for a few minutes or an hour, chances are that some or all of the same sats will be available and you will get a lock time of around 5 seconds. (assuming the receiver hasn't moved). I believe the EnableGPSSmartMode registry setting (see below) makes this happen.

If the receiver has moved or if it has been off for more than a few hours, then the almanac data is still valid but it must re-seek at least one sat to get new ephemeris information to query the almanac to know what other sats to seek. Then the seek/lock process starts again. This phase will typically take from 15 - 45 seconds (assuming you have good signal strength - i.e. you aren't indoors). The time will depend on how long the receiver has been off, how much it has moved while off, and the signal strength.

If the receiver has been off for more than three days or its memory has been cleared, it will have to download all new almanac data and you are looking at 5 minutes. This is where the second type of assistance comes in.

AGPS serves three purposes. First, it can give your receiver the latest almanac in a few seconds (over EVDO). Second, it can give you reasonably decent position information (cell tower triangulation) with which the GPS receiver can speed the seek/lock process. Third, it can refine the accuracy of the position fix by combining cell tower data, sat ephemeris information and the sat distance measurement from the phone. This information can be relayed to the network and the network can relay back a fix.

The various modes of AGPS and the GPSOne chipset are:

Stand-alone - no AGPS, only the phone's GPS radio. Accurate, but slow, especially if the almanac has to be downloaded. I believe this corresponds to GPSMode=1 in the GPSOne chipset.

Mobile-station based - If a network connection is available and a PDE (Position Determination Entity) server is available, the mobile station (your phone) will download the almanac if needed, and request a rough position calculation from the cell network. This really only needs to happen to get a lock and the GPS chip can operate without assistance from that point forward. I believe this corresponds to GPSMode=2.

Mobile-station assisted - Like above, but instead of using the cell network only for the initial fix, it uses it constantly for a more accurate fix. This would probably drain the battery faster due to the always-open data connection, but if you are using Google Maps or Live, you would have an always-open connection anyway. I think this is GPSMode=3.

Hybrid - Like above, but best I can tell it uses a different transport mechanism. I believe this corresponds to GPSMode=4.

I speculate that mode 2 is the most optimal. All modes should fall back to stand-alone if the cellular radio is off or data is not available.

Now some more general thoughts / comments.

1) There are some references to a program called QuickGPS which downloads almanac data and saves it to a .bin file in the Windows directory. However I am not convinced that the GPS driver in the HTC Touch Pro uses this file (I have no such file), so I am not convinced QuickGPS does anything with this particular phone. But the theory is sound.

2) It is possible to get a 5 second lock indoors without AGPS. If you have already had a lock within the last hour or so, and your receiver hasn't moved, then you will probably see enough signal strength from the same sats to get a fast lock. So this is "assisted" but not using the carrier's PDE. Get a lock indoors, turn off your cell radio then try again to get a lock. You will see.

3) I can ping Verizon's PDE server IP address from outside their network. I don't however have anyway to verify that the server works or responds to PDE queries from outside the Verizon network.

3) Some thoughts (theory - not confirmed) on what the HKLM\Software\HTC\SUPL AGPS registry keys do:
EnableAGPS - self-explanatory
EnableGPSSmartMode - If set, saves ephemeris data in your device. I believe it also would cause more communication with the PDE server but I have no way to check. Setting this to one should result in fast locks when your device doesn't move while powered down. Seting this to zero may decrease lock time when your device HAS moved while powered down.
EnablePDEIPFromNV - if set, I believe this instructs the GPS driver to retrieve the PDE server information (IP address and port) from NV - what you entered in QPST - instead of using what is in the registry. If not set, it uses what is in the registry. I have no way to verify this - just conjecture. But if I am correct, you would not need to set the Server IP or port in the registry. And, if the carrier changed the IP address, they can push the new data to your phone's NV - they can't do the same to change your registry.
EnableReAiding - seems to improve lock time if this is set to 1? I don't really know what this key does though.
GPSMode - sets the mode of operation (see above)
NumberFixes - no idea here
QoSAccuracy - from 0 - 255 (decimal), determines how hard the receiver works to get an accurate distance calculation for each sat. Higher number should give a more accurate fix but will likely result in longer lock times, and may impose a ceiling on how frequently you can request a position update (harder = more calculations = takes longer).
QoSPerformance - no idea here
ServerIP - IP address of the carrier's or a publicly-available PDE server
ServerPort - TCP Port on which the PDE application is listening
TimeBetweenFixes - frequency the position is updated, expressed as the updated period in ms (thus a decimal value of 1000 means get a new fix every one second). I'm sure there is a floor here - the receiver takes a finite amount of time to calculate a position - so setting this to a really low value will at some point have no effect. I don't see much value in less than 500 ms for driving, 2000 ms for walking.

4) In QPST programming, one of the options is for position calculation. The options are for mobile-calculated or PDE calculated. If you set this for mobile calculated, you may see less lag. Again, I am assuming this would be the case - it's a balance of network lag vs. computational power in your phone without the benefit of cell tower triangulation data. But if you have no network connection, your radio is off, or AGPS isn't working for some other reason your mobile device is calculating the position anyway, so this setting may not matter.

5) Finally, for those of you who think you have working AGPS (i.e. are actually communicating with the Verizon PDE at the above IP address), is there a way to verify this? Using Bored's phase 2 fix, I get good lock, but have no evidence to suggest there is any AGPS communication going on (for example, I can put my firewall IP address in and I will never see an unsolicited attempt by my phone to contact my firewall). I assume Bored knows why AGPS doesn't work with his modified PRI and is addressing it in phase 3.

Looking forward to bored's solution for AGPS...