[time-nuts] GPSDO using 100Hz
WarrenS
warrensjmail-one at yahoo.com
Mon Nov 24 21:44:43 UTC 2008
> Mike
> Neither do I, know how to reply to a post that is. This may be the
> blind leading the blind and end up in some unknown place.
> True it would be simpler to use the High freq Osc directly but it
> would not be accurate.
> The problem with just using the High freq as you suggested is that
> it is not at any known, exact or even constant frequency.
> The divider number can change for each low freq cycle. Example if
> the master freq was say 0.2520 Hz high then every forth second the
> divider would add 1 extra divide count and every 500th second it
> would divide by an additional extra clock time, therefore skipping
> 11 divides every 500 seconds.
> Regards,
> Warren
Warren, thanks for the reply. When you say "The divider number can
change", what oscillator are you referring to?
Is this the cheap crystal oscillator in the GPS unit? If so, is it
adjusting the timing of the 100Hz pulses the same way as it adjusts
the 1PPS? It doesn't seem it could do it any other way.
If that's true, how does it do the calculation for each 1Hz message
from the GPS decode?
Does it put out 100 pulses using the same timing info, and repeat
the next cycle with a different timing?
Then the sawtooth would be a group of 100 pulses, then another group
shifted slightly in phase. Heh - that would be fun for a PLL to
track:)
Another alternative would be to repeat the calculation for each
pulse and shift them according to where they are in the cycle. This
would be a much nicer signal for a PLL to work with.
It might take a lot of calculations, but I suppose a lookup table
would reduce the workload on the processor and leave enough cpu
cycles for other tasks.
Can you tell if any of the above methods are used in your system?
Thanks,
Mike Monett
********************
Mike
Note: I gave you a simple example of why it is not possible to just buffer
the High Freq osc . The actual working get a bit more complicated.
In short when it is time to give out the next pulse whether it is 1 Hz or 100 Hz
It sends it outs as close as possible to the correct time, using some
internal clock. What I have seen on the Oncore is that this causes a peak of +- 50ns
of jitter. It works the same with the 100Hz or the 1 Hz, both have the same
peak to peak rising edge jitter, which is different for each pulse sent.
The 1Hz timing error message it sends out has little to do with the 100 Hz timing.
And is not relevant when using the 100Hz except for a few advanced alising issues.
I hope that answers your questions. Can I ask why the interest?
Warren
More information about the time-nuts
mailing list