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

[Eric S. Raymond]

Alexander Carver <address@hidden>:
> On 8/16/2012 01:31, Eric S. Raymond wrote:
> >Alexander Carver <address@hidden>:
> >>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?
> >
> >Good question. Here's what you can do to help answer it.
> >
> >1. Capture a log that contains a MID52.
> >
> >2. Verify that the log contains a MID52 by replaying the log with
> >    gpsfake and checking with either gpsmon or by turning the
> >    debug level of gpsd up to where it dumps packets.
> >
> >3. Post the log here, so I and others can replay it in our environments.
> >
> 
> Raw dump available:
> 
> http://acarver.net/gpsd/sirf_raw.log
> 
> I can't get gpsfake to work because of python issues but I read the
> file by hand.  The MID 52 is in there however it seems the start
> sequence is scrambled either by missing the last byte entirely or
> having a payload length of zero.  In most cases the packet is good
> when the full start sequence is there including the payload length
> byte (but set to zero). If the last byte is missing (should be four
> bytes) then the packet is not quite right although the message ID is
> intact.
> 
> If you look through the file you'll find A0A20000 34 which has a
> valid payload.  Other times there's an A0A200 34 and has a scrambled
> payload.   I'm not exactly sure how SiRFDemo is able to read the
> data but it's there when the start sequence is A0A20000.  If it
> drops the last 00 then the packet is dead.  I suppose SiRFDemo just
> reads until the end sequence B0B3 and takes the packet.

Sounds like the actual problem, then, is that the device is emitting
garbled MID52 messages, but the vendor has failed to notice this
because SiRFDemo accepts the invalid packet.  This would account for
the code failing to set the leap second correctly

I think the safest thing to do would be to document this as a known SiRF.
firmware bug.  Can you identify the SiRF firmware version from the log?
-- 
                <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>