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

Look for osso-gpsd in the source tree - it is there, but under O, not G.

That said, the /sbin/gpsdriver is the glue between the TI chip and the NMEA
stream and appears to be closed source.  Apparently a GPIO bit turns the TI
chip on and off (I don't know which one), and data appears on /dev/ttyS0 or
/dev/ttyS1 with an unidentified stream.

I have no information on the TI chip itself.  It probably could save and
restore time and location or other information to make acquisition MUCH faster.

Although I doubt sensitivity could be improved (it also does not appear to be a
problem) since you can't fit a big strip antenna, if you can preload the chip
with a quick guess location and time gps chips normally lock on in seconds, not
minutes.

Comment 3 Simon Pickering 2008-02-03 12:18:51 UTC

> if you can preload the chip with a quick guess location and time gps chips
> normally lock on in seconds, not minutes.

If you give the chip a rough location it helps with its initial calculations.
It may also be possible to pass on almanac data (as this is valid for a long
period). 
AGPS would allow us to feed it up-to-date almanac and/or ephemeris data for a
know position.

Note that there are some files under /var/lib/gps/ which are related to the
GPS:
One of these is called nvd_data, the other is called gps_last_saved_report.
When run from the xterm, the gpsdriver talks about reading in customer conf
data and location data. After running the GPS and getting a lock the contents
of these two files change.

So, it would be nice to know what the files contain, and the formats. I note
that although it's ~14000bytes in size, the gps_last_saved_report contains lots
of 0x00, does this indicate that the file is not fully utilised (e.g. for
saving almanac/ephemeris data)?

Can we have some more details please?

Comment 4 Philippe De Swert 2008-02-04 16:50:03 UTC

check bug #2877 for a possible fix. Confirming that the fix posted there helps
might push Nokia to release that fix in a later update.

tz writes "I have no information on the TI chip itself"

See focus.ti.com/pdfs/wtbu/ti_navilink_4_gps5300.pdf
Just a 2-page product bulletin, which says "..enables a rapid TTFF from weak
satellite signals exceeding the A-GPS requirements for 3GPP..".
The part (and I presume proper documentation) is only available to industrial
customers that want millions of the things.
Since the idea is to meet the E911 requirements (in the US) to send a position
with emergency calls from a cellphone, I presume it is supposed to get a fix in 
a few seconds with AGPS (AFAIK, a rough fix from the cell tower.

Comparison with my Garmin GPSMap76 (7 year old design, internal antenna):
N810   GPSMAP76
176sec 48sec (first fix in several days, as per Garmin spec.)
126sec 35sec (first fix in 2 days)
33sec  16sec (2 minutes later)
30sec  13sec (2 minutes later)

The N810 can keep a fix from a weaker signal than the Garmin, e.g. indoors,
once it's got it.

It appears that the GPS state is saved in /var/lib/gps/nvd_data.
A note in gpsinternal.h says "this might speed up the location fixes"

I did some tests starting and stopping the GPS.

If the file is present, the GPS can reacquire a fix in about 22 seconds
after a short period turned off.
If the file is deleted, it takes 180 seconds.
If the tablet clock is changed by about an hour, it takes about 80 seconds
to get a fix. Then 22 seconds to get a second fix with the clock still wrong.
When I changed the tablet clock by 40 days, it took 344 seconds one time
and 160 another (with satellites moving around, the fix times naturally vary
somewhat)

This suggests that having the clock a bit wrong is not a big deal. However,
having it a lot wrong has a more significant effect. 
It is possible that having a significantly stale nvd_data is worse than
not having one at all.

It would seem plausible that one could update nvd_data with an estimated
position in order to get a better TTFF

Re-setting the assignee, since Carlos moved on to other tasks.

Please note that this does not affect the legitimacy of the bug in any way.
It's a purely administrative operation. Sorry for the noise.

Looks like there will be a "agps-ui" package in the next ITOS release (Diablo,
or Maemo 4.1) that fixes the slow-fix problem, possibly using agps and wifi to
download satellite positions/availability.
http://www.internettablettalk.com/forums/showpost.php?p=186839&postcount=641
for a screenshot, and that page of the thread also has some details on it.

Comment 9 Andre Klapper 2008-06-17 15:22:12 UTC

Removing the 4.0 target milestone set by reporter.
According to last comment this *may* improve for Diablo (4.1), time will tell
us.

Comment 10 Eric Warnke 2008-07-03 07:41:21 UTC

A-GPS actually made my lock times worse.  Now I can't EVER get a lock. 
Uninstalling A-GPS does nothing to restore the poor GPS lock of chinook.

Comment 11 Quim Gil 2008-07-03 10:54:28 UTC

> A-GPS actually made my lock times worse.

But most reports we have seen from people out there tell otherwise. Would it be
fair to say that this bug report is now fixed by the A-GPS functionality, and
then study the exceptions as new bugs, getting all the details to replicate
etc?

Comment 12 Simon Pickering 2008-07-03 10:56:13 UTC

The agps-ui presents a map of the world on which one must click to tell the
supl server (via supld I think) where you think you are, and then it will give
you ephemeris data, etc., for that location.

This is a pretty coarse map, each pixel is something like ~50 miles square. How
much of an deleterious effect will this inaccuracy have (bearing in mind that
it's pretty difficult to tap with single pixel accuracy anyway)? Can someone
who knows about the supl server comment?

It would be good if we could use some other interface to provide the supl
server with a location (e.g. maemo-mapper, which would give far better
precision due to the ability to zoom). Are there plans to provide an API to
interface with supld?

Comment 13 Quim Gil 2008-07-03 11:01:33 UTC

I really don't know about the details of the A-GPS applet but what about
discussing them in another place? The fact is that with the actual no-precision
the applet seems to work with visible results. Hence your point sound more like
an enhancement request rather than part of this bug.

Comment 14 Simon Pickering 2008-07-03 11:54:23 UTC

True. I'll have a word on IRC/ml and see to whom I should talk to establish
whether such an enhancement would even produce any improvements.

Comment 15 Marko Nykanen 2008-07-03 12:14:04 UTC

(In reply to comment #14)
> True. I'll have a word on IRC/ml and see to whom I should talk to establish
> whether such an enhancement would even produce any improvements.
> 

The reference location doesn't need to be that precise. It should be enough to
set the reference location within ~300km/185mile radius.

And when you get gps fix, the reference location is automatically updated to
your current gps position.

Comment 16 Neil MacLeod 2008-07-03 12:31:22 UTC

(In reply to comment #10)
> A-GPS actually made my lock times worse.  Now I can't EVER get a lock. 
> Uninstalling A-GPS does nothing to restore the poor GPS lock of chinook.

While running supld in xterm I've seen it crash with either D-BUS or GLIBC
errors. I've also seen supld hang which then seems to make the GPS search hang
(which you may interpret as never getting a lock). Rebooting usually fixes it,
until next time. A-GPS on the whole is an improvement, but it's also a bit
unstable (while it's a BETA, this is acceptable).

Comment 17 Eric Warnke 2008-07-03 15:59:58 UTC

On my unit it would sit there in the searching phase without showing a single
satellite.

I went though many reboot cycles without it clearing I tried clearing the gpd
through the control panel as well as removing /var/lib/gpd/nvr_data.  I ended
up removing libsulpd1 and agps-ui, reinstalling the system libraries that were
depended on sulp, rebooting, getting a GPS fix, and finally reinstalling and
enabling a-gps.

I understand that this is not production quality, but to silently die/corrupt
and for it go unreported to the user is bad.

agps-ui DOES NOT fix it.  With Diablo it is no better, and no better with or
without the agps-ui/supld.

It took 10 minutes to lock, and I haven't moved more than a mile or two.  So I
tried exiting and immediately coming back in.  2 minutes minimum if I have a
fairly clear path to the sky.  Same 5-10 usually.  And this is exit map, then
restart it (less than 15 seconds)!.

No, this bug is NOT fixed.  My cheapo BT GPS will stay off all night and never
takes more than 30 seconds when it is 6 foot from a window!  And the Nokia GPS
is sensitive enough - I get a lock from some fairly obstructed places.  It just
takes several minutes under an open sky when it has been off for less than 30
seconds.  Or should I contact Nokia about a warranty problem?

Diablo seems to be better - but still unacceptable. If it doesn't get fixed
soon, I am going to have to return the unit. After all, this isn't some brand
new feature - it's been around on other devices for years. The N810 is like
some early prototype.

Comment 20 Neil MacLeod 2008-07-10 17:53:20 UTC

I tend to agree with tz and comment #18 - I have to wait several minutes (up to
5) to get a lock on 5 satellites in clear skies (even with AGPS enabled), then
if I close Maps and reopen it immediately I have to again wait up to 5 minutes
to get another lock. Alternatively if I close Maps having had a lock then go to
Control Panel, open the GPS applet and hit the Location button I'm faced with
another 5 minute wait for GPS lock even though the device had a good lock less
than 30 seconds previously.

The long delay to get a lock is bad, but having to endure such long delays when
the device had a lock just seconds before is inexcusable - it makes it less
than practical to whip it out of a pocket and quickly check the current
location.

yeah. It is highly frustrating to wait for the gps to lock. It is taking more
than 10 minutes to lock even in my car with clear sky. The worst part is after
closing the map and reopening .... it takes the same time again. Some times
itloses the signals even in clear skies and reconnects which never happened in
chinook. I feel chinook was a lot better even though it is far behind compared
to any other gps.
come on nokia get your act right. The iphone 3 g apparently takes 2 seconds in
clear skies. is asking for 10 secs too much?

Just a bit of empirical info (any pointers to documentation on how it's
supposed to work appreciated):

The AGPS problem seems to be supld getting stuck.  Based on observation it gets
started by dbus and should normally live just long enough to fetch the
almanac/ephemeris data and feed it to the GPS chip, but sometimes it doesn't
exit so subsequent GPS "sessions" can't start a new one and don't get AGPS.

A tell-tale symptom of this happening is when the N810 doesn't know the list of
visible satelites at GPS app (mapper, maps etc) startup time and has to
discover them on its own.  When it is working maemo mapper should display 0/n
(for large values of n) in the GPS info pane as soon as the "Establishing GPS
fix" notification appears.  When it is not you get 0/0 instead, which slowly
increases as satellite data is downloaded from the satellites themselves.
So far this has been fixable by killing the stuck supld and restarting the GPS
application.

Reception is acceptable, but still not as good as with an LD-3W over bluetooth,
even when starting "cold" (AFAICT AGPS can't help in this case, right?).  The
built-in GPS reports weaker signal, often sees fewer satellites and has a lot
more jitter once a fix has been acquired (the location & direction stay pretty
much fixed with the LD-3W while with the internal one they constantly jump all
over the place).  Is this a hardware limitation or is there still room for
improvement?

I would consider this fixed when I have a set of a half dozen or more high
green bars in the map's gps view page going, close it.  Don't move the n810. 
Wait only 5 minutes.  Restart map, and within a few seconds get a lock.  Not
the 0/0, or the four weak gray bars that takes 5 minutes to turn green.

It should really take only a few seconds to restore the original state, and
should be able to lock in a minute if you are in the same place and your clock
(set when the GPS locks?) is accurate.

And it is not as if the ephemeris wasn't easily available on the net.

http://www.nstb.tc.faa.gov/RT_WaasSatelliteStatus.htm

Comment 24 Eric Warnke 2008-07-10 20:38:36 UTC

Installed the agps-ui with 0 change in behavior.

On a bright sunny day with a view of the southern sky

Rebooted, made sure I was on a network, fired up agps-ui and made sure
settings->agps was checked.

Maps showed 0 satellited in view, waited a minute, it picked up 2 in that time.

Maybe if there was some indication HOW this worked it might be easier to
diagnose why some people seem to get improved performance and we get nothing.

Comment 25 Ryan Abel 2008-07-10 20:59:16 UTC

(In reply to comment #24)
> Maybe if there was some indication HOW this worked it might be easier to
> diagnose why some people seem to get improved performance and we get nothing.
> 

Some information here: http://www.nokia.com/betalabs/agps-tablet

Comment 26 Eric Warnke 2008-07-10 23:01:08 UTC

(In reply to comment #25)
> (In reply to comment #24)
> > Maybe if there was some indication HOW this worked it might be easier to
> > diagnose why some people seem to get improved performance and we get nothing.
> > 
> 
> Some information here: http://www.nokia.com/betalabs/agps-tablet
> 

I believe we are very well aware of the THEORY of operation.  Specifics are
what we are lacking.

1) It claims that the A-GPS coordinates are updated automatically, why then
after a lock does maps forget the data? ( forgets as in the satellite view
shows no pre-determined satellites in view ).

2) How long do you need a lock before data is saved?  I've had better ( not
great, but better ) luck if I have a lock for 5 minutes and then close and
re-open maps then if I get a lock for 30 second close and reopen maps.

3) Is there any log files, processes, dbus calls, something that can be used to
confirm operation of this service?

4) How do we know that the Nokia database it's pulling from is even
operational?   I would hate to be chasing our tails over something like a
database error on the server side.

5) Once activated, does it always require a connection to work properly or will
it fall back on saved data when offline?


In the end it comes down to getting a lock in under 5 minutes, even under ideal
circumstances is hit-or-miss.  This makes the GPS unreliable and virtually
unusable for many tasks for which it is being marketed.  Even the iPod Touch
without a GPS receiver can estimate it's location in seconds far better than I
can touch a screen with vague coordinates.  Using the skyhook or cell tower
coordinates to estimate an initial location would probably produce an order of
magnitude faster lock time when paird with the publicly available WAAS data.

Sending some unknown blob of data to https://supl.nokia.com:7275/ and getting
some unknown blob back doesn't help.  I have a second GPS that I could use to
show visible satellites (plus azm/elev) so if I knew what it was pushing I
could see if it the values were sane.  For that matter I don't know if the
values it is sending up are sane though the red dot was at the right location
in the agps-ui app.

(my revised GPSD actually can use both the internal and a BT GPS, so I could
use  the BT GPS data to push the internal if I knew how).

Let me ask for something REALLY, REALLY simple.  A utility to display what it
thinks the satellite information is that I could run from Xterm or wherever so
I can see if anything sensible is being saved or maybe explain the complete
loss of information in the 30 seconds it takes to relaunch.  I could also
compare it with the image from that prior link.  Even better if I could set it
using the same utility.

Some of the stuff is proprietary, fine.  How about a non-proprietary CLI that
would at least show the basic data so we might have a chance at diagnosing
things.  Maybe some hardware is bad or broken but we have no way of knowing.

Having even a log file with "this is what it thinks the time, lat, and long
are" would go far.  Having a way to manually set it would be even better (e.g.
set, and see if the values stick).

Has anyone at Nokia even tried the map start / exit / relaunch and does it work
reliably for them or not?  For a lot of us, it is 100% completely repeatable
failure.  Maybe something as simple as being at a far west longitude.  I don't
know.  And I can't help if I don't have either information as to what is going
on under the hood or a utility that would at least let me see if things make
sense or not.

And the way it is acting, if it is being told or remembering I'm in australia
instead of minnesota it would explain things.

If you strace supld you can see some info, e.g.:
SUPL daemon version is Mon May  5 12:12:24 UTC 2008
SLP address: supl.nokia.com
SLP port: 7275
A-GPS srv address: supl.nokia.com
Position timestamp: 1215295872.000000
Position latitude: 49.161850
Position longitude: -123.119431
Position uncertainty: 300
Previous A-GPS req time: 0
Previous A-GPS req status: 1
A-GPS support: 1
NW INIT enabled: 0
Cached assistance data support: 1
Packet data for assistance data allowed: 1
Preferred connection id: Rogers Internet
SetId NAI: JohnDoe@nokia.com
PSK EMSK:
Wimax BSID:
GSM Cell ID by BT support: 0
Debug SLP IP source: provisioned
Debug mode: 0
Debug log folder: /media/mmc2/supllog/

The changelog in the package file (stripped off on the tablet, but can be
downloaded) has some notes; apparently cell ID was turned off in 0.27)

I don't know how to turn on debug mode.

Re. TTF, as per my previous post when I have just had a fix then stopped the
GPS, I can get another in about 20 seconds - from using the library function to
start the GPS to getting a fix from gpsd. This includes some time to start up
gpsd and is probably as good as it gets with this hardware. Starting a mapper
application like maemo-mapper or navicore/wayfinder takes longer.

I have not tested extensively with supld running. Subjectively, it seems to
show satellite data faster than without. I did have it lock up once
as others have reported. Rebooting cleared it; I did not try restarting supld
manually.

Comment 29 Simon Pickering 2008-07-11 11:00:43 UTC

> I don't know how to turn on debug mode.

It may be similar to the way the core dumps are logged, simply create the
directory it expects and it will output debugging data.

(In reply to comment #29)
> 
> It may be similar to the way the core dumps are logged, simply create the
> directory it expects and it will output debugging data.
> 
Nope.
It doesn't respond to command-line options like "-h"; maybe a DBUS command ..

One thing I just noticed; in the UI it lists only my phone as a possible
connection. I enabled that, and I think it knocked me off WiFi to try the
phone.
Which seems a bit daft, if the cell ID lookup is disabled and it's just trying
to get to a webserver.

Deinstalled agps-ui, then reinstalled it tonight.

I selected the located and started the map inside but with an internet link.

Later I started up map and it was 30-45 seconds for first fix, then close/open
took a very short time, probably less than 30 seconds.

Other than the uninstall/reinstall I didn't change anything.

If it always worked like this I would not have a complaint.

But it just makes it more frustrating to have it not work or work.  And still
no debug.

I'll try some more...

(In reply to comment #22)
> So far this has been fixable by killing the stuck supld and restarting the GPS
> application.

But not today :-(

Killed stuck supld, started maemo mapper, got "0/11" satellites almost
immediately, but it took about 10' to get a fix.

Repeated several times over the last few hours.  Lowest TTF was around 2',
whereas yesterday it could do it in under 30".  Things that didn't make a
difference:
- rebooting the N810
- uninstalling & reinstalling agps-ui
- removing /var/lib/gps/{gps_last_saved_report,nvd_data} (but they do get
recreated after the next session)

The location shown in agps-ui was correct during that time.

I also did some observation of maemo mapper's "GPS details" view.  After a fix
is obtained the satellite positions shift significantly (certainly more than
justified by the few minutes interval).  Cycling the GPS puts them back to
their pre-fix positions.  I can attach screenshots demonstrating this if
needed.

This suggests that the ephemeris data is not preserved (although the almanac
is) and/or we are getting fed bogus data from supl.nokia.com. I have no idea
whether this is the expected mode of operation or why it was working fine for
me in the past few days.

Speaking of which, I was monitoring traffic from the N810 (using tcpdump on the
router) and it seems that supld only tries to get new data once every 30'. 
This seems reasonable since ephemeris data is only supposed to be valid for
that length of time, but if it's incorrect and/or not cached we're still
effectively doing a cold start every time.

It would be useful to know which of the almanac / ephemeris are retrieved from
supl.nokia.com, which of the two are cached, and whether the cache stores the
data retrieved from the SUPL server or from the GPS chip.

(In reply to comment #11)
> Would it be fair to say that this bug report is now fixed by the A-GPS
> functionality, and then study the exceptions as new bugs, getting all the
> details to replicate etc?

Well, part of the problem is that A-GPS is currently advertised as beta and is
mostly undocumented.  Some release notes describing its operation, known issues
etc wouldn't hurt.  It would also be nice to have a more specific bugzilla
component for this.

(In reply to comment #32)
> It would also be nice to have a more specific bugzilla component for this.

Never mind, I just saw "Connectivity/Location Framework" via #3401 (which also
concerns the supld issue).  Not the most intuitive product for it, but it'll
do.

Comment 34 Neil MacLeod 2008-07-12 16:22:37 UTC

New version 0.10-1beta of AGPS-UI just appeared in app manager. No idea what's
fixed... why is this app closed source, I thought Nokia were learning but
obviously not.

Neil, might there be some proprietary Non-Nokia code involved?

Comment 36 Neil MacLeod 2008-07-15 09:30:39 UTC

(In reply to comment #35)
> Neil, might there be some proprietary Non-Nokia code involved?
> 

That, or the Nokia lawyers think there's some advantage to be gained by keeping
this source code closed. Either excuse is trotted out as justification all too
often to prevent the community from helping Nokia fix their buggy code. Nokia's
loss.

When I reinstalled, I got the updated AGPS which has been great until today,
but I think the gps driver needs adjustment.

1. Start the map program.

2. Bring up the GPS screen and enable it INDOORS.  With internet but no GPS
signal

3. Leave it for 2+ hours so all the bands are flatlines.

4. Go outdoors, clear view of sky, away from wireless access point.

Several minutes of flatline still.

5. uncheck and then recheck the enable box.

Good lock in under a minute.  A tall bar immediately.

Whatever it is doing, it should, if it gets a flatline for over 5 minutes,
assume it is indoors, maybe go into a low power mode, and do whatever it does
when cold/warm starting periodically.

Also, does it serve ionospheric corrections?

Unreliable; too long to lock; an order magnitude worse than my 770 with
tethered BT GPS.  A-gps made little difference.

bun

Unreliable, takes foreever or never log onto satellites; worse than my 770
tethered with a $29 BT GPS.  A-gps made no difference.

bun

Comment 40 Andre Klapper 2008-07-29 15:49:35 UTC

FYI, also see the thread at
http://www.internettablettalk.com/forums/showthread.php?t=21500 about A-GPS.

Comment 41 Andre Klapper 2008-07-31 19:00:34 UTC

Moving this bug to "Location framework" - "General" is always a bad choice. :)
(Bug 3515 correctly complained about this mess.)

There has been some discussion whether A-GPS makes a difference or not. Here is
my experience. 

A. Technically yes. If you look at the satellite details using maemo-mapper the
difference is clearly visible. Without A-GPS it takes a long time to find the
first satellite's channel, more time to find the second one, more time for the
third one etc etc.

With A-GPS all 10 channels (or actually SVNs) are displayed after just a few
seconds, even if their signal strength is still zero. Obviously the assistance
data told right away which channels to listen.

B. However, end user experience is very mixed. Sometimes you can indeed get
your fix in less than a minute, although GPS hasn't been used for many days (so
it should be a cold start). And sometimes I get a fix even indoors (big windows
though). Haven't seen that before.

However, *annoyingly* often it does not get a fix in any reasonable time. Even
in reasonable outdoor conditions. It appears to me that the whole system
somehow hangs, because signal strengths displayed are completely constant over
several minutes.

Somehow I have the feeling that the hanging has started when I installed A-GPS.
So A-GPS could still be the/one culprit here.

On the other side who tells us that the problem is not in maemo-mapper? What
applications are other people using when they complain about GPS performance?

Summary: Something is severely broken. A-GPS did not fix it, maybe it broke it
even more. 

I don't have the knowledge to say where the problem is, it could be GPS proper,
the integration with A-GPS, the applications interface or the application
proper. Maybe good tracing instructions might help to narrow it down.

(Although being a Nokia employee, this comment expresses nothing but my
personal opinions and end user experiences. GPS is not part of my job)

Comment 43 Eero Tamminen 2008-08-22 10:43:48 UTC

> However, *annoyingly* often it does not get a fix in any reasonable time.
> Even in reasonable outdoor conditions.

Last Sunday the sky was completely clouded here and it rained (visibility
= could dimly see a large airoplane several hundred meters above) and it
was impossible to get a fix outdoors.  I don't have experience of other
GPS devices, do they have the same issue in similar conditions?

(In reply to comment #42)
> There has been some discussion whether A-GPS makes a difference or not. Here is
> my experience. 
> 
> A. Technically yes. If you look at the satellite details using maemo-mapper the
> difference is clearly visible. Without A-GPS it takes a long time to find the
> first satellite's channel, more time to find the second one, more time for the
> third one etc etc.
> 
> With A-GPS all 10 channels (or actually SVNs) are displayed after just a few
> seconds, even if their signal strength is still zero. Obviously the assistance
> data told right away which channels to listen.
> 
> B. However, end user experience is very mixed. Sometimes you can indeed get
> your fix in less than a minute, although GPS hasn't been used for many days (so
> it should be a cold start). And sometimes I get a fix even indoors (big windows
> though). Haven't seen that before.
> 
> However, *annoyingly* often it does not get a fix in any reasonable time. Even
> in reasonable outdoor conditions. It appears to me that the whole system
> somehow hangs, because signal strengths displayed are completely constant over
> several minutes.
>
I agree until here.

> Somehow I have the feeling that the hanging has started when I installed A-GPS.
> So A-GPS could still be the/one culprit here.
>
I had that before I installed A-GPS, it's there from the start.

> On the other side who tells us that the problem is not in maemo-mapper? What
> applications are other people using when they complain about GPS performance?
>
I use "Map" by wayfinder as a GPS app, same issues. The problem really come
from the GPS unit.

> Summary: Something is severely broken. A-GPS did not fix it, maybe it broke it
> even more. 
> 
> I don't have the knowledge to say where the problem is, it could be GPS proper,
> the integration with A-GPS, the applications interface or the application
> proper. Maybe good tracing instructions might help to narrow it down.
> 
> (Although being a Nokia employee, this comment expresses nothing but my
> personal opinions and end user experiences. GPS is not part of my job)
> 

I think A-GPS helped a lot with the GPS issue, but it's only a poor workaround,
if you don't have an internet connection around it's totally useless. So, we
still need to find what's going wrong with this GPS in the end.

The lack of communication about it by Nokia is also an issue.
Is there someone working on it? Is it possible to solve this problem?

Tested the N810's GPS against that of a Garmin handheld GPS and the garmin left
the N810 in the dust.  It was able to correctly report the current location
flawlessly and did not lose the signal every time I moved.  My N810 spends most
of its time with GPS on and runs AGPS.  Movement really jarrs the readings and
the GPS on the N810 jumps around to be of any worthwhile use.

If the N810 is being outdone by a Garmin with a pokey non-colour UI, I'm going
to have to be a bit blunt: This is garbage.

If Nokia is offering a refund via warranty on these devices, a surrogate BT GPS
device or a full price discount on the "next model" for not delivering
advertised functionality, I would take the option at this point.

I would have bought the N800 if I knew the GPS wasn't worth the writing on the
box.  Really, the GPS in the N810 is false advertising.  At this point, if
Nokia doesn't address these issues in a conclusive fashion, I'll simply force a
reversal of my purchase and make the device available for the distributor to
obtain.  It's not worth using for me and there doesn't appear to be any other
way to get Nokia to actually act on what is clearly a landslide of proof here.

At this point I wouldn't be surprised if someone started a class action
lawsuit.

Comment 47 Andre Klapper 2008-09-01 17:50:02 UTC

(In reply to comment #46)
> At this point I wouldn't be surprised if someone started a class action
> lawsuit.

Please stick to the topic which is about fixing the issues. I can understand
frustration here, but adding more noise will not fix the issue any faster.
Feel encouraged to vote for this bug.

Comment 48 Neil MacLeod 2008-09-01 18:58:57 UTC

(In reply to comment #47)
> (In reply to comment #46)
> > At this point I wouldn't be surprised if someone started a class action
> > lawsuit.
> Please stick to the topic which is about fixing the issues. I can understand
> frustration here, but adding more noise will not fix the issue any faster.
> Feel encouraged to vote for this bug.

Fair comment Andre, but has anyone from Nokia even acknowleged that there are
issues? Despite all the posts in this report, not one of the posts from Nokia
people has come close to discussing the issues that people are experiencing.

We cannot really begin to fix the issues without Nokia assistance as much of
the GPS functionality is closed or NDA. We have presented copious amounts of
evidence that the current implementation is flawed and/or broken, and the
response from Nokia has been what exactly - silence?

This thread is going off topic because there's not much more the community can
add without repeating itself - it's now time for some public input from Nokia
either acknowledging the flaws or refuting them. Assuming the problems are
acknolwedged then maybe we can work together towards a solution or, more
likely, we will have to trust Nokia to provide a solution in the future beacuse
of the closed/NDA nature of the source/hardware respectively.

Once again the communities efforts to improve the product grinds to a halt
because of proprietary decisions made by Nokia. Ignoring the community in this
bug report isn't helping what is already a bad decision. Input into this bug
from Nokia is now needed to get it back on track (and keep it there), and
hopefully headed towards a satisfactory resolution. If Nokia already know what
the problems are with the current (A)GPS implementation and are working on a
fix then tell us this is the case and we'll lay off - if not, then let the
discussion commence. :)

So, i've just returned my N810 back! GPS was one of the important parts of this
tablet for me, but nokia haven't even take a notice of this grand mess...

I'll stay with my n800!

Comment 50 Eero Tamminen 2008-09-10 14:28:22 UTC

> This thread is going off topic because there's not much more the community
> can add without repeating itself

I think there are two basic use-cases for GPS:
A) You occasionally start GPS software e.g. to check whether
   the next bus stop is yours
B) You have the map sofware and GPS "always" running

Due to long fix time, the current GPS software is not very useful
for the use-case A).  The use-case situation is "over" in few minutes
and having the fix late doesn't help.


For the use-case B), the longer fixup time is less of a problem because:
- GPS position isn't lost or is quickly (in seconds) re-acquired
  when the map software & gpsd are already running
- The software & gpsd are already running when you need it
- The device battery lasts for about 4 hours which is pretty good
  compared to the other GPS devices.
  -> Depends on whether device is set offline or not, what's the display
     blanking period & brightness, is the mapping software set to constantly
     scroll the map according to GPS position or not etc

Is somebody having real issues also with B), not just fix up time?

Comment 51 Simon Pickering 2008-09-10 14:34:18 UTC

> Is somebody having real issues also with B), not just fix up time?

