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

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Thu Nov 3 18:27:04 UTC 2016

On 2016-11-03 08:45, ogre up wrote:
> On Thu, Nov 3, 2016 at 3:03 PM, Brian Inglis wrote:
>> On 2016-11-02 17:51, Paul wrote:
>>> On Sun, Oct 30, 2016 at 1:29 PM, ogre up wrote:
>>>> Hello everyone, I've setup a NMEA+PPS ntp server, but both ref clock have
>>>> strange offset value reported by ntpq -p.

>>> Your billboard is fine.  If you want less jitter in your NMEA sentences you
>>> need to buy better hardware.  Not necessarily more expensive but better.
>>> However it doesn't matter as long as you stay within a few hundred
>>> milliseconds of the correct second since the timing is done with PPS and
>>> the GPS output is only used to number the seconds.  Unfortunately I have
>>> no experience with your PPS problem.
>>> I prefer using ATOM (PPS) + a GPS specific driver.  In the past I've been
>>> unhappy using the PPS option in the NMEA driver so I don't bother.
>>> Output from a low jitter NMEA compatible GPSDO:
>>>      remote           refid      st t when poll reach   delay   offset jitter
>>> ==============================================================================
>>> o127.127.22.0    .GPPS.           0 l    2    8  377    0.000    0.000 0.002
>>> *    .FURY.           0 l    1    8  377    0.000   -0.003 0.011

What do your refclock ntp.conf lines look like?

Also please see driver comments in [time-nuts] NTP refclock JLT Fury:

>> The uBlox LEA-6T is probably as good as the older M12+ used in the JLT Fury,
>> and has been used for DIY GPS-DOs.
>> With proper GPS antenna, receiver, and system configuration, the results
>> achievable should be comparable, limited by system and NTP performance,
>> compared to the standalone Fury GPS-DO [TO]CXO which will not be affected
>> by temperature.
>> Follow the instructions for timing setup on a uBlox LEA-6T to get the best
>> results; see sections 10 Time Mode Configuration and 11 Timepulse in:
>> https://www.u-blox.com/sites/default/files/products/documents/u-blox6_ReceiverDescrProtSpec_%28GPS.G6-SW-10018%29_Public.pdf#page=37&zoom=auto,0,323.15
>> You may want to do the setup in uBlox mode at higher speed, especially if
>> you load ALP data from Ublox, before switching to 9600 bps and NMEA output.
>> Once the setup is done properly, it would be worth comparing the performance
>> using the NMEA driver with kernel PPS against the separate PPS/ATOM driver.

> I just noticed I've made a mistake. My original ntp.conf looks like this:
> # use GPRMC sentence only
> server mode 1 minpoll 3 maxpoll 4 iburst prefer
> fudge fudge flag1 0 time2 0.213
> server
> fudge fudge flag2 1 flag3 1
> tos mindist 0.10 # required, or both peer will be falseticker
> There is an unnecessary "fudge" after .20.0, and .22.0, so options after may
> not take effect. I will have a try with correct config file and see
> what happens.
> In the world of software, nothing is strange; If you do find one, chances are
> you've make some stupid mistake...

For decent results you also have to switch off output of other messages.

If you think you have to set tos parameters (dist default range 0.001-1.5s)
you need to check your setup, read up the theory behind the parameter setting,
do some calculations, then test.

With patch antennae, indoors, north-ish window, floor heating vent below,
non-timing serial GPS+PPS, I get:

* RPi, GT MKT 3339, kernel PPS, NMEA only:
      remote           refid      st t when poll reach   delay   offset  jitter
oGPS_NMEA(0)     .GPS.            0 l   10   16  377    0.000    0.002   0.001
+W10             .GPS.            1 s   16   16  376    1.279    0.283  83.321

* W10, Garmin 18x, user mode PPS, NMEA only:
      remote           refid      st t when poll reach   delay   offset  jitter
*GPS_NMEA(2)     .GPS.            0 l   10   16  377    0.000   -0.006   0.006
-RPi             .GPS.            1 s    4   16  377    1.181   -0.236  70.814

[peer jitter due to USB 11N low band wifi - should get a long enet cable
sometime to reduce LAN peers' and WAN backups' delay and jitter]

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

More information about the questions mailing list