ubuntu-phone team mailing list archive

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

On Sun, Nov 29, 2015 at 9:59 PM, Thomas Voß <thomas.voss@xxxxxxxxxxxxx> wrote:
> 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.
>

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