Yes, on a number of occasions I have had a fix and then lost it for one reason
or another (e.g. moved N810) and it won't come back despite having signals from
at least 8 satellites. I presume this is simply an issue with the chipset and
how it processes the data/the SNR it requires/etc. In my cases the satellite
signals were probably not very strong, so perhaps I was lucky to get a fix in
the first place, and would then be back in category A).

Comment 52 Andrew Flegg 2008-09-10 14:43:57 UTC

I also have issues with use case B:

Scenario: trying to use the N810 as in-car navigation.
Problem:
 * GPS doesn't get lock within most buildings
=> Connection only becomes viable once in car.
 * Stationary device is easier to get fix for.
 * However, getting a fix takes a long time.
=> Passengers get grumpy when told to sit and wait whilst device gets a GPS
lock.

The other solution is to set off and hope it gets a lock en-route, but this
takes even longer and if you're navigating back home from somewhere unfamiliar,
you may need the lock ASAP to avoid getting lost.

I've used it in both A and B, and the problem - without AGPS it can take
forever to get a fix under a clear sky.  With AGPS, it seems to work about 3/4
of the time perfectly.  The other 1/4 it doesn't.

But here is where Nokia is dropping the ball.  All the low-level stuff going on
is proprietary.  The AGPS (and some other daemon it installs) is proprietary
and has NO information or flexibility.

I can't enter known coordinates directly, only by tapping somewhere in the
featureless continental North America blob(and my screen is way off even at the
best calibration).  I have the Map program but can't zoom in and say "here"
although I can probably get to within 50 feet of the location.  But NO, tap
somewhere and hope it is nebraska and not north dakota.

So I have exact coordinates (and a second GPS), and an atomic clock, but don't
have any way to tell the a-gps subsystem.

And I do have wifi.  Most of the time.  But there is no way to force or even
check that it connected to get the satellite status from the server.  Maybe it
has fresh and valid data and will only take 20 seconds, maybe it is stale so it
will take 20 minutes to acquire.  Who knows?

A button that would "Grab sat data now" and indicate when it was refreshed
would help while I am in range of my hotel's' or some other wifi.

So it is even more infuriating since it seems completely random, but instead of
taking 20 seconds v.s. 20 minutes in about a 20/80 split, it is now 80/20.  And
it should be 100, and probably would be if I knew what was going on or could
force it to do a pull.

But I can't, so (the internal) GPS will still on frequent enough occasions take
longer to lock than for me to reach my destination to be useful.  And I will
never know why or when.

And I probably could fix it if I knew.

I just tried it again.  Four satellites had more than adequate signal for at
least 10 minutes continuously, but no fix.  It wouldn't lock.  Why?  Who knows?
 Maybe Nokia, but they aren't telling.  Maybe TI, but they aren't either.

Comment 55 Neil MacLeod 2008-09-10 17:29:33 UTC

I've been in an open area[1] in central London with open sky and only three
attempts in as many as 15-16 actually achieved a lock (this with A-GPS, prior
to SSU1). On one of the three occassions when I did get a lock, I shut down the
GPS for less than 10 seconds and without moving from my original position I
again tried - and failed - to get a lock, despite seeing several sattelites.

Most often I want to use the GPS for "Usecase A" (Is this my next bustop?) but
also for "Usecase B" (planning longer routes) but unfortunately for both
usecases the N810 GPS is utterly, comprehensively and undeniably useless.

For "Usecase A" the GPS takes so long to lock (assuming it ever gets a lock)
that I begin to feel very, very uncomfortable holding an expensive device in my
hand in central London - to be honest, there's a greater chance of me being
mugged for my N810 than the N810 actually getting a lock.

Eero - your input is much appreciated, as always, but it's time Nokia came
clean on the problems we are having and start assuring us they are seeing the
same problems, that they understand what is causing the problem and are working
on a solution. There's not much more we can do - other than complain - while
Nokia insist on using closed-source hardware & software.

