[ntp:questions] garmin 18x and linux

Rob nomail at example.com
Mon Sep 5 17:19:19 UTC 2011

unruh <unruh at wormhole.physics.ubc.ca> wrote:
> On 2011-09-05, Miroslav Lichvar <mlichvar at redhat.com> wrote:
>> On Mon, Sep 05, 2011 at 03:04:54PM +0000, unruh wrote:
>>> On 2011-09-05, Miroslav Lichvar <mlichvar at redhat.com> wrote:
>>> > With 18x LVC (firmware 3.70) I see errors up to 150 ms. That
>>> > wouldn't be that bad if it was randomly distributed.
>>> >
>>> > A capture over 30 hours:
>>> > http://mlichvar.fedorapeople.org/tmp/18x_nmea.png
>>> This was captured how? Is that the beginning or the end of the nmea
>>> sentence?
>>> You have some where the offset is negative. Does this really mean that
>>> the nmea came in before the beginning of the second it referred to?
>> No, I forgot to mention that was already with 0.5s correction applied.
>> It's from gpsd which seems to make the NMEA receive timestamp after
>> the message is processed.
> Never did understand that. Timestamping the beginning of the sentences
> is cheap enough and easy enough. 

It is not that easy because it requires communicating an extra item of
information (the timestamp of the beginning of the message) all the
way through the protocol stack alongside with the message.
(you would not want to store it in a global variable, would you?)
Right now, the timestamp is only taken at the moment the entire message
has been received at the toplevel of the stack, parsed, and it has been
found to contain a time of fix.

It does not really matter when using NMEA because there is no definition
of the message timing relative to the timestamp anyway.  The time in the
message is a "time of fix".  You simply don't know how long the receiver
takes from computing the fix to sending the NMEA messages, and on many
receivers this amount of time wildly varies.

More information about the questions mailing list