[HD2 Android Q&A, Help & Troubleshooting and Genera] Luther Blissett:
Hello all, I've been searching the forums for a similar thread but didn't find anything, so I'm going ahead and posting my advice, hope it can be useful to HD2 fellow owners. I came into possession of an euro HD2 one month ago (my mom didn't use it, it's practically new, lucky me), installed straight away an Android ROM, Tytung's "NexusHD2-JellyBean-4.1.2-CM10 V1.3a" (at http://xdaforums.com/showthread.php?t=1930240).

Cool stuff, I was only pretty disappointed with the GPS fix times.

Then I learned about the gps.conf file, went on to open it, and was very surprised to find out that in this ROM it is very basic and short. I don't know about the situation with other ROMs and other Android versions, but the problem could possibly concern many HD2 users.

So I went for a search on XDA and on the general internet, got educated a bit on the matter, then I started experimenting and finally put together a file that's working very well for me - I'm getting cold fixes in under a minute, and warm fixes in seconds flat (all of this indoors, standing by a window). It was a long trial-and error work.

Hint: gps.conf is to be found in /system/etc directory. You'll need a rooted device to access it, and possibly to change permissions to the file to be able to modify it, I don't even remember if I did the latter :laugh:

Here's my take on the code:

#NTP_SERVER=ru.pool.ntp.org

NTP_SERVER=0.ru.pool.ntp.org

NTP_SERVER=1.ru.pool.ntp.org

NTP_SERVER=2.ru.pool.ntp.org

#NTP_SERVER=3.ru.pool.ntp.org

#NTP_SERVER=europe.pool.ntp.org

NTP_SERVER=0.europe.pool.ntp.org

NTP_SERVER=1.europe.pool.ntp.org

#NTP_SERVER=2.europe.pool.ntp.org

#NTP_SERVER=3.europe.pool.ntp.org

XTRA_SERVER_1=http://xtra1.gpsonextra.net/xtra.bin

XTRA_SERVER_2=http://xtra2.gpsonextra.net/xtra.bin

XTRA_SERVER_3=http://xtra3.gpsonextra.net/xtra.bin

DEFAULT_USER_PLANE=TRUE

DISABLE_AGPS_WHEN_ROAMING=true

REPORT_POSITION_USE_SUPL_REFLOC=1

AssistMethodType=1

AgpsUse=1

AgpsMtConf=0

AgpsMtResponseType=1

AgpsServerType=1

AgpsServerIp=3232235555

DEFAULT_SSL_ENABLE=FALSE

INTERMEDIATE_POS=1

QOS_ACCURACY=60

QOS_TIME_OUT_AGPS=120

QOS_TIME_OUT_STANDALONE=180

SUPL_HOST=supl.google.com

SUPL_PORT=7276

SUPL_SECURE_PORT=7275

SUPL_NO_SECURE_PORT=3425

CURRENT_CARRIER=common

ENABLE_WIPER=1

I'll explain a little: NTP URLs are for getting the precise time from a special server, this is necessary for the A-GPS because location is tracked by estimating the time to reception of the satellite's signal (I'm no expert but I shouldn't be much off the mark). So you want to download the time with the shortest network ping (delay) or it will not be accurate, and in order to do this you need to choose a NTP server as close to you as possible. In fact, of all the code I posted, the only part you should personalize to your needs is the lines regarding the NTP servers. I live in Russia, so I have the letters "ru" in the domains. To find the active servers closest to you, go to:

http://www.pool.ntp.org/en/

Also, I added the European servers as a backup (because they are not too far away from Russia), as some people suggest, and I verified that in some cases they get used by my device, possibly because of an excessive delay in receiving an answer from the earlier-listed addresses.

So why did I comment out some of the servers in the code? Well, looks like a failure in receiving an answer from a server can lead to a waste of time because of longish timeouts. In any case, I found out that by using only three servers from my area (and a couple from Europe, not more) I'm getting better fix times. So I left out the others but did not erase them for good, in order to stress the fact that I found a difference from those who suggest to add some eight NTP addresses or more.

So to recap, say you're from Japan, you could use:

NTP_SERVER=0.jp.pool.ntp.org

NTP_SERVER=1.jp.pool.ntp.org

NTP_SERVER=2.jp.pool.ntp.org

and immediately below (optional):

NTP_SERVER=0.asia.pool.ntp.org

NTP_SERVER=1.asia.pool.ntp.org

Then there's the Xtra servers needed to get the satellites' updated position in a format recognized by our Qualcomm chip. One size fits for all, no need to change anything here. The Agps engine relies on them, or in case of necessity falls back on the SUPL hosts (in this case, google.com).

I found out that the SUPL TLS hosts are useless for me, so I erased the following lines, that some people included and some others say are malformed:

SUPL_TLS_HOST=FQDN

SUPL_TLS_CERT=/etc/SuplRootCert

Also, the much advertised C2K host, and the following lines of code, did not work for me:

C2K_HOST=c2k.pde.com

C2K_PORT=1234

The last line,

ENABLE_WIPER=1

determines the persistence of the (AGPS?) position established by WIFI. It is not clear to me,though, if this is related to the AGPS data unloaded by WIFI, or the geographic position extrapolated by Google from a WIFI networks database (the fix you get when your WIFI is on even without GPS of AGPS). Anyway, 0 stands for inactive, as expected, and 1 for active. I believe modifying this line should not have any negative influence, make your tests.

I recommend you to:

1 - verify that you successfully saved the modified gps.conf file.

2 - reboot the phone (some say one should even turn it off, remove the battery and leave it off for minutes, in order to clean the cache) then use the app "GPS Status" to flush the Agps data and reload said data (and of course wait 1-2 min. the first time). Only then will the effects be visibile.

3 - needless to say, check that your data connection is active.

Also I recommend you not to use programs, like FasterGPS, that work by overwriting the contents of the gps.conf file, or you will have to start anew.

That's it. Please let me know how is your mileage, thanks for your attention.

March 5 edit:

The edited file described above works well until the ephemerides expire (after 2-3 hours from a cold fix). After that, fix times tend to rise, until the 6th hour from the last AGPS data download, at which point (at least on my phone) fresh data get downloaded as per GPS Status app settings (under "download GPS data at start"). My feeling is, since the script does not provide for a routine for assessing data age, and this JB ROM does not include a gpsconfig.xml file, this routine must be missing for good - so the phone tries a warm GPS start using data that are not valid anymore, thence the longer fix times (I may be totally wrong in my diagnosis, so commentaries from more tecnically savvy users are very welcome). I'm going to try and use chunks of a gpsconfig.xml from some other ROM, and see if the newly included gpsconfig.xml file gets recognized at all, to try and include a routine for discerning old from fresh data. Going to update this post further in case of progress.

March 7 note: this problem may be overcome by modifying the already mentioned option "download GPS data at start" choosing the suboption "download if data are older than one hour" under settings in the "GPS Status" app.

This solution is not very elegant from a developing standpoint, plus it involves using the network (and to have it available) more often than the normal ephemerides' expiry term, plus it forces you to use an external app, so I'm looking for a better solution anyway.

March 7 edit: slight modifications to the code. Also, erased the sentence "Important: if you use the app "GPS Status", remember to choose "weak" or "no filter" under "Sensors filter" in the settings" (as this seems to exert little influence with the use of QoS in the code).