[ntp:questions] Strange jumps in PPM

unruh unruh at invalid.ca
Fri Aug 23 13:33:25 UTC 2013


On 2013-08-23, Charles Elliott <elliott.ch at verizon.net> wrote:
> 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.

That difference will make only a few nanosecond correction to your time.
Most drivers and certainly the Intrrupt handling on the PC cannot get
that kind of accuracy. Your location would have to be out by about a
km for it to make a difference and if your GPS location is out by a km,
return it immediately.


>
> 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