ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On Sun, Nov 29, 2015 at 6:04 AM,  <ubuntu.mexon@xxxxxxxxxxxxxxx> wrote:
> On 2015-11-27 23:05 , Thomas Voß wrote:
>> On Fri, Nov 27, 2015 at 3:50 PM,  <ubuntu.mexon@xxxxxxxxxxxxxxx> 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.

> 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@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp