On 2015-11-27 23:05 , Thomas Voß wrote: > On Fri, Nov 27, 2015 at 3:50 PM, <[email protected]> wrote: >> FWIW I took care to install OTA8 and re-try before filing my bugs, and I >> haven't seen a big improvement. >> > ack, I will keep updating this thread to keep you posted. > > I take it back. I just tested by switching the phone to airplane mode and leaving it on the roof for ten minutes. When I checked back it had a fix. I guess something in OTA-8 did indeed fix it, and the last time I tried I just didn't give it enough of a chance, or perhaps I was moving too much.
I also tried the same thing last night only to discover that it got a fix within a few seconds. That seemed suspicious, I don't believe you could ever download the ephemeris so quickly, so it seemed like it had been cached from somewhere. But I'm just guessing. It really would be good if the system exposed what it knows about the current status of the ephemeris somehow so I can check. I.e. when a request was made and when it was successful. It seems like more logging in the syslog would be a good idea - record when GPS and location services are switched on and off, when ephemeris is requested by the GPS unit, log whether or not an actual network request is made, log when it succeeds, and log when a fix is established or disappears. Should I submit a bug for that? Also, so the chipset doesn't expose its own satellite ephemeris status. Do you know if that's universal with GPS chips? I don't know much about it, but I assume this means the GPS chip has its own RAM, in which case it might not be too difficult for a chip designer to provide raw RAM access if they had a reason to do so. It might be possible to encourage some phone manufacturers (e.g. Fairphone) to choose a more hacker-friendly option, if there is one. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
