[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