On Fri, 23 Oct 2015 07:30:10 -0700 Nick Sayer via time-nuts <time-nuts@febo.com> wrote:
> > BTW: Tom van Baak mentioned in a private mail, that the DOC supply current > > is much higher than i thought it was. So it isn't exactly a drop in > > replacement > > either. > > I’ve run them with the same LDO and they work. The LDO gets warm, of > course, but then, so does the oscillator. The LM1117 is specced for 800mA output. The DOC is specced with max 2.5W at warmup, or 750mA @ 3.3V. Assuming the rest of the circuit does not use more than 50mA, that's barely within specs. I would guess that going up to 900mA shouldn't fry the LM1117 as long as you can deal with the produced heat. Even in the best case, it's too close for my engineers love of safety margins :-) > When I compare them to the same > circuit, but powered with the SC189Z switcher I use for the OH300 variant, > their performance is identical. Which is to say, a half order of magnitude > worse than the DOT050V at tau 1s. Hmm... For a circuit like this, I would use a switched DC/DC converter to get down to 3.8V or even 3.5V, then use a modern LDO with high ripple rejection and low drop-out (<0.5V). This solution will be more expensive then a simple LM1117, but the heating of the circuit would be approximately independent of the input voltage and also much lower. > The data sheets of both claim a short term stability of 1e-9 at 1s. The DOC > is exceeding that, but the DOT is *slaughtering* it. I routinely see 9e-11 > instead. I asked Connor Winfield about that and they said that they should > change the data sheet, as my observations are more in line with reality. But no explanation why this might be the case? > Meanwhile, the OH300 (I’ve only tried one of them so far, however) is at > around 3e-11 at 1s. So that’s what $100 buys you. :) I'm taking notes here :-) > The other thing I saw with the DOC020V that I have not seen with either the > DOT or OH300 variants is a weird oscillation on the VC pin. I posed the > question to Stack Exchange and they suggested that the VC pin internally goes > to a varactor which adds too much capacitance for the output of the OP amp. That sounds kind of strange. Yes, too much capacitance could lead to oscillations. But given the fact that the datasheet of the AD8538 has graphs that go up to 1000pF load capacitance (although with huge overshots) I would expect it to be stable at least up to 100pF (where the overshot graph starts to go up). Most Varicaps are usually in the range of 2-20pF, there are a few that go up to 100pF, but it'd be surprised if they'd use one of these. You can "easily" try whether the varicap theory is right, if you add an 2-10k resistor in the path between the AD8538 and the VCO/OCXO. > I asked Connor Winfield about this and they didn’t have an immediate answer. > The latest boards have the footprints for another RC LPF on the output to > counter this, but since I gave up on the DOC part, the cap is no-stuff and > the resistor is 0 ohms when I build them out (with the other parts). ACK > > > > In the AD5061 datasheet (Rev C) on page 3, at the bottom, > > section "Reference Input/Output", item "V_REF Input Range". > > Yes, it will not fry the device, but it will not work up to spec either > > (unfortunately, manufacturers never mention what part of the spec gets > > degraded if you violate something). > > I do see that now. If you look at the footnote, figure 27 which it references > shows that the Vdd headroom with a VRef of 3.3 volts is more like 20 mV or > so. I would posit that the headroom issue is more likely to result in non- > linearity at high DAC values, perhaps because the output amp may not be > capable of full rail-to-rail operation. It is not clear where the limit comes from. It could be the ouptut buffer, which would then be a no-problem. Or it could be the input buffer for V_ref, which then would lead to an un-buffered, and hence unstable internal reference voltage. Or it could be a problem of one of the DAC internal stages, that needs the headroom.... BTW: 20mV or even 50mV below VDD is considered close to rail (as in rail-to-rail). You need to compare this to the 1-2V (sometimes even 3V) that opamps needed as headroom (both at input and output) from the rails before rail-to-rail opams became en-vogue. IIRC any headroom around/below 100-200mV is considered close to rail. > In practice, the VC output of the analog section is quite stable (more stable > > than the analog supply rail), however, because of the LPF on the DAC's > output. Remember that the DAC was designed with a maximum clock speed of > 30 MHz and we’re using it effectively at 10 mHz. So the LPF trades bandwidth > and slew rate (neither of which are interesting in this application) for > stability. And to some extent you’d be throwing away the pains to which you > went to come up with a super-accurate Vref because you then feed the DAC > output into an op amp that’s powered by the analog supply rail, so its own > noise and non-linearity would likely have a greater impact (at least, I would > expect so). Noise itself is not a problem. As long as it's "high" frequency (>10Hz or so) and not too large, it will get averaged out by the long integration times of the VCO. Yes, it decreases the short-term stability and phase noise performance, but that's not the main selling point here, is it? On the other hand, long term stability (>1s) is important and does improve with a more stable DAC reference voltage. That the Opamp power supply is not as stable might be a little bit of a problem, but shouldn't be too big, as the AD8538 has a power supply rejection ratio of >100dB, ie power supply noise/variations should be very small compared to the instabilities of the DAC and Vref. Attila Kinali -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neil Stephenson _______________________________________________ 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.