maemo.org Bugzilla – Bug 2877
Incorrect GPS timestamps reported over D-BUS
Last modified: 2008-09-10 14:14:32 UTC
You need to log in before you can comment on or make changes to this bug.
SOFTWARE VERSION: (Control Panel > General > About product) OS2008 Final STEPS TO REPRODUCE THE PROBLEM: When GPS is on, fix data is sent over D-BUS several times a second [user@nokia ~]$ dbus-monitor --system signal sender=:1.76 -> dest=(null destination) path=/org/gpsd; interface=org.gpsd; member=fix double 1.20207e+09 int32 0 double 0.005 double 47.xxx double -122.xxx double nan double 131.1 double nan double 313.06 double nan double 0 double nan double 0 double nan The first double in this message is the GPS time (in UTC). The time is always exactly 1 day (24 hours) larger than it should be [user@nokia ~]$ python >>> from time import * >>> ctime(1.20207e+09) 'Sun Feb 3 12:20:00 2008' >>> ctime() 'Sat Feb 2 11:29:25 2008' In the example above, dbus-monitor displays the double value with 5 significant digits, losing 4 digits (10000 seconds = 2.5 hours). However, if I hack dbus-monitor to display doubles with %f instead %g, the times match exactly (down to the second), while the date is always 1 off. EXPECTED OUTCOME: GPS time should match UTC time. ACTUAL OUTCOME: GPS time is 86400 seconds greater than UTC time. REPRODUCIBILITY: (always/sometimes/once) always EXTRA SOFTWARE INSTALLED: OTHER COMMENTS: I get the same problem with external GPSs, so if there is a bug it is likely in gpsd and not in gpsdriver. I wonder if this bug contributes to slow satellite acquisition times on N810. If there is an off-by-one error in gpsd, perhaps the internal GPS is initialized with an incorrect time, invalidating almanac / ephemeris data.
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.
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?
(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?
(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.
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.
(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?