On Sun, Nov 29, 2015 at 9:59 PM, Thomas Voß <thomas.v...@canonical.com> wrote: > On Sun, Nov 29, 2015 at 6:04 AM, <ubuntu.me...@spamgourmet.com> wrote: >> On 2015-11-27 23:05 , Thomas Voß wrote: >>> On Fri, Nov 27, 2015 at 3:50 PM, <ubuntu.me...@spamgourmet.com> 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. >> > > That's good to know, thanks for the update. > >> 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. >> > > The chipset and its driver certainly cache ephimeris information. We > have test cases to force cold-starts, though. > Invoking them requires command-line access to your phone: > > > sudo ubuntu-location-serviced-cli --bus system --test > > Runs 3 trials to estimate the mean time to first fix from cold start. > (and yes: 3 is low, but a tradeoff in terms of time :)). > If you want to see what the test is doing, simply run: > > > sudo GLOG_v=200 GLOG_logtostderr=1 ubuntu-location-serviced-cli > --bus system --test > > Other than that, I think surfacing more status information to the user > via our UI would help quite a lot. >
Just executed the test (which I do for every landing): Mean time to first fix in [ms]: 219656 With the following three fixes: * Position(lat: Coordinate(51.4447 deg), lon: Coordinate(7.21089 deg), alt: Coordinate(102.6 m), hor.acc.: 7 m, ver.acc.: n/a) * Position(lat: Coordinate(51.4448 deg), lon: Coordinate(7.21105 deg), alt: Coordinate(137 m), hor.acc.: 51 m, ver.acc.: n/a) * Position(lat: Coordinate(51.4448 deg), lon: Coordinate(7.21083 deg), alt: Coordinate(105.8 m), hor.acc.: 23.6 m, ver.acc.: n/a) One remaining note: You might want to remove all ephimeris data prior to running the test. That will give you insight into when the data is downloaded (obviously, only with a data connection): * sudo rm /android/data/misc/EPO.DAT HTH, Thomas >> 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? >> > > Not required for "raw" logging. If you are happy to do some config > file editing, you can easily switch > on verbose logging by following > http://bazaar.launchpad.net/~phablet-team/location-service/15.04/view/head:/doc/debugging.md#L52. > You only need to adjust /etc/init/ubuntu-location-service.override to > gain quite some insight into what the service is doing. > > Enabling verbose logging at runtime without the need to edit > configuration files is in-flight, too: > > https://code.launchpad.net/~mardy/location-service/runtime-log-switch > > We are aiming to land for OTA-9 right now. > >> 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. >> >> > > So to clarify: The chipset *might* expose that information somehow, it > is not available to us via the chipset driver, though. > We ultimately rely on Android's GPS HAL to access the GPS subsystem > (see > http://androidxref.com/4.4.4_r1/xref/hardware/libhardware/include/hardware/gps.h). > While there is a debug hook available, it is highly vendor specific > and we do not use it (for the simple reason that we aim to keep higher > levels of the stack free of > vendor-specific code). If I could choose, I would prefer the chipset > to expose debugging information via sysfs entries @Fairphone et al. > > Cheers, > > Thomas > >> -- >> Mailing list: https://launchpad.net/~ubuntu-phone >> Post to : ubuntu-phone@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~ubuntu-phone >> More help : https://help.launchpad.net/ListHelp -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp