[ntp:questions] Reasons of NTP not to use GPS source
unruh at invalid.ca
Tue Sep 17 02:32:04 UTC 2013
On 2013-09-16, Igor Pavlov <pavlov.ig at gmail.com> wrote:
> I already tryed to use PPS from my GPS receiver connected to DCD-pin of the
> same RS-232.
> But I had PPS also marked as "x", that is why I tryed first to fix problems
> with NMEA-based GPS data separate from PPS.
> I will try to connect PPS again.
> But I can't understand why it is marked "x"? What is wrong with it?
Its time is way outside the time delivered by all your other sources.
ntpd thus rates it as an outlier and thus as the wrong time.
You could tell ntpd to add say 300ms to the time delivered by the nmea,
to bring it into line with the others. You could tell ntp that it must
use that source.
> 2013/9/16 Rob <nomail at example.com>
>> Igor Pavlov <pavlov.ig at gmail.com> wrote:
>> > Hi!
>> > I am using GPS-receiver based on Geos-1m chip (
>> > http://www.geostar-navigation.com/en/navigation_05.html)
>> > I connected it to serial port and configured NTP.
>> > It becomes unused by NTP: when do ntpq -p reuest ti puts "x" near
>> > "GPS_NMEA(1)" record.
>> > What reasons can be for this?
>> A GPS with NMEA protocol is usually a very lousy time source.
>> You can see this in your output: the time offset relative to
>> the internet sources is very large:
>> > remote refid st t when poll reach delay offset
>> > jitter
>> > xGPS_NMEA(1) .GPS. 0 l 14 16 377 0.000 -303.07
>> > 4.292
>> > *stratum1.net .PPS. 1 u 62 64 377 62.800 -68.052
>> > 43.693
>> > +dl120g7.naviteh 18.104.22.168 2 u 58 64 377 30.151 -100.04
>> > 52.432
>> > +22.214.171.124 126.96.36.199 2 u - 64 377 10.006 -105.88
>> > 64.279
>> That is why ntpd declares the time as invalid and attempts to use the
>> 3 other sources instead.
>> When you want to fix this, you should use PPS with the receiver,
>> when possible.
>> questions mailing list
>> questions at lists.ntp.org
More information about the questions