Re: [gpsd-users] gpsd vs Pharos 360

[Eric S. Raymond]

Jeff Woolsey <address@hidden>:
> 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.
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>