Comment 1 Andre Klapper 2008-11-11 15:06:34 UTC

CC'ing Marko as I don't have an idea how to successfully debug this.
Help appreciated.

For me, I don't "Always" get this, but 10-30% of the time with AGPS working
"properly".  8 or so bars - most of the time under clear sky conditions a lock
in 15 seconds.  Other times, only the first few are large and take minutes to
lock if at all.

However I've noticed that it sometimes (on the -11 beta) says the data is
stale, and I can confirm that with "ls -l /var/lib/supld".  The tablet has been
in range of an internet AP the whole time and never specifically disconnected.

supld seems to not be able to wake the wifi connection properly or there is a
race condition with gpsd/gpsdriver where the update won't be downloaded in time
(and ignored).

I normally keep my tablet in a power saving mode, so the wifi will be shut off
after a period of inactivity (I see this with an SSL session or anything that
doesn't continually use the WIFI like x11vnc).  When it is powered down, it can
take several seconds to reestablish communications.  Sometimes it doesn't seem
to work in that the agps data will not be updated (though browsing a web page a
few seconds later does).

I'll repeat my request for a "pull now" button in the AGPS program - if the
data is stale (or not since it can only update near a connection).

Whatever in the GPS system doesn't seem to want to wait that long, and I will
get 3 bars.

Well, in my case this happens with non-stale AGPS data.

In fact, when I start with stale AGPS info, I can see how first there a are no
bars, then after a little time AGPS does it job and and see lots (around 10) of
satellites but most of them with no bar above them, that is 0SNR.

That is why I think AGPS info is not helping me...

After it updates (you see the multiple bars instead of the three) try shutting
down and restarting the GPS - untic Enable GPS, wait 5 seconds, and retic it
and see how long it takes to come up.

I've found if the GPS chip takes more than a minute to get a lock, AGPS won't
help, at least not until it is shut-down and restarted.

Comment 5 Quim Gil 2008-11-17 08:58:22 UTC

Setting priority to high since any progress done understanding issues with the
AGPS will help improving the location user experience and figuring out whether
there are specific issues related to the pre-installed location software - see
Bug 2878

*** This bug has been confirmed by popular vote. ***

In response to comment #4.

My problem is not that it takes too long to take the fix. In fact, in good
conditions I'm able to get it in one or two minutes.

My report is that it always takes this time, no matter if I use AGPS or not.

When not in use, even after a week of non-GPS usage, I see two-three bars
almost from the start that soon increase to four-five. After a minute or so in
this conditions I get a lock.

When I use AGPS the situation is similar. Once AGPS kicks in I see lots of
bars, but most of them with no signal, and between three or four bars that do
have signal. That is, the same situation as without AGPS, I only get a few bars
with signal. After a minute or so the GPS finally gets a lock.

In both cases, after the lock is established I get around ten bars with strong
signal, although usually there are no more that 6-7 in blue.

So, my question is. With AGPS activated shouldn't I see most bars with strong
signal even before the GPS gets a lock?

Comment 8 Neil MacLeod 2008-11-21 17:42:49 UTC

(In reply to comment #7)
> So, my question is. With AGPS activated shouldn't I see most bars with strong
> signal even before the GPS gets a lock?

That does seem a reasonable question, and worthy of a good explanation as I
suspect what you are seeing is what a lot of others are seeing ie. lots of
empty bars despite most of the satellites being in clear view and easily
visible to other GPS devices.

Try (with the GPS off) manually removing the /var/lib/gps/nvd_data
file (use the xterm, then type "rm /var/lib/gps/nvd_data", then verify
the AGPS data is good (the current applet will say if the cache data
is valid), and then try starting it up under a clear sky and see if it
still takes a long time.

Normally at least 5 bars will be over half the height within a few
seconds of starting the GPS when I'm doing this and it gets a fix in
15-30 seconds at most.

I suspect something in nvd_data is getting corrupted or miscalibrated
and causing the chip not to tune into the satellites properly.

This is a question but might be a new and different bug report -

Does supld run every 30 minutes (turning on the wlan to grab data)?  Even when
there has been no user input and gpsd is not running (I've noticed my battery
dying overnight recently, and I generally have everything turned off but
remembered this - which according to my logs does run every 30 minutes).

What affect does this have on the battery life if it is never really idle and
the Wlan has to be on for several minutes every hour?

In response to comment #9.

I finally found some time to try removing nvd_data with AGPS info, and I must
say that results are *entirely satisfactory*.

I must confess I was skeptical about it, because my n810 gets a lock usually
under 2 minutes on the open air, even without AGPS, so I doubted very much that
nvd_data was corrupt.

The results: after removing nvd_data and always in clear sky I'm able to get
locks in 25-30 seconds. Also I immediately can see strong signal from at least
6 or 7 satellites, and not just 3-4 like before.

So, there must be some /interesting/ interaction going on between AGPS and
nvd_data.

May I suggest changing the summary to "AGPS not helping with stale nvd_data"
and automatically removing/ignoring nvd_data when switching the GPS on if the
AGPS info is recent enough as a fix?

HTH.

My original suggestion which bounced, but is part of the context:

Try (with the GPS off) manually removing the /var/lib/gps/nvd_data
file (use the xterm, then type "rm /var/lib/gps/nvd_data", then verify
the AGPS data is good (the current applet will say if the cache data
is valid), and then try starting it up under a clear sky and see if it
still takes a long time.

Normally at least 5 bars will be over half the height within a few
seconds of starting the GPS when I'm doing this and it gets a fix in
15-30 seconds at most.

I suspect something in nvd_data is getting corrupted or miscalibrated
and causing the chip not to tune into the satellites properly.

It isn't just that the nvd_data is stale, there is something invalid that
poisons whatever the AGPS is trying to do.  Sometimes I can't get any lock - 10
bars, at least 8 should be green, four well above lock territory, but no lock. 
Sometimes it is just very slow.  Sometimes it works perfectly.

Good AGPS + NO nvd_data = fast locks.
Good AGPS + valid nvd_data = fast locks.
Good AGPS + broken nvd_data = slow or no locks
no (stale) AGPS + valid nvd_data = slow locks (maybe fast if within a few
minutes)
no AGPS + broken nvd_data = no locks.

Comment 14 Neil MacLeod 2008-11-26 01:32:28 UTC

I can confirm that deleting nvd_data (I also killed supld for good measure) got
me a lock in under 20-30 seconds, inside, with AGPS over a WiFi (rather than
cellular) connection - ie. less than ideal conditions.

Before deleting nvd_data I very rarely got a lock even in ideal conditions
(outside, clear skies, cellular connection)!

This is great news...

Comment 15 Neil MacLeod 2008-12-17 23:00:24 UTC

Quim - have Nokia confirmed the issues we are seeing with apparently corrupt
/var/lib/gps/nvd_data? I note this bug isn't assigned to anyone or been given
an internal bug reference, so suspect not.

This bug has gone awful quiet despite an apparent cause being found for the
poor GPS performance.

Comment 16 Quim Gil 2008-12-18 14:23:23 UTC

(In reply to comment #15)
> Quim - have Nokia confirmed the issues we are seeing with apparently corrupt
> /var/lib/gps/nvd_data? I note this bug isn't assigned to anyone or been given
> an internal bug reference, so suspect not.
> This bug has gone awful quiet despite an apparent cause being found for the
> poor GPS performance. 

Marko is in the CC of this report and he is in the Location team. Perhaps he
can comment?

Created an attachment (id=1082) [details]
Scatterplot of TTF with stale nvd_data

I tried to model the effect of a large delay between GPS usage by replacing
nvd_data with a valid file obtained some months previous. For this test, the
tablet had a WiFi connection and the AGPS daemon
supllistenerd was running. The estimated location was set correctly in the
agps-gui.

The script was essentially
{
  turn on gps
  get fix
  turn off gps
  replace nvd_data
  sleep rand(10)
}

This data was collected Dec 6th 2008, before the recent OS update was applied.
The data shows quite long TTF as if AGPS was not operating. I would have
expected AGPS data to override out-of-date nvd_data to give fix times of 20
seconds
See ttf-scatter.gif attachment in 
https://bugs.maemo.org/show_bug.cgi?id=2878 - data collected at same geographic
location without AGPS and with nvd_data preserved

The large delay generally won't demonstrate the problem if the nvd_data file
was actually valid and saved when it was tuned (and it might just be recognized
as stale and treated as a deleted file would be).

What I've noticed is that if everything is "working" and you stop the GPS, it
will restart and fix rapidly, faster with AGPS.

If you start the GPS indoors and let it run a while (15-20 minutes without a
signal), then stop the GPS, even with AGPS (valid cache), if you then go
outside under a clear sky and start the GPS it may not lock in for several
minutes, however if you delete the nvd_data and have AGPS it will usually lock
in under 30 seconds.

When it doesn't have a good signal for a while (maybe having not locked since
startup), it seems to get detuned to any GPS signal and REMEMBERS it in the
nvd_data file if it is saved.

I think I also noticed if you let it run inside for a while and it can't lock
(even with AGPS) and just walk outside to an unobstructed view of the
satellites, it won't get a lock though the signal bars will be more than high
enough.

Perhaps I should try to save one of these broken nvd_data files, and then
delete it and get it to relock and compare the new nvd_data to the old.

Comment 19 Neil MacLeod 2009-01-07 14:27:07 UTC

(In reply to comment #16)
> Marko is in the CC of this report and he is in the Location team. Perhaps he
> can comment?

Marko?

Comment 20 Marko Nykanen 2009-01-07 14:42:42 UTC

(In reply to comment #19)
> 
> Marko?
> 

Sorry about the delay. 

If deleting the nvd_data helps to this problem, it seems to me that there is
some bug in the gpsdriver.

Comment 21 Neil MacLeod 2009-01-07 15:34:17 UTC

(In reply to comment #20)
> (In reply to comment #19)
> > 
> > Marko?
> > 
> Sorry about the delay. 
> If deleting the nvd_data helps to this problem, it seems to me that there is
> some bug in the gpsdriver.

Do you need examples of "corrupt" nvd_data files to help track down the issue?
I'm not sure I have any at the moment, others might be able to attach examples
before I can come up with one.

It might not be the gpsdriver program as such.

It could also be the GPS chip, or perhaps not using the save/restore for the
chip quite right.

Saving it ONLY when the GPS has or just had a lock might help (stale nvd_data
files during locks I think work better than fresher ones that have gone several
minutes without a lock before saving).

I should try it - I have two n810s so I can run both at the same time with
different nvd_data files, one saved after a while without a lock and one with,
and next to each other with the same view of the sky.

Comment 23 Andre Klapper 2009-03-18 07:00:14 UTC

Marko, would corrupt nvd_data files help here to track this down?

tz, did you try this with two N810s?

I haven't done a conclusive experiment, but the nvd_data files do control the
speed of the locks.  I was able to take a good one from one tablet and the
second which was having lots of problems locked right in.  I now need to try
the reverse (but I need a consistently bad file).

It wasn't perfectly conclusive since it did lock under an open sky after 5
minutes, but putting a bad nvd_data file from one tablet did seem to cause
problems with locking on the second tablet.

I'll try to get a more conclusive result, but sometimes it is hard to get it
very far out of sync.

Comment 26 Quim Gil 2009-04-13 22:42:35 UTC

GPS fixes are obtained pretty fast using Fremantle and compatible hardware
under clear sky or indoors, and A-GPS helps. Tested several times and under
different circumstances without issues.

Resolving this one as Fixed in Fremantle, since the development of A-GPS for
Diablo has been discontinued. The reason for this are the deep changes in the
hardware architecture around the GPS and the location libraries. The inclusion
of cellular data connectivity is a game changer for A-GPS and we are
concentrating all the location resources available in the Maemo 5 project.

Wow.

Based on the information in this bug, I tried an experiment.  I copied the gps
daemon to another name, and then replaced the original with
the archetypal "very small shell script".  The script simply removes the
/var/lib/gps/nvd_data file and then launched the (renamed) daemon with the
full set of command-line options that the script was passed.

I've gotten fast locks every time I've started up Maemo Mapper - faster
and more reliably than in the past.  I have yet to see a single slow- or
no-lock attempt, even indoors.

This is with AGPS, and (I think) current AGPS data in all cases.

I may try removing AGPS and its data, and see what effect this has on the
lock speed.

There definitely seems to be something amiss in the driver's attempt to use
the saved GPS information... it's pessimizing the location-lock process rather
than optimizing it :-(.  The GPS chip in the N810 may not really deserve the
lukewarm reputation it has developed.

Depending on how long it's going to be until Fremantle ships, I wonder whether
the kind developers might be willing to push a minor tweak to the Diablo
code base which would turn off the use of the nvd_data file?  N810 owners
would probably appreciate it!