Re: [ntp:questions] PPS as a falseticker!!!
Paul wrote: On Wed, Aug 27, 2014 at 4:44 PM, juergen perlinger juergen.perlin...@t-online.de wrote: The basic problem is that using a PPS clock and a GPS(NMEA) clock separates what belongs together This is not true. Normally I wouldn't fall prey to there's something wrong on the Internet but this assertion doesn't help solve any problems let alone the problem at hand. In fact in some configurations I've run using the PPS option in the NMEA refclock has *caused* problems. None of the PPS refclock + NMEA refclock instances Ive run have any problems. I think the best solution depends on some details. The case where a separate NMEA message and PPS pulse via ATOM driver are handled directly by ntpd is certainly different from the case where the NMEA driver also evaluates the PPS signal and only passes clean timestamps on to ntpd's base algorithms. The timing relationship between the NMEA message (which one?) and the 1 PPS signal provided by the GPS receiver, and its variation (jitter) over time depends on the type and even firmware version of the GPS receiver. Since both the refclock code and the ntpd's basic algorithms can be slightly different in different versions of ntpd the results may depend on the specific version of ntpd, and both ways implemented in that version cope with the timing characteristics of the particular GPS receiver. This is not to mention the ability to run a PPS disciplined local clock as a S1 (taking some care to do it right) without a persistent external source of second numbering. I'd consider the above as just another use case requiring a different configuration. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS as a falseticker!!!
On Wed, Sep 3, 2014 at 4:53 AM, Martin Burnicki martin.burni...@meinberg.de wrote: I think the best solution depends on some details. Sure, but my point was that the bald assertion -- The basic problem is that using a PPS clock and a GPS(NMEA) clock separates what belongs together -- is wrong. Sometimes it's useful or essential that your PPS and timestamps come from the same place and sometimes it's irrelevant. Certainly using the NMEA driver to infer PPS quality can be a win but it's not guaranteed. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS as a falseticker!!!
On 08/27/2014 08:46 PM, David Lord wrote: Mike S wrote: On 8/27/2014 5:48 AM, valizade...@gmail.com wrote: I not sure, how should I write the ntp.conf file to achieve the maximum accuracy using pps. i don't know if the ntpd use the pps or not in my case! Sometimes it is recognized as a falseticker (x) and sometimes it is OK(o) !!! Try adding tos mindist 0.02 to your config. NMEA tends to wander around - the default mindist of 0.001 can result in what you see. You might try setting it even higher, and work your way down to a reliable minimum. Hi For several years I've used: tos minsane 3 tos orphan 10 tos mindist 0.4 currently with PPS, NMEA, 2 x local pcs, 4 x local pool.ntp.org servers and one remote source. ntp-dev-4.2.7p444 on NetBSD-6/i386 David The basic problem is that using a PPS clock and a GPS(NMEA) clock separates what belongs together: the time message and the PPS pulse. Using the PPS-support flag at the NMEA driver and *not* using a separate PPS clock avoids the problem. As already mentioned, some receivers (e.g. my Garmin GPS18xLVC) have a serial timing that leaves something to be desired... I decided to use the NMEA-internal PPS support and had no problems whith that since years. Pearly From the docs: mindist mindistance Specify the minimum distance used by the selection and anticlockhop algorithm. Larger values increase the tolerance for outliers; smaller values increase the selectivity. The default is .001 s. In some cases, such as reference clocks with high jitter and a PPS signal, it is useful to increase the value to insure the intersection interval is always nonempty. I tested different ntp.conf and here are some results (ntp.conf and ntpq-p): #TEST:1 - ntp.conf--- server 127.127.22.1 minpoll 4 #PPS server 127.127.20.1 prefer minpoll 4 mode 16 #GPS fudge 127.127.20.1 flag1 1 flag3 1 - GPS on COM port (PPS connected to DCD pin) remote refid st t when poll reach delay offset jitter == xPPS(1) .PPS.0 l3 16 3770.000 30.681 29.011 oGPS_NMEA(1) .GPS.0 l2 16 3770.000 29.964 29.404 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS as a falseticker!!!
On Wed, Aug 27, 2014 at 4:44 PM, juergen perlinger juergen.perlin...@t-online.de wrote: The basic problem is that using a PPS clock and a GPS(NMEA) clock separates what belongs together This is not true. Normally I wouldn't fall prey to there's something wrong on the Internet but this assertion doesn't help solve any problems let alone the problem at hand. In fact in some configurations I've run using the PPS option in the NMEA refclock has *caused* problems. None of the PPS refclock + NMEA refclock instances Ive run have any problems. This is not to mention the ability to run a PPS disciplined local clock as a S1 (taking some care to do it right) without a persistent external source of second numbering. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS as a falseticker!!!
thanks for the reply i added tos mindist X and changed x from 0.001 to 10 but none of them worked! any answers for my questions in first post? especially the first one! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS as a falseticker!!!
valizade...@gmail.com wrote: thanks for the reply i added tos mindist X and changed x from 0.001 to 10 but none of them worked! any answers for my questions in first post? especially the first one! Hi The settings needed can depend on your gps device, make, model, firmware release etc. For my 'sure' gps as well as tos mindist 0.4 I have: server 127.127.20.2 mode 18 prefer fudge 127.127.20.2 stratum 7 time2 0.407 flag1 0 refid GPSb server 127.127.22.2 minpoll 4 maxpoll 4 fudge 127.127.22.2 flag2 0 flag3 1 refid PPSb The time2 value was obtained by setting 'noselect' rather than 'prefer' and monitoring the GPSb offset over a few days then setting time2 to a value that included that range. David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS as a falseticker!!!
On 8/27/2014 5:48 AM, valizade...@gmail.com wrote: I not sure, how should I write the ntp.conf file to achieve the maximum accuracy using pps. i don't know if the ntpd use the pps or not in my case! Sometimes it is recognized as a falseticker (x) and sometimes it is OK(o) !!! Try adding tos mindist 0.02 to your config. NMEA tends to wander around - the default mindist of 0.001 can result in what you see. You might try setting it even higher, and work your way down to a reliable minimum. From the docs: mindist mindistance Specify the minimum distance used by the selection and anticlockhop algorithm. Larger values increase the tolerance for outliers; smaller values increase the selectivity. The default is .001 s. In some cases, such as reference clocks with high jitter and a PPS signal, it is useful to increase the value to insure the intersection interval is always nonempty. I tested different ntp.conf and here are some results (ntp.conf and ntpq-p): #TEST:1 - ntp.conf--- server 127.127.22.1 minpoll 4 #PPS server 127.127.20.1 prefer minpoll 4 mode 16 #GPS fudge 127.127.20.1 flag1 1 flag3 1 - GPS on COM port (PPS connected to DCD pin) remote refid st t when poll reach delay offset jitter == xPPS(1) .PPS.0 l3 16 3770.000 30.681 29.011 oGPS_NMEA(1) .GPS.0 l2 16 3770.000 29.964 29.404 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] PPS as a falseticker!!!
Mike S wrote: On 8/27/2014 5:48 AM, valizade...@gmail.com wrote: I not sure, how should I write the ntp.conf file to achieve the maximum accuracy using pps. i don't know if the ntpd use the pps or not in my case! Sometimes it is recognized as a falseticker (x) and sometimes it is OK(o) !!! Try adding tos mindist 0.02 to your config. NMEA tends to wander around - the default mindist of 0.001 can result in what you see. You might try setting it even higher, and work your way down to a reliable minimum. Hi For several years I've used: tos minsane 3 tos orphan 10 tos mindist 0.4 currently with PPS, NMEA, 2 x local pcs, 4 x local pool.ntp.org servers and one remote source. ntp-dev-4.2.7p444 on NetBSD-6/i386 David From the docs: mindist mindistance Specify the minimum distance used by the selection and anticlockhop algorithm. Larger values increase the tolerance for outliers; smaller values increase the selectivity. The default is .001 s. In some cases, such as reference clocks with high jitter and a PPS signal, it is useful to increase the value to insure the intersection interval is always nonempty. I tested different ntp.conf and here are some results (ntp.conf and ntpq-p): #TEST:1 - ntp.conf--- server 127.127.22.1 minpoll 4 #PPS server 127.127.20.1 prefer minpoll 4 mode 16 #GPS fudge 127.127.20.1 flag1 1 flag3 1 - GPS on COM port (PPS connected to DCD pin) remote refid st t when poll reach delay offset jitter == xPPS(1) .PPS.0 l3 16 3770.000 30.681 29.011 oGPS_NMEA(1) .GPS.0 l2 16 3770.000 29.964 29.404 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
