[gpsd-users] 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.

--
Jeff Woolsey {woolsey,address@hidden,jxh}.com address@hidden,hp,jlw}.com
Spum bad keming.
Nature abhors a straight antenna, a clean lens, and unused storage capacity.
"Delete! Delete! OK!" -Dr. Bronner on disk space management
"Card sorting, Joel." -me, re Solitaire