Confirming.

It's not just the dbus interface either: using the gpsd c library does the same
thing. I tested with an external gps device, and the NMEA seems correct but
gpsd is 24h wrong:

actual UTC time:
1201992380
(meaning 02 Feb 08 22:46.20)

NMEA: 
$GPRMC,224110.777,V,,,,,,,020208,,,N*46
(meaning 02/Feb/08 22:41.10)

gpsd fix time:
1202079062
(meaning 03 Feb 08 22:51.02)
         ^^


Ouch.

This is a leap year bug, and is fixed in gpsd 2.36. Things should work right
again after Feb 28th.

Still, here's a patch that seems to work:

diff --normal osso-gpsd-1.0-orig/gpsutils.c osso-gpsd-1.0/gpsutils.c
84a85,88
>     if ((year % 4) == 0 && ((year % 100) != 0 || (year % 400) == 0) &&
>        (t->tm_mon % MONTHSPERYEAR) < 2)
>             result--;
> 



Of course I can't be _sure_ it works since the last available source version is
 1.0-23 while the binary on OS2008 is 1.0-25.

Something that is even more weird:

When a lock is acquired, the first couple of fixes report a date in February
2036:

signal sender=:1.87 -> dest=(null destination) path=/org/gpsd;
interface=org.gpsd; member=fix
   double 2.08591e+09

Not sure if this is specific to the internal GPS yet.

