[ntp:hackers] refclock_atom.c

David L. Mills mills at udel.edu
Tue Dec 14 16:04:54 PST 2004


Mark,

I was wrong. All the PPSAPIs I have here do sequence numbering and there 
is a range gate in the driver (but not a frequency discriminator). 
However, your code snip won't work. The driver is polled at nominal 
one-second intervals; however, this is not synchronous with the PPS 
signal. In principle, zero, one or two events could occur between polls. 
In fact, the sequence number checks are superflous, since better checks 
are available. The range gate is designed to reject samples outside of a 
band of 5 ms either side of the next second. It is primarily intended to 
reject such common things as connecting an invalid or very noisy PPS 
signal (A common problem is when somebody connects the 10 MHz output of 
a cesium oscillator to the PPS input).

You describe a problem that lasts for several minutes - no amount of 
pulse-to-pulse grooming can fix that. What you suggest is called a noise 
gate that amounts to puncturing the sequence when the interval between 
samples is greater than nominal one second. This assumes that the noise 
mechanism is primarily erasures, not large time errors, which would be 
caught by the range gate. I'll see that I can do.

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