[LG Optimus 2x] breeno.net:
tonyp: Breakdown of @sgspluss GPS Fix

Link to [MENTION=4920940]sgspluss[/MENTION] GPS Fix

tonyp: I've done a breakdown on this GPS fix. I haven't tried it yet because I like to know how things work before I go mucking about in my system.

The fix creates /system/etc/gps.conf, /system/etc/init.d/07lto-dat (shell script), and /system/bin/gps-update (shell script). None of these files currently exist on my phone.

The two shell scripts are identical. Not being steeped in Android or Linux (BSD is a little different), I don't really follow why the second script is necessary. The init.d script will get called on boot. I don't see any crontab entries created to call the gps-update script on a recurring interval. The fix only seems to do anything if you reboot. Unless the existing infrastructure that calls gps.conf also calls gps-update.

I also wonder if both the gps.conf and lto.dat updating are necessary in combination, or if only one of them is required to get useful GPS on the P990.

Given you are the expert, would it be helpful to you if I test any of this, separately or in combination, to get to the bottom of it. Or is it painfully obvious to you?

-Breeno

File Catalog, including contents:

META-INF/com/google/android/update-binary

META-INF/com/google/android/updater-script

system/bin/gps-update, contents:

#!/system/bin/sh

# Author: waydownsouth
# - Workaround for downloading long term orbit data (lto.dat)
# - for Broadcom aGPS chips such as BCM4750
# - adapted from the aries CyanogenMod device (gb branch)
# - triggered by init when init.svc.wpa_supplicant=running

lto_dat_file=/data/gps/lto.dat
lto_dat_url=http://216.34.140.162/7day/latest/lto.dat
max_age_days=5
net_retry_count=30
net_retry_delay=10

if [ ! -e $lto_dat_file -o ! -z "$(find $lto_dat_file -mtime +$max_age_days)" ]; then
echo "LTO data not found or > $max_age_days days old - attempting update"
for i in $(seq $net_retry_count); do
echo "checking connectivity"
if [ $(cat /proc/net/route | wc -l) -le 1 ]; then
echo "no network - waiting for route"
sleep $net_retry_delay
else
wget -O $lto_dat_file $lto_dat_url
[ $? -ne 0 ] && break
chmod 664 $lto_dat_file
echo "LTO data successfully updated"
exit 0
fi
done
echo "LTO data update failed"
exit 1
fi
echo "LTO data < $max_age_days days old - skipping update"

NOTE: The above IP address "216.34.140.162" is owned by Broadcom. They appear to update the lto.dat file on a daily basis. Why the script updates every five days is beyond me. Why not every day? It shouldn't have that much more of an impact on Broadcom's server.

system/etc/gps.conf, contents:

##################################################
### NTP IS NETWORK TIME PROTOCOL AND PROVIDES ###
### A TIME-HACK TO DEVICES THAT HAVE SYNCING ###
### MADE READLIY POSSIBLE. MANY XDA PATCHES ###
### MISINTERPRET WHAT NTP IS AND IMPORTANCE. ###
### NTP PACKETS HAVE BUILT-IN MECHANISMS FOR ###
### TRANSMISSION LOSS. NTP PACKETS ARE VERY ###
### SMALL. LASTLY, NTP MATTERS FOR PARSING ###
### THE XTRA.BIN. BUT, IT ONLY MATTERS WHEN ###
### YOUR DEVICE HAS ITS TIME EXTREMELY OFFSET ###
### COMPARED TO REALITY. THUS, I BUILD THIS ###
### PATCH FOR WORLDWIDE OPERATION. RARELY ###
### WOULD LOCAL NTP SERVERS BE REQUIRED. ###
##################################################

NTP_SERVER=ntp.derekgordon.com

###

##################################################
### AGPS AND XTRA TELL THE AGPS DAEMON WHERE ###
### IT MAY LOCATE THE AGPS DATA. THE DATA ###
### OPERATES AS AN ALMANAC WITH THE LOCATION ###
### OF GPS SATS STORED WITHIN IT. THIS DATA ###
### IS ONLY VALID FOR 24 HOURS. IT WILL BE ###
### DOWNLOADED AND CACHED. IT IS NO LONGER ###
### KEPT IN THE /DATA/ PARTITION PERMANTENTLY. ###
### THERE IS NO POINT TO KEEP IT THERE! ###
##################################################
### MY SERVER PROCESSES THE XTRA.BIN EVERY 30 ###
### MINUTES. TYPICALLY IT UPDATES EVERY HOUR ###
### WHEN NEW DATA IS AVAILABLE. ###
### SHOULD MY SERVER BECOME OVERLOADED, I WILL ###
### NEED DONATIONS TO KEEP THIS SUCKER STORED ###
### AT MORE LOCATIONS. ###
##################################################

