Reply by Michael A. Terrell July 26, 20122012-07-26
"Michael A. Terrell" wrote:
> > John Larkin wrote: > > > > On Wed, 18 Jul 2012 02:02:50 -0400, "Michael A. Terrell" > > <mike.terrell@earthlink.net> wrote: > > > > > > > >John Larkin wrote: > > >> > > >> On Tue, 17 Jul 2012 19:50:15 -0400, "Michael A. Terrell" > > >> <mike.terrell@earthlink.net> wrote: > > >> > > >> > > > >> >John Larkin wrote: > > >> >> > > >> >> We used to use AD1862 (20 bit parallel) DACs, but we had bad popcorn > > >> >> noise problems, and AD eventually discontinued them. > > >> >> > > >> >> We have 140 in stock, popcorn fallouts. > > >> > > > >> > > > >> > Would they be useful for a digitally controlled power supply? > > >> > > >> Sure, if you don't mind the occasional 10 PPM bump. > > > > > > > > > That wouldn't bother me. I want to build some new bench supplies that > > >I can program the voltage & current limiting. I would need two per > > >output and I'd like at least four outputs. > > > > I can certainly send you some DACs, and some nice voltage references, > > too. You will need a uP and some displays and encoders or something, > > too. > > > > One could also do it as a feedback system, where a 24-bit delta-sigma > > ADC would measure the output and servo it to a target value. Some of > > those cheap d-s adcs are amazingly good. > > I have some LCD displays & encoders. > > I have some 12x1 LCD displays like these: > http://www.ebay.com/itm/180915257890 > > I have some 16x2 LCD displays like these: > http://www.ebay.com/itm/120949311392 > > I have some similar to these Rotary Encoders: > http://www.ebay.com/itm/140739970480 > > I am learning to program Atmel processors on a Arduino Mega 2560. I > just haven't been able to find the DACs. We used some dual 18 bit at > Microdyne to set video output levels & DC offset. A lookup table gave > accurate .1 dB steps over a range of 0 to -63 dB. > > I'll send you an email for my address.
I got the box in the mail. Thank you for the DACs.
Reply by Mike July 20, 20122012-07-20
John Larkin <jlarkin@highlandtechnology.com> wrote:

> On Fri, 20 Jul 2012 22:20:09 GMT, Mike <spam@me.not> wrote:
> Maybe he's seeing an opamp disturbance thing, from charge injection > into the opamp front end. Any time a CMOS switching thing connects to > the input of a bipolar opamp, expect troubles. IF that is part of the > problem, a model that assumes a voltage source glitch followed by a > filter isn't the real story.
It doesn't have to be bipolar. Overdriving the input of most op amps can cause them to go nonlinear and produce serious recovery problems. It's the same as not feeding RF to the input where it can be rectified, not putting a capacitor from the negative input to ground, not driving a capacitor at the output, and so on. Be we already know these things. The point is your suggestion of a 3-pole Sallen-Key filter won't work. Regards, Mike
Reply by Stephan Goldstein July 20, 20122012-07-20
On Fri, 20 Jul 2012 16:01:58 -0700, John Larkin
<jlarkin@highlandtechnology.com> wrote:

