[Touch Pro, Fuze General] semu5g:
Sorry - not a development issue as such but I'm hoping you guys can help with another HTC Touch Pro (A)GPS query. I have read a number of other posts on this but they appear to be inconclusive and I'm not sure if the problems widely reported elsewhere are supposed to have been resolved in the latest shipped ROMS.

I'm experiencing very long acquisition times with the internal GPS on the O2 XDA Serra (just released in the UK), to the point where the GPS is virtually unusable. Cold lock can take anywhere between 15 and 30 minutes, even in open ground in good weather with a clear view of satellites. By comparison, a Garmin eTrex Vista in the same location gets a lock in seconds. I never expected the XDA Serra to equal the performance of a dedicated handheld GPS but I would have expected it to get an initial lock in less than 5 minutes in clear sight.

If and when a lock is acquired, it seems to hold OK and I've experienced no major lag problems.

I'm using Tom Tom Navigator 5, Memory Map Pocket Navigator OS 5 and Google Maps. I've also installed a couple of GPS utilities from this forum - Chartcross GPS Test 1.04 and the HTC GPS Tool v1.1.1.0. These are all configured to point to COM4 at 38400 baud (as per advice in this forum), and I've never had a problem detecting the GPS.

What is bizarre and frustrating is that there is absolutely no mention of GPS functionality in the supplied O2 manual, other than a brief warning about not operating a GPS while driving. The XDA Serra is not supplied with any GPS software or utilities out of the box other than an "External GPS" utility in the System folder, which is completely undocumented. I'm unclear in what circumstances you are supposed to use this utility, but I'm assuming it allows you to set a hardware COM port for an external GPS device (presumably bluetooth?) and select whether or not it is managed by Windows. I've tried turning this off but it appears to make no difference.

I'm aware that the XDA Serra is AGPS capable but I'm unclear exactly what this means in this context (i.e. which particular AGPS technique it actually uses), and how - in the absence of an explicit Program or System setting - my installed GPS applications are supposed to invoke it. I have checked the relevant registry settings in HKLM\Software\HTC\SUPL AGPS:

EnableAGPS 0x00000000 (0)

GPSMode 0x00000002 (2)

Number Fixes 0x3b9ac9ff (9999999999)

QoS Accuracy 0x00000032 (50)

QoS Performance 0x00000059 (89)

Server IP 10.1.101.63

Server Port 0x00001cb6 (7275)

TimeBetweenFixes 0x00000001 (1)

... and can see that the AGPS function is currently disabled (the default), but is this supposed to be enabled programmatically by the GPS application, or do you have to set it explicitly? If the latter, how can you do this other than by hacking the registry?

I have followed advice in this forum about disabling GPS logging (it was disabled by default) using the Schapman Advanced Configuration Tool v3.3.0.0. I have tried enabling the AGPS function using a registry editor, but again it appears to make no difference. In addition, I could see no evidence of it having downloaded an emphemeris file anywhere (unless it's hidden in system ROM), which I presume is how it is supposed to work? If I enable it, doesn this necessarily mean that any of my GPS apps will actually use it?

I have tried using SeaSGEE to download emphemeris data to no avail - it downloads what looks like a good packedEmphemeris.ee file OK but it makes absolutely no difference to performance. I have since uninstalled this and deleted the //windows/packedEmphemeris.ee file.

Finally, if I connect an external bluetooth GPS adapter (the Emtac BTGPS) on COM6 I generally get a good cold lock in less than a minute. I used this all the time on my old XDA Mini S (HTC Wizard) and never had a problem.

So, basically, I'd like to understand how native AGPS works on the Touch Po, how it is supposed to be invoked by GPS applications, and whether there are any tweaks I can try to improve performance over and above the ones I've already tried. Is this a problem that is likely to be improved in subsequent ROM or Radio versions or is this simply a fundamental limitation of a crappy internal GPS chip?

Any advice greatly appreciated.