Hi The DAC noise is likely “outside the loop” in a GPSDO. It’s not reduced by feedback. You can indeed find some of these parts that are noisy enough to degrade the ADEV or phase noise of an OCXO.
Bob On Jun 2, 2014, at 10:13 PM, Bob Stewart <[email protected]> wrote: > Hi Bob, > > I decided to look at Mouser for 16-bit DACs, and found the MAX541CCPA for > $12.47. On the one hand, it's an extra $12.47 for the project. On the > other, the dsPIC is a 3.3V device. I'll have to give some thought as to > whether I want to lose that much output range between the DAC and the EFC > divider which will be placed right at the OCXO. Given the flexibility of the > dsPIC33 pin remapping, I may just add it to the board but jumper around it at > first. Hmm, I could just place it right at the OCXO, since I need to > communicate with it with SPI. TBH, I don't think I have the equipment needed > to measure the noise unless it's really bad. I'm already way past my ability > to measure with my TIC daughterboard added to the VE2ZAZ board. > > This is all new territory for me. Should be fun. =) > > Bob > > > ________________________________ > From: Bob Camp <[email protected]> > To: Discussion of precise time and frequency measurement <[email protected]> > Sent: Monday, June 2, 2014 8:01 PM > Subject: Re: [time-nuts] "Audio" DAC for GPSDO? > > > Hi > > There are several reasons why they don’t recommend the typical MCU DAC for > control applications: > > 1) They are noisy at low frequency (1/f noise corner). That impacts their > hitting their INL and DNL specs. > 2) They have constant current leakage at DC. That makes their “center” value > wander around by more than the spec’s would suggest. > 3) The major steps are trimmed for AC (high sample rate) compensation (the > trim includes capacitance effects). At DC … no capacitance effects. > > Yes it’s all one big mess and the effects slop back and forth between the > categories. Bottom line - they very much do not want you to measure their INL > and DNL numbers on a continuous DC basis and then return the parts as being > out of spec. MCU ADC’s can have some of the same issues. Even some pretty > fancy outboard ADC’s only work well at DC if you put a chopper around them. > > Bob > > On Jun 2, 2014, at 7:22 PM, Bob Stewart <[email protected]> wrote: > >> Hi Poul, >> >> I've been reviewing microchips literature and the way I read it is that the >> DAC isn't sensitive to staying at a fixed value. If it's on, the FIFO is >> fed to the DAC. If the FIFO is drained, then the user-settable default >> value is fed to the DAC. When the output amp is turned off, it goes to a >> high impedance output. I also noticed that Finput can vary from 0-45 khz. >> I'm not certain what a 61db SNR would mean at DC values. I see that the >> specifications are for a 15 uA load. I assume that's not hard to meet with >> a typical op-amp. >> >> It's interesting that in one paragraph they call the DAC default register a >> safety feature for industrial control applications, and then a few inches >> later a black box warns that it's not recommended for control type >> applications. >> >> >> Bob >> >> >> >> ________________________________ >> From: Poul-Henning Kamp <[email protected]> >> To: Bob Stewart <[email protected]>; Discussion of precise time and frequency >> measurement <[email protected]> >> Sent: Monday, June 2, 2014 4:08 PM >> Subject: Re: [time-nuts] "Audio" DAC for GPSDO? >> >> >> In message <[email protected]>, Bob >> Stewart writ >> es: >> >>> Could someone explain to me how such an audio DAC differs from a non >>> -audio DAC and why it's not suitable for this application?=A0 Is this just >> >>> a disclaimer from microchip to avoid liability or is there some practical >>> reason to go with a traditional DAC? >> >> A lot of them have DC protections, so you can't leave them at a particular >> input value for very long before they go into safety mode and clamp the >> output to zero. >> >> Your speakers love them for this, your OCXO not so much. >> >> >> -- >> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 >> [email protected] | 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 -- [email protected] >> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts >> and follow the instructions there. > > > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