>On Fri, 20 Jul 2012 22:20:09 GMT, Mike <spam@me.not> wrote: > >>John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >> >>> A 3-pole Sallen-Key Bessel filter would be good. The odd pole is >>> passive, so put it first. An S-K is good because the DC gain is 1.000 >>> and doesn't depend on resistor values or TCs. PPM settling will of >>> course be an issue, not just in the filter but everywhere in your >>> signal chain. I usually have transient-response tweaks in my NMR >>> gradient drivers to get to PPM settling in a hundred microseconds or >>> so. >> >>The odd pole is usually first anyway. But it won't help. Speff needs <25 >>ppm, preferably <5ppm. >> >>A quick LTspice transient analysis shows the glitch amplitude is reduced >>by a factor of 20 or so, depending on the risetime, width and amplitude >>assumptions. I modeled a simple triangle pulse 50mv high with 100ns rise >>and fall. This is a bit worse than Speff's image at >> >>http://www.speff.com/glitch.png >> >>but the Sallen-Key LPF is so far from what he needs it doesn't matter >>much. >> >>I used the 3rd order Sallen-Key Low-pass Filter Design Tool at >> >>http://sim.okawa-denshi.jp/en/Sallenkey3Lowkeisan.htm >> >>I calcuated for a Bessel response (minimum overshoot) with the cutoff at >>100KHz. The output pulse height was about 2.5mV, and the tail probably >>goes on for a very long time. >> >>It doesn't look like filtering is going to solve the problem. > >Maybe he's seeing an opamp disturbance thing, from charge injection >into the opamp front end. Any time a CMOS switching thing connects to >the input of a bipolar opamp, expect troubles. IF that is part of the >problem, a model that assumes a voltage source glitch followed by a >filter isn't the real story.
Nope, it's from the internal switches. I got that straight from the designer. It's a combination of the architecture and the voltage range. Big switches to stand the high voltage, and (relatively) high impedances.
Reply by John Larkin July 20, 20122012-07-20
On Fri, 20 Jul 2012 22:20:09 GMT, Mike <spam@me.not> wrote:

