[ntp:questions] Reasons of NTP not to use GPS source

David Lord snews at lordynet.org
Tue Sep 17 09:58:50 UTC 2013


Igor Pavlov wrote:
> Thanks, Brian.
> 
> I'll do all these things.
> Now will try to fix problem with PPS: it's level 3.3V, and serial port
> seems to not recognising such low level.
> Now playing with time2 parameter and my GPS now stoped getting "x".

Serial ports are RS232 rather than 3.3V TTL so you might need
a converter or if your system has a parallel port you could
possibly use that with type 22 (Atom) driver.

Note that there is usually a delay before PPS shows itself,
ntp needs to be synced, ie reach column for prefer peer might
need to be at 377 before PPS is seen.

If as has been suggested, you've marked the GPS as noselect
and set another server as prefer, the PPS should be seen and
used since the fudge time2 is not needed just yet.


> I can't understant one thing.
> Should system time be fluently corrected by NTP so in some term offset of
> active ("*") source would be close to 0?

Without PPS, ntp will condition the system clock to a low
value which will fluctuate. My non PPS systems usually have
offset varying around zero, best are +/- 300 us and worst
are +/- 1500 us.

With PPS it's mostly +/- 3 us but with peaks from heating
and system load of almost +/- 40 us.


David

> 
> 2013/9/17 Brian Inglis <Brian.Inglis at systematicsw.ab.ca>
> 
>> On 2013-09-16 01:00, Igor Pavlov wrote:
>>
>>> Hi!
>>>
>>> I am using GPS-receiver based on Geos-1m chip (
>>> http://www.geostar-navigation.**com/en/navigation_05.html<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?
>>>
>>> Example of "ntpq -p" output
>>>
>>>       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 194.190.168.1    2 u   58   64  377   30.151  -100.04
>>>   52.432
>>> +89.221.207.113  192.36.133.25    2 u    -   64  377   10.006  -105.88
>>>   64.279
>>>
>> See David Taylor's pages at
>> http://www.satsignal.eu/ntp/**NTP-on-Windows-serial-port.**html<http://www.satsignal.eu/ntp/NTP-on-Windows-serial-port.html>
>> and linked pages at top for a lot of details about setup, but keep
>> everything really simple to start, then change one thing at a time after
>> running for a while and checking the results.
>>
>> Check your GPS comms and config using the supplied setup software:
>> are you seeing NMEA output at your selected 115.2kbps?
>> which sentences $GPRMC, etc.?
>> has your receiver completed its initial survey and is it reporting Active,
>>  and reasonable mode, position, altitude, UTC date and time in sentence
>> $GPRMC?
>> how many satellites is your receiver tracking to what precision in
>> sentences $GPGGA, $GPGSA, $GPGSV?
>> is your receiver set to 1Hz PPS rather than 5Hz updates?
>> is PPS toggling DCD high for about 100ms at the start of ecah second?
>> Note that Windows recognizes only low to high DCD transitions as PPS.
>>
>> If your mouse cursor starts jumping around, unplug your RS232 cable,
>> *disable* the Windows mouse driver which just got loaded on your serial
>> port, plug in your RS232 cable, and restart if required.
>>
>> If all that looks good, next try disabling everything but PPS and $GPRMC
>> sentence output from your receiver config, and use only your server
>> 127.127.20.n line, without any fudge settings, plus your backup Internet
>> servers, in ntp.conf.
>> Then restart NTP and see if ntp.log shows something like:
>> ...
>> 14 Aug 12:50:38 ntpd[####]: GPS_NMEA(#) serial /dev/gps# open at 4800 bps
>> 14 Aug 12:50:38 ntpd[####]: GPS_NMEA(#) 8011 81 mobilize assoc #####
>> ...
>> 14 Aug 12:50:39 ntpd[####]: GPS_NMEA(#) 802b 8b clock_event clk_no_reply
>> 14 Aug 12:50:39 ntpd[####]: Using user-mode PPS timestamp for GPS_NMEA(#)
>> ...
>> 14 Aug 12:50:57 ntpd[####]: GPS_NMEA(#) 8034 84 reachable
>> 14 Aug 12:50:57 ntpd[####]: GPS_NMEA(#) 904a 8a sys_peer
>> ...
>> Now ntpq -p should show * beside your GPS_NMEA(#) entry:
>>
>>      remote           refid      st t when poll reach   delay   offset
>>  jitter
>> ==============================**==============================**
>> ==================
>> *GPS_NMEA(#)     .GPS.            0 l   12   16  377    0.000   -0.011
>> 0.021
>> and if you defined statsdir ... and statistics clockstats in ntp.conf you
>> should see entries in clockstats.yyyymmdd like:
>> 56512 7.123 127.127.20.# ...
>> ...$GPRMC,000006,A,5108.####,**N,11411.####,W,000.0,000.0,**
>> 080813,014.7,E,D*0F
>>
>> If nothing seems to be working, try restarting the NTP service - at times
>> it seems to have issues getting going properly in various ways.
>>
>>
>> ______________________________**_________________
>> questions mailing list
>> questions at lists.ntp.org
>> http://lists.ntp.org/listinfo/**questions<http://lists.ntp.org/listinfo/questions>
>>





More information about the questions mailing list