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 <li...@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 <davidwh...@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.ch...@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 <d...@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@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@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.