1. http://tinyurl.com/5g3m6d   [Google Maps - the photo is showing an ice rink,
however in summer they host events on the circle and I tried obtaining a lock
several times about 6 weeks ago in the dead center of the circle]

Comment 56 Marko Nykanen 2008-09-10 19:48:11 UTC

(In reply to comment #53)
> I can't enter known coordinates directly, only by tapping somewhere in the
> featureless continental North America blob(and my screen is way off even at the
> best calibration).  I have the Map program but can't zoom in and say "here"
> although I can probably get to within 50 feet of the location.  But NO, tap
> somewhere and hope it is nebraska and not north dakota.

If you want to experiment A-GPS with exact coordinates, you can set them using
gconftool /system/osso/supl/pos_latitude and pos_longitude, before starting
application that is using GPS.

> So I have exact coordinates (and a second GPS), and an atomic clock, but don't
> have any way to tell the a-gps subsystem.
> 
> And I do have wifi.  Most of the time.  But there is no way to force or even
> check that it connected to get the satellite status from the server.  Maybe it
> has fresh and valid data and will only take 20 seconds, maybe it is stale so it
> will take 20 minutes to acquire.  Who knows?

Supl has it's own cache for assistance data at /var/lib/supl/ad_cache. Check
the timestamp of that file. If it's less than 30minutes old, it has valid data.

Comment 57 Quim Gil 2008-10-31 12:08:58 UTC

Hi, answering to the original report:

- agps-ui is provided to improve time fixes. According to our tests on
the field, the average timing for a fix is around 15 seconds.

- Cellular (e.g. through tethered mobile phone) and WiMAX connections in
conjunction with A-GPS might help enhancing fix timings since they can
provide almanac and ephemeris data.

- The Location team has gone through these issues and doesn't think that
long timings are caused by bugs in gpsd or the closed components
developed by Nokia.

- Hardware choices are not made by the Maemo SW team. Discussion about
future hardware choices is out of scope in bugs.maemo.org.

- Nokia is investing heavily in order to differentiate in location
software and services. Many improvements are being developed during the
Fremantle time frame. Opening Nokia components is not seen as favoring
the Nokia strategy in the location area.


Therefore this bug could be resolved as fixed. Some of you are reporting
in the comments irregular issues using with the agps-ui. You are
encouraged to open specific bugs that will be followed by the
corresponding developers.

Comment 58 Andrew Flegg 2008-10-31 12:18:49 UTC

(In reply to comment #57)
> Hi, answering to the original report:
> 
> - agps-ui is provided to improve time fixes. According to our tests on
> the field, the average timing for a fix is around 15 seconds.

What's the plan for providing agps-ui as not a beta, or even as part of the
integrated default platform (in diablo)?

It's a sub-optimal solution:
  1) It needs to be opened manually.
  2) It doesn't provide information on when it's updated the ephemeris data.
  3) There aren't clear instructions on how to use it (for example, it /can/
     be closed after updating the information)
  4) There's no indication to the user how long the information it's downloaded
     is valid for (if I run it, and then half an hour later want to get a fix,
     do I need to run it again)?
  5) How accurate does the pixel need to be? Again, the user doesn't know. If
     I'm moving back and forth about 100 miles a day, that's within the circle;
     do I need to move the dot?

agps-ui is, at best, a beta-level proof-of-concept, and this bug should not be
resolved until it is pushed out to end-users in a better state.

Comment 59 Simon Pickering 2008-10-31 12:25:41 UTC

When AGPS works it appears to work well, the question is whether the other
problems people are seeing are due to the hw chipset/firmware, or some
malfunction in the way agps-ui -> supld -> gspdriver -> nvd_data is working.
The former we can do nothing about (unfortunately), the latter we could debug
with some source code.

I've opened bug #3833 to request either agps-ui source code or some way to hook
into the AGPS API, I hope that if we get this information, we will be stepping
in the right direction. 

I have seen mention that deleting the nvd_data file can miraculously make the
GPS start working again (implying that feeding the GPS chipset with possibly
corrupt nvd_data stops it from working), therefore we might want to ask for the
gspdriver source code too (as it is this which writes the nvd_data and sends it
to the gps chipset).

Comment 60 Marko Nykanen 2008-10-31 12:37:30 UTC

> It's a sub-optimal solution:
>   1) It needs to be opened manually.

The idea is that you don't have to open it every time. Only when you have moved
>300km from the last fix position.

>   2) It doesn't provide information on when it's updated the ephemeris data.

Next version should have this information.

>   3) There aren't clear instructions on how to use it (for example, it /can/
>      be closed after updating the information)

AGPS-UI is just a settings ui for supldaemon. If you have once enabled the
agps-support in agps-ui settings, supldaemon will always be running in the
background when it needs assistance data. So, AGPS-ui can be closed after
setting the position/settings, supldaemon will then update the assistance data
from the server when it needs it, based on the coordinates you have set with
agps-ui.

>   4) There's no indication to the user how long the information it's downloaded
>      is valid for (if I run it, and then half an hour later want to get a fix,
>      do I need to run it again)?

Next version will show if the data is valid and when it has been updated.

>   5) How accurate does the pixel need to be? Again, the user doesn't know. If
>      I'm moving back and forth about 100 miles a day, that's within the circle;
>      do I need to move the dot?

~300km/185mi radius. You should not need to touch agps-ui if you just moving
100mi. And once you get the fix, supldaemon will use your last fix position
next time it needs assistance data.

Comment 61 Andrew Flegg 2008-10-31 12:41:26 UTC

(In reply to comment #60)
> 
> The idea is that you don't have to open it every time. Only when you have 
> moved >300km from the last fix position.
>
[snip lots of lovely information]

Thanks: this is interesting. I don't think a Bugzilla comment counts as
end-user documentation, though :-)

> 
> >   2) It doesn't provide information on when it's updated the ephemeris data.
> 
> Next version should have this information.
> 
> >   3) There aren't clear instructions on how to use it (for example, it /can/
> >      be closed after updating the information)
> 
> AGPS-UI is just a settings ui for supldaemon. If you have once enabled the
> agps-support in agps-ui settings, supldaemon will always be running in the
> background when it needs assistance data. So, AGPS-ui can be closed after
> setting the position/settings, supldaemon will then update the assistance data
> from the server when it needs it, based on the coordinates you have set with
> agps-ui.
> 
> >   4) There's no indication to the user how long the information it's downloaded
> >      is valid for (if I run it, and then half an hour later want to get a fix,
> >      do I need to run it again)?
> 
> Next version will show if the data is valid and when it has been updated.
> 
> >   5) How accurate does the pixel need to be? Again, the user doesn't know. If
> >      I'm moving back and forth about 100 miles a day, that's within the circle;
> >      do I need to move the dot?
> 
> ~300km/185mi radius. You should not need to touch agps-ui if you just moving
> 100mi. And once you get the fix, supldaemon will use your last fix position
> next time it needs assistance data.
>

But does it TRACK the GPS location when it has a fix?  Like when I drive
600miles/1000km will it "remember" the remote location or the home location?

Otherwise having it update the dot upon a locked GPS signal (maybe first lock
then every 5-15 minutes) would really help.

Having a way of determining if the supld has updated (beyond gconf and the
debug stuff), or perhaps forcing it if you are just leaving a wifi-hotspot
would help.

Although I am generally annoyed at closed portions, I usually don't care as
much when they work 100%.  Or at least tell me in enough detail why they aren't
working when they don't.

Right now it is a black box that works some of the time (is it installed right,
did the supl thingy get installed with agps-beta?, is the data fresh or
stale?).

I'm quite sure most people would be willing to do what they would need to do on
their part to speed up fix time.  But they just get a bar or two that won't
lock for several minutes under a clear sky even after maybe having followed
instructions correctly.

It isn't "FIXED" because of that.  Because engineers at Nokia can with
additions get it to work perfectly just outside their office doesn't mean
everyone else has the same luck.  Many do.  I think I do as far as I can tell. 
But every so often it doesn't work.

Even a "Doing a ColdStart | Assisted at Lat/Lon/Time | WarmStart | HotStart"
indicator would help.  There is a "private" nokia GPS sentence - perhaps you
could encode something there.  Or in the location manager a detailed internal
GPS status.

When it works (on you constantly connected WiMax tablet in Finland with an
accurate A-GPS setup with correctly installed packages), it locks quickly. 
When it doesn't work - it is all but impossible to tell why.  For me, it has
been working consistently (and for some reason my minigpsd which should not do
anything different seems to improve the lock time according to reports).

Comment 63 Marko Nykanen 2008-10-31 14:41:46 UTC

(In reply to comment #62)
> But does it TRACK the GPS location when it has a fix?  Like when I drive
> 600miles/1000km will it "remember" the remote location or the home location?

Agps-ui doesn't track the location.

> Otherwise having it update the dot upon a locked GPS signal (maybe first lock
> then every 5-15 minutes) would really help.

That is possible but the dot movement might be so small that you wouldn't
notice it anyway :) Best way to verify that agps is working is to check how
many satellites there are in the view. If there is >5 satellites in view right
after gps is started, then agps has done its job.

> Having a way of determining if the supld has updated (beyond gconf and the
> debug stuff), or perhaps forcing it if you are just leaving a wifi-hotspot
> would help.
> 
> Although I am generally annoyed at closed portions, I usually don't care as
> much when they work 100%.  Or at least tell me in enough detail why they aren't
> working when they don't.
> 
> Right now it is a black box that works some of the time (is it installed right,
> did the supl thingy get installed with agps-beta?, is the data fresh or
> stale?).

Yep, supl is installed with agps-ui. With next version of agps-ui you can check
the validity of cached assistance data. I just pushed it forward, hopefully it
will be in the repo soon.

