[time-nuts] GPSDO Alternatives
davidwhess at gmail.com
Fri Dec 7 01:17:48 UTC 2012
It is not a 16 bit capture and it does not run at 1/4 the clock rate.
The Shera uses a 12 bit counter to capture the phase difference
between the OCXO frequency divided by 16 and GPS pulse per second
output to a resolution of about 42ns.
What I suggested effectively captures the same phase difference but
divides the OCXO by 65536 and only has a resolution of 100ns. The
OCXO division is just conceptual though as it comes from the 16 bit
timer/counter overflow internal to the microcontroller so in practice,
the timer/counter is arbitrary length with an interrupt about every
6.5ms doing the housekeeping for the extra bits. It directly measures
the pulse per second period to a resolution of 100ns using the OCXO as
a clock. If a 20 MHz OCXO was used (limited by the maximum clock
frequency of the microcontroller), then the resolution would be 50ns.
That is not how I plan on designing my own GPSDO which has taken a
significant turn from what I posted about here some time ago but I
have stopped discussing that until I have some results to share.
On Thu, 6 Dec 2012 19:34:08 -0500, Bob Camp <lists at rtty.us> wrote:
>Again, the math is pretty simple.
>A 16 bit capture running at a 1/4 clock is not going to get you very near a Shera. It's even further from the more modern "enhanced Shera" designs.
>On Dec 6, 2012, at 6:59 PM, David <davidwhess at gmail.com> wrote:
>> 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.
>> On Thu, 6 Dec 2012 14:57:19 -0800, Chris Albertson
>> <albertson.chris at gmail.com> wrote:
>>> You'd have to seriously divide down the output from the 10MHz OCXO if you
>>> were going to use it as an interrupt. Maybe to divide by 10,000? and even
>>> at the higher clock rate you'd still have poor resolution.
>>> I image each interrupt handler would sample some internal counter and the
>>> background task would look at the delta between the two and adjust the DAC
>>> to drive the OCXO to close the difference. The resolution would be
>>> (maybe?) a "handful" of clock cycles. Given enough time, say a 1000
>>> second period it might wrk well enough. I can't know without doing a more
>>> detailed design
>>> On Thu, Dec 6, 2012 at 1:59 AM, Don Latham <djl at montana.com> wrote:
>>>>> The question I have again is about a simple phase detector.
>>>> I did ask if the arduino interrupt ports could be used as a phase
>>>> detector; one on the GPS and one on the OXCO. Too much jitter? If the 12
>>>> MHz clock is too slow, would an 80 MHz clock ARM arduino style processor
>>>> work? I'm simply too new at this to decide.
>> 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.
>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