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

[Alexander Carver]

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.