(In reply to comment #3)
> Something that is even more weird:
> 
> When a lock is acquired, the first couple of fixes report a date in February
> 2036:
> 
> signal sender=:1.87 -> dest=(null destination) path=/org/gpsd;
> interface=org.gpsd; member=fix
>    double 2.08591e+09
> 
> Not sure if this is specific to the internal GPS yet.
> 

This is no doubt because of NMEA weirdness -- only one NMEA message contains
the year (IIRC) and any position messages before that won't contain a valid
date.

Still, it probably has nothing to with this bug, so I suggest you file another
bug if you're interested...

(In reply to comment #2)
> Of course I can't be _sure_ it works since the last available source version is
>  1.0-23 while the binary on OS2008 is 1.0-25.
> 

I was wrong on this btw, chinook only has -23, but the OS2008 source dir has
-25:
http://repository.maemo.org/pool/os2008/free/source/o/osso-gpsd/

The patch does work and seems to improve fix times dramatically.

Comment 6 Jukka Rissanen 2008-02-05 13:53:37 UTC

This is same as internal bug #79009

The leap year problem only affects the dates that are sent to GPS clients that
use the C library interface or dbus interface, it does not affect raw interface
(NMEA data) that the Map program is using.

The analysis that the leap year bug would affect fix times is wrong. If you are
seeing improvements in fix times after patching gpsd, then the reason is
something else. For example osso-gpsd 1.0-25 fixes serious performance bug
found in original gpsd (it reads only one sentence / sec from gps device), the
fixed version reads all possible sentences from gps device in one go (normally
this is only visible when gpsd fixes are used in voice navigation, before the
correction the fixes where coming 1-2 seconds too late).

There is some rumours circulating that the osso-gpsd is based on very ancient
gpsd version. That is not correct, the osso-gpsd is based on 2.32 which is not
so ancient (released 2006). Perhaps the mixup is caused by version number of
osso-gpsd which is currently 1.0-27, unfortunatly the original 2.32 is not
shown in version string (the upstream version is mentioned in changelog thou).

The leap year bug is fixed in osso-gpsd 1.0-26 that is only released in diablo.
Currently there are no plans to release it in chinook, fortunately the leap
year problem goes away at the end of february.

The slow fix times from internal gps chip cannot really be affected by leap
year bug because the gpsdriver is before gpsd in the GPS data pipeline. The
NMEA date data is correct (year is set correctly) but only the GPS data that
gpsd provides to clients gets incorrect date. The wrong date is never fed back
to gpsdriver and internal chip.

Hi Jukka, thanks for commenting

(In reply to comment #6)
> This is same as internal bug #79009

I understand that even one BTS is a chore, but logging stuff like this to the
external bug system would be really nice,

> The analysis that the leap year bug would affect fix times is wrong. If you are
> seeing improvements in fix times after patching gpsd, then the reason is
> something else. For example osso-gpsd 1.0-25 fixes serious performance bug
> found in original gpsd (it reads only one sentence / sec from gps device)...

Now, current up-to-date OS 2008 has osso-gpsd 1.0-25, right? The only thing I
changed was the patch, which according to you shouldn't affect fix time... 

I can accept myself seeing a placebo effect, but I've been contacted by
literally dozens of people saying that fix times have improved, many claiming
dramatic improvement and none who said they had not seen an improvement. So I
wonder what this is about.

I guess I'll have to try installing a clean 1.0-25 and testing again. 

> The slow fix times from internal gps chip cannot really be affected by leap
> year bug because the gpsdriver is before gpsd in the GPS data pipeline. The
> NMEA date data is correct (year is set correctly) but only the GPS data that
> gpsd provides to clients gets incorrect date. The wrong date is never fed back
> to gpsdriver and internal chip.

I don't have access to the internals so I probably shouldn't argue with you :) 
I based my assumption on gpsinternal.h:
  * This function is only to be called from gps driver daemon process.
  * The function checks whether the internal GPS chip can be used, and
  * it also returns last known location position so that internal GPS
  * chip gps driver daemon can initialize the chip...
Are you saying gpsinternal_check_stuff() is not actually used by gpsdriver or
that the date it provides is correct?

Comment 8 Jukka Rissanen 2008-02-05 15:34:35 UTC

(In reply to comment #7)

> I can accept myself seeing a placebo effect, but I've been contacted by
> literally dozens of people saying that fix times have improved, many claiming
> dramatic improvement and none who said they had not seen an improvement. So I
> wonder what this is about.

I understand what you and others are seeing but it is just not possible that
the leap year problem could affect the fix time by itself.
If the incorrect fix time is used to update the system clock (via NTP or some
other method), then it is possible that something weird could happen with the
fix time, but I assume that this is not the case here.


> I don't have access to the internals so I probably shouldn't argue with you :) 
> I based my assumption on gpsinternal.h:
>   * This function is only to be called from gps driver daemon process.
>   * The function checks whether the internal GPS chip can be used, and
>   * it also returns last known location position so that internal GPS
>   * chip gps driver daemon can initialize the chip...
> Are you saying gpsinternal_check_stuff() is not actually used by gpsdriver or
> that the date it provides is correct?

Yes there is a function but currently it is not used by gpsdriver.

ok, thanks a lot.

I'll add this comment, but follow-ups should probably happen in bug 2878. It
seems that 
 A) 1.0-25 is  better than 1.0-23 at getting a fix and 
 B) people have different versions of osso-gpsd even 
    with the same OS revision (possibly based on 
    hardware, I've received reports of 1.0-25 on N800 
    and 1.0-23 on N810) 
and that's what created all the confusion: I checked the version on my N800 and
used 1.0-25 as the base because that's what I saw there.

removing "blocks 2878" status based on Jukkas info.

(In reply to comment #9)
>  B) people have different versions of osso-gpsd even 
>     with the same OS revision (possibly based on 
>     hardware, I've received reports of 1.0-25 on N800 
>     and 1.0-23 on N810) 

ok, scratch that. It seems people were just confused after seeing 1.0-23
available (possibly from repository.maemo.org). As far as I know everyone is on
1.0-25.

Now I'm shutting up for real.

Jukka,

Thanks for the detailed explanation.

Is it possible that bad data is fed to the chip via gps_last_saved_report? This
file is generated by gpsd and most likely stores the incorrect timestamp.

I would think that gps_last_saved_report is involved in GPS startup. Otherwise,
how would the chip know the last location? If last location is not used, this
would imply that GPS5300 ignores almanac data and could explain the poor
performance we've being seeing.

