[LG Optimus 2x] breeno.net:
I did some research on that thread and it looks very promising! [MENTION=3605868]tonyp[/MENTION] should be able to confirm.

Before I get into this I want to apologize to the real developers out there. I haven't coded in Java since 1999, and I've never worked on anything complicated enough to require an IDE or revision control. Please excuse me as I stumble my way through this.

I found this template for returning LTO values to a caller: CM Code Review Change-Id:	If4d194b61ded03efa646567a2134b66d92d1df5c. It is just a skeleton.

Then I tracked down a couple of platform implementations: TF300T and tuna. These appear to be complete implementations. Both are identical.

The setup is pretty simply. Four public functions: [1] isSupported(); [2] getSourceLocation(); [3] getDestinationLocation(); and [4] getDownloadInterval(). These return [1] true; [2] LTO_SCR; [3] LTO_DST; and [4] DOWNLOAD_INTERVAL_DEFAULT.

Here are the private variables:

// We use the "7 day" data file
private static final String LTO_SRC = "http://gllto.glpals.com/7day/v2/latest/lto2.dat";
private static final File LTO_DST = new File("/data/gps/lto.dat");
private static final long DOWNLOAD_INTERVAL_DEFAULT = 259200000; /* 3 days */

There is some great info to pull from this.

First, we now have a proper domain from which to pull the lto.dat file. Global Locate has a DNS pool on that subdomain, probably geolocation optimized, but even round robin would be better than the static IP "216.34.140.162". We've now got more redundancy on our lto.dat source.

Second, the replacement default is 3 days. This confirms my hunch from earlier today.

Third, the CM implementation is using a different LTO data file. I grabbed the file and tried it out. Initial testing appears to indicate faster satellite fixes. My first fix happened in seven seconds. So far, none of my subsequent fixes has been over 13 seconds. Given that the GPS satellites are 20,000KM away, this might be attributable to atmospheric conditions. Regardless, another benefit of this new lto2.dat file is that it is 52KB instead of 83KB.

The astute observer will at this point say "Great, there is a framework for returning LTO requirements to a calling function. Is there actually code to take advantage of this?". I don't know. Hopefully yes. I'm sure tonyp will be able to tell us soon.

If not, we've got [MENTION=4920940]sgspluss[/MENTION]' script to keep us going.

I've gotta step back now. I've not spent enough time on my studying! :eek:

-Breeno

---------- Post added at 08:00 PM ---------- Previous post was at 07:37 PM ----------

Here's some good reading on GPS: How GPS Works and How Accurate is GPS Time?

They're very informative articles. My takeaway: the internal time measuring mechanisms of the GPS chipset are thousands of times more accurate than NTP. GPS would be mostly useless if we only relied on NTP for clock accuracy in measuring locations using GPS.

My final, absolute, incontrovertible proof that gps.conf is useless on P990: About an hour ago I put gps.conf back in /system/etc. I did a cold boot (battery out). Turned on GPS. Loaded up GPS Status. Got my fixes. I've been checking fixes regularly over the last hour, turning the GPS off and on each time before loading GPS Status. If GPS on the P990 is utilizing the gps.conf file then the filesystem will show a recent file access. At the very least it would have to show an access from an hour ago when I cold booted.

I've just loaded the terminal: $ stat /system/etc/gps.conf

:D

The last access was yesterday afternoon, right around the last time I opened the file with a file editor. :p

That's all she wrote, boys. I've just loaded up my file explorer and deleted gps.conf right off my phone. :victory:

-Breeno