ubuntu-phone team mailing list archive

[ubuntu.mexon@xxxxxxxxxxxxxxx]

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.

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.