6/8/09 FIRMWARE UPDATE: Verizon GPS Unlocked

[dimitri]

Originally Posted by stretchs

Even since I've applied these changes my on screen keyboard has switched to compact QWERTY. Even when I attempt to change it back to full QWERTY the change isn't saved. Has anyone else experienced this? I like others am still having an issue getting a GPS lock. So far I've only been able to do this once.

The fix shouldn't have anything to do with your keyboard. Did you install anything else?

[stretchs]

Originally Posted by dimitri

The fix shouldn't have anything to do with your keyboard. Did you install anything else?

Other than the items listed in the original post I've also installed Google Maps and MS Live Search

[lllboredlll]

The fix only affects the radio programing. The only thing affected in windows mobile would be the fact you installed a cab and a minor reg edit. There is no elements of this fix that become a part of WM other than the reg key that setups for future AGPS.

[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...

[chuckz07]

Former...Well written, I learned something.

Prior to reading this I just got off the phone with Verizon (I had a trouble ticket and they actually called back). Anyway, during the conversation I asked since BB had unlocked GPS when would the TP get it...Reply "NEVER...because the TP isn't strong enough to carry or hold the signal". They informed me that VZNav is not 'TRUE' GPS that it calculates by towers and will not truly work without assistance if you get into an 'Extended Network'. But the fact of matter that the TP will never be able to be used with anything other than VZNav, will never change. And of course it was discretely put that VZW wants that extra $10 a month. Oh yes, and all this being told to me as I was staring at my phone with GPSTool running and seeing 8-9 satelites.

CONGRATS BORED...

[lllboredlll]

Originally Posted by 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...

ya what he said

[dimitri]

When it comes to GPS and the Quick GPS program, if you have everything downloaded from Quick GPS and you set your Baud Rate to 57600 in the HTC GPS Tool you will get a faster lock and with more sats. Then when using Google Maps set it to Manual and use Com 4 and a Baud Rate of 57600. I have tested this all day. Before today, it would take me anywhere from 30 seconds to 2 1/2 minutes to get a lock and I would lock with 5 to 7 sats. With Quick GPS I am getting locks in less then 15 seconds and locking up to 11 sats.

[lllboredlll]

interesting

[lbjohnny]

Originally Posted by lbjohnny

Until aGPS is figured out I tried this: GPS TODAY http://www.geoterrestrial.com/

It basically keeps turning on GPS @ user set time intervals - keeping it alive. I have it set from 6am to 11pm. When I woke up this morning I had sats locked in about 15 seconds. Usually after a long time out from GPS it takes lots of minutes to re-acquire a signal.

I haven't fully tested the battery drain but this DOES work well FWIW.....

I'm tellin' you guys - try this - it really works. I have fast connections all day -.....I set to receive/instantiate GPS once an hour. And it's FREE....

[PCCGeek300]

My info: Verizon Wireless HTC Touch Pro just purchased and activated tonight. First experience with HTC, upgraded from Treo 700wx...

I followed every instruction step by step in the original post. The only installed programs I have are Google Maps and HTC GPS Tool 1.2.2.11. I have all the settings the way the first post said to have them, but it still won't find any satellites in either HTC GPS Tool or Google Maps. What could I be doing wrong? My PRI version in the phone is showing 1.46_002 and PRL is 51143