DAC Essentials: How accurate is your DAC?

We’ve covered a lot of material in the DAC Essentials series, starting with a simple ideal digital-to-analog converter (DAC) all the way to complex problems, like reducing glitch. In this final post in the series, we’ll talk about total unadjusted error (TUE).

Precision DACs deliver excellent DC, or very low frequency, performance. In many precision DAC applications, the AC error specifications related to code transitions, glitch and slew rate, are negligible when defining the accuracy of the DAC. This is because the output will spend a majority of its time settled and unchanging.

In my “DAC Essentials: Static specifications & linearity” post, I explained all of the DAC DC error parameters: offset error, zero code error, gain error, differential non-linearity (DNL) and integral non-linearity (INL). When trying to express how accurate a DAC is at DC, it’s challenging to keep all of those error sources in mind. That’s the beauty of TUE. It gives you a single number that succinctly explains how accurate the DC DAC output is as a result of the sum of all of these error sources. The only catch is you have to do a little statistics.

In statistics, a technique called RSS, or root sum squared, is used to sum uncorrelated error sources for error analysis. With string and ladder DAC architectures, offset, gain and INL error come from different components of the DAC architecture. This means they’re uncorrelated, and the RSS technique is safe to apply. Here’s the equation:

You may have noticed that I didn’t include zero code error and DNL. That’s because zero code error only applies to a very small portion of the DAC output. For a 16-bit DAC, this might be a few hundred codes out of 65,536 total codes. DNL, meanwhile, is actually included in the error calculation via INL.

Now let’s go through a short example that shows how to calculate TUE. Below are the datasheet maximum and typical specifications for the 16-bit, two-channel DAC8562.


Each of the specifications for the DAC8562 are provided in different units, which is typical across the industry. To calculate TUE, everything needs to be in the same unit, so we’ll use the table below to convert the values.

Once we’ve converted units, we can plug the values back into the TUE equation and calculate the total unadjusted error for the DAC8562.

Using the maximum values for all of the specifications provides what I refer to as the “probable maximum TUE” of +/-111 LSBs, +/-8.5mV, or 0.17% FSR. I say this because the max values in the datasheet are three-sigma figures that should encompass 99.7% of all parts ever produced. On a typical Gaussian distribution, these edge cases are not likely to happen. You’re even less likely to find a part that actually displays the maximum errors for all parameters (an “absolute maximum error” so to speak - the figure you would see from simply summing all of the errors together). Even this probable maximum TUE is a somewhat unlikely unit to observe.

Using the typical figures provides the most realistic estimation of what you’ll see from most systems. The typical TUE for the DAC8562 is +/- 23 LSBs, 1.78mV, or 0.0356% FSR. Check out this TI Precision Design to see this method in practice, and proven reliable, with real data on a real system.

Remember that these parameters also have direction associated with them. For a DAC with positive offset error, negative gain error would actually help make the system more accurate. This isn’t taken into account when you use RSS to sum the maximum errors. So in many cases, RSS on typical error figures still provides a pretty modest estimate of TUE.

While this post marks the end of the DAC Essentials series, you’ll find me blogging on other topics on The Hub, our blog focused exclusively on precision analog tips, tricks and design techniques.

And be sure to check out my new Engineer It video if you want to get some advice on how to select the perfect DAC for your system.

