[ntp:hackers] refclock_atom.c

David L. Mills mills at udel.edu
Tue Dec 14 08:51:29 PST 2004


Mark,

Not all the timepps.h files support sequence numbering, which is by 
definition in the spec unreliable. A better way to fix your problem is 
the range gate code in the nanokernel PPS grooming. See the hardpps() 
routine. That code doesn't need sequence numbers; it is driven entirely 
by the raw timestamps and would work in any system environment.

Dave

Dave

Mark Martinec wrote:

>Dave,
>
>>from me:
>  
>
>>>The atom_start() passes a correct mode (obtained from the mode keyword)
>>>to the atom_ppsapi(), but then the atom_control() runs, recomputes
>>>the mode according to its own idea (flag2), and calls atom_ppsapi again,
>>>clobbering the already correctly configured ppsapi.
>>>      
>>>
>
>  
>
>>Mark, the atom driver should be fixed.
>>    
>>
>
>I presume the change hasn't made it to the repository yet
>  (apart from fixing the uninitialized pointer (pp=peer->procptr))
>so I'll wait a bit.
>
>
>May I suggest the following change as well:
>
>--- refclock_atom.c~	Tue Dec 14 12:01:17 2004
>+++ refclock_atom.c	Tue Dec 14 15:33:17 2004
>@@ -350,4 +354,4 @@
> 	if (up->pps_params.mode & PPS_CAPTUREASSERT) {
>-		if (pps_info.assert_sequence ==
>-		    up->pps_info.assert_sequence)
>+		if (up->pps_info.assert_sequence !=
>+		    pps_info.assert_sequence + 1) {
> 			return;
>@@ -356,4 +360,4 @@
> 	} else if (up->pps_params.mode & PPS_CAPTURECLEAR) {
>-		if (pps_info.clear_sequence ==
>-		    up->pps_info.clear_sequence)
>+		if (pps_info.clear_sequence !=
>+		    up->pps_info.clear_sequence + 1)
> 			return;
>
>It causes the pps event to be ignored if more than one event occurred
>since the last check (i.e. exactly one event is valid, anything
>else is to be ignored).
>
>Background: using an el cheapo radio clock receiver without an
>autonomous oscillator, the one second pulses start to get erratic
>once or twice per day for some period just before reception is
>completely lost. The median filtering tries to do its job,
>but if such erratic situation lasts for several minutes,
>it can't do miracles and the dying breath kicks the loop frequency
>way off more often than not. It would be far better if the event
>is simple ignored if it turns out there were more then one during
>the last second interval.
>
>I don't suppose the change could affect any quality clock or GPS
>receiver. Multiple events per second are a cause of suspicion anyway
>(perhaps warranting a log entry).
>
>  Mark
>
>  
>




More information about the hackers mailing list