gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-users] GPS reporting wrong time to SHM


From: Alexander Carver
Subject: Re: [gpsd-users] GPS reporting wrong time to SHM
Date: Wed, 15 Aug 2012 22:26:09 -0700
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0

On 8/15/2012 19:20, Alexander Carver wrote:
On 8/15/2012 15:01, Gary E. Miller wrote:
Yo Alexander!

On Wed, 15 Aug 2012 12:35:12 -0700
Alexander Carver <address@hidden> wrote:

I can confirm that the SHM data being sent by gpsd to ntpd is now
wrong after the leap second occured.

Have you restarted your ntpd since the leap second?


Yes, I've restarted everything several times including last night.  SHM
is still one second ahead of UTC.


I just restarted gpsd in debug mode (level 5) and noticed something even more interesting:

gpsd:PROG: SiRF: MND 0x02: Navtype = 0x84, Status = 2, mode = 3
gpsd:PROG: SiRF: NTPD valid time MID 0x02, seen=0x00, time;1345090666.42, leap:15 gpsd:DATA: SiRF: MND 0x02: time=1345090666.42 lat=34.24 lon=-118.27 alt=590.38 track=0.00 speed=0.00 mode=3 status=2 hdop=1.20 used=8 gpsd:DATA: packet from /dev/ttya with {ONLINE|TIME|LATLON|ALTITUDE|SPEED|TRACK|CLIMB|STATUS|MODE|DOP|PACKET|USED|CLEAR|REPORT|PPSTIME}
gpsd:DATA: packet from /dev/ttya with {ONLINE|PACKET}


Leap 15?

According to SiRFDemo, the leap seconds are reported as 16 via MID 52 (0x34). The GPS is sending out MID 52 however gpsd is ignoring it because the debug output does not show it being processed.

The code for driver_sirf.c shows:
gpsd_report(LOG_PROG, "SiRF: PPS 0x34: Status = 0x%02x\n",
                getub(buf, 14));

but I don't see this message at all even though I do see the message in SiRFDemo.

From what I can tell in the driver_sirf.c code, the value of leap_seconds is set if MID 52 shows up. Otherwise it's assuming a value because I don't see it being set anywhere else in the code. The only other place it is defined is in timebase.h and it's defined as 15 there. If MID 52 is being ignored then that explains why the above debug log shows 15 instead of 16 because it's reporting the default compiled value since it is never reset by MID 52.

It now appears that my calculation was off in sign and I wasn't a second in the future, I was a second in the past. I modified timebase.h to set the leap seconds to 16. So the question is why is gpsd (or at least my copy) ignoring MID 52 completely?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]