[ntp:questions] Re: NMEA driver clk_fault - OK. Thanks

Allen McIntosh mcintosh at mc-pc.research.telcordia.com
Wed Sep 17 03:06:40 UTC 2003


In article <3F672FF7.B3D1C058 at udel.edu>, David L. Mills <mills at udel.edu> wrote:
>David,
>
>Why do you need to do this when the clockstats facility is so readily
>accessable? All the drivers I know about stash the timecode string via
>this facility as enabled by fudge flag 4.

Having spent some time fighting with the NMEA driver, I went back and
looked at the code, which (in my version, 4.1.72c) does this just
prior to exiting:

	if (!up->polled)
	    return;
        up->polled = 0;
        pp->lastref = pp->lastrec;
        refclock_receive(peer);
        /* If we get here - what we got from the clock is OK, so say so */
         refclock_report(peer, CEVNT_NOMINAL);
        record_clock_stats(&peer->srcadr, pp->a_lastcode);

>From this, I conclude:

1) The NMEA sentences only get reported when the refclock is polled.
   I'd prefer to see the first sentence that causes the clock to
   go out of sync.  I know the two sentences probably convey the same
   information, but it's not that hard to add the offending message
   to the system log info.

2a) The driver only reports NMEA sentences via clockstats if the GPS
    receiver is happy (as the comment suggests).
or
2b) After detecting a clock fault and aborting some calculations, the
    driver reports that things are wonderful after all (as my
    reading of the code suggests).

I'm leaning towards (2b).  I'll turn on clockstats and post a followup
next time the receiver gets unhappy.

Does anyone know if the PPS signal stops when the GPS receiver is unhappy?



More information about the questions mailing list