[time-nuts] GPS Disciplined TCXO

[Nick Sayer]

> On Oct 24, 2015, at 2:43 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> 
> On Fri, Oct 23, 2015 at 11:08 PM, Nick Sayer via time-nuts
> <time-nuts at febo.com> wrote:
>> 
>>> 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.
> 
> Indeed!  However, the spec sheet shows (e.g. figure 10) a differential
> non-linearity of 0.2 .. -0.2  LSB,  meaning that when the PLL makes a
> single step the result may be 20% greater or lower than expected,
> which probably isn't good for stability though not the PLL
> breaking-ness of a non-monotone response.
> 
>> That strikes me as familiar - a little like how Arduino fakes analog output by running PWM into an LPF.
> 
> It's a common technique, (it and ones like it) also used internally in
> high bit depth DACs.
> 
>> 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.
> 
> Ouch, that is a fairly substantial spike compared to 1lsb... it's
> short at least, but if you are only updating once a second

Actually, once every 100 seconds presently.

> I'd wonder
> if that would not have a measurable impact on stability.
> 
> A potential advantage of running at a constant high rate is that
> rather than taking the impact of that glitch once per second, the
> glitch happens constantly and so its effect can just be averaged out
> by the PLL.  (e.g. it becomes equivalent to just scaling the output
> voltage by its average effects).

Well, at the risk of sounding a bit self-serving, I encourage you to give it a try. If you have a 3.3 volt (or target powered) AVR programmer you can modify the firmware and experiment with your technique. Of course, since it’s open hardware you don’t need to get one from me if you don’t want to.

At the moment my priorities are in getting the chassis fit and finish finalized (I’ve got one more PCB version to order and I think that will likely wind up being The One) and tuning the PLL constants better. I want to get some long term samples of the oscillators uncorrected so that I can run the GPSDO simulator to accelerate that process. At the moment my perception is that the feedback is… glacial…