|
From: | Alexander Carver |
Subject: | Re: [gpsd-users] GPS reporting wrong time to SHM |
Date: | Sat, 18 Aug 2012 01:12:28 -0700 |
User-agent: | Mozilla/5.0 (Windows NT 5.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 |
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.logI 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.
[Prev in Thread] | Current Thread | [Next in Thread] |