As always, leave your comments below if you’d like to hear more about anything mentioned in this post, or if there is something you would like to see included in a future post here or on The Hub.


  • I am always happy to see another reminder of the useful RSS technique for determining system error.  It is seldom taught except by manufactures of precision analog parts.  I have used it for 30+ years and determined if your measured results do not agree with this prediction, it is time to find out what is wrong with your system.  

    A few comments.

    - Use it for complete systems not just parts (probably obvious).

    - Beware of two things - correlated errors (which you mention) and errors with non-normal distributions.  The traditional non-normal distribution was a part that was selected from a general population for better specifications.  These parts do not have a normal distribution of errors (the distribution "tails" have been truncated) and must be added as worst case, not RSS.

    - I have found that system errors will usually be higher than given by the typical values by enough that I have stopped using typical values.  Perhaps its just that I design measurement systems and mostly care about what limits I can depend on rather than what might be considered "normal".

    Thanks for all the useful articles.

    Jim McGrew

  • Jim,

    I completely agree with your comments.

    When I started writing this post I was a little apprehensive about the reception that it might receive - to some extent I think the RSS could be considered "controversial" given the qualifications that are required for it's use (normal distributions and uncorrelated sources, as you mentioned). I've seen a few arguments come up around the topic of exactly what error sources are correlated and uncorrelated, especially within the discussion of integrated circuits and other discrete components, but I've found that the RSS technique is still pretty accurate even if you have to "fudge" a few sources into the uncorrelated bucket.

    I was also a little worried about the use of typical figures in my calculations. You're certainly correct that, in your case, using a min/max spec is probably for the best so that you can guarantee performance boundaries. It is tricky to manage the balance between absolute performance boundaries, probable performance boundaries, and selling your products short (since some of those absolute min/max bounds are not very likely to happen).

    The TI Designs I linked to also apply the RSS technique to an entire system. When I started writing these reference designs I needed some way to overcome not having a DAC model and I bumped into RSS. I use a combination of RSS, SPICE models, and Monte-Carlo analysis to come up with the bounds for performance in the reference designs and it's worked out pretty well (although my sample size is usually limited to 10-20 designs, not a very large population).

    Thanks for reading, and for your excellent comments!

  • Hello, I have a question to the equation of TUE. I have an "Analog Monitoring and Control Circuit - AMC7823" with an eight channel 12 Bit DAC. My result for TUE is +/-7,66 mV, because the gain error is very high (typical 0,3 %FS).

    Now my question. Isn't the calculated value relative to the output voltage of the DAC?

    An Example:

    Output DAC: 2 V

    TUE: 7,6 mV

    The  Deviation is 0,38%.

    Output DAC: 10 mV

    TUE: 7,6 mV

    The  Deviation is 76%?????

    I hope you understand my Problem. With your equation of TUE the error is more critical for the System with a lower output voltage of the DAC.


    Stefan Kavelmann  

  • Stefan,

    I was travelling abroad for the last week and was not able to deliver a more prompt response to your post.

    Several error parameters are specified in terms that are relative to the full-scale output span; gain error is usually specified in % full-scale range and INL error is usually specified in LSBs which are also relative the full-scale output span. Offset error, on the other hand, is usually specified in absolute terms of voltage - so the larger the output span the less and less significant the offset error is.

    When calculating TUE we're really calculating a statistical value for the entire transfer function rather than the error at any given point. So in the example in this post with the DAC8562 the error analysis is stating that, at any point in the transfer function, our worst case expected error should be within 0.17%.

    I hope this answers your question. If not, please clarify a little more and I'll be happy to explain.

  • Kevin,

    Thanks for this interesting article. I am calculating a total error of a design with the ADS1247 and I want to use your method there. I am wondering if the errors in delta-sigma ADC are also uncorrelated, so I can calculate a typical error using RSS technique.

    It looks that you made your example with Vref=5V. From what I see your TUE calculation for the maximum errors is done using RSS, while the TUE for typical errors is  calculated as a normal sum of errors. Is there any reason for it?

    Thanks in advance,

    Mariusz Krzyzanski

  • Mariusz ,

    You're correct that I made a mistake in the typical TUE calculation - after messing with the math for a little bit it turns out I took the typical "full-scale" error figure instead of the typical "gain error" figure in that calculation. It should be 0.023% FSR error typical.

    Regarding the delta-sigma I would say that the error sources are uncorrelated. I'm not an expert on delta-sigma ADCs but often these parts include on-chip buffers which would contribute the offset error while the actual conversion process would contribute the INL/DNL and gain errors. I'm not sure exactly how the source of INL/DNL and gain error would differ but for most of these converters the INL/DNL errors are so small that they're insignificant in the RSS calculation anyhow, so I think you're safe to apply the same technique.