AGPS=http://derekgordon.com/gps-files/bin/xtra.bin
XTRA_SERVER_1=http://derekgordon.com/gps-files/bin/xtra.bin
XTRA_SERVER_2=http://xtra3.gpsonextra.net/xtra.bin
XTRA_SERVER_3=http://xtra2.gpsonextra.net/xtra.bin

###

##################################################
### NOT GOING TO GO INTO DETAIL HERE. THESE ###
### NEED TO BE CALLED FIRST IN GPS DAEMON ###
### STARTUP. RELATES TO AGPS AND SUPL. ###
##################################################

DEFAULT_AGPS_ENABLE=TRUE
DEFAULT_USER_PLANE=TRUE
DEFAULT_SSL_ENABLE=FALSE

###

##################################################
### INTERMEDIATEPOS RELATES TO USING GPS DATA ###
### FROM SATS THAT ARE NOT FULLY LOCKED. ###
### THE ACCURACY VARIABLE IS A THRESHOLD MAX ###
### ON DEVIATIONS FROM THE ASSUMED LOCATION ###
### WHERE THE DEVICE WILL DISCARD DATA. ###
### THIS VARIABLE IS =0 IN ALTERNATE BUILDS ###
##################################################

INTERMEDIATE_POS=1
ACCURACY_THRES=3000

###

##################################################
### THIS IS QUALITY OF SERVICE INFORMATION FOR ###
### PROCESSING THE GPS DATA. MOST SHOULD BE ###
### SELF-EXPLANATORY. GPS DATA OUTSIDE THE ###
### ACCURACY AND THRESHOLD RANGE WILL NOT BE ###
### USED WHEN POSITIONING DATA. ###
##################################################

QOS_ACCURACY=50
QOS_TIME_OUT_AGPS=95
QOS_TIME_OUT_STANDALONE=80
QosHorizontalThreshold=1000
QosVerticalThreshold=500

###

##################################################
### THESE VARIABLES RELATE TO AGPS. IT SAYS TO ###
### USE AGPS. THIS WILL NOT BE USED IF YOUR ###
### ROM HAS AGPS DISABLED IN THE CODE. ###
### THE SERVER IP IS FOR AN INTERNAL IP FOR ###
### ACCESSING THE AGPS DAEMONS DATA WHEN IT ###
### IS OPERATIONAL. ###
##################################################

AssistMethodType=1
AgpsUse=1
AgpsServerType=1
AgpsServerIp=3232235555
AgpsMtConf=0
AgpsMtResponseType=1

###

##################################################
### THIS SUPL DATA IS TO MATCH THE SUPLROOTCERT ##
### IF IT IS REQUIRED BY THE SUPL SERVER. ###
##################################################

SUPL_HOST=supl.google.com
SUPL_PORT=7276
#SUPL_SECURE_PORT=7275
SUPL_NO_SECURE_PORT=3425
#SUPL_TLS_HOST=FQDN
#SUPL_TLS_CERT=/etc/SuplRootCert
REPORT_POSITION_USE_SUPL_REFLOC=1

###

####################################################
### Carrier tags used univesrally in GPS configs ###
####################################################

CURRENT_CARRIER=common
PHONE_TYPE=UMTS

###

The author of gps.conf has used his own private server resources for NTP and the primary xtra.bin server (Qualcomm owns gpsonextra.net, so the #2 and #3 are probably fine). This is obviously a problem if he can't handle future capacity or simply moves on, which means to me that this is not an ideal fix. I suspect it would make more sense to source from ntp.org for NTP and LG for the xtra.bin.

The domain "derekgordon.com" appears to be owned by the author, and I found this particular page at the domain: A-GPS Worldwide Patch. It links to a number of GPS fix zips here on XDA. I checked the zips for a couple of phones and each consists of just this exact gps.conf file. One also has the /etc/SuplRootCert file, while the other did not.

system/etc/init.d/07lto-dat, contents identical to "system/bin/gps-update".