(In reply to comment #62)

> Otherwise having it update the dot upon a locked GPS signal (maybe first lock
> then every 5-15 minutes) would really help.

Having a "battery-saver" mode for the GPS would be nice, as did my old Magellan
set. The chip would turn on every so often (configurable ?), get a fix and
update the almanac if necessary, then turn off. The last fix would be available
to user programs. If it could not get a fix, it would time out and turn off
anyway, perhaps dropping to a longer interval between checks.

Running the GPS fulltime uses significantly more power (10x ?) than mostly idle
mode e.g. checking a map every hour while hiking.

>(In reply to comment #62)
>> But does it TRACK the GPS location when it has a fix?  Like when I drive
>> 600miles/1000km will it "remember" the remote location or the home location?

>Agps-ui doesn't track the location.

>> Otherwise having it update the dot upon a locked GPS signal (maybe first lock
>> then every 5-15 minutes) would really help.

>That is possible but the dot movement might be so small that you wouldn't
>notice it anyway :) Best way to verify that agps is working is to check how
>many satellites there are in the view. If there is >5 satellites in view right
>after gps is started, then agps has done its job.

It is not a matter of the movement being small or large.  If it knows the
tablet's correct and actual coordinated when there is a lock, there should be
some way of moving the dot to that place.  When I'm back in MI, I want the dot
to be near my home in MI.  When I'm at my jobsite in MN, I want the dot to be
near it in MN.

In the new (will it still be called "beta"?) version you should at least have
that option, especially for travelers.  Not everyone will always be 500 miles
away from home, and even the map is hard to use as there are no fine boundaries
(where is omaha nebraska?), just massive white blobs so I need to know the
lat/lon before trying to set it many times.

Comment 66 Neil MacLeod 2008-11-01 18:16:07 UTC

Just thought I'd mention that I purchased a Nokia N85 today and it's built-in
GPS is getting a solid lock indoors on an overcast day within 30 seconds - my
N810 has never got a lock indoors (same location as the N85 managed to get it's
lock) no matter the weather conditions outside - in fact my N810 struggles to
get a any kind of lock in under 5 minutes when outside in clear skies.

It seems pointless for anuone to try and argue the N810 is working correctly or
acceptably when it's patently obvious based on evidence from real users that
the N810 hardware, or the N810 firmware, or both, result in a product that
simply *does not work* acceptably, if at all.

It seems that the little N85 is using a TI CPU (not sure if it's OMAP) which
might suggest it also has a TI designed GPS in which case does this point the
finger at the N810 firmware, or the N810 GPS antennae design?

Either way, the N810 GPS performance is *dire* and once again (as happens with
most hardware problems) Nokia seem to be ignoring the issue the best they can.
:(

Comment 67 Neil MacLeod 2008-11-01 18:18:16 UTC

Why isn't the AGPS/supl application rolled up into the GPS Control Panel
applet? Or will this happen once it exits from Beta status?

Comment 68 Andre Klapper 2008-11-02 00:09:11 UTC

(In reply to comment #57)
> - The Location team has gone through these issues and doesn't think that
> long timings are caused by bugs in gpsd or the closed components
> developed by Nokia.
> 
> - Hardware choices are not made by the Maemo SW team. Discussion about
> future hardware choices is out of scope in bugs.maemo.org.
> 
> Therefore this bug could be resolved as fixed. Some of you are reporting
> in the comments irregular issues using with the agps-ui. You are
> encouraged to open specific bugs that will be followed by the
> corresponding developers.

To summarize:

No software issues known to Nokia anymore.
Potential remaining hardware restrictions are out of scope here.
Please file seperate and specific bugs under Connectivity > Location framework.

Quim, thanks for investigations and getting Nokia people involved.
(Removing Target Milestone set by original reporter.)

(In reply to comment #68)
> To summarize:
> 
> No software issues known to Nokia anymore.
> Potential remaining hardware restrictions are out of scope here.

Since you resolved the bug as *fixed*, do you have a summary of what has been
fixed (in addition to AGPS)? TIA for any information.

> Please file seperate and specific bugs under Connectivity > Location framework.

Shouldn't this bug be a tracking bug for those specific bugs?

(In reply to comment #66)
> Either way, the N810 GPS performance is *dire* and once again (as happens with
> most hardware problems) Nokia seem to be ignoring the issue the best they can.

I have to agree with this description.  

It's incredibly frustrating to see this marked as resolved when the GPS
functionality is clearly broken.  My own and many other's experience is that
even with a-gps, the GPS mostly wont get a fix.  

The N810 was sold as having a GPS - it's (past) time for Nokia to step up to
the plate and make it work...

Comment 71 Neil MacLeod 2008-11-02 13:47:04 UTC

(In reply to comment #68)
> To summarize:
> 
> No software issues known to Nokia anymore.
> Potential remaining hardware restrictions are out of scope here.

Reading between the lines, are you saying the poorly functioning (assuming it
functions at all) N810 GPS *is* due to a hardware problem/design flaw which now
won't be discussed any further?

I'm not really sure what you mean by "hardware restrictions" unless you mean
the GPS hardware has so many restrictions (is "restriction" Nokia speak for a
flaw?) that it is no longer capable of functioning as a GPS.

The GPS in the N810 should do the job as it was advertised but the sad fact is
it doesn't work *at all* for many of us - if that's due to a "hardware
restriction" then we can add it to the Nokia Tablet list of hardware design
c0ckups. :(

*I really object to this bug being closed RESOLVED/FIXED btw as it's nothing of
the sort*

Comment 72 Quim Gil 2008-11-02 15:48:46 UTC

(In reply to comment #58)
> agps-ui is, at best, a beta-level proof-of-concept, and this bug should not be
> resolved until it is pushed out to end-users in a better state.

Alright, let's reopen this bug until we agree on its resolution.

Since A-GPS is an important part of the solution it should be integrated in a
way that an average user could enable it and make it work, getting those fixes
in a decent time and reliably.

Tomorrow I'll reflash an N810 with the latest firmware and see how it goes. You
are encouraged to do the same and report here your results.

Comment 73 Quim Gil 2008-11-02 16:18:49 UTC

More comments:

(In reply to comment #58)
> It's a sub-optimal solution:
>   1) It needs to be opened manually.
>   2) It doesn't provide information on when it's updated the ephemeris data.
>   3) There aren't clear instructions on how to use it (for example, it /can/
>      be closed after updating the information)
>   4) There's no indication to the user how long the information it's downloaded
>      is valid for (if I run it, and then half an hour later want to get a fix,
>      do I need to run it again)?
>   5) How accurate does the pixel need to be? Again, the user doesn't know. If
>      I'm moving back and forth about 100 miles a day, that's within the circle;
>      do I need to move the dot?

Do you mind filing bugs against the A-GPS to keep track on the progress? Or
perhaps do you prefer to wait to the next release and fil bugs if there is
something missing. Sticking a long discussion on several points under a generic
bug report is not helpful at this point. Thanks!

(In reply to comment #58)
> Just thought I'd mention that I purchased a Nokia N85 today and it's built-in
> GPS is getting a solid lock indoors on an overcast day within 30 seconds

As said, 

Cellular (e.g. through tethered mobile phone) and WiMAX connections in
conjunction with A-GPS might help enhancing fix timings since they can
provide almanac and ephemeris data.

Your N85 bnefits from its cellular connectivity to get those fast fixes. Have
you tried to get a lock on your N810 with A-GPS installed while being connected
to a cell phone?

Also a general comment. The Maemo SW team deals with software and only
software. If you have complaints about your N810 (a hardware product with
software inside) then you should exercise your customer rights through the
Nokia customer support channels:
http://europe.nokia.com/link?cid=PLAIN_TEXT_655233 . Really, don't expect here
a discussion about Nokia products. Thank you for your understanding.

Comment 74 Neil MacLeod 2008-11-02 20:29:55 UTC

Created an attachment (id=1024) [details]
Satellite reception in Maps after successful run of AGPS (log below)

(In reply to comment #73)
> Your N85 bnefits from its cellular connectivity to get those fast fixes. Have
> you tried to get a lock on your N810 with A-GPS installed while being connected
> to a cell phone?
> 
Yes, *ALL* my previous comments and test with N810 GPS have related to using
the N810 assisted with AGPS and a Sony Ericsson W950i mobile phone when
connected to the T-Mobile UK network over 3G - the N810 doesn't get a lock
*ever* indoors, and only rarely outdoors when in clear, open skies.

The N85 and N810+AGPS+cellular are like night and day when comparing their
respective GPS abilities, the N85 works great while the N810 is simply unusable
as a serious tool as it's so unlikely to get a lock making it simply not worth
trying any more. The N810 really is *that* bad.

With my limited testing of the N85 it's clear that the N85 "sees" several
satellites that the N810 fails to find, the N810 is virtually blind in
comparison to the N85. Having now seen the N85 in operation if it weren't for
the 90 votes and copious comments in this bug confirming my own N810 experience
I'd have said the GPS in my N810 was defective and in need of repair. The
trouble is with 90 votes, it's not a one-off defect and most likely an
irreparable design fault, which is worrying.

Regarding your general comment, maybe I should put the N810 in for repair
before the warranty expires as I've got nothing to lose, but I guess the point
of this bug is to determine the root cause of the problem which is affecting so
many users - this is not an isolated case, this is endemic.

As an additional data point, what follows is the output from supld.log when
connected to the N85+T-Mobile UK over 3G (I'm located in South London):

[DEBUG] Connected to DBus
[DEBUG] Got requested service name
[DEBUG] DBus message handler registered
[INFO]  SUPL daemon starting up.
[DEBUG] Message received!!!
[DEBUG] Interface: com.nokia.supld
[DEBUG] Member:    GetAssistData
[DEBUG] Signature:
[DEBUG] ASSIST_DATA_REQ
[DEBUG] Starting up thread for SUPL session
[DEBUG] ---------THREAD INIT----------
[DEBUG] Hey! I'm running in a thread
[]HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHh
[]Assistance data requested!
supld[1767]: GLIB DEBUG ConIc - con_ic_connection_send_event(0x6d818,
02d0016d-4f68-410a-a27c-260a18e51786, DUN_GSM_PS, 0)
[]Assistance data received from SUPL server!
[DEBUG] Hey! Exitting thread
[DEBUG] No more active threads, setting timeout

[DEBUG] ---------THREAD FINISHED------
SUPL daemon version is Mon May  5 12:12:24 UTC 2008
SLP address: supl.nokia.com
SLP port: 7275
A-GPS srv address: supl.nokia.com
Position timestamp: 1215872384.000000
Position latitude: 53.100513
Position longitude: -2.068965
Position uncertainty: 300
Previous A-GPS req time: 0
Previous A-GPS req status: 0
A-GPS support: 1
NW INIT enabled: 0
Cached assistance data support: 1
Packet data for assistance data allowed: 1
Preferred connection id: 02d0016d-4f68-410a-a27c-260a18e51786
SetId NAI: JohnDoe@nokia.com
PSK EMSK:
Wimax BSID:
GSM Cell ID by BT support: 0
Debug SLP IP source: provisioned
Debug mode: 0
Debug log folder: /media/mmc2/supllog/
Timeout occured
[INFO]  SUPL daemon exiting (code 0).

I've also attached a screenshot of the corresponding GPS status window in Maps
(Diablo 4.2008.36-5) which was running while the above supld log was captured -
after several minutes the GPS had only detected weak signals from satellites 03
and 22, but never achieved a lock. This is how it is most of the time - only
rare occasions have I ever got a lock, and even then it's impossible to keep
for more than a minute or so.

Now compare the N810 performance with the N85 which, when standing in the same
position, detected signals from 9 satellites (3, 6, 11, 14, 19, 20, 22, 28 and
32) and appeared to get a good lock on 3, 6, 14, 19, 22, 28 and 32 - all within
30-45 seconds. According to the N85 my latitude is 51°22'19.12"N, longitude
0°06'12.29"W.

Comment 75 Simon Pickering 2008-11-02 21:24:23 UTC

It would be interesting to see the SNR of the satellites using the N95 GPS vs
the N810 GPS. The different may come down to the fact that the N810 GPS antenna
is partially shielded by the metal case of the device.

If this is the case, we can accept that the implementation is flawed and
there's not much (except making a new case ;)) that we can do about it.

Either way, it would be good to narrow down the possible causes.

Comment 76 Quim Gil 2008-11-03 10:19:10 UTC

End user test done this morning in Helsinki:

1 - Flashed the N810 with 4.2008.36-5.
2 - Went outdoors in a square with good visibility.
3 - Opened Map application and clicked on the GPS icon.
4 - Tried several times, changing location within walking distance and
rebooting a couple of times.

Times between opening the app and getting a fix:

- 54 secs
- 28 secs
- 29 secs
- 35 secs
- 88 secs (this one walking next to a wall)

All this with the stock software and relying only on satellites, no previous
location data gathered, no wlan or phone connection used.

Only for this it looks that the N810 performs decently.

Then I installed A-GPS.

- Default location offered was Helsinki city already. No idea whether this was
gathered from my last fix or this is a default (remember I'm a pure end user
here).
- "Allow pavket data" activated. "Provider connection" selected.
- Quit.

The Map application doesn't register any remarkable improvement, keeps offering
timings around 30 - 60 - 90 seconds.

fwiw I installed Maemo Mapper. Same results.

Actually none of them seem to take any advantage from the A-GPS, relying
uniquely on the data coming from the satellites.

Going indoors now. Map and Mapper don't bring any fix. They don't seem to be
helped at all by A-GPS.

However, reboot:

- Settings >> Control Panel >> GPS Location
- Click "Location"
- A location is instantly provided there (last fix stored?)
- Click Refresh, wlan and GPS are connected, a fix is provided in 19 seconds.
- Click Refresh and you get updates in less than 10 secs. In fact it looks like
most of the time is invested initializing the GPS. When GPS and wlan are on,
the refresh provides data instantly (I guess it's the same with active packet
data connection, haven't tried though).

My *personal* conclusions from a pure end user experience today:

- "Satellite acquisition with internal GPS" and latest firmware is decent and
this bug can be resolved as fixed.

- A-GPS UI is so simple and undocumented that it might be indeed confusing
since a normal user doesn't know this tool at all, nor understands what it
does. However, A-GPS itself works well.

- Nokia Map and Maemo Mapper doesn't seem to read the fixes provided by A-GPS
though, which means that for Joe Average it doesn't work: no improvement in
outdoors fixes, no indoor fixes at all.

Considering that A-GPS and the features it brings belong to a separate
component and were never advertized in the N810 *product*, I keep thinking that
this bug can be resolved and specific bugs should be filed against the
components responsible.

Comment 77 Simon Pickering 2008-11-03 11:31:43 UTC

> End user test done this morning in Helsinki:
<snip>
> Times between opening the app and getting a fix:
> 
> - 54 secs
> - 28 secs
> - 29 secs
> - 35 secs
> - 88 secs (this one walking next to a wall)
> 
> All this with the stock software and relying only on satellites, no previous
> location data gathered, no wlan or phone connection used.
> 
> Only for this it looks that the N810 performs decently.

So presumably the first of these was a cold fix, in which case it performed
pretty well. Did you delete the nvd_data file for the latter fixes? I'm
guessing not, in which case these were warm/hot fixes, and the later times are
then not so impressive.

> Then I installed A-GPS.
> 
> - Default location offered was Helsinki city already. No idea whether this was
> gathered from my last fix or this is a default (remember I'm a pure end user
> here).
> - "Allow pavket data" activated. "Provider connection" selected.
> - Quit.
> 
> The Map application doesn't register any remarkable improvement, keeps 
> offering timings around 30 - 60 - 90 seconds.

If you had a recently updated nvd_data from your previous testing you'd not
expect any improvement (updating with the same info basically).

> fwiw I installed Maemo Mapper. Same results.
> 
> Actually none of them seem to take any advantage from the A-GPS, relying
> uniquely on the data coming from the satellites.

A-GPS operates at a level below the applications, there's nothing they can do
to take advantage of A-GPS, it happens automatically. Its use (via supld and
gpsdriver) should occur transparently afaiu.

> Going indoors now. Map and Mapper don't bring any fix. They don't seem to be
> helped at all by A-GPS.

There are different ways the A-GPS server can provide assistance, one is to
produce almanac/ephemeris data for the location of interest, another is to
process mangled data received by the GPS chipset and use brute force to
calculate what was supposed to be there. I don't think this applies though for
our case (N810 vs N95), as both can receive location information via the cell
ID. Perhaps the N95 is simply more sensitive (due to antenna position,
different firmware, etc.)

> However, reboot:
> 
> - Settings >> Control Panel >> GPS Location
> - Click "Location"
> - A location is instantly provided there (last fix stored?)

This is normal even without A-GPS afair

> - Click Refresh, wlan and GPS are connected, a fix is provided in 19 seconds.

Not too bad. Is this outside again?

<snip>

> - Nokia Map and Maemo Mapper doesn't seem to read the fixes provided by A-GPS
> though, which means that for Joe Average it doesn't work: no improvement in
> outdoors fixes, no indoor fixes at all.

See above, A-GPS apparently does work and lets the chipset know which
satellites it's looking for, it's just that it still can't see them.

I'm still interested in how corrupted A-GPS data are detected and how the
chipset handles things if it's given an incorrect set of alamanac/ephemeris
data (which might explain why some people have better results after deleting
nvd_data and then re-running agps-ui).

Comment 78 Quim Gil 2008-11-03 12:10:23 UTC

(In reply to comment #77)
> So presumably the first of these was a cold fix, in which case it performed
> pretty well. Did you delete the nvd_data file for the latter fixes?

No, I didn't do anything a normal user would do. It was clearly a very casual
testing made a by someone with a busy agenda on a Monday morning.  :)  

> I'm
> guessing not, in which case these were warm/hot fixes, and the later times are
> then not so impressive.

From those times, around 15 seconds are taken by the application just to
initiatize and show a forst sight on the satellites around. As said, I think
the experience was "decent" and not "very poor".


> A-GPS operates at a level below the applications, there's nothing they can do
> to take advantage of A-GPS, it happens automatically. Its use (via supld and
> gpsdriver) should occur transparently afaiu.

Then, something weird is happening since I do get a position in the Location
applet but such location is not shown in the apps.


> > - Click Refresh, wlan and GPS are connected, a fix is provided in 19 seconds.
> 
> Not too bad. Is this outside again?

Inside. I didn't go outside again since then because I have a pile of real work
to do.  ;)

Comment 79 Simon Pickering 2008-11-03 12:55:04 UTC

> > So presumably the first of these was a cold fix, in which case it performed
> > pretty well. Did you delete the nvd_data file for the latter fixes?

> No, I didn't do anything a normal user would do. It was clearly a very casual
> testing made a by someone with a busy agenda on a Monday morning.  :)  

No worries, just wanted to establish the facts :) 

> > I'm
> > guessing not, in which case these were warm/hot fixes, and the later times 
> > are then not so impressive.

> From those times, around 15 seconds are taken by the application just to
> initiatize and show a forst sight on the satellites around. As said, I think
> the experience was "decent" and not "very poor".

Yes, app start-up time is something I'd forgotten. This makes the cold fix even
more impressive and the latter fixes not awful (though really I'd expect a hot
fix to take more like <5s).

> > A-GPS operates at a level below the applications, there's nothing they can 
> > do to take advantage of A-GPS, it happens automatically. Its use (via supld 
> > and gpsdriver) should occur transparently afaiu.

> Then, something weird is happening since I do get a position in the Location
> applet but such location is not shown in the apps.

Yeah, I've never been sure why the location applet has this information (which
should also be present after a normal fix), but it's not output by gpsd. Then
again perhaps it is output by gpsd but the apps choose to ignore it as there's
no fix (to avoid reporting that the GPS actually knows, and not that it's just
using its last known position, etc.) I'll have to take a look at the
maemo-mapper source and check.

> > > - Click Refresh, wlan and GPS are connected, a fix is provided in 19 
> > > seconds.

> > Not too bad. Is this outside again?

> Inside. I didn't go outside again since then because I have a pile of real 
> work to do.  ;)

That's not bad, but of course hard to quantify. SNR comparisons are probably
the way to go (for the rest of us once we've eaten into our piles of real work
;))

how do I enable debug (to create the supld.log files)?

I'm already working on a lot of GPS stuff for my minigpsd program, so while I'm
investigating things I could try correlating fix times (I actually have that
information in raw form in my testing logs since I grab every NMEA string and
I'm often running an external GPS at the same time so would know which
satellites should be visible).

Comment 81 Neil MacLeod 2008-11-03 20:35:30 UTC

@Quim: Did you run supld (AGPS) from the command line? Quite often it will
crash due to a D-Bus error which may give the impression that AGPS is not
helping... you won't get any indication supld has crashed unless you run supld
from the command line before starting the GPS.

Also, could there possibly be a Helsinki bias in the GPS software? I know that
sounds ridiculous but we shouldn't forget Nokia did once ship a firmware with
only the Helsinki timezone!

@tz: supld.log is just the name I gave to the file to which I captured the
output from supld. supld does make mention of a debug directory on mmc2 but
this is always empty - it would be most helpful if we could capture more detail
from both supld and the GPS hardware in locations other than Helsinki which may
help pinpoint any suboptimal behaviour.

Comment 82 Quim Gil 2008-11-04 10:10:14 UTC

(In reply to comment #81)
> @Quim: Did you run supld (AGPS) from the command line?

No, I didn't do anything a normal user would do. :)

> Quite often it will
> crash due to a D-Bus error which may give the impression that AGPS is not
> helping... you won't get any indication supld has crashed unless you run supld
> from the command line before starting the GPS.

Have you filed a bug about this?

> Also, could there possibly be a Helsinki bias in the GPS software? I know that
> sounds ridiculous but we shouldn't forget Nokia did once ship a firmware with
> only the Helsinki timezone!

No idea but... Like what, hardcoding the paths of the satellites in view in
Helsinki's sky?  :)

However, I thought that there could be a bias inside the Nokia Research Center
where I happily work e.g. GPS repeaters and such. This is why I tried again
back home in a plain quiet suburb, and I got almost identical results both
outdoors/indoors.

Comment 83 Simon Pickering 2008-11-04 10:55:13 UTC

If someone's got an N82/N95 and an N810, it would be interesting to compare
SNRs for the two at the same time in the same place (we're interested in
whether the N810 chipset has a fundamentally lower SNR due to antenna position,
etc. here. We might also try testing the speed/quiality of the A-GPS data to
see if there are any differences in the implementation).

for the N95 you could use something like this to view/capture data. E.g.:

http://gagravarr.livejournal.com/104793.html
or
http://discussion.forum.nokia.com/forum/showthread.php?t=108657
or
http://www.symarctic.com/beta/index.php?entry=entry070925-235759

And for the N810 something like this, e.g.:
minigpsd + associated python scripts:
http://www.internettablettalk.com/forums/showthread.php?t=24205&page=16
or
https://garage.maemo.org/projects/gps-saver/


Would this be better taken to the maemo-developers mailing list, rather than
clogging up the bug tracker?

Comment 84 Quim Gil 2008-11-04 11:00:15 UTC

(In reply to comment #83)
> Would this be better taken to the maemo-developers mailing list, rather than
> clogging up the bug tracker?

The point to resolve this bug or not is to find out whether the user experience
is acceptable or not, isn't it. 

Direct comparisons with e.g. the N95 are of course interesting but hopefully
nobody expects the N810 to beat them in order to close this bug. At least you
should calculate timings in proportion to the price of both products.  ;)

Maybe comparing N810 with N800 + cheap external bluetooth SIRF III GPS module
makes more sense if the price is to be considered.

Comment 86 Simon Pickering 2008-11-04 11:48:06 UTC

We already know that a cheap SiRF Star III GPS is significantly better.

My point was to try and narrow down the possibilities for what's causing the
poor GPS performance on the N810. If it comes down to the fact that the N810
antenna isn't as good (or the case is acting as a shield, or some other
physical factor) then the bug can be closed and we will just have to live with
it.

If, on the other hand, the two produce identical SNRs, there must be some
programming issue that's causing the relatively poor N810 performance when
compared with the N82/N95.

Comment 87 Eero Tamminen 2008-11-04 11:55:52 UTC

(In reply to comment #85)
> Maybe comparing N810 with N800 + cheap external bluetooth SIRF III GPS module
> makes more sense if the price is to be considered.

Besides GPS, N810 has also screen that's better in daylight than N800 one, a
keyboard, a light sensor and 2GB internal memory card, but it misses
FM-receiver & 2nd memory card slot and camera orientation is fixed.  Of these
differences, I think keyboard is price-wise the most significant (complicates
device mechanics etc).

(In reply to comment #63)
> That is possible but the dot movement might be so small that you wouldn't
> notice it anyway :) Best way to verify that agps is working is to check how
> many satellites there are in the view. If there is >5 satellites in view right
> after gps is started, then agps has done its job.

It seems that perhaps some interfaces get the apgs data and some don't (as Quim
noticed).

Nokia Maps seems to show ~ a dozen satellites straight after starting with AGPS
turned on, but Maemo Mapper doesn't. Making a little test program that uses
gpsbt_start() (like what Maemo Mapper does), I only see 5 satellites at
startup, from the third value in the $GPGSV lines:
$GPGSV,2,1,05,09,05,259,,10,36,315,,17,34,042,,07,06,098,*79
$GPGSV,2,2,05,28,65,142,*42

Should I file this as a separate bug? The test program is attached anyway.

Created an attachment (id=1027) [details]
Testcase for gpsbt_start

Once I get a fix (which may take 15 minutes even though 6-9 satellites are
visible), there's no problem to follow the position, even when no satellites
are visible during several seconds. But yesterday, I quit the Map application
after getting a fix and restarted it *immediately*, and I could get the new fix
only after 2 minutes. Is that normal? Shouldn't it be immediate?

Comment 91 Simon Pickering 2008-11-04 12:50:23 UTC

> It seems that perhaps some interfaces get the apgs data and some don't (as 
> Quim noticed).

> Nokia Maps seems to show ~ a dozen satellites straight after starting with AGPS
> turned on, but Maemo Mapper doesn't. Making a little test program that uses
> gpsbt_start() (like what Maemo Mapper does), I only see 5 satellites at
> startup, from the third value in the $GPGSV lines:
> $GPGSV,2,1,05,09,05,259,,10,36,315,,17,34,042,,07,06,098,*79
> $GPGSV,2,2,05,28,65,142,*42

Those lines indicate 5 satellites (09, 10, 17, 07, 28), none of which have an
SNR value.

I'm pretty sure I've seen zero-SNR satellites (i.e. from A-GPS) in maemo-mapper
and I've also seen all the (A-GPS provided) satellites vanish. Did you run
maemo-mapper after running the Nokia Map application? Did the GPS shutdown
in-between? I wonder if the nvd_data is correctly written if the GPS doesn't
get a fix while it's running (i.e. is the A-GPS sat data written back to it
even though the GPS never actually saw them)? Or perhaps while the Nokia Map
application was running it did see some of the sats, and it's only those ones
which were saved on shutdown?

