[time-nuts] GPSDO Alternatives
Bob Camp
lists at rtty.us
Fri Dec 7 01:54:51 UTC 2012
Hi
PSoC's are another attractive possibility that suffers from the same basic "re-clock everything" flaw. Lots of time down the drain there….
Bob
On Dec 6, 2012, at 8:22 PM, SAIDJACK at aol.com wrote:
> David,
>
> The NXP LPC932 processor series are very cheap and small, and we got very
> excited to see timers running at up to 32MHz internally if I remember
> correctly.
>
> Then setting up a test system we noted that the timer can capture with
> 32MHz resolution which is good enough for a low-cost GPSDO implementation, but
> that they gated the input pin through a flip-flop running at CPU core
> speed, which was around 6MHz if I remember correctly.
>
> DAAHHHH. So all that fast timer resolution goes out the door by gating the
> input pin instead of using non-gated inputs for the timer functions.
>
> It does work however, in the end we made that processor do the chores in
> our quite old and discontinued FireFox GPSDO circuit. TVB has some plots on
> his website for that unit I think, and its quite surprising what type of
> stability we achieved with that little 8 bit bugger back then.
>
> bye,
> Said
>
>
> In a message dated 12/6/2012 16:00:27 Pacific Standard Time,
> davidwhess at gmail.com writes:
>
> You can use the ATmega328 16 bit timer/counter in input capture mode
> to count the number of 10 MHz OCXO cycles per pulse per second period
> to a resolution of 100ns but there are some problems:
>
> The ATmega328 16 bit timer/counter external clock is limited to 1/4 of
> the CPU frequency with an asynchronous source so the 10 MHz OCXO would
> need to be divided down which would further limit performance and
> require an external divider. Modifying the Aruino board to use the 10
> MHz OCXO in place of the CPU clock solves that problem.
>
> Then operating the counter/timer in input capture mode with the GPS
> pulse per second signal connected to the input capture pin would allow
> almost Shera like performance. The timing resolution would be 2.4
> times lower (and not asynchronous) limiting performance over short
> time spans.
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
More information about the time-nuts
mailing list