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 <p...@phk.freebsd.dk> wrote: > In message <437c6604-20a5-4e05-be99-9e26b01d8...@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 > p...@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@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.