[ntp:questions] Strange jumps in PPM

E-Mail Sent to this address will be added to the BlackLists Null at BlackList.Anitech-Systems.invalid
Thu Aug 22 00:07:57 UTC 2013

Harlan Stenn wrote:
> I'd love to see NTP be able to query and use this sort of information.

Several of the NMEA sentences have fix quality,
 for binary Refclock drivers if the feature exists,
 there is sure to be packets that include the fix quality.

I guess we'd have to look at the driver source to see if
 if make use of any of the fix quality fields.

Of the messages it appears the NMEA driver supports,
  Have some variety of detail of Fix Quality

 GPZDA Does NOT have fix quality

  So the advantage of using _only_ ZDA's compact / short sentence
   to get date & time, is slightly devalued by not getting any
   quality indications?

If does appear to read and use them, See: parse_qual LEAP_NOTINSYNC

	if (pp->leap == LEAP_NOTINSYNC)
		return PPS_RELATE_NONE; /* clock is insane, no chance */
	/* if whole system out-of-sync, do not try to PLL */
	if (sys_leap == LEAP_NOTINSYNC)
		return PPS_RELATE_EDGE; /* cannot PLL with atom code */
	 * Grab fields depending on clock string type and possibly wipe
	 * sensitive data from the last timecode.
	switch (sentence) {
	case NMEA_...:
		/*Check quality byte, fetch data & time */
		pp->leap = parse_qual ...
	/* check clock sanity; [bug 2143] */
	if (pp->leap == LEAP_NOTINSYNC) {	/* no good status? */
		refclock_report(peer, CEVNT_BADREPLY);
 * Check sync status
 * If the character at the data field start matches the tag value,
 * return LEAP_NOWARNING and LEAP_NOTINSYNC otherwise. If the 'inverted'
 * flag is given, just the opposite value is returned. If there is no
 * data field (*cp points to the NUL byte) the result is LEAP_NOTINSYNC.

E-Mail Sent to this address <BlackList at Anitech-Systems.com>
  will be added to the BlackLists.

More information about the questions mailing list