[ntp:questions] Strange jumps in PPM

Charles Elliott elliott.ch at verizon.net
Fri Aug 23 11:07:19 UTC 2013


Several people on the mail list have suggested that the nmea clock driver
estimate the accuracy of the time reading by the divergence of the indicated
location from the GPS device's true location.  Right now the nmea driver
does not look at the lat/long readings.

You can find an accurate estimate of your true position by averaging the 
lat/long readings in clockstats over several days, if you are using the RMC
sentence.  Enter the average into Google maps and the little arrow should
point
exactly at your location.

Then plot, say, the sum of SQRT( (trueLat - lat(i))^2 + (trueLong -
long(i))^2 )
divided by the number of readings against the GPS clock offset to see if
there 
is any relationship.  This is easily done in Excel or another spreadsheet,
though it would take time.

Another interesting experiment would be to determine if WAAS active or
inactive
makes any difference in the accuracy of the time.

Charles Elliott

> -----Original Message-----
> From: questions-bounces+elliott.ch=verizon.net at lists.ntp.org
> [mailto:questions-bounces+elliott.ch=verizon.net at lists.ntp.org] On
> Behalf Of E-Mail Sent to this address will be added to the BlackLists
> Sent: Wednesday, August 21, 2013 8:08 PM
> To: questions at lists.ntp.org
> Subject: Re: [ntp:questions] Strange jumps in PPM
> 
> 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,
>  GPRMC, GPGGA, GPGLL, GPZDG, PGRMF
>   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
> 
> <ntp-dev-4.2.7p348/ntpd/refclock_nmea.c>
> ...
> 	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);
> 		up->tally.bad++;
> ...
>  * 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.
> 
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions



More information about the questions mailing list