[LinuxPPS] Why is my ATOM clock a falseticker?

[Paul Simons]

I moved to p158 and the times are correctly translated again: 

# ntpq -c rv -c ass -p
associd=0 status=00b8 leap_none, sync_unspec, 11 events, no_sys_peer,
version="ntpd 4.2.5p158 at 1.1809-o[1] Mon Feb  9 04:32:17 UTC 2009 (1)",
processor="i686", system="Linux/2.6.26.simonet", leap=00, stratum=1,
precision=-19, rootdelay=0.000, rootdisp=2.071, refid=TRUE,
reftime=cd3a392b.fff1aea4  Sun, Feb  8 2009 21:10:03.999,
clock=cd3a3956.aa9bebb6  Sun, Feb  8 2009 21:10:46.666, peer=0, tc=6,
mintc=3, offset=0.448, frequency=-88.714, sys_jitter=0.051,
clk_jitter=0.050, clk_wander=0.003 

ind assid status  conf reach auth condition  last_event cnt
===========================================================
  1 36392  914a   yes   yes  none falsetick    sys_peer  4
  2 36393  913b   yes   yes  none falsetick clock_alarm  3
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
xPPS(1)          .PPS.            0 l   28   16   76    0.000  -493.19   0.002
xTRUETIME(0)     .TRUE.           0 l   43   64  377    0.000    0.448   0.051

Could the problem be with the "reach"? It seems that ntpd can always reach the TRUETIME, but frequently does not reach the PPS. 

1. I did find time fudge in the TRUETIME driver, but I wanted to bring up the above question first. 

2. The Wiki indicates that the ATOM driver does not need to be patched (That is the main reason I picked it instead of modifying the TRUETIME driver).  Does anybody else use the ATOM driver?  Or is it better to modify the specific clock driver? 

On 02/06/2009, "Cirilo Bernardo" stated:
>
> That shows that there is no problem with PPS or your electronic interface.
>
> I have looked at the NTPD driver (refclock_true.c) and the driver
> performs some voodoo which I don't understand (some ad-hoc atmospheric
> propagation delay).  However, if this reference driver is tied to the
> ATOM driver (which assumes a precise interval reference, not
> necessarily synchronised to TAI/UTC/GPS) it will calculate an 'offset'
> for the ATOM signals and eventually tie into it.  All I can suggest at
> the moment are:
>
> 1. fiddle with the option settings of the driver; see the driver
> documentation.  This may be sufficient to discipline the TrueTime
> output.
> 2. check that the ATOM driver is correctly patched to use LinuxPPS
>
> The ideal behavior here (based on how the drivers work) is for the
> TRUE driver to calculate an 'offset' for the ATOM driver; that offset
> needs to be used (either in the ATOM driver or LinuxPPS - it doesn't
> matter).  If the calculated offset is ignored, then the PPS will
> become a 'false ticker' (because the offset can be as much as 0.5
> seconds).
>
> - Cirilo
>


Links:
------
[1] mailto:4.2.5p158 at 1.1809-o


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ml.enneenne.com/pipermail/linuxpps/attachments/20090208/f787a0c1/attachment.htm