Are you also the maintainer for gpsdriver? I would really like to ask some
questions about it. Any chance Nokia could opensource it?

For example, I have noticed that the GPS in N810 can never obtain a fix using 3
satellites (it needs at least 4). gpsdriver has strings like 'Allow 2D'. I
wonder if this option is disabled, and whether enabling it could lead to faster
fix times.

Thanks!

Also, may I ask which process in the pipeline decides whether to do a cold
start or a warm start? Is it gpsdriver? Where is the time of last fix stored to
help in this decision?

Comment 13 Jukka Rissanen 2008-02-06 10:39:09 UTC

(In reply to comment #11)
> Is it possible that bad data is fed to the chip via gps_last_saved_report? This
> file is generated by gpsd and most likely stores the incorrect timestamp.
> 
> I would think that gps_last_saved_report is involved in GPS startup. 

No, the gps_last_saved_report just contains the latest report + some other
stuff and it is used to show the info in "GPS location details" window if the
gpsd is not running. Its contents is not fed to internal chip.

> Otherwise,
> how would the chip know the last location? If last location is not used, this
> would imply that GPS5300 ignores almanac data and could explain the poor
> performance we've being seeing.

No, almanac and ephemeris are fed back to the chip. But if they are too old,
then the system needs to download them from satellite and if there is an error
during this download you will see delayed fixes etc, see
http://en.wikipedia.org/wiki/Gps#Navigation_signals for more details.

> 
> Are you also the maintainer for gpsdriver? I would really like to ask some
> questions about it. Any chance Nokia could opensource it?

No, I am not the gpsdriver maintainer.

Opensourcing the gpsdriver is currently not possible because of proprietary TI
messages used when communicating with the chip.

Thanks Jukka,

I am fairly familiar with how GPS works.

Almanac data is useless without an approximate position and time. If you say
that almanac data is used by the GPS chip, the last location has to be stored
somewhere. Hence my assumption that last_position_report was being used.

Do you know in what file the last position is persisted, to be fed to the GPS
chip at startup?

Is there any chance that the gpsdriver maintainer could also comment on this
thread? Perhaps there is something he could add to the discussion. I would also
really like to hear his thoughts on bug 2878.

I see that a new version of gpsd is now available in the official repository.
Does that mean that the leap year bug did have an effect on TTFF? If so, may I
ask how?

(In reply to comment #15)
> I see that a new version of gpsd is now available in the official repository.
> Does that mean that the leap year bug did have an effect on TTFF? If so, may I
> ask how?

Not a new version. It's the same version that the firmware had all along. 

This is just Nokia being a little late with the SDK, that's all: The SDK really
matching OS2008 was released only today.

(In reply to comment #14)

> Do you know in what file the last position is persisted, to be fed to the GPS
> chip at startup?

It appears that the last position is saved in /var/lib/gps/nvd_data
When gpsdriver gets a request to turn on the GPS, it reads this file and
writes binary data to the GPS on /dev/ttyS0. When it gets a request to power
off, this file is written.

See also related bug 2878

Just a few comments:

-cold fix times are much shorter if the antenna is pointed to the south (in the
north hemisphere) than towards the north. This suggests that the GPS chip does
not use the correct doppler shift.

-hot fix times are short if a cold fix was done using the wayfinder map
application. If I use, say, maemo mapper only, hot fixes are not shorter than
the first fix (cold fix), suggesting that almanach or last position data is not
saved correctly when using another application than the wayfinder map
application.

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.

Comment 20 Andre Klapper 2008-06-06 14:56:19 UTC

According to the internal ticket, this has been fixed in sso-gpsd 1.0-27 which
will be available for Diablo (4.1). Hence closing.

Comment 21 Eero Tamminen 2008-09-10 14:14:32 UTC

(In reply to comment #20)
> According to the internal ticket, this has been fixed in sso-gpsd 1.0-27 which
> will be available for Diablo (4.1). Hence closing.

Could somebody verify the fix?