[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
>>> *127.127.20.0 .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:
https://www.febo.com/pipermail/time-nuts/2013-October/080889.html
>> 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 127.127.20.0 mode 1 minpoll 3 maxpoll 4 iburst prefer
> fudge 127.127.20.0 fudge flag1 0 time2 0.213
> server 127.127.22.0
> fudge 127.127.22.0 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