[time-nuts] Another Arduino GPSDO

[Bob Camp]

Hi

Since the output of your GPS (short term and long term)  is likely much better than your ability to measure (using your setup), why not just drive the clock with the GPS? You would use far less power and have far fewer problems.

Bob

On Mar 28, 2014, at 5:55 PM, Eric Williams <wd6cmu at gmail.com> wrote:

> I just saw Lars' postings on his design and thought I'd throw mine in since
> I've been working on a similar low-end goal but doing it a different way.
> Not really an Arduino, either, but it's based on an AVR processor and
> should be portable to an Arduino.  Right now it's still on a solderless
> breadboard but it seems to be working.
> 
> I have a 5MHz OCXO feeding counter/timer 1 on a ATmega644, the 16-bit
> counter is set to count modulo 5000 and the 1PPS from the GPS (uBlox NEO
> 6M) triggers a capture of the counter, and also a capture interrupt.  If
> the OCXO is exactly right you should get the same capture value every
> second.  If the value changes, the frequency is off.
> 
> Obviously this only tells you if the OCXO drifts off from the 1PPS by one
> cycle or more, so that's only 200ns resolution.  To get below that I count
> the number of 1PPS ticks before a second cycle is dropped, then use the
> inverse of the time interval to correct the DAC on the OCXO.  (The shorter
> the period, the larger the correction.)  I was lucky enough to snag a
> Symetricom OCXO with a built-in DAC, so that's a simple matter of clocking
> a 16-bit value into it.
> 
> Typically the thing runs at an interval of 2000 seconds or so between
> corrections, so that's about 1 part in 10^10.  The code is pretty ad-hoc,
> but once it thinks it has the frequency pretty close it starts nudging the
> phase in a direction to where the capture count converges on zero.  The
> object of the thing is to make a ridiculously accurate table clock, and the
> clock code is driven by the 1ms counter overflow interrupt, so this make
> the interrupt line up with the 1PPS from the GPS.
> 
> I'm sure the short-term stability isn't as good as a PLL, but averaging the
> errors over such a long period does have the advantage of making the
> sawtooth error pretty much irrelevant.
> 
> I also have a 1-Wire thermometer stuck to the OCXO case and record the DAC
> values by temperature in the AVR's EEPROM, they can be retrieved for use in
> holdover conditions.  The DAC values that produce longer transition periods
> take precedence over those with shorter ones for the same temperature.
> --
> Eric Williams WD6CMU
> _______________________________________________
> 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.