Can anybody think of any reason against generating a bunch of sinuisoids, say 8, with a single DAC and a group of analog mux. What are the problems I might run into?
"Duong Nguyen" <Duong.Ngu...@roads.vic.gov.au> wrote in message
news:1059d530.0109282139.28dc263f@posting.google.com... | Can anybody think of any reason against generating a bunch of | sinuisoids, say 8, with a single DAC and a group of analog mux. What | are the problems I might run into?
It's a common solution if you don't have enough DACs. The only problem I can see is the speed.
I'm not sure I understand the question. Do you mean generating 8 sine waves with different phases or amplitudes? I'm not sure how you would use the mux in that case. Or do you mean sampling 8 sine waves with a single ADC?
>Can anybody think of any reason against generating a bunch of >sinuisoids, say 8, with a single DAC and a group of analog mux. What >are the problems I might run into?
In sci.electronics.design Steve Yeager <n...@spam.org> wrote:
> "Duong Nguyen" <Duong.Ngu...@roads.vic.gov.au> wrote in message > news:1059d530.0109282139.28dc263f@posting.google.com... > | Can anybody think of any reason against generating a bunch of > | sinuisoids, say 8, with a single DAC and a group of analog mux. What > | are the problems I might run into? > It's a common solution if you don't have enough DACs. The only problem I > can see is the speed.
Use a S&H per output, and the mux would be used as a demux. The updates will be at different times, which could be important in some cases. And the speed, as Steve says, is the main issue.
> In sci.electronics.design Steve Yeager <n...@spam.org> wrote: > > "Duong Nguyen" <Duong.Ngu...@roads.vic.gov.au> wrote in message > > news:1059d530.0109282139.28dc263f@posting.google.com... > > | Can anybody think of any reason against generating a bunch of > > | sinuisoids, say 8, with a single DAC and a group of analog mux. What > > | are the problems I might run into?
> > It's a common solution if you don't have enough DACs. The only problem I > > can see is the speed.
> Use a S&H per output, and the mux would be used as a demux. The updates > will be at different times, which could be important in some cases. And > the speed, as Steve says, is the main issue.
Use a cap. at the each mux. output and an error amplifier with the inverting input also switched through an analog mux. to reduce settle time/errors. Place a resistor between the mux. channel output and the cap. to reduce errors due to the settle time of the DAC. Alternatively use a break before make Mux. to let the DAC settle to the desired voltage before switching in the next cap.
The resistor between the output and the cap. may not be nessesary as the typical on resistance of the Mux. channel may be enough depending on the selected Mux. IC.
Regards
Klaus
> Best regards, > -- > Spehro Pefhany --"it's the network..." "The Journey is the reward" > sp...@interlog.com Info for manufacturers:
I use this approach in an application where I require hundreds of outputs to 16 bit resolution updated at 8KHz.
The big problem I am having is noise. The noise spectrum of the DAC gets aliased down to baseband. It is not possible to filter the output of the DAC because of the requirement that it settles within the required sampling time.
For example if you are multiplexing a DAC 16:1 and need an output that is updated at 8KHz with a bandwidth of 4KHz, the DAC needs to create a new sample every 8uS. I currently have allowed for a DAC settling time of 4 us and a sampling time of 4us. To get settling to 16 bits requires about 10 time constants for a first order settling which then implies a bandwidth of 400KHz. The noise in this 400KHz bandwidth gets aliased down to the 4Khz baseband - about 10 times as much as if you had a single DAC with 4KHz output bandwidth.
Am I correct in my understanding of the problem? Any ideas how to solve it?
I am changing to a lower noise DAC (as a side note I found one 14 bit DAC that has noise that is equivalent to 5-6 LSBs) to improve the situation but it is one that I hadnt' anticipated.
You also have to be very careful about power supply noise - many voltage references have zero PSRR above a few hundred Hz and and to a lesser extent the DAC and other circuitry allows high-frequency noise (from switching power supplies) to get into the system and then be aliased down to the region of interest.
Have other people successfully used the DAC multiplexing technique?
> "Spehro Pefhany" <sp...@interlog.com> wrote in message > news:QHot7.113412$sM1.29109733@news3.rdc1.on.home.com... > > In sci.electronics.design Steve Yeager <n...@spam.org> wrote: > > > "Duong Nguyen" <Duong.Ngu...@roads.vic.gov.au> wrote in message > > > news:1059d530.0109282139.28dc263f@posting.google.com... > > > | Can anybody think of any reason against generating a bunch of > > > | sinuisoids, say 8, with a single DAC and a group of analog mux. What > > > | are the problems I might run into?
> > > It's a common solution if you don't have enough DACs. The only problem I > > > can see is the speed.
> > Use a S&H per output, and the mux would be used as a demux. The updates > > will be at different times, which could be important in some cases. And > > the speed, as Steve says, is the main issue.
> Use a cap. at the each mux. output and an error amplifier with the inverting > input also switched through an analog mux. to reduce settle time/errors. > Place a resistor between the mux. channel output and the cap. to reduce > errors due to the settle time of the DAC. Alternatively use a break before > make Mux. to let the DAC settle to the desired voltage before switching in > the next cap.
> The resistor between the output and the cap. may not be nessesary as the > typical on resistance of the Mux. channel may be enough depending on the > selected Mux. IC.
> Regards
> Klaus
> > Best regards, > > -- > > Spehro Pefhany --"it's the network..." "The Journey is the > reward" > > sp...@interlog.com Info for manufacturers: > http://www.trexon.com > > Embedded software/hardware/analog Info for designers: > http://www.speff.com > > /.-.\ > > (( * )) > > \\ // Please help if you can: > > \\\ http://dailynews.yahoo.com/fc/US/Emergency_Information/ > > //\\\ > > /// \\\ > > \/ \/
> Can anybody think of any reason against generating a bunch of > sinuisoids, say 8, with a single DAC and a group of analog mux. What > are the problems I might run into?
This approach does work as long as you're not using a delta-sigma DAC. Delta-sigma DACs contain an internal digital filter which assumes all samples are part of the same data stream.
-- Jim Thomas ** Principal Applications Engineer ** Bittware, Inc 703.779.7770 ** jtho...@bittware.com ** http://www.bittware.com The secret to enjoying your job is to have a hobby that is even worse. - Calvin's dad
Unless of course you can get at or bypass and substitute the filter. If you do it in an FPGA, it is easy to turn the filter into a multichannel filter by adding extra sample delays between each tap to match the number of multiplexed samples.
> > Can anybody think of any reason against generating a bunch of > > sinuisoids, say 8, with a single DAC and a group of analog mux. What > > are the problems I might run into?
> This approach does work as long as you're not using a delta-sigma DAC. > Delta-sigma DACs contain an internal digital filter which assumes all > samples are part of the same data stream.
> -- > Jim Thomas ** Principal Applications Engineer ** Bittware, Inc > 703.779.7770 ** jtho...@bittware.com ** http://www.bittware.com > The secret to enjoying your job is to have a hobby that is even worse. > - Calvin's dad
-- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email r...@andraka.com http://www.andraka.com
"They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759
In article <1059d530.0109282139.28dc2...@posting.google.com>,
Duong Nguyen <Duong.Ngu...@roads.vic.gov.au> wrote: >Can anybody think of any reason against generating a bunch of >sinuisoids, say 8, with a single DAC and a group of analog mux. What >are the problems I might run into?
One problem could be charge injection, where the switching signal of the (de)mux couples into the signal channel and adds some glitches and offsets. Some mux are designed to avoid this.
Mark Zenier mzen...@eskimo.com Washington State resident
I'm still not sure I understand the point of this circuit unless it is for high bit resolution. You can buy octal 8 bit DACs fairly cheaply and avoid the need for the mux or any sample/hold circuits etc. I agree with Mark that charge injection is a major concern that needs to be looked at too.
What is the end application of all this? Is it for audio and the signals will be recombined (sine waves representing keys on a keyboard say) Or some other purpose? If the signals are to be combined you could add all of the sine waves in the digital domain? Simply plug your multi-sine wave requirements into an IFFT and feed the digital output DAC.
Ray Andraka wrote in message <3BB8A01D.3EC39...@andraka.com>... >Unless of course you can get at or bypass and substitute the filter. If >you do it in an FPGA, it is easy to turn the filter into a multichannel >filter by adding extra sample delays between each tap to match the number >of multiplexed samples.
>Jim Thomas wrote:
>> Duong Nguyen wrote:
>> > Can anybody think of any reason against generating a bunch of >> > sinuisoids, say 8, with a single DAC and a group of analog mux. What >> > are the problems I might run into?
>> This approach does work as long as you're not using a delta-sigma DAC. >> Delta-sigma DACs contain an internal digital filter which assumes all >> samples are part of the same data stream.
>> -- >> Jim Thomas ** Principal Applications Engineer ** Bittware, Inc >> 703.779.7770 ** jtho...@bittware.com ** http://www.bittware.com >> The secret to enjoying your job is to have a hobby that is even worse. >> - Calvin's dad
>-- >--Ray Andraka, P.E. >President, the Andraka Consulting Group, Inc. >401/884-7930 Fax 401/884-7950 >email r...@andraka.com >http://www.andraka.com
> "They that give up essential liberty to obtain a little > temporary safety deserve neither liberty nor safety." > -Benjamin Franklin, 1759
In sci.electronics.design red rover <natpr...@sympatico.ca> wrote:
> I'm still not sure I understand the point of this circuit unless it > is for high bit resolution. You can buy octal 8 bit DACs fairly > cheaply and avoid the need for the mux or any sample/hold > circuits etc. I agree with Mark that charge injection is a major > concern that needs to be looked at too.
A 4051, 8 capacitors and 8 buffer amplifiers cost maybe 60 cents total, this could be a powerful motivation if there were quantities involved.
"red rover" <natpr...@sympatico.ca> wrote in message <news:1uot7.46181$GQ2.4850664@news20.bellglobal.com>... > I'm not sure I understand the question. Do you mean generating > 8 sine waves with different phases or amplitudes? I'm not sure > how you would use the mux in that case. Or do you mean > sampling 8 sine waves with a single ADC?
> Steve
perhaps I should have used the term S&H to make it clearer. The circuit is similar to the one you mention except that it used in reverse, i.e. the DAC output feeds the S&H.
> I use this approach in an application where I require hundreds of outputs to > 16 bit resolution updated at 8KHz.
> The big problem I am having is noise. The noise spectrum of the DAC gets > aliased down to baseband. It is not possible to filter the output of the > DAC because of the requirement that it settles within the required sampling > time.
> For example if you are multiplexing a DAC 16:1 and need an output that is > updated at 8KHz with a bandwidth of 4KHz, the DAC needs to create a new > sample every 8uS. I currently have allowed for a DAC settling time of 4 us > and a sampling time of 4us.
Is it possible that this is the main noise source, the noise being the difference between the ideal DAC output and the level it gets to when the output is hold? When all the successive DAC samples are from the same signal then the error, which is a percentage of the sample to sample difference, is proportional to the required signal and the effect is probably just a simple gain. In the case where successsive samples are totally uncorrelated (and this is the situation being discussed here) then it is uniform noise. If this reasoning is correct then perhaps you need better sample and hold circuit and alter the timing to hold the signal at the last possible moment, or a DAC with a better output slew rate.
> To get settling to 16 bits requires about 10 > time constants for a first order settling which then implies a bandwidth of > 400KHz. The noise in this 400KHz bandwidth gets aliased down to the 4Khz > baseband - about 10 times as much as if you had a single DAC with 4KHz > output bandwidth.
I'm not sure I understand what you are saying. What is "first order settling"? Where does the 400 kHz noise band come from?
> Am I correct in my understanding of the problem? Any ideas how to solve it?
> I am changing to a lower noise DAC (as a side note I found one 14 bit DAC > that has noise that is equivalent to 5-6 LSBs) to improve the situation but > it is one that I hadnt' anticipated.
Could you let us know about this 14-bit DAC with a noise floor of 5-6 LSBs?
> You also have to be very careful about power supply noise - many voltage > references have zero PSRR above a few hundred Hz and and to a lesser extent > the DAC and other circuitry allows high-frequency noise (from switching > power supplies) to get into the system and then be aliased down to the > region of interest.
> Have other people successfully used the DAC multiplexing technique?
> > > > It's a common solution if you don't have enough DACs. The only problem > I > > > > can see is the speed.
> > > Use a S&H per output, and the mux would be used as a demux. The updates > > > will be at different times, which could be important in some cases. And > > > the speed, as Steve says, is the main issue.
> > Use a cap. at the each mux. output and an error amplifier with the > inverting > > input also switched through an analog mux. to reduce settle time/errors. > > Place a resistor between the mux. channel output and the cap. to reduce > > errors due to the settle time of the DAC. Alternatively use a break before > > make Mux. to let the DAC settle to the desired voltage before switching in > > the next cap.
> > The resistor between the output and the cap. may not be nessesary as the > > typical on resistance of the Mux. channel may be enough depending on the > > selected Mux. IC.
> > Regards
> > Klaus
> > > Best regards, > > > -- > > > Spehro Pefhany --"it's the network..." "The Journey is the > reward" > > > sp...@interlog.com Info for manufacturers: > http://www.trexon.com > > > Embedded software/hardware/analog Info for designers: > http://www.speff.com > > > /.-.\ > > > (( * )) > > > \\ // Please help if you can: > > > \\\ http://dailynews.yahoo.com/fc/US/Emergency_Information/ > > > //\\\ > > > /// \\\ > > > \/ \/
> I use this approach in an application where I require hundreds of outputs to > 16 bit resolution updated at 8KHz.
> The big problem I am having is noise. The noise spectrum of the DAC gets > aliased down to baseband. It is not possible to filter the output of the > DAC because of the requirement that it settles within the required sampling > time.
> For example if you are multiplexing a DAC 16:1 and need an output that is > updated at 8KHz with a bandwidth of 4KHz, the DAC needs to create a new > sample every 8uS. I currently have allowed for a DAC settling time of 4 us > and a sampling time of 4us. To get settling to 16 bits requires about 10 > time constants for a first order settling which then implies a bandwidth of > 400KHz. The noise in this 400KHz bandwidth gets aliased down to the 4Khz > baseband - about 10 times as much as if you had a single DAC with 4KHz > output bandwidth.
What do you mean by "To get settling to 16 bits requires about 10 time constants for a first order settling which then implies a bandwidth of 400KHz" Is this the S/H bandwidth ?
I would expect you to do in order:
1 Provide a sample from the DAC 2 Wait for the DAC to settle to 1 LSB 3 Sample voltage with S/H circuit (use high current error amp. to minimize sample time) 4 Move on to the next multiplexer input
I don't see (perhaps someone else do) how you get more noise with this system. In effect the sample method corresponds to a single DAC output - the time for the DAC voltage to be sampled by the S/H is just shorter.
What are your system components partnumbers: DAC, Mux., S/H, Amp ?
> Am I correct in my understanding of the problem? Any ideas how to solve it?
> I am changing to a lower noise DAC (as a side note I found one 14 bit DAC > that has noise that is equivalent to 5-6 LSBs) to improve the situation but > it is one that I hadnt' anticipated.
> You also have to be very careful about power supply noise - many voltage > references have zero PSRR above a few hundred Hz and and to a lesser extent > the DAC and other circuitry allows high-frequency noise (from switching > power supplies) to get into the system and then be aliased down to the > region of interest.
> Have other people successfully used the DAC multiplexing technique?
> > > > It's a common solution if you don't have enough DACs. The only problem > I > > > > can see is the speed.
> > > Use a S&H per output, and the mux would be used as a demux. The updates > > > will be at different times, which could be important in some cases. And > > > the speed, as Steve says, is the main issue.
> > Use a cap. at the each mux. output and an error amplifier with the > inverting > > input also switched through an analog mux. to reduce settle time/errors. > > Place a resistor between the mux. channel output and the cap. to reduce > > errors due to the settle time of the DAC. Alternatively use a break before > > make Mux. to let the DAC settle to the desired voltage before switching in > > the next cap.
> > The resistor between the output and the cap. may not be nessesary as the > > typical on resistance of the Mux. channel may be enough depending on the > > selected Mux. IC.
> > Regards
> > Klaus
> > > Best regards, > > > -- > > > Spehro Pefhany --"it's the network..." "The Journey is the > > reward" > > > sp...@interlog.com Info for manufacturers: > > http://www.trexon.com > > > Embedded software/hardware/analog Info for designers: > > http://www.speff.com > > > /.-.\ > > > (( * )) > > > \\ // Please help if you can: > > > \\\
> What do you mean by "To get settling to 16 bits requires about 10 time > constants > for a first order settling which then implies a bandwidth of 400KHz" > Is this the S/H bandwidth ?
First-order settling is a simple exponential decay; one time constant. The assumption that the time constant, T, is about 1/(radian-frequency bandwidth). The worst case is a full-scale swing.
> I would expect you to do in order:
> 1 Provide a sample from the DAC
This is quick.
> 2 Wait for the DAC to settle to 1 LSB
We need to satisfy exp(t/T) = 1/2^16. Settling to one part in 65536 requires 11 time constants. A reasonable audio bandwidth of 20 KHz has a time constant (1/2*pi*f) of about 8 microseconds, so the DAC would need 88 microseconds to settle for each multiplexed channel.
> 3 Sample voltage with S/H circuit (use high current error amp. to > minimize sample time)
The S/H can be open while the DAC is settling if you use a a cascaded pair in bucket-brigade fashion. Otherwise, you will need another 3 time constants or so.
> 4 Move on to the next multiplexer input
1. and 4. are the easy parts.
The bandwidth of the DAC needs to be 11 * #-of-channels * bandwidth-of- one-channel. A DAC used for a single channel doesn't need to make full-scale jumps, but multiplexing even two channels imposes that unfavorable condition.
> I don't see (perhaps someone else do) how you get more noise with this > system. In effect the sample method corresponds to a single DAC output - the > time for the DAC voltage to be sampled by the S/H is just shorter.
Noise is proportional to bandwidth. A good DAC may nevertheless be dominated by quantization noise in your application.
...
Jerry
P.S. Most devices settle with at least two time constants, one of them much longer than the obvious one. This often comes about when a pole and zero almost cancel but not quite. The closer they are, the smaller the magnitude and lower the time constant. An op amp in the DAC's output will likely display this characteristic because of its loop compensation. Trying to settle to 15 ppm is enough to make such a tail quite noticeable, so it would not be very surprising to see as many as 20 time constants needed in practice. Of course, if you settle to three counts instead of one, few could tell and fewer would care. -- Engineering is the art of making what you want from things you can get. -----------------------------------------------------------------------
Thanks for some useful info - yes I was surprised that a 14 bit DAC would have such bad noise. This voltage output DAC has a buffer amplifier on its output with 320nV/rootHz noise with 3.5 us settling and 0-4.096V output. I am guessing that its bandwidth is in the 500KHz to 1MHz region. If it is 1MHz it implies the noise will be about 320uV RMS (320nV * sqrt(10^6)) or about 2mV p-p. The LSB of course is only 250uV.
> > What do you mean by "To get settling to 16 bits requires about 10 time > > constants > > for a first order settling which then implies a bandwidth of 400KHz" > > Is this the S/H bandwidth ?
> First-order settling is a simple exponential decay; one time constant. > The assumption that the time constant, T, is about 1/(radian-frequency > bandwidth). The worst case is a full-scale swing.
> > I would expect you to do in order:
> > 1 Provide a sample from the DAC > This is quick.
> > 2 Wait for the DAC to settle to 1 LSB > We need to satisfy exp(t/T) = 1/2^16. Settling to one part in 65536 > requires 11 time constants. A reasonable audio bandwidth of 20 KHz has a > time constant (1/2*pi*f) of about 8 microseconds, so the DAC would need > 88 microseconds to settle for each multiplexed channel.
> > 3 Sample voltage with S/H circuit (use high current error amp. to > > minimize sample time)
> The S/H can be open while the DAC is settling if you use a a cascaded > pair in bucket-brigade fashion. Otherwise, you will need another 3 time > constants or so.
> > 4 Move on to the next multiplexer input > 1. and 4. are the easy parts.
> The bandwidth of the DAC needs to be 11 * #-of-channels * bandwidth-of- > one-channel. A DAC used for a single channel doesn't need to make > full-scale jumps, but multiplexing even two channels imposes that > unfavorable condition.
> > I don't see (perhaps someone else do) how you get more noise with this > > system. In effect the sample method corresponds to a single DAC output - the > > time for the DAC voltage to be sampled by the S/H is just shorter.
> Noise is proportional to bandwidth. A good DAC may nevertheless be > dominated by quantization noise in your application.
> ...
> Jerry
> P.S. Most devices settle with at least two time constants, one of them > much longer than the obvious one. This often comes about when a pole and > zero almost cancel but not quite. The closer they are, the smaller the > magnitude and lower the time constant. An op amp in the DAC's output > will likely display this characteristic because of its loop > compensation. Trying to settle to 15 ppm is enough to make such a tail > quite noticeable, so it would not be very surprising to see as many as > 20 time constants needed in practice. Of course, if you settle to three > counts instead of one, few could tell and fewer would care. > -- > Engineering is the art of making what you want from things you can get. > -----------------------------------------------------------------------
> Thanks for some useful info - yes I was surprised that a 14 bit DAC would > have such bad noise. This voltage output DAC has a buffer amplifier on its > output with 320nV/rootHz noise with 3.5 us settling and 0-4.096V output. I > am guessing that its bandwidth is in the 500KHz to 1MHz region. If it is > 1MHz it implies the noise will be about 320uV RMS (320nV * sqrt(10^6)) or > about 2mV p-p. The LSB of course is only 250uV.
> > > What do you mean by "To get settling to 16 bits requires about 10 time > > > constants > > > for a first order settling which then implies a bandwidth of 400KHz" > > > Is this the S/H bandwidth ?
> > First-order settling is a simple exponential decay; one time constant. > > The assumption that the time constant, T, is about 1/(radian-frequency > > bandwidth). The worst case is a full-scale swing.
> > > I would expect you to do in order:
> > > 1 Provide a sample from the DAC > > This is quick.
> > > 2 Wait for the DAC to settle to 1 LSB > > We need to satisfy exp(t/T) = 1/2^16. Settling to one part in 65536 > > requires 11 time constants. A reasonable audio bandwidth of 20 KHz has a > > time constant (1/2*pi*f) of about 8 microseconds, so the DAC would need > > 88 microseconds to settle for each multiplexed channel.
> > > 3 Sample voltage with S/H circuit (use high current error amp. to > > > minimize sample time)
> > The S/H can be open while the DAC is settling if you use a a cascaded > > pair in bucket-brigade fashion. Otherwise, you will need another 3 time > > constants or so.
> > > 4 Move on to the next multiplexer input > > 1. and 4. are the easy parts.
> > The bandwidth of the DAC needs to be 11 * #-of-channels * bandwidth-of- > > one-channel. A DAC used for a single channel doesn't need to make > > full-scale jumps, but multiplexing even two channels imposes that > > unfavorable condition.
> > > I don't see (perhaps someone else do) how you get more noise with this > > > system. In effect the sample method corresponds to a single DAC output - > the > > > time for the DAC voltage to be sampled by the S/H is just shorter.
> > Noise is proportional to bandwidth. A good DAC may nevertheless be > > dominated by quantization noise in your application.
> > ...
> > Jerry
> > P.S. Most devices settle with at least two time constants, one of them > > much longer than the obvious one. This often comes about when a pole and > > zero almost cancel but not quite. The closer they are, the smaller the > > magnitude and lower the time constant. An op amp in the DAC's output
^^^^^ <-- longer
> > will likely display this characteristic because of its loop > > compensation. Trying to settle to 15 ppm is enough to make such a tail > > quite noticeable, so it would not be very surprising to see as many as > > 20 time constants needed in practice. Of course, if you settle to three > > counts instead of one, few could tell and fewer would care. > > -- > > Engineering is the art of making what you want from things you can get. > > -----------------------------------------------------------------------
You're welcome!
Jerry -- Engineering is the art of making what you want from things you can get. -----------------------------------------------------------------------
> > What do you mean by "To get settling to 16 bits requires about 10 time > > constants > > for a first order settling which then implies a bandwidth of 400KHz" > > Is this the S/H bandwidth ?
> First-order settling is a simple exponential decay; one time constant. > The assumption that the time constant, T, is about 1/(radian-frequency > bandwidth). The worst case is a full-scale swing.
> > I would expect you to do in order:
> > 1 Provide a sample from the DAC > This is quick.
> > 2 Wait for the DAC to settle to 1 LSB > We need to satisfy exp(t/T) = 1/2^16. Settling to one part in 65536 > requires 11 time constants. A reasonable audio bandwidth of 20 KHz has a > time constant (1/2*pi*f) of about 8 microseconds, so the DAC would need > 88 microseconds to settle for each multiplexed channel.
I think one of us is missing something (hope it is not me :-)) or we are not talking about the same thing.
Take this example - a 16bit DAC has a specified settletime of 1us. That means the output will settle within 1LSB in 1us. Is it a special DAC you are taling about needing 10 time constants to settle to 1 LSB ? Or do you have a first order filter later in the chain and if so - why ?
> > 3 Sample voltage with S/H circuit (use high current error amp. to > > minimize sample time)
> The S/H can be open while the DAC is settling if you use a a cascaded > pair in bucket-brigade fashion. Otherwise, you will need another 3 time > constants or so.
> > 4 Move on to the next multiplexer input > 1. and 4. are the easy parts.
> The bandwidth of the DAC needs to be 11 * #-of-channels * bandwidth-of- > one-channel. A DAC used for a single channel doesn't need to make > full-scale jumps, but multiplexing even two channels imposes that > unfavorable condition.
> > I don't see (perhaps someone else do) how you get more noise with this > > system. In effect the sample method corresponds to a single DAC output - the > > time for the DAC voltage to be sampled by the S/H is just shorter.
> Noise is proportional to bandwidth. A good DAC may nevertheless be > dominated by quantization noise in your application.
> ...
> Jerry
> P.S. Most devices settle with at least two time constants, one of them > much longer than the obvious one. This often comes about when a pole and > zero almost cancel but not quite. The closer they are, the smaller the > magnitude and lower the time constant. An op amp in the DAC's output > will likely display this characteristic because of its loop > compensation. Trying to settle to 15 ppm is enough to make such a tail > quite noticeable, so it would not be very surprising to see as many as > 20 time constants needed in practice. Of course, if you settle to three > counts instead of one, few could tell and fewer would care. > -- > Engineering is the art of making what you want from things you can get. > -----------------------------------------------------------------------
> > > What do you mean by "To get settling to 16 bits requires about 10 time > > > constants > > > for a first order settling which then implies a bandwidth of 400KHz" > > > Is this the S/H bandwidth ?
> > First-order settling is a simple exponential decay; one time constant. > > The assumption that the time constant, T, is about 1/(radian-frequency > > bandwidth). The worst case is a full-scale swing.
> > > I would expect you to do in order:
> > > 1 Provide a sample from the DAC > > This is quick.
> > > 2 Wait for the DAC to settle to 1 LSB > > We need to satisfy exp(t/T) = 1/2^16. Settling to one part in 65536 > > requires 11 time constants. A reasonable audio bandwidth of 20 KHz has a > > time constant (1/2*pi*f) of about 8 microseconds, so the DAC would need > > 88 microseconds to settle for each multiplexed channel.
> I think one of us is missing something (hope it is not me :-)) or we are not > talking about the same thing.
> Take this example - a 16bit DAC has a specified settletime of 1us. That > means the output will settle within 1LSB in 1us. Is it a special DAC you are > taling about needing 10 time constants to settle to 1 LSB ? Or do you have a > first order filter later in the chain and if so - why ?
> Regards
> Klaus
For a more detailed explanation - see the datasheet for the 1us MAX5541 16Bit DAC. The settle time is determined by the output resistance of the DAC and the output capacitance. In this example this is 6.25kOhms and 10pF respectively. This yields a time-constant of 62.5ns and the needed timeconstants is 12 for a 16bit DAC to settle within 1 LSB.
This gives your DAC settle to 1LSB: 62.5ns * 12 = 0.75us. Ofcourse any buffer amplifier needs a high bandwidth as the timeconstants are added in a root square manor.
> > > 3 Sample voltage with S/H circuit (use high current error amp. to > > > minimize sample time)
> > The S/H can be open while the DAC is settling if you use a a cascaded > > pair in bucket-brigade fashion. Otherwise, you will need another 3 time > > constants or so.
> > > 4 Move on to the next multiplexer input > > 1. and 4. are the easy parts.
> > The bandwidth of the DAC needs to be 11 * #-of-channels * bandwidth-of- > > one-channel. A DAC used for a single channel doesn't need to make > > full-scale jumps, but multiplexing even two channels imposes that > > unfavorable condition.
> > > I don't see (perhaps someone else do) how you get more noise with this > > > system. In effect the sample method corresponds to a single DAC output - > the > > > time for the DAC voltage to be sampled by the S/H is just shorter.
> > Noise is proportional to bandwidth. A good DAC may nevertheless be > > dominated by quantization noise in your application.
> > ...
> > Jerry
> > P.S. Most devices settle with at least two time constants, one of them > > much longer than the obvious one. This often comes about when a pole and > > zero almost cancel but not quite. The closer they are, the smaller the > > magnitude and lower the time constant. An op amp in the DAC's output > > will likely display this characteristic because of its loop > > compensation. Trying to settle to 15 ppm is enough to make such a tail > > quite noticeable, so it would not be very surprising to see as many as > > 20 time constants needed in practice. Of course, if you settle to three > > counts instead of one, few could tell and fewer would care. > > -- > > Engineering is the art of making what you want from things you can get. > > -----------------------------------------------------------------------
> I think one of us is missing something (hope it is not me :-)) or we are not > talking about the same thing.
> Take this example - a 16bit DAC has a specified settletime of 1us. That > means the output will settle within 1LSB in 1us. Is it a special DAC you are > taling about needing 10 time constants to settle to 1 LSB ? Or do you have a > first order filter later in the chain and if so - why ?
> Regards
> Klaus
It takes 11 time constants for a 16-bit DAC to settle to 1 LSB if it's settling curve is that of a single R-C. To do that in 1 microsecond implies that the bandwidth is 1.75 MHz. All the noise in that band needs to be allowed through. If the DAC is not multiplexed, it's out can be filtered to allow through a much narrower band, eliminating much of the noise. If the DAC has very low noise to start with, this might not matter. The ratio of the necessary multiplexed bandwidth to 20 KHz is nearly 90:1.
Does that clarify what I was driving at?
Jerry -- Engineering is the art of making what you want from things you can get. -----------------------------------------------------------------------
> > I think one of us is missing something (hope it is not me :-)) or we are not > > talking about the same thing.
> > Take this example - a 16bit DAC has a specified settletime of 1us. That > > means the output will settle within 1LSB in 1us. Is it a special DAC you are > > taling about needing 10 time constants to settle to 1 LSB ? Or do you have a > > first order filter later in the chain and if so - why ?
> > Regards
> > Klaus
> It takes 11 time constants for a 16-bit DAC to settle to 1 LSB if it's > settling curve is that of a single R-C. To do that in 1 microsecond > implies that the bandwidth is 1.75 MHz. All the noise in that band needs > to be allowed through. If the DAC is not multiplexed, it's out can be > filtered to allow through a much narrower band, eliminating much of the > noise. If the DAC has very low noise to start with, this might not > matter. The ratio of the necessary multiplexed bandwidth to 20 KHz is > nearly 90:1.
> Jerry > -- > Engineering is the art of making what you want from things you can get. > -----------------------------------------------------------------------
