[ntp:questions] garmin 18x and linux

Chris Albertson albertson.chris at gmail.com
Mon Sep 5 16:47:20 UTC 2011


On Mon, Sep 5, 2011 at 8:04 AM, unruh <unruh at wormhole.physics.ubc.ca> wrote:
> On 2011-09-05, Miroslav Lichvar <mlichvar at redhat.com> wrote:
>> On Sat, Sep 03, 2011 at 08:05:21AM -0500, steven Sommars wrote:
>>> I monitored Garmin LVC (corrected firmware) NMEA time and saw variance of up
>>> to 50msec.  I wonder if the variation in NMEA time depends on GPS signal
>>> quality.
>>
>> I'm wondering what is the cause of the variance too.
>>
>> 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?

These plots are made with an arbitrary zero point.  The  offsets is
relative.  By looking at the plot we don't know the true offset.  That
data is simply not provided.   But it shows what we care about, the
dispersion.   We can always correct a fixed bias on the time using a
"Fudge" in the ntp.conf but we can't do anything at all about the
dispersion.

The cause?   My theory is that it can't be in the GPS data.  It is
where then the computed location would "Bounce" over a two kilometer
circle.  I think the error is in the conversion of internal data to
ASCII.  This requires many conversions of floating point internal
numbers to ASCII and in a low-powered micro controller the time to
convert one number depends on the value of the number.  For example
let's look at small integers.  To convert "7" to ASCII we first load
the hex value of ascii zero into a register.  then we scan the bits in
the number to be converted and add in a power of two (or  not) based
on if the bit is a one or zero.  In the case of "7" we add 4, 2 and 1.
  If we convert a "4" we would only add "4".  The variability is much,
much more with floating point.   Remember the little processor in the
Garmin is tiny and runs slow.  The thing is designed to run on battery
power.

When Processing NMEA on the computer, you can't do anything until you
get the terminating end of line character.  The PC then has to convert
back to floating point.   This can take a varying about of time too.
But the computer is MUCH faster and so has much less variability

Also remember that the NMEA spec only required the all NMEA sentences
be output "within the second" and if the GPS "stutters" badly it is
still in-spec.

The PPS signal solves all this.  The GPS 18 has one of the poorest
timing spec, but even this unit's PPS is spec'd for only 1uS error
(that would be one sigma about the mean)  1uS is usable  to NTP.
Better GPS have a single digit nanosecond error.  And cheap eBay GPS
will have two digit nanosecond error.

I think only with timing equipment will you see specs that differ by a
factor of 10,000.   Look at any other gadget, the watts in a stereo,
GHz clock on a computer.  MPG on a car, You don't see one brand being
10,000X different like you do in GPSes.

Chris Albertson
Redondo Beach, California



More information about the questions mailing list