[ntp:questions] Help: fudge time2 value for NMEA driver

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Wed Nov 2 17:43:54 UTC 2016


On 2016-11-02 10:16, ogre up wrote:
> The GPS module in use is an ublox LEA-6T, not Garmin GPS 18x, sorry
> for the mistake.
> The NTP server runs in an isolated network, GPS is the only time
> source I can refer to, and 1 millisecond accuracy is good enough for
> me. Reliable, trustworthy means more to me than performance. So if
> signal delay measured by oscilloscope and offset reported by ntpq can
> conform each other, it will bring me great confidence to rely on the
> server.  
> I upload oscilloscope screenshot at
> https://cdn.pbrd.co/images/mqRtAxzXq.png, delay
> between "end of $GPRMC" and "preceding PPS edge" is about 213 ms. I've
> tested with
> ntp.conf:
> server 127.127.20.0 mode 1 minpoll 3 maxpoll 4 iburst prefer
> fudge  127.127.20.0 flag1 0
> server 127.127.22.0 minpoll 3 maxpoll 4 noselect
> fudge  127.127.22.0 flag2 1 flag3 1
> tos mindist 0.05
> However, no matter what the value for .22.0 flag2 is (1 or 0), when
> NTP synchronized to .20.0, offset value of .22.0 is always about 116.
> Where is this 116 ms come from?

It looks like it may be the time from the PPS trailing edge to the \n.

As I advised earlier, get the PPS test working normally, then set .22.0
to flag2 0, as you can not control Linux PPS using the leading edge, and
switch off the GPS receiver output of the other message, as more than a
single message will not be handled well by the NMEA driver.

The PPS driver was designed for use with standalone high accuracy PPS
sources.
Better just use NMEA driver with kernel PPS to achieve accuracy and
reliability: PPS was added to the driver to improve handling using the
same port, because results using the separate PPS driver were worse.


-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada


More information about the questions mailing list