gpsd vs Pharos 360

[Jeff Woolsey]

I have a Pharos GPS-360 that came with Streets and Trips 2006. I was
watching its NMEA output in GPSy which claims it's about 150ms behind
the ntp-synced host (but then who knows what GPSy thinks is on-time
here). The time is given to millisecond precision, which loses a few
ms/min. I then gave gpsd 3.6 (later 3.11~dev...) on my Raspberry Pi a
whack at it, which put it in SiRF binary mode (who knew? gpsmon clock
status always blank, firmware field "231.000.000ES03" only twice), which
reports UTC minus ten or eleven seconds. Was UTC offset hardcoded at
manufacture? Have there been 6 or 7 leap seconds since 2006? No. How
about in 1994? (gpsmon says it's 2014-02-06T, cgps initially says it's
1994-06-23T). There have been 7 leap seconds since 1994-06-30. 10 leap
seconds ago was 1990-12-31, 11 a year earlier.

Examining driver_sirf.c answers some questions (MID 0x29 ignored since
e.g. UTC all zeroes at my firmware level) and begs others (if a packet
is ignored, why don't we turn it off? Can we turn on others?).

So what's going on here? Is the GPS fudging its GPS time? Is gpsd
fetching the wrong UTC offset from some packet (MID 0x34?)

I added code to turn off MID 0x29 and the 10-second offset magically
went away. Either gpsd actually wasn't ignoring it or there's some
weird interaction in the SiRF II.

[Eric S. Raymond]

Post by Jeff Woolsey
I have a Pharos GPS-360 that came with Streets and Trips 2006. I
was watching its NMEA output in GPSy which claims it's about 150ms
behind the ntp-synced host (but then who knows what GPSy thinks is
on-time here). The time is given to millisecond precision, which
loses a few ms/min. I then gave gpsd 3.6 (later 3.11~dev...) on my
Raspberry Pi a whack at it, which put it in SiRF binary mode (who
knew? gpsmon clock status always blank, firmware field
"231.000.000ES03" only twice), which reports UTC minus ten or eleven
seconds. Was UTC offset hardcoded at manufacture? Have there been
6 or 7 leap seconds since 2006? No. How about in 1994? (gpsmon
says it's 2014-02-06T, cgps initially says it's 1994-06-23T). There
have been 7 leap seconds since 1994-06-30. 10 leap seconds ago was
1990-12-31, 11 a year earlier.
Examining driver_sirf.c answers some questions (MID 0x29 ignored
since e.g. UTC all zeroes at my firmware level) and begs others (if
a packet is ignored, why don't we turn it off? Can we turn on
others?).
So what's going on here? Is the GPS fudging its GPS time? Is gpsd
fetching the wrong UTC offset from some packet (MID 0x34?)
I added code to turn off MID 0x29 and the 10-second offset magically
went away. Either gpsd actually wasn't ignoring it or there's some
weird interaction in the SiRF II.

That's a weird one. The 0x29 code has been inside #ifdef __UNUSED__
for years. Would you please send me your turnoff code for 0x29?
That's a good idea, especially at 4800 where there's some tendency for
the sentence inventory to not fit in a 1-second window.