Re: PPS signal that's not synchronized with second boundaries - NTP

This is a discussion on Re: PPS signal that's not synchronized with second boundaries - NTP ; Maarten Wiltink wrote: > "Hal Murray" wrote in message > news:_--dnTaJHdp4oALZnZ2dnUVZ_vKdnZ2d@megapath.net... > >> Suppose I had something like a Rubidium oscillator that makes >> a nice PPS signal, but it's not synchronized to a second boundary. >> >> Is there ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: PPS signal that's not synchronized with second boundaries

  1. Re: PPS signal that's not synchronized with second boundaries

    Maarten Wiltink wrote:
    > "Hal Murray" wrote in message
    > news:_--dnTaJHdp4oALZnZ2dnUVZ_vKdnZ2d@megapath.net...
    >
    >> Suppose I had something like a Rubidium oscillator that makes
    >> a nice PPS signal, but it's not synchronized to a second boundary.
    >>
    >> Is there any way to take advantage of that?

    >
    > If I've understood past news correctly, you can connect it as a
    > PPS source and, once you have an idea of its offset, tinker/fudge
    > it so it does appear synchronised to the second boundary.
    >
    > The bad news is that my recollection of said past news is also that
    > this didn't quite work then. I think the offset correction was
    > applied at the wrong point, so it still appeared off-beat. But
    > perhaps that got fixed in the meantime.
    >
    > Groetjes,
    > Maarten Wiltink
    >
    >



    It's ok if you let ntp manage the pps but if you use the kernel pps (at least in FreeBSD) ntp
    doesn't tell the kernel about the offset so it locks to the pps edge not the real boundary. There
    is a patch in an open bug for the nmea driver that would also work for the pps driver but nobody
    seem interested in folding it in.

    John

  2. Re: PPS signal that's not synchronized with second boundaries

    John Pettitt wrote:

    > It's ok if you let ntp manage the pps but if you use the kernel pps
    > (at least in FreeBSD) ntp doesn't tell the kernel about the offset
    > so it locks to the pps edge not the real boundary. There is a patch
    > in an open bug for the nmea driver that would also work for the pps
    > driver but nobody seem interested in folding it in.


    You probably need to open a separate bug for refclock_atom.
    A similar problem in refclock_parse has recently been fixed.

    --
    Ronan Flood
    working for but not speaking for
    Network Services, University of London Computer Centre
    (which means: don't bother ULCC if I've said something you don't like)

+ Reply to Thread