Comment 92 Quim Gil 2008-11-04 12:59:14 UTC

(In reply to comment #90)
> Once I get a fix (which may take 15 minutes even though 6-9 satellites are
> visible)

Are you doing this with updated firmware and no hacks in the location
components? Are you under open sky, with limited view or indoors? Do you have
A-GPS installed or not? Can you please try several times chronometer in hand?

Precise reports are more usful at this point. I would set my own testing in
Comment #76 as the lowest quality acceptable.  :)

And yes, do not hesitate opening new reports with precise bugs. Thanks!

(In reply to comment #91)
> > It seems that perhaps some interfaces get the apgs data and some don't (as 
> > Quim noticed).
> 
> > Nokia Maps seems to show ~ a dozen satellites straight after starting with AGPS
> > turned on, but Maemo Mapper doesn't. Making a little test program that uses
> > gpsbt_start() (like what Maemo Mapper does), I only see 5 satellites at
> > startup, from the third value in the $GPGSV lines:
> > $GPGSV,2,1,05,09,05,259,,10,36,315,,17,34,042,,07,06,098,*79
> > $GPGSV,2,2,05,28,65,142,*42
> 
> Those lines indicate 5 satellites (09, 10, 17, 07, 28), none of which have an
> SNR value.
> 
> I'm pretty sure I've seen zero-SNR satellites (i.e. from A-GPS) in maemo-mapper
> and I've also seen all the (A-GPS provided) satellites vanish. Did you run
> maemo-mapper after running the Nokia Map application? Did the GPS shutdown
> in-between? I wonder if the nvd_data is correctly written if the GPS doesn't
> get a fix while it's running (i.e. is the A-GPS sat data written back to it
> even though the GPS never actually saw them)? Or perhaps while the Nokia Map
> application was running it did see some of the sats, and it's only those ones
> which were saved on shutdown?

I've just realised that I was reading direct from /dev/pgps, rather than
connecting to localhost:2947 as is meant to happen. Trying that, I get the full
10 satellites straight away. It's a bit odd - shouldn't it be the GPS chip
itself reporting "phantom" agps satellites, rather than gpsd?

Created an attachment (id=1028) [details]
Better testcase for gpsbt_start using localhost:2947 rather than /dev/pgps