>John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: > >> A 3-pole Sallen-Key Bessel filter would be good. The odd pole is >> passive, so put it first. An S-K is good because the DC gain is 1.000 >> and doesn't depend on resistor values or TCs. PPM settling will of >> course be an issue, not just in the filter but everywhere in your >> signal chain. I usually have transient-response tweaks in my NMR >> gradient drivers to get to PPM settling in a hundred microseconds or >> so. > >The odd pole is usually first anyway. But it won't help. Speff needs <25 >ppm, preferably <5ppm. > >A quick LTspice transient analysis shows the glitch amplitude is reduced >by a factor of 20 or so, depending on the risetime, width and amplitude >assumptions. I modeled a simple triangle pulse 50mv high with 100ns rise >and fall. This is a bit worse than Speff's image at > >http://www.speff.com/glitch.png > >but the Sallen-Key LPF is so far from what he needs it doesn't matter >much. > >I used the 3rd order Sallen-Key Low-pass Filter Design Tool at > >http://sim.okawa-denshi.jp/en/Sallenkey3Lowkeisan.htm > >I calcuated for a Bessel response (minimum overshoot) with the cutoff at >100KHz. The output pulse height was about 2.5mV, and the tail probably >goes on for a very long time. > >It doesn't look like filtering is going to solve the problem.
Maybe he's seeing an opamp disturbance thing, from charge injection into the opamp front end. Any time a CMOS switching thing connects to the input of a bipolar opamp, expect troubles. IF that is part of the problem, a model that assumes a voltage source glitch followed by a filter isn't the real story. -- John Larkin Highland Technology, Inc jlarkin at highlandtechnology dot com http://www.highlandtechnology.com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom laser drivers and controllers Photonics and fiberoptic TTL data links VME thermocouple, LVDT, synchro acquisition and simulation
Reply by Michael A. Terrell July 20, 20122012-07-20
Spehro Pefhany wrote:
> > On Fri, 20 Jul 2012 14:47:31 -0400, "Michael A. Terrell" > <mike.terrell@earthlink.net> wrote: > > > > >Jon Elson wrote: > >> > >> Spehro Pefhany wrote: > >> > >> > Nope. Although I suppose I could declare some codes personna > >> > (numbera?) non grata and avoid the worst of them at the expense of a > >> > bit or two resolution. 8-( > >> I'm sure it varies by the exact DAC construction, but my experience > >> is the glitches are not related to specific codes, but specific transitions. > >> So, if there is a big glitch across the 1/4 scale transition, then ANY > >> transition that crosses the boundary creates a roughly similar glitch. > >> This would be when the N-2 bit changes state. So, my understanding is that > >> eliminating the two states on either side of the transition won't get > >> rid of the glitch. Slowly creeping up on this transition also won't > >> get rid of the glitch. It seems that lacking a DAC which has been > >> designed from the ground up to minimize glitch energy, then some sort > >> of sample/hold circuit would be the only solution that actually works. > > > > > > Microdyne had glitch problems in one design, so every board had to be > >tested though the full range of steps while the tech watched the > >sawtooth waveform. > > Bad engineering can produce employment opportunities, if only in > performing rework and installing kludges.
I think the problem cropped up after the original part went from ceramic to plastic dip. Once the test was part of the process, it was never removed. I never saw a bad DAC on the control boards I tested in a four year period. It was the oldest product still in production, and some parts had to be bought form brokers, so I figured they were afraid some old parts would surface. Maybe even the ones they had sent back to the OEM. The test only took a couple minutes, and we probably built 75 of that obsolete item a year so it was no budget breaker.
Reply by Mike July 20, 20122012-07-20
John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote:

> A 3-pole Sallen-Key Bessel filter would be good. The odd pole is > passive, so put it first. An S-K is good because the DC gain is 1.000 > and doesn't depend on resistor values or TCs. PPM settling will of > course be an issue, not just in the filter but everywhere in your > signal chain. I usually have transient-response tweaks in my NMR > gradient drivers to get to PPM settling in a hundred microseconds or > so.
The odd pole is usually first anyway. But it won't help. Speff needs <25 ppm, preferably <5ppm. A quick LTspice transient analysis shows the glitch amplitude is reduced by a factor of 20 or so, depending on the risetime, width and amplitude assumptions. I modeled a simple triangle pulse 50mv high with 100ns rise and fall. This is a bit worse than Speff's image at http://www.speff.com/glitch.png but the Sallen-Key LPF is so far from what he needs it doesn't matter much. I used the 3rd order Sallen-Key Low-pass Filter Design Tool at http://sim.okawa-denshi.jp/en/Sallenkey3Lowkeisan.htm I calcuated for a Bessel response (minimum overshoot) with the cutoff at 100KHz. The output pulse height was about 2.5mV, and the tail probably goes on for a very long time. It doesn't look like filtering is going to solve the problem. Here are the LTspice files: Version 4 SHEET 1 1204 680 WIRE 880 -272 688 -272 WIRE 976 -272 880 -272 WIRE 688 -256 688 -272 WIRE 1008 -224 928 -224 WIRE 928 -208 928 -224 WIRE 880 -192 880 -272 WIRE 896 -192 880 -192 WIRE 976 -176 976 -272 WIRE 976 -176 960 -176 WIRE 1040 -176 976 -176 WIRE 368 -160 352 -160 WIRE 432 -160 368 -160 WIRE 544 -160 512 -160 WIRE 576 -160 544 -160 WIRE 688 -160 688 -192 WIRE 688 -160 656 -160 WIRE 736 -160 688 -160 WIRE 832 -160 816 -160 WIRE 896 -160 832 -160 WIRE 352 -144 352 -160 WIRE 544 -128 544 -160 WIRE 832 -128 832 -160 WIRE 928 -128 928 -144 WIRE 1008 -128 1008 -224 WIRE 352 -48 352 -64 WIRE 384 -48 352 -48 WIRE 400 -48 384 -48 WIRE 544 -48 544 -64 WIRE 832 -48 832 -64 WIRE 352 -32 352 -48 WIRE 928 -32 928 -48 WIRE 1008 -32 1008 -48 WIRE 352 64 352 48 FLAG 352 64 0 FLAG 368 -160 Vin FLAG 384 -48 VRef FLAG 544 -48 0 FLAG 832 -48 0 FLAG 1040 -176 Vout FLAG 928 -32 0 FLAG 1008 -32 0 SYMBOL voltage 352 -48 R0 WINDOW 3 26 83 Invisible 2 SYMATTR Value PULSE(1 1.000001 0 1u 1u 100u 200u) SYMATTR InstName V1 SYMBOL voltage 352 -160 R0 WINDOW 3 28 75 Invisible 2 WINDOW 123 0 0 Left 2 WINDOW 39 0 0 Left 2 SYMATTR Value PULSE(0 50mv 0 100n 100n 1n 200u) SYMATTR InstName V2 SYMBOL res 528 -176 R90 WINDOW 0 0 56 VBottom 2 WINDOW 3 32 56 VTop 2 SYMATTR InstName R1 SYMATTR Value 9.1k SYMBOL res 672 -176 R90 WINDOW 0 0 56 VBottom 2 WINDOW 3 32 56 VTop 2 SYMATTR InstName R2 SYMATTR Value 91k SYMBOL res 832 -176 R90 WINDOW 0 0 56 VBottom 2 WINDOW 3 32 56 VTop 2 SYMATTR InstName R3 SYMATTR Value 27k SYMBOL cap 528 -128 R0 SYMATTR InstName C1 SYMATTR Value 68pf SYMBOL cap 672 -256 R0 SYMATTR InstName C2 SYMATTR Value 22pf SYMBOL cap 816 -128 R0 SYMATTR InstName C3 SYMATTR Value 6.8pf SYMBOL opamps\\2pole 928 -176 R0 SYMATTR InstName U1 SYMBOL voltage 928 -32 R180 WINDOW 3 35 73 Invisible 2 WINDOW 0 -48 91 Left 2 WINDOW 123 0 0 Left 2 WINDOW 39 0 0 Left 2 SYMATTR Value 5 SYMATTR InstName V3 SYMBOL voltage 1008 -144 R0 WINDOW 3 35 73 Invisible 2 WINDOW 123 0 0 Left 2 WINDOW 39 0 0 Left 2 SYMATTR Value 5 SYMATTR InstName V4 TEXT 544 -320 Left 2 !.tran 10u TEXT 544 -352 Left 2 ;'3-Pole Sallen-Key Low-Pass TEXT 456 24 Left 2 ;http://sim.okawa-denshi.jp/en/Sallenkey3Lowkeisan.htm Plot File [Transient Analysis] { Npanes: 2 Active Pane: 1 { traces: 1 {524292,0,"V(vout)-V(Vref)"} X: ('&#2013266101;',0,0,1e-006,1e-005) Y[0]: ('m',1,-0.0006,0.0003,0.0027) Y[1]: ('_',0,1e+308,0,-1e+308) Volts: ('m',0,0,1,-0.0006,0.0003,0.0027) Log: 0 0 0 GridStyle: 1 }, { traces: 2 {524290,0,"V(vin)"} {268959747,0,"V(vout)"} X: ('&#2013266101;',0,0,1e-006,1e-005) Y[0]: (' ',3,0.995,0.005,1.055) Y[1]: ('_',0,1e+308,0,-1e+308) Volts: (' ',0,0,3,0.995,0.005,1.055) Log: 0 0 0 GridStyle: 1 } }
Reply by Spehro Pefhany July 20, 20122012-07-20
On Fri, 20 Jul 2012 14:47:31 -0400, "Michael A. Terrell"
<mike.terrell@earthlink.net> wrote:

> >Jon Elson wrote: >> >> Spehro Pefhany wrote: >> >> > Nope. Although I suppose I could declare some codes personna >> > (numbera?) non grata and avoid the worst of them at the expense of a >> > bit or two resolution. 8-( >> I'm sure it varies by the exact DAC construction, but my experience >> is the glitches are not related to specific codes, but specific transitions. >> So, if there is a big glitch across the 1/4 scale transition, then ANY >> transition that crosses the boundary creates a roughly similar glitch. >> This would be when the N-2 bit changes state. So, my understanding is that >> eliminating the two states on either side of the transition won't get >> rid of the glitch. Slowly creeping up on this transition also won't >> get rid of the glitch. It seems that lacking a DAC which has been >> designed from the ground up to minimize glitch energy, then some sort >> of sample/hold circuit would be the only solution that actually works. > > > Microdyne had glitch problems in one design, so every board had to be >tested though the full range of steps while the tech watched the >sawtooth waveform.
Bad engineering can produce employment opportunities, if only in performing rework and installing kludges.
Reply by Michael A. Terrell July 20, 20122012-07-20
Jon Elson wrote:
> > Spehro Pefhany wrote: > > > Nope. Although I suppose I could declare some codes personna > > (numbera?) non grata and avoid the worst of them at the expense of a > > bit or two resolution. 8-( > I'm sure it varies by the exact DAC construction, but my experience > is the glitches are not related to specific codes, but specific transitions. > So, if there is a big glitch across the 1/4 scale transition, then ANY > transition that crosses the boundary creates a roughly similar glitch. > This would be when the N-2 bit changes state. So, my understanding is that > eliminating the two states on either side of the transition won't get > rid of the glitch. Slowly creeping up on this transition also won't > get rid of the glitch. It seems that lacking a DAC which has been > designed from the ground up to minimize glitch energy, then some sort > of sample/hold circuit would be the only solution that actually works.
Microdyne had glitch problems in one design, so every board had to be tested though the full range of steps while the tech watched the sawtooth waveform.
Reply by John Larkin July 20, 20122012-07-20
On Fri, 20 Jul 2012 11:26:04 -0400, Spehro Pefhany
<speffSNIP@interlogDOTyou.knowwhat> wrote:

>On Fri, 20 Jul 2012 07:47:42 -0700, Jim Thompson ><To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> wrote: > >> >> >>I suspect most of Spehro's "glitch" is due to the DAC buffer... I've >>never seen _anything_ approaching that bad coming straight out of the >>DAC's I design. But I have an advantage in that my stuff stays on >>chip... going thru buffers that have to drive capacitance is where you >>can get hosed. >> >> ...Jim Thompson > >Don't think so. If it was the buffer it wouldn't be code-pattern >dependent. A uniform glitch would not be nearly as much of an issue.
A fast spike glitch from the DAC could disturb some opamps and make things worse, and that would be code sensitive. Most opamps do weird things if you shoot charge into their inputs or outputs. A passive RC section would be a good first pole of a higher-order lowpass filter. A 3-pole Sallen-Key Bessel filter would be good. The odd pole is passive, so put it first. An S-K is good because the DC gain is 1.000 and doesn't depend on resistor values or TCs. PPM settling will of course be an issue, not just in the filter but everywhere in your signal chain. I usually have transient-response tweaks in my NMR gradient drivers to get to PPM settling in a hundred microseconds or so. -- John Larkin Highland Technology Inc www.highlandtechnology.com jlarkin at highlandtechnology dot com Precision electronic instrumentation Picosecond-resolution Digital Delay and Pulse generators Custom timing and laser controllers Photonics and fiberoptic TTL data links VME analog, thermocouple, LVDT, synchro, tachometer Multichannel arbitrary waveform generators
Reply by Spehro Pefhany July 20, 20122012-07-20
On Fri, 20 Jul 2012 07:47:42 -0700, Jim Thompson
<To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> wrote:

> > >I suspect most of Spehro's "glitch" is due to the DAC buffer... I've >never seen _anything_ approaching that bad coming straight out of the >DAC's I design. But I have an advantage in that my stuff stays on >chip... going thru buffers that have to drive capacitance is where you >can get hosed. > > ...Jim Thompson
Don't think so. If it was the buffer it wouldn't be code-pattern dependent. A uniform glitch would not be nearly as much of an issue.