[ntp:questions] garmin 18x and linux
unruh at wormhole.physics.ubc.ca
Mon Sep 5 17:38:41 UTC 2011
On 2011-09-05, Rob <nomail at example.com> wrote:
> 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
>>>> 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.
Since you already communicate the message all the way through the stack,
adding on a few bytes to store a timestamp is not exactly a stretch.
> (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.
Yes, I saw that-- actually it waits until it communicates that time fix
on to ntp.
> 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.
I guess I am surprized that it "wildly varies". Those receivers can send
out 5 or more messages per second. That means that each message only has
about .2 sec to be sent out, and since the messages often start "late"
even less time than that. From Lichvar's plots the fluctutation in the
timestamp is about .4 sec. That is surprizing.
More information about the questions