(In reply to comment #92)
> (In reply to comment #90)
> > Once I get a fix (which may take 15 minutes even though 6-9 satellites are
> > visible)
> 
> Are you doing this with updated firmware and no hacks in the location
> components?

4.2008.36-5, no hacks.

> Are you under open sky, with limited view or indoors?

There were trees and I was walking.

> Do you have A-GPS installed or not?

It is installed, but I didn't have a wifi connection at that time.

> Can you please try several times chronometer in hand?

I'll try to do that when I have the time.

The n810's antenna isn't a problem unless it is being shielded by something
outside the n810.  AFTER it acquires the satellites, the signal strength,
retention, etc. is not quite an external GPS, but is better than the early
handhelds with better and bigger internal antennas.

I've already tried this - and the minigpsd program I'm working on logs BOTH gps
units simultaneously - I probably have over 100 hours of logs if anyone wants
to do a comparison.  The only thing is the n810GPS fades indoors faster (I have
to be close to the windows for it to stay connected).

The problem has and always has been Time to first fix.  Most of the time from a
coldstart, but that is the problem in trying to describe it in this thread from
the beginning.  We don't know the state of the black-box that is the GPS other
than it does or doesn't see satellites.  Nor the new attached box with the
supld and agps that sometimes magically makes it lock, sometimes makes no
apparent difference.

For the earlier report of /dev/pgps v.s. gpsd, I suspect that there should be
no difference between the output of pgps and the gpsd port as the latter is a
passthrough for the former (osso-gpsd is an open component).  I assume the AGPS
magic happened between the two different attempts.

(Also, for those in Helsinki - are you constantly near an internet connection? 
Consider if I leave the range of my AP, or am not connected for a while, and
THEN turn the GPS on).

Is the GPS starting cold?  Did the AGPS info give it hints?  Where the hints
right?  Are they fresh? (A satellite display or data image of what GPGSA/GPGSV
should be from supld would help).

And here might be one of the keys

Part of the problem is even with fairly high bars TO START, it might not be
getting enough signal to download the ephemeris or whatever other digital data
correctly from the GPS.  My other GPS units can use a satellite for navigation
at far lower SN levels (just over 20db) than it can "lock" onto it (over 35db),
here "lock" means receiving or downloading data from the satellite.  From a
cold start it needs to see more than one and LOCK for many seconds before it
will get a fix.

I'm not sure how the AGPS and the TI chip interact, but even if it knows which
satellites should be visible, if it needs them to have a constant N-second
internal lock on the satellite, it would cause what we are seeing.  WiFi may
not interfere much, but my best BT GPS unit can't get a fix at all (and it sees
the signals!) when sitting on my Portable Access Point and the tablets have a
10mw and 100mw setting, and the latter if you are far from your AP might be
causing just enough noise.  If the internal satellite lock is being disrupted
every few seconds (checksum errors so it has to wait again for the satellite to
retransmit that block)?

AGPS if I understand is supposed to download the equivalent data via the
internet.  But there seem to be cases where that has happened but the internal
GPS for some reason isn't using it beyond the list (and maybe position) of the
satellites.  It may still want a lock or two.  Instead of one or two gray bars
that never lock, you get a descending series of 8 or more, where the first few
should be strong enough but it stays gray for a minute or two.

Does this AGPS also do ionospheric corrections? (SBAS/WAAS/EGNOS/DGPS stuff)

And I don't know what the big deal with "where are the satellites" that has to
have a special server since the values are public, e.g.:

http://www.nstb.tc.faa.gov/RT_WaasSatelliteStatus.htm

And the tablet should have enough computing power when supplied with the
orbital elements.

Comment 97 Simon Pickering 2008-11-04 15:04:17 UTC

> The n810's antenna isn't a problem unless it is being shielded by something
> outside the n810.  AFTER it acquires the satellites, the signal strength,
> retention, etc. is not quite an external GPS, but is better than the early
> handhelds with better and bigger internal antennas.

Yeah, but different signal strengths are needed to obtain and keep the lock (as
you mention below). If we have some degradation due to shielding it may make
the signal strength too low for the initial fix.

> I've already tried this - and the minigpsd program I'm working on logs BOTH 
> gps units simultaneously - I probably have over 100 hours of logs if anyone 
> wants to do a comparison.  The only thing is the n810GPS fades indoors faster 
> (I have to be close to the windows for it to stay connected).

Unfortunately different manufacturers measure the SNR in different ways
(http://gauss.gge.unb.ca/papers.pdf/SNR.memo.pdf), so it's hard to perform a
direct comparison (unless we use the same chipset & software of course in a
different device). But comparing to a different chipset (that we already know
has better performance, i.e. works inside better) won't establish if it's
solely the signal strength or the firmware that's at fault.

> I'm not sure how the AGPS and the TI chip interact, but even if it knows which
> satellites should be visible, if it needs them to have a constant N-second
> internal lock on the satellite, it would cause what we are seeing. 

A-GPS provides the almanac (gross positions) + ephemeris data for the
satellites in view (fine tuning, including such things as ionospheric
disturbances). The GPS chipset still needs to lock onto the sat and obtain an
accurate time fix before it can start working, but as it knows the position and
speed of the sat it can work out what the Doppler shift will be and therefore
shouldn't need to scan the frequencies to do that.

> And I don't know what the big deal with "where are the satellites" that has to
> have a special server since the values are public, e.g.:

Yes it's of course possible to know the rough position of the satellites some
time into the future (like a couple of months), it depends how much processing
you want to do in the GPS chipset to attain this level of accuracy for your
predictions (not much in this case as we have A-GPS to do it for us ;))

(In reply to comment #96)
> For the earlier report of /dev/pgps v.s. gpsd, I suspect that there should be
> no difference between the output of pgps and the gpsd port as the latter is a
> passthrough for the former (osso-gpsd is an open component).  I assume the AGPS
> magic happened between the two different attempts.

Ah, trying again, that does appear to be the case. No idea why AGPS started
eventually working (it was internet-connected the whole time), but I suppose
that's its nature :)

> Ah, trying again, that does appear to be the case. No idea why AGPS started
> eventually working (it was internet-connected the whole time), but I suppose
> that's its nature :)

And that is the root of the bug.  We have no idea of what the original hardware
"blackbox" is really doing, and the new AGPS "blackbox", other than the number
of satellites.

> Unfortunately different manufacturers measure the SNR in different ways
> (http://gauss.gge.unb.ca/papers.pdf/SNR.memo.pdf), so it's hard to perform a
> direct comparison (unless we use the same chipset & software of course in a
> different device). But comparing to a different chipset (that we already know
> has better performance, i.e. works inside better) won't establish if it's
> solely the signal strength or the firmware that's at fault.

My Wintec 10Hz (5hz if I want WAAS) WBT-300 GBlox based GPS units have a nice
utility and a proprietary sentence that indicates if the satellite is locked
(and how long), and somewhere in there was a note of the SNR level it required.
 It would help if Nokia would give us a clue as to what conditions are needed,
and there is a proprietary nokia sentence.

Although the SNRs differ, my main point is that if I have the n810 and the BT
gps next to each other outside, they should see similar satellites with the
same RELATIVE strength.  And in practice, they do, at least after the AGPS
kicks in.  But I've still seen the many large gray bars stay gray for a long
time.  It sees the satellites, and according to the GPGSV it is getting a good
signal, but it still doesn't get a fix.  Sometimes it goes right from off to
fix in a few seconds.  And there seems to be no pattern.  Sometimes I get a
really fast fix under less than ideal conditions, sometimes the persistent
"good" signal but no fix under open sky.

I can throw practically anything into my minigpsd KML log files (so can Nokia
since I post the GPL source) including the supl time/gconf, but I don't know if
it would help track it down.

I haven't gone through the P?NOK sentences though.  Maybe there is something
interesting in there.

Comment 100 Neil MacLeod 2008-11-04 19:34:27 UTC

(In reply to comment #82)
> Have you filed a bug about this?

Not yet but I will when it happens again.

> No idea but... Like what, hardcoding the paths of the satellites in view in
> Helsinki's sky?  :)

I've no idea either, but as it works reasonably well in Helsinki but poorly in
many other locations you do have to wonder and as I pointed out Nokia do have
previous for this kind of mistake. :)

Comment 101 Neil MacLeod 2008-11-04 19:40:51 UTC

(In reply to comment #90)
> Once I get a fix (which may take 15 minutes even though 6-9 satellites are
> visible), there's no problem to follow the position, even when no satellites
> are visible during several seconds. But yesterday, I quit the Map application
> after getting a fix and restarted it *immediately*, and I could get the new fix
> only after 2 minutes. Is that normal? Shouldn't it be immediate?
> 

See coment 20, this behaviour is not unusual and may be a related issue of the
generally poor GPS performance or may be a seperate issue that would benefit
from it's own bug - it's definately not correct behaviour and should be close
to immediate IMHO. Quim?

The last few days I've been starting supld in xterm and watching what happens
when I start maemo-mapper.

When it works (which is mostly), I can see supld get the data, and maemo-mapper
reports 5-10 satellites.  When this happens I always get a lock within 2 mins
and usually in less than 1 min.  The polar plot of satellites looks pretty much
identical to what I see on a Garmin unit.

However, sometimes, it just doesn't work.  I see supld get the data ok, but
maemo-mapper only shows 1-3 satellites and it can take a long time to get a
lock - more than a half hour.  Also the polar plot of satellites looks nothing
like what I see on the Garmin.

Sometimes starting a-gps and relocating myself fixes this, sometimes it
doesn't. Deleting nvd_data, as some have suggested, doesn't fix it.

Maybe supld is asking for data for the wrong location, or the ephemeris data is
getting mangled?

Sometimes when I start supld, it exits immediately with this message "unable to
acquire dbus service"

If I start maemo-mapper, without running supld in xterm, but watch the internet
connection with tcpdump, I only see the ephemeris data being retrieved about
half the time - this happens even when the GPS has been off long enough for the
ephemeris data to be stale.  If the data isn't retrieved, it takes a long time
to get a lock.  Maybe there is also a problem in the events that lead to the
retrieval of ephemeris data?

Why is an Internet connection required?

First, my apologies for not being as informed on the innards of AGPS as most of
you.  If this is a dumb question, please growl at me and I'll evaporate.

Apparently with AGPS the visible satellite constellation is provided via
Internet, correct?  My five year old Garmin iQue has no Internet connectivity. 
Yet when its GPS is turned on, it immediately displays the constellation for
the last known location, and typically receives several satellites within
seconds.  When it gets a fix, the constellation adjusts somewhat, but most of
the original satellites are in view.

So why can't the Nokia software compute this information?  Most of the time
when I use the GPS, I am not sitting next to a WiFi hot spot.

Created an attachment (id=1031) [details]
Scatterplot, TTF vs time-since-last-fix

Earlier this year, before the A-GPS code was released, I did some tests with my
N810 on my front lawn. This is Vancouver, Canada at (49.16, -123.12), with a
view of about 70% of the sky (there's a 2-story wood-framed house about 6m to
the east, and some small trees to the south) on 27 Apr 2008  about 23:59 GMT.
This is calling the GPS API from C - turning the receiver on, waiting for a
fix, then turning it off (not allowing it to time out, as the map application
does). Generally, with valid almanac data, I got a fix in 19 seconds. Sometimes
it took longer. Waiting a few minutes between fixes had no clear effect on
time-to-fix (there are fewer data points in that region for the obvious reason
that the longer you wait between attempts, the longer it it going to take to
collect data)

Generally, I have been happy with the GPS performance in my car running on
external power, or in my pocket if I leave the GPS on, But in common with
others, I would wish for a faster first fix coming into an unfamiliar city, or
noting where I have parked my car etc.

Created an attachment (id=1032) [details]
Scatterplot, TTF vs time-since-last-fix

See comments for attachment 1031 [details].
I added them in the wrong order. This is the "normal" one, with almanac data
preserved from the previous fix. 1031 shows the time-to-fix when nvd_data is
deleted between fixes, so it
is always a "time-to-first-fix"

Comment 106 Neil MacLeod 2008-11-07 21:20:14 UTC

@Quim - the supld "failure" message is:

----------------------
/home/user # supld
[DEBUG] Connected to DBus
[FATAL] Unable to acquire DBus service: '(null)'.

/home/user #
----------------------

however I'm now thinking it might be the case that supld is already running
(invoked by Maps) and when supld is concurrently run from the command line the
second version bombs straight away, with the above error. If this isn't a
correct observation then the failure is a bug and I'll open a new report.

On Monday I was in a place called Thames Valley Park in Reading (just west of
London) and my N810 managed to get a lock on 4 satellites out of 12 while
standing in clear open blue sky.

Today I came back from Reading on the train and just as we pulled into a
station called North Camp (16 miles from Reading) I whipped out my N85 and
watched as the N85 connected over it's 3G connection to get an approximate
location, then within 20 seconds it had locked onto between 5 and 7 satellites
and accurately located my position.

Concurrent to this I started Maps on the N810 which listed about a dozen
satellites that should have been in view (I presume it used AGPS for this but
as per the comment above the command line version of supld was failing so don't
know for sure) and after 2-3 minutes of waiting the N810 had failed to register
*any* satellite activity - not a single grey bar appeared in that time and
eventually I gave up waiting and closed down the Maps application.

It's clear there is a problem with the N810 GPS - at this time my N810 GPS is
working but only intermittently, and I very much doubt it would be working any
better if I were to send it in for repair (but if it did work better after a
repair then someone isn't telling us something!)

The GPS in the N810 is, quite frankly, hopeless (maybe not in Helsinki, but
pretty much everywhere else!) On the other hand the GPS in the N85 works great
- speaking to the Symbian developers might be an idea?

We somehow need to diagnose (hopefully, together) where the problem lies - is
it possible to produce a version of the GPS software that will output more
debug/diagnostic information that we can feed back to Nokia for analysis? I
don't know how to obtain SNR figures from either the N810 or N85, but it would
be helpful if we could at least tell if the GPS is using AGPS, making use of
stale or AGPS ephemeris/almanac data, SNR figures for various satellites etc. -
logging this to syslog should be adequate or dumping to a file... anything that
would help narrow down where the problem lies.

If the problem is a N810 hardware flaw (poor antennae design, metal case
obstructing signals, poor choice of GPS chip etc.) then fair enough - I can and
would live with that, but if it's a bug we should fix it.

Unfortunately we seem to be fighting a battle just getting someone from Nokia
to accept that there might be a problem in the first place... which is very
frustrating and wouldn't be necessary if closed hardware/software hadn't been
used...

Comment 107 Quim Gil 2008-11-10 14:05:08 UTC

At this point, I still think my Comment 57 is applicable. Most users seem to
get most fixes under 30-60-90 seconds, and A-GPS improves these timings.
attachment 1031 [details] is a good graphical representation illustrating what others
have commented in several comments in this bug.

There are exceptions that bring those timings up, but the Maemo engineers say
that the software preinstalled is doing its work. They don't see anything to be
touched in Diablo to get faster fixes. GPS antenna, hardware clock and
positioning of the satellites are potential reasons external to software why a
fix would be more difficult to get.

In practice this means that the room for improvement in Diablo and the current
hardware, if any, relies on the A-GPS efficiency. If you find potential bugs
related to it, please file them separately. Markko is following the discussion
and his team is working on this component actively.

As said in Comment 57 in our opinion this bug can be resolved since no
additional development or bugfixes are planned in the current release. Maemo 5
comes with a location framework that assumes cellular connectivity, and
therefore is better prepared to get direct comparisons with its Symbian/S60
neighbours.

(In reply to comment #107)
> Most users seem to get most fixes under 30-60-90 seconds,

This is clearly not my case under normal conditions (I mean, under conditions
for which if I already have a fix, then there's no problem at all). So, since
GPS works fine for most users, do you mean that's a hardware defect present on
some of the tablets, which should be returned for repair?

(In reply to comment #97)
> A-GPS provides the almanac (gross positions) + ephemeris data for the
> satellites in view (fine tuning, including such things as ionospheric
> disturbances).

"in view"? What if I'm indoors with wifi connection to retrieve GPS data (but
with no visible satellites) then want to go outside to get a fix a few minutes
later?

Is there a way to know when all the needed data have been retrieved?

It means it is not RESOLVED, it is WONTFIX

1. Whatever is there, hardware/software is broken so that under a clear view of
the sky it takes 5 minutes or more to get a lock (sans AGPS) or it is not
broken and the 5 minutes is expected and normal behavior every time the GPS is
turned on, not just the first time or after a reflash, large location shift, or
other things that every other GPS would have problems with.

2. There is some blackbox saved data whose purpose might be to speed up the
fixes (to maybe 1-2 minutes) by remembering location and/or some other data in
a binary blob, but works infrequently and won't be fixed, or more importantly
won't even be investigated for bugs either with the hardware or software.  This
is at the root of this bug so this is what must be resolved or marked wontfix. 
Saying "resolved" is different from knowing why this is happening to the point
where it can't be fixed or it would be impractical or something else.  AFAIK no
one at Nokia knows why this works sometimes, but not other times.

Note that, for example, if a bug involves negative (West) longitude, you won't
see it in continental europe.  There might be some other overflow or truncation
in the binary blob or up/download which sometimes could be preventing it (and
AGPS!) from accepting data.

3. AGPS has a random but high success rate in getting a fix within about 30
seconds, and although it fails often enough to generate complaints, nothing
more will be done.  It is another binary blob which we have no idea what is
going on when it either works or doesn't, but from the little we can tell fresh
data is apparently available during many of the lock failures.  It also
requires internet connection with some unknown conditions before it will get
data fresh enough for the GPS to lock, and many places people would like to use
the GPS will NOT be anywhere near an access point or WiMax.

I would be willing to say AGPS resolved THIS bug if it actually resolved the
bug.  If there was some icon on the AGPS or location manager screen that when
green  would guarantee that if I used the GPS in the next hour (or at least
some known period) that it would lock in under a minute with a clear view of
the sky, and if that icon was red, I could find a connection and press update
or do something I would know would work to turn it green.  But nothing like
that is available and the GPS frequently won't lock.  It is install AGPS and
hope it works, hope it updated the blob, hope the GPS driver gets the message,
and maybe be lucky enough for it to work this time, but you can't tell. 
Resolving it some or even "most" of the time isn't resolving it.

The frustration is more because we can never trust that it will work when we
turn it on next time.  The built-in mechanism is unreliable, but so is AGPS. 
And maybe it is not AGPS but something at the GPS-driver end.  Without a way of
telling (i.e. AGPS/supld might be working perfectly, when the lock problems
remain) there is no reason to split off a different bug.  This one is for the
GPS system.  The system now has new components, but still doesn't work.

Perhaps it is no longer "very poor" as in the title of the bug, but it is still
"unreliable".

Comment 111 Neil MacLeod 2008-11-10 18:44:30 UTC

(In reply to comment #107)
> At this point, I still think my Comment 57 is applicable. Most users seem to
> get most fixes under 30-60-90 seconds, and A-GPS improves these timings.

How can you explain the difference between an N810+AGPS which *never* gets a
fix and a N85+AGPS that always gets a fix against 6-8 satellites in well under
20 seconds? Same time, same place, very different result.

> As said in Comment 57 in our opinion this bug can be resolved since no
> additional development or bugfixes are planned in the current release. Maemo 5
> comes with a location framework that assumes cellular connectivity, and
> therefore is better prepared to get direct comparisons with its Symbian/S60
> neighbours.

Maybe I've missed the point, but how is a N810 with AGPS over a cellular
connection any different to an N85, or the future Maemo 5 with assumed cellular
connectivity? Isn't the existing N810 AGPS obtaining the same GPS data as the
N85? If so the only difference is then the actual GPS implementation, which
judging by the experience of more than a few N810 users (90 votes!) is simply
not working or working _very_ poorly.

I'd love to be able to get you more detailed diagnostics of what is occurring
on my N810 when I enable GPS but I probably need you to provide me with the
software to generate and collect and then analyse this data.

Whatever you might say, the current N810 implementation is woeful on more than
a few devices and in more than a few locations. I really don't see how the
addition of cellular connectivity will improve the situation when that is
already available (via Bluetooth). I'd like nothing more than to help get to
the bottom of this problem, which trust me really is a problem.

There are at least two problems listed in this bug:

1. GPS never gets a lock even in open skies
2. On the rare occasion the GPS does get a lock, if the GPS is shut down and
then restarted just a few seconds later without moving location the GPS will
fail to get a lock

Dunno what else to say really. If you want to analyse my N810 for a hardware
fault you're more than welcome to come pick it up! :)

I do believe this bug is really fixed (at least in my experience), as fix times
without AGPS have surely improved with the latest firmware release. In any case
I have filled #3851 for the problems I experience with AGPS.

> 3. AGPS has a random but high success rate in getting a fix within about 30
> seconds, and although it fails often enough to generate complaints, nothing

I've been looking at this over the last few days.  What I'm seeing is that when
I start maemo-mapper, maybe 30% of the time,  I see 2-3 satellites and no lock
after a few minutes.  When it's in this state, agps-ui reports the assistance
data is out of date.  "ps" in a terminal window shows supld running.

At this point the gps system appears to be stuck in this state - restarting
maemo-mapper produces no improvement.

You can get the gps to work again by closing maemo-mapper, killing supld, then
starting supld in the terminal and restarting maemo-mapper.

Comment 114 Quim Gil 2008-11-10 22:48:53 UTC

(In reply to comment #110)
> It means it is not RESOLVED, it is WONTFIX

This is just about bugzilla language: "in our opinion this bug can be resolved
since no additional development or bugfixes are planned in the current
release." This time I'm not suggesting whether the resolution should be fixed.
If you prefer wontfix, worksforme, invalid... your choice. At the end the
important piece of information is that the Maemo SW team sees a decent
performance in the software side, no way of improvement in the pre-installed
software and no further development is planned.

With or without location problems you are encouraged to use A-GPS, an
additional piece of software that is under development for Diablo and should be
helpful to get those fixes in decent timings. "Very poor satellite acquisition
with internal GPS" is a different problem than A-GPS issues since it refers to
different components and different test cases. Another reason for us to move
forward onto the specific issues you are having with the A-GPS software.

Is the closed software a problem? I can only repeat that the engineers
responsible of those components are convinced that the closed components are
not causing delays. 

We also see that having all components open would help everybody determining
the responsibilities of software and hardware in this issue. However, it is
simply hard to open pieces of this stack. Starting with the hardware interface
itself (owned by TI) and continuing with the library used to calculate the
fixes (developed by Nokia and containing sensitive data). As said, the fact of
having Nokia investing heavily in a very competitive area doesn't help opening
and sharing either. 

Just for a reference, are there manufacturers and platforms offering a higher
level of openness in the Location area? If so, do they perform better than
Diablo + N810?

To those of you wondering about specific hardware problems in your device, we
have only obvious advice for you. If you are in serious doubt reflash
completely and try out. If you have a friend with another N810 meet up and
compare. Or contact Nokia Care and exercise your customer rights. Maemo SW and
maemo.org can do very little with hardware issues.

Really, we do see the problems some of you are raising here and nobody is
neglecting them. Hopefully it's getting clear though what can cause the
problems, how to deal with them and how to move forward with this discussion.

Closed software wouldn't be a problem if you could simply give some state
information, i.e. if it is doing a coldfix, warmfix, or AGPS assisted fix. 
There is a $PxNOK sentence, so perhaps you could put something in there which
would at least indicate what the chip and driver are trying to do or some
information as to why it isn't locked.  Enumerations or booleans even, but
something that I could say "that is why it is taking so long", or even "it
won't get a lock until the 4th entry goes over 20".  GPGSV doesn't really tell
anyone anything.

As far as openness, I have two WinTec GPS units using a UBLOX chip, and have
used others with Sirf or MTK chipsets, and they have private sentences that
explain what is going on in more detail, scans, lock, etc.  There is probably
proprietary stuff, but I can see far more about the status for almost every
other GPS device I have ever owned (at least 5 different chipsets) by enabling
and looking at the private sentences.  I have the manuals describing both their
special protocol and the NMEA extensions.  Even Garmin's special protocol is
documented and that gives raw data!

And for opensource, there is OpenMoko which has a chip which uses the
hammerhead protocol and there is a GTK frontend already
http://wiki.openmoko.org/wiki/Hardware:AGPS which has links to LOTS of
opensource things going on.  And it might be interesting to try some of them on
the Nokia just in case the chip uses the same protocol.  Or something near
enough to decode.

If you do nothing else but switch to this other chip in the next hardware
revision it would at least allow better efforts to fix this bug.

Comment 116 Eero Tamminen 2008-11-11 09:53:52 UTC

(In reply to comment #113)
> At this point the gps system appears to be stuck in this state - restarting
> maemo-mapper produces no improvement.
> 
> You can get the gps to work again by closing maemo-mapper, killing supld,
> then starting supld in the terminal and restarting maemo-mapper.

If you strace supld, is it doing anything?

(If it threads, you need to check the thread IDs from /proc/PID/task/ and
strace them separately, you don't see threads in top/ps output.)

> ------- Comment #116 from eero.tamminen@nokia.com
> (In reply to comment #113)
>> At this point the gps system appears to be stuck in this state -
>>restarting
>> maemo-mapper produces no improvement.
>>
>> You can get the gps to work again by closing maemo-mapper,
>> killing supld,
>> then starting supld in the terminal and restarting maemo-mapper.
>
> If you strace supld, is it doing anything?
>
> (If it threads, you need to check the thread IDs from
> /proc/PID/task/ and
> strace them separately, you don't see threads in top/ps output.)

The N810 was in a state where supld was running.  agps-ui showed the assistance
data as out of date.  maemo-mapper showed 2 satellites and wouldn't get a fix
after many minutes.

The strace output is below.  The first one is the process you see with ps.  
The second strace is on the process id from /proc/PID/task/

I killed off supld and ran it from the terminal and restarted maemo-mapper. 
You could see it get the assistance data and maemo-mapper  had a fix in less
than a minute.

I was using wifi for all this.



--------------------------------------------------------------
Nokia-N810-23-14:/var/lib/gps# strace -p 13534
Process 13534 attached - interrupt to quit
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN,
revents=POLLIN}], 3, -1) = 1
read(6, "l\1\0\1\0\0\0\0\21\1\0\0~\0\0\0\1\1o\0\20\0\0\0/com/no"..., 2048) =
144
read(6, 0x69888, 2048) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN}], 3,
0) = 0
write(2, "[DEBUG] Message received!!!\n", 28) = 28
write(2, "[DEBUG] Interface: com.nokia.sup"..., 35) = 35
write(2, "[DEBUG] Member: RefreshAssist"..., 37) = 37
write(2, "[DEBUG] Signature: \n", 20) = 20
write(2, "[DEBUG] SUPL_ASSIST_DATA_CACHE_R"..., 43) = 43
writev(6, [{"l\3\1\1#\0\0\0;\0\0\0O\0\0\0\6\1s\0\5\0\0\0:1.25\0\0\0"..., 96},
{"\36\0\0\0A-GPS request interval error"..., 35}], 2) = 131
poll(
--------------------------------------------------------------


--------------------------------------------------------------
Nokia-N810-23-14:/var/lib/gps# strace -p 13536
Process 13536 attached - interrupt to quit
read(7,
--------------------------------------------------------------

I just tried it again - I'm trying to integrate logging so I wanted to see.

AGPS said the data was old and invalid, ls /var/lib/supl/ad_cache was 10am and
I was testing around 7pm

Started map.  No lock.  No bars, no sats

Started location from control panel which started GPSD, no lock.  File was the
same.

Killed supld, ran it from the shell.  It gave a few debug messages.

Restarted control panel location searching - still nothing.

Restarted map.still nothing.

Exited everything.

ad_cache was still 10am.

Note I was near an access point all day (I have a portable version, or am at my
hotel which has one 24/7).

restarted supld.  got a message about libconic, and it updated.  Note the
tablet was connected with wifiinfo running all this time.

So I start the GPS, and it doesn't cause the supld to refresh a number of
times, then it does.

What was or is supposed to happen?

Nokia-N810-WiMAX-36-5:/var/lib/supl# supld
[DEBUG] Connected to DBus
[DEBUG] Got requested service name
[DEBUG] DBus message handler registered
[INFO]  SUPL daemon starting up. 

(******NOTE - the other times it just sat at this point and did nothing for a
minute or two)

[1] + Stopped                    supld
Nokia-N810-WiMAX-36-5:/var/lib/supl# bg
[1] supld
Nokia-N810-WiMAX-36-5:/var/lib/supl# ls -l
total 4
-rw-r--r-- 1 messagebus messagebus 3444 Nov 11 10:46 ad_cache
Nokia-N810-WiMAX-36-5:/var/lib/supl# bg
[1] supld
Nokia-N810-WiMAX-36-5:/var/lib/supl# [DEBUG] Message received!!!
[DEBUG] Interface: com.nokia.supld
[DEBUG] Member:    GetAssistData
[DEBUG] Signature: 
[DEBUG] ASSIST_DATA_REQ
[DEBUG] Starting up thread for SUPL session
[DEBUG] ---------THREAD INIT----------
[DEBUG] Hey! I'm running in a thread
[]HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHh
[]Assistance data requested!
SUPL daemon version is Mon May  5 12:12:24 UTC 2008
SLP address: supl.nokia.com
SLP port: 7275
A-GPS srv address: supl.nokia.com
Position timestamp: 1226017280.000000
Position latitude: 44.096245
Position longitude: -93.246834
Position uncertainty: 300
Previous A-GPS req time: 0
Previous A-GPS req status: 1
A-GPS support: 1
NW INIT enabled: 0
Cached assistance data support: 1
Packet data for assistance data allowed: 1
Preferred connection id: 
SetId NAI: JohnDoe@nokia.com
PSK EMSK: 
Wimax BSID: 
GSM Cell ID by BT support: 0
Debug SLP IP source: provisioned
Debug mode: 0
Debug log folder: /media/mmc2/supllog/
supld[8298]: GLIB DEBUG ConIc - con_ic_connection_send_event(0x6d818,
3350fb2c-d3a1-43eb-bfc2-bf83750230eb, WLAN_INFRA, 0)
[]Assistance data received from SUPL server!
[DEBUG] Hey! Exitting thread
[DEBUG] No more active threads, setting timeout

[DEBUG] ---------THREAD FINISHED------
ls -l
(file was updated)

Comment 119 Marko Nykanen 2008-11-13 08:28:50 UTC

(In reply to comment #117)
> The N810 was in a state where supld was running.  agps-ui showed the assistance
> data as out of date.  maemo-mapper showed 2 satellites and wouldn't get a fix
> after many minutes.
> 
> The strace output is below.  The first one is the process you see with ps.  
> The second strace is on the process id from /proc/PID/task/
> 
> I killed off supld and ran it from the terminal and restarted maemo-mapper. 
> You could see it get the assistance data and maemo-mapper  had a fix in less
> than a minute.
> 
> I was using wifi for all this.
> 
> 
> 
> --------------------------------------------------------------
> Nokia-N810-23-14:/var/lib/gps# strace -p 13534
> Process 13534 attached - interrupt to quit
> poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN,
> revents=POLLIN}], 3, -1) = 1
> read(6, "l\1\0\1\0\0\0\0\21\1\0\0~\0\0\0\1\1o\0\20\0\0\0/com/no"..., 2048) =
> 144
> read(6, 0x69888, 2048) = -1 EAGAIN (Resource temporarily unavailable)
> poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=6, events=POLLIN}], 3,
> 0) = 0
> write(2, "[DEBUG] Message received!!!\n", 28) = 28
> write(2, "[DEBUG] Interface: com.nokia.sup"..., 35) = 35
> write(2, "[DEBUG] Member: RefreshAssist"..., 37) = 37
> write(2, "[DEBUG] Signature: \n", 20) = 20
> write(2, "[DEBUG] SUPL_ASSIST_DATA_CACHE_R"..., 43) = 43
> writev(6, [{"l\3\1\1#\0\0\0;\0\0\0O\0\0\0\6\1s\0\5\0\0\0:1.25\0\0\0"..., 96},
> {"\36\0\0\0A-GPS request interval error"..., 35}], 2) = 131
> poll(
> --------------------------------------------------------------
> 
> 
> --------------------------------------------------------------
> Nokia-N810-23-14:/var/lib/gps# strace -p 13536
> Process 13536 attached - interrupt to quit
> read(7,
> --------------------------------------------------------------
> 

File a new bug of this issue.

AGPS says:
Cache refreshed Nov 14 2:49 pm 2008
Cached data is not valid

supld is running (ps shows it).

It has been near an access point from that time until now (8am on Nov 15).

When I killed and restarted supld, then restarted the map/gps, it downloaded
the fix information almost immediately.

I also had the GPS on and off during this period.  I was ssh-ed to it several
times so it WAS connected.

I keep asking for a "force agps update now".  Instead I can at least get the
"cache data not valid - last refreshed yesterday" while I'm listing to a live
internet stream and have no idea why it isn't refreshing.

One other thing I noticed - It was updating constantly every 30 minutes, but if
the tablet was indoors with the GPS on for a while (>5 minutes) so it could not
get a lock, if I went outdoors, it would not get a lock (>5 minutes) until I
shut down and restarted the GPS, at which point it locked in under 30 seconds.

There seems to be something wrong with the GPS still BELOW the agps/supld.  If
it locks quickly, it gets better and stays on.  If it cannot lock, it seems to
keep getting farther off until it all but refuses to lock EVEN WITH FRESH,
CORRECT, AGPS DATA which it is using by having 8+ bars showing.

I need to repeat this a few times (my original n810 is fixed!) but perhaps
others can perform the experiment too.

Indoors (or otherwise out of GPS signal range), insure the cache has just been
refreshed using the latest agps-ui, then start the gps (which should display
lots of bars), but wait 5 minutes indoors, then walk outside and see how long
it takes to lock.  If it doesn't after several minutes, stop and restart the
GPS and see how long it takes to lock.

Comment 121 Neil MacLeod 2008-11-15 21:39:21 UTC

(In reply to comment #120)
> AGPS says:
> Cache refreshed Nov 14 2:49 pm 2008
> Cached data is not valid
> 
> supld is running (ps shows it).
> 
> It has been near an access point from that time until now (8am on Nov 15).
> 
> When I killed and restarted supld, then restarted the map/gps, it downloaded
> the fix information almost immediately.
> 

I can confirm this exact behaviour although I just killed supld and allowed the
GPS to restart supld automatically, at which point agps-ui declared the cache
was now valid (hadn't updated cache since 9 November despite being sat on a
WiFi connection 24x7 since that date).

However as there are no bugs in the GPS software it must be in our
imagination... ;)

Hanging daemons seem to be a fact of life with Maemo - I wonder if supld
hanging is related to the Modest hang bug (bug 3641)?

> However as there are no bugs in the GPS software it must be in our
> imagination... ;)
> 
> Hanging daemons seem to be a fact of life with Maemo - I wonder if supld
> hanging is related to the Modest hang bug (bug 3641)?

Or maybe with dbus or with conic somehow getting confused and not sending or
receiving messages to (re)connect properly.  If the wlan gets stuck in
power-down, it would affect both similarly.

It may not be in the software, it might be the hardware that needs a kick if it
doesn't get sufficient signal within N minutes from original restart.

I've been researching this problem and have found that not being able to get a
fix is related to a corrupted /var/lib/gps/nvd_data that is created by an used
by the GPS driver. The following link is to a section of the Maemo Mapper HowTo
I wrote. The section provides more insight into the issue and how I got things
working. Far from a solution it may be helpful in creating a real fix. 

http://fragostech.com/MaemoMapper/#lockfailure

Comment 124 Quim Gil 2008-11-17 09:17:15 UTC

Just for the record:

Bug 3851 AGPS not helping to get a lock under clear sky
Bug 3862 AGPS UI is hard to use, doesn't actually get satellite data

Note also that in Bug 3862 Comment 1 Markko is mentioning a new version of
supld with improvements.

Feedback on AGPS and related non-preinstalled components is welcome in those
bugs or new ones. Let's limit the scope of this bug to the internal GPS and the
software pre-installed.

Comment 125 Simon Pickering 2008-11-17 12:33:31 UTC

One thing to remember, for those doing these tests, is that the supl data won't
be updated while the GPS chipset is up and running (there's no point as the GPS
to write its refreshed data back to the nvd_data file).

It would be interesting to hear (or see, hint, hint ;) what happens when the
GPS shuts down without obtaining a lock - is any satellite data that was
obtained written to the nvd_data file (e.g. can almanac alone be written, or
almanac + ephemeris for only a couple of satellites without having a fix?)

(In reply to comment #125)
> One thing to remember, for those doing these tests, is that the supl data won't
> be updated while the GPS chipset is up and running (there's no point as the GPS
> to write its refreshed data back to the nvd_data file).

I am not sure that this is quite accurate.

The data IS updated, apparently in the background if there is a wifi
connection, and I think I've seen it go from 1-3 bars to 8+ just after startup
(when the wifi had to connect to update the data).

Also, I think the possible corrupt nvd_data file has a lot of merit.  I've been
experimenting and things will take the longer time but be much more RELIABLE if
I delete this file before starting the GPS (under a clear sky).

I'm beginning to suspect that if the GPS spends a long time where it loses or
can't get a lock, and saves the nvd_data file in that state, it will "resume"
in that lost state and have lots of trouble getting a lock (even with good AGPS
data).

Since I now have my old n810 back from repair I should write a test program
that tries various things and watches this file.  Saving off the nvd_data and
just comparing the content along with "locks/doesn't lock" might be
informative.

And a Thankyou to Quim!

The problem is still present with 4.1.3 (you can update the version, I don't
have the permission to do it): Yesterday, after 12 minutes, with 3 to 5
satellites *constantly* visible, I didn't manage to get a fix. No AGPS, because
where I was, there was no wifi connection (but I don't think 12 minutes without
a fix is normal, even without AGPS).

(In reply to comment #127)
> (but I don't think 12 minutes without
> a fix is normal, even without AGPS).

Yes, is normal:
http://en.wikipedia.org/wiki/Time_to_first_fix
The problem is the data not being cached and reused properly, it seems.

(In reply to comment #128)
> http://en.wikipedia.org/wiki/Time_to_first_fix
> The problem is the data not being cached and reused properly, it seems.

Thanks. So, this contradicts information given in bug 3850 by Quim Gil (who was
talking about up to 1 minute to get a fix). BTW, I'm not even sure that data
were cached since this was after an upgrade of Map.

Did you try removing the /var/lib/gps/nvd_data file and try again?

(In reply to comment #130)
> Did you try removing the /var/lib/gps/nvd_data file and try again?

No, I couldn't try.

Today, it started with some list of satellites, but didn't find any signal!

I don't know what you mean by "couldn't try" - is the file not there, or can't
you delete it?

(In reply to comment #132)
> I don't know what you mean by "couldn't try" - is the file not there, or can't
> you delete it?

I can delete it, but I wasn't outside any longer.

BTW, after deleting this file, if I run Map indoors, with no visible satellites
and no wifi connection, the file is created with some data in it (that are not
all zeros). I wonder where these data come from.

I tried again today, at the same place (where I was waiting for the bus): I
removed the /var/lib/gps/nvd_data file. But Map filled all the memory and
crashed. Even after quitting all the applications (that is, RSS feed reader and
X Terminal), the memory was still full!

So, I rebooted my N810. I removed /var/lib/gps/nvd_data again and restarted
Map. Then the bus came. So, I put the tablet in my pocket. When I took it a few
minutes later, I saw I obtained a fix.

Comment 135 Eero Tamminen 2008-12-29 14:10:02 UTC

(In reply to comment #134)
> I tried again today, at the same place (where I was waiting for the bus): I
> removed the /var/lib/gps/nvd_data file. But Map filled all the memory and
> crashed. Even after quitting all the applications (that is, RSS feed reader
> and X Terminal), the memory was still full!

If you're a power user, you could check "top" output (after pressing "M" to
sort by memory usage) in terminal to see whether it was still running in the
background (if yes, should be reported separately).  There might also be some
other processes that use memory.

(For example some of the codecs leak a bit of memory, so if you've watched e.g.
many hours of Windows Media content, you might need to restart
osso-media-server to reclaim the memory it uses.  3rd party Home & Statusbar
applets can also leak memory which is even worse because Desktop is
out-of-memory protected.  To reclaim that memory, Desktop needs to be
restarted.)


> So, I rebooted my N810.

Reboot restarts everything, if you want to restart just some particular
services (like media-server or Desktop), you could stop & start them using
their init scripts from the terminal.  Most of the services are run as user so
you don't even need root for that (for Desktop case, it's better just to
disable altogether the applets that you don't really need before restarting).

(In reply to comment #135)
> If you're a power user, you could check "top" output (after pressing "M" to
> sort by memory usage) in terminal to see whether it was still running in the
> background (if yes, should be reported separately).  There might also be some
> other processes that use memory.

I don't remember exactly, but the system asked me to quit these applications.
I'm not sure if it was possible to restart the terminal (because of lack of
memory).

Well let me tell you my story. After a while I gave up on the n810, but Im a
seasons kind of guy, and I started too look again for a solution to 1) useless
gps software such as Mmapper(pretty and all but doesnt help at all when your
lost) or Wayfinder (wayfinder is uslees because I live in Latin america and you
have to fork over money) 2) the ridiculous time it takes to lock or the little
time it takes to loose signal.

Solution #1

NAVIT!!!! cool new software that reads vector maps and its FREE!!!(its still a
little buggy and requires a little time to config but whats even better, IT
READS GARMIN MAPS!! GAAARMIIIN!!!!

Solution #2

I downloaded the so called A-gps even though I didnt know what tha **** was
for, until I read about it and how it works on the nokia site (yes nokia
actually did help with the device they sold and manufactured and put in a
package to let others do the fixing for them). Let me explain the steps I took
to see if they work for you

1. Open A-gps settings, Click all of the options. (if you have cell phone
internet I recomend something with Edge).Then used my Davinci painting
precision hand, to click on the nearest i could get to my previously known
coordinates EXIT
2. Shutdown the device, turned it back on
3. Go outside of my house, clear sky, open the application called Maps (It
started trying to connect to my cel phone via Btooth)
4. I took the gps 30-50 seconds to get a lock on the sattelites
5. Shutdown, and restarted the device again
6. Opened Maemo Crapper. (it didnt try to conect to my cell phone) 30-50
seconds to lock AGAIN!!!!
7. Shutdown, restart the device again!again!
8. Opend Control panel, went into GPs location>location, clicked refresh. It
took again 30-50s to LOCK. AGAIN after 3 cold starts.

So Im not going to say im happy, Ill say Im finally happy, and waiting to be
even more when Navit gets out of alfa state
Edit/Delete Message(In reply to comment #136)
> (In reply to comment #135)
> > If you're a power user, you could check "top" output (after pressing "M" to
> > sort by memory usage) in terminal to see whether it was still running in the
> > background (if yes, should be reported separately).  There might also be some
> > other processes that use memory.
> 
> I don't remember exactly, but the system asked me to quit these applications.
> I'm not sure if it was possible to restart the terminal (because of lack of
> memory).
>

Article with explanation of what is going on:

http://gpsinformation.net/main/gpslock.htm

And there are lots of other articles:

http://gpsinformation.net/

From the article (which might explain why it tends to stay drifted):

The second dimension is frequency. The receiver must correct for
inaccuracies in the apparent doppler frequency of the satellite and
"zero-beat" the signal. For reasons that I won't go into here (related to
the 1 msec code repeat cycle and a fellow named Nyquist), the coarsest
frequency steps a receiver can take during initial acquisition is 500 Hz,
but the receiver's crystal oscillator may be off by up to +/- 10 kHz or
so, so there are 20ish frequency cells that have to be tested. And this
process must happen for all N satellites that are in use. So, the
acquisition process can be quite laborious.

The usual search strategy is to start at an oscillator frequency
predicted on the basis of (a) what is my approximate position? (based on
either the last known position or the guess you "typed in"), (b) where
are the satellites now and what is their apparent velocity (based on the
almanac data downlinked from the satellite and stored in the receiver's
memory), and (c) what is the best guess for the receiver's crystal
oscillator error (based on the last known error and the current
temperature). At this frequency, the receiver tries all 1023 possible
code phases and if it sees some power, it will initiate a finer search.
If none of the 1023 states "smells" a satellite, it offsets the
oscillator to the next test value and repeats the process until something
"smells promising".

When you start "blinded", the receiver goes thru its initial search,
finds nothing and steps outwards. After a long while it may decide to
start all over again at the "zero" predicted value, or it may continue
into oblivion and initiate an "all sky" search on its own.

Comment 139 Quim Gil 2009-05-10 01:17:17 UTC

Hi, an update:

There is no more development in the location framework for Diablo. All th work
is being done on Fremantle at the moment.

Maemo 5 comes with HSPA support, which implies a whole change in the way the
location framework is organized. It is assumed that devices have data
connectivity available, A-GPS is well integrated and the efficiency getting
coarse fixes is equivalent to the rest of Nokia devices offering location
software.

The fine accuracy provided by the internal GPS comes right after that, in
decent time. Even right after flashing and with no data connectivity a first
fix is obtained in a decent period of time.

Sorry but I can't provide here results of tests, and not even the home made
tests with my N810 I could share here months ago. In any case I believe the
Maemo 5 users won't be upset by GPS fixes and tracking.

Now, if someone wants to figure out the right resolution for this bug...

Comment 140 Neil MacLeod 2009-05-10 05:01:05 UTC

(In reply to comment #139)
>
> Now, if someone wants to figure out the right resolution for this bug...
> 

Sounds like another WONTFIX to me, same as all the other bugs in Diablo that
will never be fixed. And you seriously expect people to invest time & money in
your next OS?!

so, AIUI, the strange problem of why the n810's ability to get a GPS fix hasn't
been resolved, all we know is that Nokia's developers say "it works for me
(TM)" in Helsinki. 
meanwhile no documentation has been provided at all to let people who live
where it doesn't work attempt to discover why and feed back debug information
to Nokia so that they might get some insight.

now, I have sympathy with Nokia in that if they cannot reproduce a fault then
they cannot fix it except by code inspection and guesswork. could someone not
set up a VPN connection from a tablet where the GPS won't lock so that a Nokia
engineer could login and see what's happening? If I had an n810 I'd be offering
that service.

Comment 142 Quim Gil 2009-05-11 10:56:08 UTC

My Comment #57 stands. A-GPS + internal GPS provide a decent (even if not
optimal) user experience for most users. It's not only Maemo SW people like me
saying the experience is fine, you do find users happy about their exoeriences,
or at least not so upset to consider the situation a big.

But I'm not even trying to push a FIXED resolution for Diablo if you don't
accept it. I'm just saying that location based on internal GPS alone works fine
in Fremantle, and that we are not putting more development resources in the
location framework of Diablo.

As I've reported, there is a problem when the nvd_data file gets corrupted,
usually from being indoors for too long with the GPS active but unable to lock.
 If it "remembers" these bad values even with AGPS it will refuse to lock for a
long time even under an open sky.  I don't have data on the format of this file
(but can guess several sections are for the satellite).

Perhaps if a good AGPS data (which is NOT available everywhere) would delete
this file or otherwise reset the search it would fix this, or if it doesn't get
a lock for a long time it would ignore the file or something.

But I've been able to get this to repeat (I now have two N810s so it is easier
to show).  It doesn't always happen, but does follow the nvd_data file (i.e.
swapping the files across the tablets moves which one has problems).

Now if someone would tell me how to get the information on the Ti GPS chip
inside, or the format of this file, I might be able to do more...

Just for the record, I was on vacation in Paris and used the N810 GPS. First
lock though a while, but not too much (about 1min or 2). Then I walked the
streets, I even though the metro where it lost the signal, but as soon as I was
on open sky I got the fix immediately.

The 2nd day I didn't turn the device on until I was in Versailles, totally open
sky in the middle of the garden, I turned it on... I waited *30min* with no
lock! It showed me 6 satelits... I finally rebooted it and I got a lock in no
time...

Definitely a bug here. I can understand that Nokia can't fix that now that they
are working on next generation software. Tbh I don't complain much because I
had my N810 for 100€ thanks to Nokia's offer... But if I had to pay to full
price for that result I would be totally upset by Nokia.

(In reply to comment #144)
> The 2nd day I didn't turn the device on until I was in Versailles, totally
> open sky in the middle of the garden, I turned it on... I waited *30min*
> with no lock! It showed me 6 satelits...

I typically had this problem in the past. Now I always delete the nvd_data file
and GPS works without much problems after that.

> I finally rebooted it and I got a lock in no time...

Does anyone know what happens to the nvd_data file after a reboot?

Comment 146 Quim Gil 2009-05-19 01:27:00 UTC

(In reply to comment #140)
> Sounds like another WONTFIX to me

Resolved like WONTFIX, then.

Comment 147 Eric Warnke 2009-05-19 04:13:44 UTC

(In reply to comment #146)
> (In reply to comment #140)
> > Sounds like another WONTFIX to me
> 
> Resolved like WONTFIX, then.
> 

If you are not investing any more time in Diablo then you might as well close
90% of the bugs here and abandon your only *actual users* at this point. 
Comments #143, #144, and #145 show a clear bug with the current A-GPS software
in a portion which, from my reading, is closed Nokia code.

If the resolution is to remove A-GPS then the TTF is still a big problem, if we
leave A-GPS there we have to reboot/muck around a root to clear a bug in the
Nokia A-GPS code.

Maybe we can move the documented A-GPS bug to another report or is that a moot
point now that fremantle is in the works?

Comment 148 Simon Pickering 2009-05-19 11:24:02 UTC

What are the chances of open-sourcing gpsdriver?

Assuming this is not a hardware/physical problem with the location of the GPS
receiver (i.e. it's not getting a very good signal) though I think this has
probably got something to do with the poor performance, and assuming we're not
going to be able to obtain any information about the innards of the GPS chipset
(so we can't do any reprogramming there, even if it were possible), the only
other possibilities are to look at whether the gps chipset is getting confused
if it's sent either corrupt or old data from the nvd_data file. 

If we could hack gpsdriver we could work out if either of this is the case, and
it would make people happy too (hearts and minds and all that ;)).

Now I imagine there are probably some NDAs and such in place as it interfaces
with the Ti GPS chipset, is this the case? I guess that if it is the case,
Nokia don't currently have the manpower/will to spend on splitting the gps
driver into a binary interface to the proprietary code + open source that we
can look at?

For that matter, I would sign an NDA, although I've decoded part of the
nvd_data file (not that I know what everything means though a large portion
seems to be per satellite with ephemeris, doppler corrections, and the like,
but have not found any specific bytes which seem to be involved when it refuses
to lock.).

It might be possible with enough samples of nvd_data files with whether it was
jamming or locking to figure something out.

You won't have AGPS everywhere, so I hope the new device uses a new chip.

And a bad nvd_data WILL override good AGPS in some cases.

The gpsdriver program appears to simply decode serial output (ttyS1?) in some
form of stx/etx packet format into standard NMEA.  If you enable the GPS, you
can easily capture the serial port output, but decoding it is a bit more
difficult.

Comment 150 Andre Klapper 2009-05-19 12:47:07 UTC

(In reply to comment #148)
> What are the chances of open-sourcing gpsdriver?

Nokians can probably answer this best. If there's at least some chances, please
file a new enhancement request about it and copy the (good) arguments.

Comment 151 Simon Pickering 2009-05-19 13:01:26 UTC

Well this one is related: https://bugs.maemo.org/show_bug.cgi?id=3833

and this is the very question, which is marked WONTFIX:
https://bugs.maemo.org/show_bug.cgi?id=4380 though it's for a different reason
(porting to another platform). Perhaps this could be reviewed?

Otherwise I guess reverse engineering is the only solution.

When the n810 product was advertised 1.5 years ago the GPS/maps feature was one
of the main emphasized features (man in marketing video walks around navigating
with n810).

GPS fix never worked for me reliably. I tried a couple of times, but gave up
frustrated after waiting endlessly in 80% of my attempts to get a fix. Yes I
had tried the A-GPS feature but couldn't understand why it didn't help. Hearing
that 1.5 years after market introduction this primary feature of a 500 € device
still hasn't been fixed, and is not going to be fixed, is very disappointing.
It may stop me from buying future Nokia navigation devices. Sorry for the
bugspam.

(In reply to comment #152)
> GPS fix never worked for me reliably. I tried a couple of times, but gave up
> frustrated after waiting endlessly in 80% of my attempts to get a fix. Yes I
> had tried the A-GPS feature but couldn't understand why it didn't help. Hearing
> that 1.5 years after market introduction this primary feature of a 500 €
> device still hasn't been fixed, and is not going to be fixed, is very
> disappointing. It may stop me from buying future Nokia navigation devices.
> Sorry for the bugspam.

I totally sympathise as I have had exactly the same poor reliability from the
N810's GPS. I never use it for GPS because I cannot rely on it working most of
the time.

I don't think this is a problem with Nokia as a manufacturer though. ALL of the
other Nokia GPS devices I've ever tried have worked much much better than the
N810 (for example the Nokia 5800 gets a lock even when indoors, and even older
hardware like the N95 totally outperforms the N810's GPS). All of Nokia's
devices have been very useful GPS devices for me... except the N810.

What needs to be dealt with by Nokia is whether the N810's problem is the
hardware (does it use a different chip to Nokia's GPS phones?) or the software
(is Symbian much better at handling GPS than Maemo?) or a combination of the
two, and Nokia needs to take action to make sure these problems don't repeat
themselves on future Maemo devices.

Comment 154 Eero Tamminen 2009-05-19 19:46:30 UTC

(In reply to comment #153)
> I don't think this is a problem with Nokia as a manufacturer though. ALL of the
> other Nokia GPS devices I've ever tried have worked much much better than the
> N810 (for example the Nokia 5800 gets a lock even when indoors, and even older
> hardware like the N95 totally outperforms the N810's GPS). All of Nokia's
> devices have been very useful GPS devices for me... except the N810.

Phones get initial position from phone network and because of the phone side,
they also have more accurate clock.  Especially former helps a lot with GPS
functionality.

(In reply to comment #154)
> Phones get initial position from phone network and because of the phone side,
> they also have more accurate clock.  Especially former helps a lot with GPS
> functionality.

Nokia said that the next Maemo device will have HSPA. Does that mean it could
theoretically use the same positioning techniques as phones?

(In reply to comment #154)
> and because of the phone side, they also have more accurate clock.

Still, running ntpd (usually much more accurate than the operator's idea of the
time) hasn't improved things for me.

I have to say that most of the time, the GPS works for me and I do often use
it. E.g. download a route to some street address, then start up Maemo Mapper
and open the route before I leave home. That way the A-GPS can get an update
over WLAN even if the GPS can't yet see any satellites, and by the time I've
gone too far up the road, I have a fix and can route to it. I also use recorded
tracks to geotag digital photos, and have used SMS to send my location to
Twitter while on the road.
But I have also on occasion been unable to get a fix for many minutes,
documented in my earlier attachments. Being unable to rely on it when, say,
emerging from a subway exit and walking to an unknown address is understandably
frustrating. After all this time, I still don't know whether there is anything
more that could be done in software, or whether it's a hardware/physics issue -
if you are unlucky enough to try for a first fix when there are only 2
satellites visible, plus a reflection from a building, and your clock is a bit
off, using a tiny antenna that isn't pointing in the optimal direction, maybe
it just isn't going to work.

Comment 158 Neil MacLeod 2009-08-27 12:05:18 UTC

It seems that some N97 devices also have very poor GPS acquisition and without
any acknowledgement so far from Nokia, speculation is pointing towards a
manufacturing or design flaw affecting early build devices.

A lengthy thread on the Nokia support form has all the details and in
particular the following post has a video comparing a recently purchased N97
(gps lock in 10 seconds) and one from the first few batches (gps lock in 28
minutes):

http://discussions.europe.nokia.com/discussions/board/message?board.id=navigation&view=by_date_ascending&message.id=13305#M13305

Perhaps lightning has struck twice and this could explain why _some_ N810s have
very poor GPS (leading to corruption of nvd_data?) while others do not.

Hopefully the N900 will be third time lucky...

For what it's worth, my Nokia 5800's GPS locks more quickly and stays locked
much more reliably than my N97.

But the N97 is still much much much better than the N810. I can use my N97 to
navigate, while the N810 simply doesn't lock quickly or reliably enough for
navigation to be practical.

There are three odd things about the 5800 outperforming the N97 which may have
implications for the N810's problems too:

The 5800 is a very similar device to the N97, it uses the same OS version and
has similar computing hardware.

The N97 hardware costs about twice the unsubsidised price of the 5800 hardware.

The N97 came out six months after the 5800, so Nokia had more development time
on the N97.

...which implies GPS problems aren't necessarily cheap hardware because in this
case the much cheaper hardware actually does better than the expensive
hardware. It also implies that design times and OS versions aren't necessarily
a factor either, because the 5800 had less design time and uses the same OS
version.

Perhaps it's something about the designs themselves, or the type of GPS
hardware used, or a combination of the two. Perhaps certain device designs suit
certain types of GPS hardware? Maybe the GPS aerial is in a better place on the
5800, or maybe it is a better quality aerial?

Whatever the cause, it looks like the N810's GPS problems will never be
solved...

Hopefully Nokia can look at the 5800/N97 situation and learn lessons about what
makes GPS work at its best on their devices.

To Krisse's points: there are so many design and technology variables at play
here.  I could move the exact same cicruitry from one housing to another and
see drastically different levels of performance-- especially if, say, I went
from plastic to metal.  And that's just one factor of many.  Root GPS
components could be the same, yet hampered by selection of poor supporting
components (capacitors and diodes are good culprits here, as I have encountered
quality problems with those components in the past).  Then there's drivers,
application, etc.

My entirely speculative assessment is that the field trial segment of N810
testing was too short, or the test protocol inadequate.  I can certainly see
the latter being possible-- I had to expand the N800 factory test protocol that
I had been provided because it didn't take into account some critical features
and failure modes.

My one hope is that lessons were learned and factored into current and future
development.  Ah, how I miss running corrective action projects... :D

Interesting to hear this comment:

(In reply to comment #160)
> To Krisse's points: there are so many design and technology variables at play
> here.  I could move the exact same cicruitry from one housing to another and
> see drastically different levels of performance-- especially if, say, I went
> from plastic to metal.

Based on my experiences with first batch examples of each device:

5800 - highest quality GPS, no metal in casing
N97 - moderate quality GPS, some metal in casing
N810 - lowest quality GPS, lots of metal in casing

Could it be that Nokia's quality control is somehow failing to make allowances
for the effect of metal in the casing?

One way of testing this would be to see how the N810 hardware performs when you
remove it from its casing. Has anyone done this?

I don't know of any such testing, but it is interesting to see your
correlations.  I know that there are larger GPS units sold in aluminum
housings, and perhaps other alloys, but again maybe it isn't as simple as just
a metal housing.  I would not be surprised to find that the choice of a metal
housing requires compensatory moves in antenna design, power, etc.

I now have a Nokia E71 which has a lot of metal in its body, and its GPS
performance is mediocre - useable but you have to be outdoors or at least next
to a window with 90 degree clear view of the sky. I think, but cannot be sure
as the diagnostics are not particularly brilliant, but the A-GPS does improve
lock time quite a bit.

Work provides me with a Nokia 6300, plain old GSM phone, and if GSM signal is
low I can get better coverage by removing the thick metal battery cover which
covers 80% of the back of the phone.

Comment 164 Simon Pickering 2009-09-01 13:36:07 UTC

After some talking on #maemo, it has been concluded that gpsdriver does
significantly more than just feeding the GPS chipset with the contents of
nvd_data. In fact it almost certainly uses the data contained therein itself
and performs the location calculations using raw low-level data supplied by the
GPS chipset. This may have been mentioned before, but I at least just assumed
that the chipset would do the whole deal and just directly spit out NMEA
strings. Apparently I was wrong.

Therefore, it may be possible to improve the performance of the GPS by
re-implementing gpsdriver (with the added benefit of making the resultant code
GPL). 

However, gpsdriver may be completely without fault and the real cause may well
be antenna placement, etc., but at least this would give us something useful
and interesting to do.

You can see what is coming out of the chip - use GPS driver to enable the chip
(it needs to be sent a P 3 or something - I do this in minigpsd), then you can
simply do "cat /dev/ttyS0" (it may be ttyS1) to a file to see the binary stream
from the chip.

The chip is what tracks the satellites and decodes at least the first level of
data from the satellites, but locking in itself has to be done by the chip.  (I
don't have pointers to the articles, but in order to lock it has to compensate
for the doppler shift, find the data frames, etc. and it helps to know
approximately where the satellite is).

Deleting the nav_data file helps when it seems to not want to lock in so I
assume it has something to do with the chip but would not be sent raw (maybe a
series of register address, data image messages).  But the chip is doing the
tuning and turning the satellite signal into something digital.

Very good information coming out of this... data that could at least be plugged
back into product development and testing.  I hope it's getting to the right
eyes and ears!  ; )

-Texrat