[time-nuts] GPSDO control loops and correcting quantizationerror

Bob Camp lists at rtty.us
Sat Sep 15 20:41:04 UTC 2012


Hi

The real answer is that you don't need anything near 32 bits. Anything with a <1.0x10^-13 AVAR isn't going to have much of a tuning range on the EFC. 22 bits will do just fine for a 1 ppm EFC range part with 1.0 x10^-12 at 1 second. With that sort of sensitivity you will have a *very* hard time getting the voltage into the OCXO without a gotcha right at the terminals, unless the unit has a fully isolated EFC input. That rules out roughly 99.99% of all OCXO's.

Bob

On Sep 15, 2012, at 3:12 PM, Poul-Henning Kamp <phk at phk.freebsd.dk> wrote:

> In message <437C6604-20A5-4E05-BE99-9E26B01D80B7 at rtty.us>, Bob Camp writes:
> 
>> If indeed 32 bits matters, then instability at the 32 bit level will show up.
>> [...]
>> No free lunch
> 
> Absolutely agree there.
> 
> My point was merely that the requirements for the DAC after a
> software-PLL are very narrow and specific, compared the the quality
> metrics of DAC's in general, and that low cost methods are available
> to meet those needs, so there is no need to spend a fortune on a
> general X bit DAC, if cheaper special purpose one will do.
> 
> One of the advantages of the charge-transfer DAC concept is that
> there is only thermal noise for a stable output, there is no reference
> voltage which can suffer from tempco or noise bleed-through.
> 
> You'll have the tempco of your integration capacitor to deal with,
> but already around 16-20 bits you will be ovenizing everything anyway.
> 
> The noise on EFC voltage changes can be given an almost arbitrary high
> frequency spectrum which will filter out long before it reaches the
> EFC input of the OCXO or Rb.
> 
> In steady state, my experiment fired a single 40nsec pulse every
> some seconds, and I never managed to detect these pulses on the
> output of the voltage follower, because the integration capacitor
> is a glorified low-pass filter.
> 
> Even at high update rates, it would be possible to use a PRNG to
> spread out the spectrum of the update noise.
> 
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk at FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.
> 
> _______________________________________________
> 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_lists.febo.com mailing list