[time-nuts] GPSDO Alternatives

David 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:

>Hi
>
>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. 
>
>Bob
>
>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:
>>> 
>>>> Chris:
>>>> 
>>>>> 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.
>>>> 
>>>> Don
>> 
>> _______________________________________________
>> 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 mailing list