[time-nuts] GPS Disciplined TCXO

[Nick Sayer]

> On Oct 23, 2015, at 2:09 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> 
> On Tue, Oct 20, 2015 at 8:53 PM, Bryan _ <bpl521 at outlook.com> wrote:
>> Saw this on the Hackaday site if anyone is interested.
>> https://hackaday.io/project/6872-gps-disciplined-tcxo
> 
> Will this design that uses the output of the DAC directly not run into
> problems with non-monotonicity and/or dead-zones in the DAC output?  I
> would expect a PLL to behave very poorly if there is any
> non-monotonicity in the least significant bit of the DAC.

The datasheet claims the DAC is inherently monotonic. It’s a $7 part, so I don’t have much reason to look sideways at that claim.

> 
> My intuition would be to use TPDF dither against a higher resolution
> internal value (perhaps 32 bits) with noise shaping so that the dither
> has no power at DC (and not much near it), followed by a RC low-pass
> filter. With this approach the fact that available DAC parts run at
> speeds far faster than needed for this control helps overcome the fact
> that highly monotone parts are less common (last I looked).  This
> would also help give much finer control without compromising tuning
> range.

That strikes me as familiar - a little like how Arduino fakes analog output by running PWM into an LPF.

If you look at the AD5061 datasheet, there is unfortunately a relatively significant (to my eyes, at least) update glitch. I suppose it’s quick enough that the RC filter would get rid of most of it, but it is an extra noise source if you do it frequently, like you’re suggesting.

It’s an avenue I’ve not investigated, but in principle, it’s just a firmware change. The one issue you may find is that the DAC update is bit-banged at the moment, so it’s much slower than it could be, even with the AVR clocked at 10 MHz. You could use the SPI facilities built into the ATTiny… except that I goofed and used MISO instead of MOSI (or the other way - I forget) for the data pin to the DAC. Changing that would require a board redesign and a compile time firmware flag, and SPI wouldn’t be usable on currently deployed hardware versions.