Paul wrote:
On Wed, Aug 27, 2014 at 4:44 PM, juergen perlinger
<[email protected]> 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
I"ve 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
[email protected]
http://lists.ntp.org/listinfo/questions
