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 ; On Mon, 26 Jun 2006 09:21:22 +0200,
"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 ...
-
Re: PPS signal that's not synchronized with second boundaries
On Mon, 26 Jun 2006 09:21:22 +0200,
"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.
I hope so, as that's how we're planning to hook-up a Rubidium oscillator,
using refclock_atom! Without kernel/hardpps, i.e. flag3=0.
Note that we expect to have to alter the fudge regularly to track Rb aging.
--
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)
-
Re: PPS signal that's not synchronized with second boundaries
Ronan Flood wrote:
> On Mon, 26 Jun 2006 09:21:22 +0200,
> "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.
>
> I hope so, as that's how we're planning to hook-up a Rubidium oscillator,
> using refclock_atom! Without kernel/hardpps, i.e. flag3=0.
>
> Note that we expect to have to alter the fudge regularly to track Rb aging.
>
It should work - it's the flag3 = 1 mode thats broken.
John