How to Effectively Interpret Data Sheets to Recognize Misleading Information

By Max Maxfield |
Datasheets.com to access the latest data on electronic components, including environmental, packaging, manufacturing, and reference designs). 

To some extent, how you read data sheets and what aspects of them interest you the most depends on what you are doing. Three usage scenarios that immediately spring to mind are as follows:

  • Design: In this case, you may start by sifting through a mound of data sheets looking for parameters and operating modes that satisfy a specific set of design constraints (does the component do what you want it to do?)
  • Verification: Did whoever created this portion of the design read the data sheet correctly and make appropriate assumptions as to its content (does the component really do what the designer thought/assumed it did?)
  • Debug: Does this component do anything that violates the original design specification? Is there anything about this component that could cause the system failure you are currently experiencing? 

Two more potential usage scenarios are as follows (can you think of more?):

  • Research: In the case of a new technology or new device, you may use the data sheet as one resource to learn more: What does this component do? How does it work? Will it be of interest for current and/or future designs?
  • Reverse Engineering: Component datasheets provide an invaluable resource if you are trying to reverse engineer a product or understand how one works.

 One common pitfall with data sheets is when the user fails to read the small print. It's easy to glance at a parameter and say something like: "Great, a maximum value of 100mA; that will do the job," without noticing the qualifying '*' and the associated note at the bottom of the page that says something like: "You will only achieve this value if you have an imaginary load with negative resistance and the arrow of time is pointing backwards" (or words to that effect).

 Other problems include the following:

  • Missing/omitted information
  • Incorrect/sub-standard information
  • Misinterpretation of measured data
  • Flat-out misprints (someone typed it in wrong)
  • Babel fish issues 

Babel Fish Issues

It's not uncommon for the original version of a data sheet to be written in a language like Chinese, Japanese, or Korean before being translated into another language like English (or American). Just to increase the fun and frivolity, some datasheets undergo an intermediate step, first being translated from Chinese etc. into German or Hebrew, and later being translated from German etc. into English. 

As an aside, I particularly enjoy translations from Hebrew to English. These oftentimes end up with a very Shakespearian quality, along the lines of: "But where are the variables, you ask? Ha! The variables are over here!" You can almost imagine this being presented as a play in the stage: 

Character 1: "But where are the variables, you ask?" 

Character 2: "Ha! The variables are over here!" {Actor throws curtains apart to reveal the elusive variables} 

In fact, this just reminded me of three related columns -- Error Messages We Can All Understand and The Worst Oscilloscope User Manual of All Time and Different Countries = Different Writing Styles in User Manuals -- but I fear we are in danger of wandering off into the weeds. 

Missing/Omitted Information

As one example of missing information, consider the NeoPixel RGB LED Strips from Adafruit. I love NeoPixels and I've used them in all sorts of projects, like my Cunning Chronograph and my BADASS Display

I have to say that I've always been impressed with the Adafruit website. I particularly appreciate all of the technical information they provide, including example Arduino sketches (programs) that will quickly get you up and running. In the case of NeoPixels, one of the documents Adafruit provides is their NeoPixel Uberguide

Unfortunately, even the folks at Adafruit can drop the ball on occasion. When I first started using their NeoPixel Strips, I was under the impression that I could simply drive the first pixel in the chain directly from the output pin on my Arduino.

(Source: Max Maxfield)

Sad to relate, things tended to work for a while, but then the first pixel in the chain would "bite the dust." After a few pixels had shrugged off this mortal coil, I carried my setup into the next bay and we used an oscilloscope to see what was going on. When we probed the first pixel's Data-In pin, we observed an eye-watering amount of overshoot and undershoot. Adding a 390-ohm serial resistor just before the input solved the problem. I communicated this information to the folks at Adafruit. I don’t know if my email prompted the change, but the next time I looked at their Uberguide, I saw that the "Connections" page now included a note about adding such a resistor (they recommend adding a ~470-ohm device). 

Incorrect/Sub-Standard Information

By some strange quirk of fate, I have a corker of an example of sub-standard data sheet information. As part of my BADASS Display project, I decided to use one of the MSGEQ7 7-band graphic equalizer chips you can pick up from SparkFun Electronics for only $4.95. 

The MSGEQ7 is a clever little 8-pin device. Inside there are seven band-pass filters tuned to 63Hz, 160Hz, 400Hz, 1,000Hz, 2,500Hz, 6,250Hz, and 16,000Hz. Each of these filters has an associated peak detector. The clever thing is that the outputs from the seven peak detectors are multiplexed together, which explains how everything fits into an 8-pin package. 

(Source: Max Maxfield)

If you are interested in using one of these little rascals in your own project, you might want to peruse some of my MSGEQ7-based audio spectrum analyzer articles, including Introduction, Construction, Testing, and Software & Timing

So, where does the problem appear? I'm afraid it's in the data sheet. Sometimes the values presented in a data sheet are difficult to interpret and understand without an associated timing diagram. The following is my original interpretation of the timing diagram presented in the component manufacturer's data sheet (I added color and made it prettier).

(Source: Max Maxfield)

Do you see any problems with the above timing diagram? Neither did I. In fact, it was my chum, David Ashton, who pointed out that the minimum strobe pulse width (ts) of 18us is specified as being less than the minimum output settling time (to) of 36us. 

If this were to prove to be correct, then one interpretation would be that we could continue to read data on the DATA_OUT pin even after STROBE signal has returned to its logic 1 (inactive) state. In this case, a better representation of the timing relationships and waveforms would be as illustrated below. 

(Source: Max Maxfield)

However, this really doesn't make much sense. Since it wasn't possible to make a definitive decision based on the official data sheet, I talked to John Ambrose at Mixed Signal Integration -- the company that makes the MSGEQ7 (along with many other interesting products). 

John explained that the DATA_OUT signal is clamped to 0V when the STROBE signal is HIGH, which -- obviously -- means there's no way you can read the data when the STROBE signal is in its HIGH state. In turn, this means that the minimum strobe pulse width ("ts") really isn't 18us. Instead, it's equal to the output settling time ("to") plus however long it takes for you to actually read the sample (let's call this "tsr" for "sample read time"). Based on this, a much better timing diagram would be as shown below.

(Source: Max Maxfield)

 How to Read a Data Sheet

Remember that the title of this column is "How to Effectively Interpret Data Sheets to Recognize Misleading Information." So, how do we go about doing this?

 Well, the first step is to learn how to read a data sheet in the first place. The problem here is that data sheets vary between component types and manufacturers. As a result, each data sheet can provide its own unique problems.

 Fortunately, Elizabeth Simon -- who is one of the members of the EEWeb Experts team dedicated to answering questions on the EEWeb Forums -- has kindly agreed to write a mini-series of articles describing the tips and tricks associated with reading the data sheets for various types of components, including regulators, diodes, transistors, and analog-to-digital converters (ADCs). 

Keep on visiting EEWeb.com to see these articles as they appear. In the meantime, we would love to hear any examples you have of data sheets you've seen that exhibit confusing, misleading, or missing information. 

"/>

Have you ever run across a data sheet that exhibits confusing, misleading, or missing information?


If you are involved in developing electronic products, one of the things you can look forward to doing a lot of is perusing and pondering component data sheets. If you are lucky, these documents will summarize the characteristics -- physical, electrical, etc. -- of the components in sufficient detail for you to be able to confidently integrate them into your system (visit Datasheets.com to access the latest data on electronic components, including environmental, packaging, manufacturing, and reference designs). 

To some extent, how you read data sheets and what aspects of them interest you the most depends on what you are doing. Three usage scenarios that immediately spring to mind are as follows:

  • Design: In this case, you may start by sifting through a mound of data sheets looking for parameters and operating modes that satisfy a specific set of design constraints (does the component do what you want it to do?)
  • Verification: Did whoever created this portion of the design read the data sheet correctly and make appropriate assumptions as to its content (does the component really do what the designer thought/assumed it did?)
  • Debug: Does this component do anything that violates the original design specification? Is there anything about this component that could cause the system failure you are currently experiencing? 

Two more potential usage scenarios are as follows (can you think of more?):

  • Research: In the case of a new technology or new device, you may use the data sheet as one resource to learn more: What does this component do? How does it work? Will it be of interest for current and/or future designs?
  • Reverse Engineering: Component datasheets provide an invaluable resource if you are trying to reverse engineer a product or understand how one works.

 One common pitfall with data sheets is when the user fails to read the small print. It's easy to glance at a parameter and say something like: "Great, a maximum value of 100mA; that will do the job," without noticing the qualifying '*' and the associated note at the bottom of the page that says something like: "You will only achieve this value if you have an imaginary load with negative resistance and the arrow of time is pointing backwards" (or words to that effect).

 Other problems include the following:

  • Missing/omitted information
  • Incorrect/sub-standard information
  • Misinterpretation of measured data
  • Flat-out misprints (someone typed it in wrong)
  • Babel fish issues 

Babel Fish Issues

It's not uncommon for the original version of a data sheet to be written in a language like Chinese, Japanese, or Korean before being translated into another language like English (or American). Just to increase the fun and frivolity, some datasheets undergo an intermediate step, first being translated from Chinese etc. into German or Hebrew, and later being translated from German etc. into English. 

As an aside, I particularly enjoy translations from Hebrew to English. These oftentimes end up with a very Shakespearian quality, along the lines of: "But where are the variables, you ask? Ha! The variables are over here!" You can almost imagine this being presented as a play in the stage: 

Character 1: "But where are the variables, you ask?" 

Character 2: "Ha! The variables are over here!" {Actor throws curtains apart to reveal the elusive variables} 

In fact, this just reminded me of three related columns -- Error Messages We Can All Understand and The Worst Oscilloscope User Manual of All Time and Different Countries = Different Writing Styles in User Manuals -- but I fear we are in danger of wandering off into the weeds. 

Missing/Omitted Information

As one example of missing information, consider the NeoPixel RGB LED Strips from Adafruit. I love NeoPixels and I've used them in all sorts of projects, like my Cunning Chronograph and my BADASS Display

I have to say that I've always been impressed with the Adafruit website. I particularly appreciate all of the technical information they provide, including example Arduino sketches (programs) that will quickly get you up and running. In the case of NeoPixels, one of the documents Adafruit provides is their NeoPixel Uberguide

Unfortunately, even the folks at Adafruit can drop the ball on occasion. When I first started using their NeoPixel Strips, I was under the impression that I could simply drive the first pixel in the chain directly from the output pin on my Arduino.

(Source: Max Maxfield)

Sad to relate, things tended to work for a while, but then the first pixel in the chain would "bite the dust." After a few pixels had shrugged off this mortal coil, I carried my setup into the next bay and we used an oscilloscope to see what was going on. When we probed the first pixel's Data-In pin, we observed an eye-watering amount of overshoot and undershoot. Adding a 390-ohm serial resistor just before the input solved the problem. I communicated this information to the folks at Adafruit. I don’t know if my email prompted the change, but the next time I looked at their Uberguide, I saw that the "Connections" page now included a note about adding such a resistor (they recommend adding a ~470-ohm device). 

Incorrect/Sub-Standard Information

By some strange quirk of fate, I have a corker of an example of sub-standard data sheet information. As part of my BADASS Display project, I decided to use one of the MSGEQ7 7-band graphic equalizer chips you can pick up from SparkFun Electronics for only $4.95. 

The MSGEQ7 is a clever little 8-pin device. Inside there are seven band-pass filters tuned to 63Hz, 160Hz, 400Hz, 1,000Hz, 2,500Hz, 6,250Hz, and 16,000Hz. Each of these filters has an associated peak detector. The clever thing is that the outputs from the seven peak detectors are multiplexed together, which explains how everything fits into an 8-pin package. 

(Source: Max Maxfield)

If you are interested in using one of these little rascals in your own project, you might want to peruse some of my MSGEQ7-based audio spectrum analyzer articles, including Introduction, Construction, Testing, and Software & Timing

So, where does the problem appear? I'm afraid it's in the data sheet. Sometimes the values presented in a data sheet are difficult to interpret and understand without an associated timing diagram. The following is my original interpretation of the timing diagram presented in the component manufacturer's data sheet (I added color and made it prettier).

(Source: Max Maxfield)

Do you see any problems with the above timing diagram? Neither did I. In fact, it was my chum, David Ashton, who pointed out that the minimum strobe pulse width (ts) of 18us is specified as being less than the minimum output settling time (to) of 36us. 

If this were to prove to be correct, then one interpretation would be that we could continue to read data on the DATA_OUT pin even after STROBE signal has returned to its logic 1 (inactive) state. In this case, a better representation of the timing relationships and waveforms would be as illustrated below. 

(Source: Max Maxfield)

However, this really doesn't make much sense. Since it wasn't possible to make a definitive decision based on the official data sheet, I talked to John Ambrose at Mixed Signal Integration -- the company that makes the MSGEQ7 (along with many other interesting products). 

John explained that the DATA_OUT signal is clamped to 0V when the STROBE signal is HIGH, which -- obviously -- means there's no way you can read the data when the STROBE signal is in its HIGH state. In turn, this means that the minimum strobe pulse width ("ts") really isn't 18us. Instead, it's equal to the output settling time ("to") plus however long it takes for you to actually read the sample (let's call this "tsr" for "sample read time"). Based on this, a much better timing diagram would be as shown below.

(Source: Max Maxfield)

 How to Read a Data Sheet

Remember that the title of this column is "How to Effectively Interpret Data Sheets to Recognize Misleading Information." So, how do we go about doing this?

 Well, the first step is to learn how to read a data sheet in the first place. The problem here is that data sheets vary between component types and manufacturers. As a result, each data sheet can provide its own unique problems.

 Fortunately, Elizabeth Simon -- who is one of the members of the EEWeb Experts team dedicated to answering questions on the EEWeb Forums -- has kindly agreed to write a mini-series of articles describing the tips and tricks associated with reading the data sheets for various types of components, including regulators, diodes, transistors, and analog-to-digital converters (ADCs). 

Keep on visiting EEWeb.com to see these articles as they appear. In the meantime, we would love to hear any examples you have of data sheets you've seen that exhibit confusing, misleading, or missing information. 

Join the Conversation!

User must log-in to comment.
  • by  Max Maxfield
    I keep on thinking of additional points, such as the fact that when you are reading a data sheet you have to think about it critically. Does what you are reading make sense. If not, either there's an error in the data sheet (not tremendously likely, but also not uncommon) or a problem with your understanding.

    Re the latter -- if you read something and you don't understand it, then you need to do more research and talk to people until you do understand it. You have to fully understand the data sheet before you design this component into your system -- if not, they you can bet that you will be re-reading this data sheet downstream when you get to the debug stage LOL

  • by  Max Maxfield

    Another thought -- one that relates to "missing" information -- is that the creator of the data sheet may not know (or may have decided not to document) all the ways in which the component might be used.


    Take a diode, for example; the data sheet may (not surprisingly) focus on the characteristics of the diode under normal operating conditions. But suppose you want to use the diode as a crossbar safety, which may involve avalanching it (causing it to undergo a rapid increase in conductivity due to an avalanche process).


    In this case, you would be interested to know how the device will fail -- open circuit or short circuit (or catch fire or explode), but this information will probably not be available in the data sheet (on to the lab -- "Dispatch the butler to fetch my safety goggles!)

    • by  Elizabeth Simon

      @ Max

      "... In this case, you would be interested to know how the device will fail -- open circuit or short circuit (or catch fire or explode), but this information will probably not be available in the data sheet (on to the lab -- "Dispatch the butler to fetch my safety goggles!)"

      I think there's a design guideline we have at work that covers this situation. The guideline about using diodes or transistors in avalanche mode is basically DON'T.

      Circuit designs using "features" of parts not found in data sheets are highly discouraged.  I learned about this when I was a technician trouble shooting a circuit like this. I spent the better part of a day trying to figure it out until the engineer came by and told me I had to use a part from a particular vendor  in that spot for it to work.

      • by  Max Maxfield

        @Elizabeth: "...I think there's a design guideline we have at work that covers this situation. The guideline about using diodes or transistors in avalanche mode is basically DON'T..."

        Party Pooper!

      • by  Aubrey Kagan

        Max, Elizabeth

        Circuit designs using "features" of parts not found in data sheets are highly discouraged

        Just to remind you that yet another one of my blogs discussed this  “The dangers of undocumented and unguaranteed properties”


  • by  Elizabeth Simon

    @ Max

    "... In this case, you would be interested to know how the device will fail -- open circuit or short circuit (or catch fire or explode), but this information will probably not be available in the data sheet (on to the lab -- "Dispatch the butler to fetch my safety goggles!)"

    I think there's a design guideline we have at work that covers this situation. The guideline about using diodes or transistors in avalanche mode is basically DON'T.

    Circuit designs using "features" of parts not found in data sheets are highly discouraged.  I learned about this when I was a technician trouble shooting a circuit like this. I spent the better part of a day trying to figure it out until the engineer came by and told me I had to use a part from a particular vendor  in that spot for it to work.

    • by  Max Maxfield

      @Elizabeth: "...I think there's a design guideline we have at work that covers this situation. The guideline about using diodes or transistors in avalanche mode is basically DON'T..."

      Party Pooper!

    • by  Aubrey Kagan

      Max, Elizabeth

      Circuit designs using "features" of parts not found in data sheets are highly discouraged

      Just to remind you that yet another one of my blogs discussed this  “The dangers of undocumented and unguaranteed properties”


  • by  Max Maxfield

    @Elizabeth: "...I think there's a design guideline we have at work that covers this situation. The guideline about using diodes or transistors in avalanche mode is basically DON'T..."

    Party Pooper!

  • by  Aubrey Kagan

    Max, Elizabeth

    Circuit designs using "features" of parts not found in data sheets are highly discouraged

    Just to remind you that yet another one of my blogs discussed this  “The dangers of undocumented and unguaranteed properties”


  • by  Max Maxfield

    @Aubrey: "...Just to remind you that yet another one of my blogs discussed this  'The dangers of undocumented and unguaranteed properties'..."

    Sometimes I think you write more columns than I do -- LOL

  • by  Elizabeth Simon

    @Aubrey

    I'd forgotten about that blog...

    I must have read it though because I commented on it.

    You must have some system for keeping track of all the blogs you've done...

  • by  John Beetem

    My favorite data sheet error -- an obvious one -- was where it said you needed a 10 KW resistor.  They actually meant a 10 K Ohm resistor, but the Omega in the Symbol font got printed as its equivalent ASCII letter "W".   Hard to fit a 10 KW resistor into a small enclosure :-)

    Back when I was an assistant professor, I would sometimes use data sheets in lectures.  I would start by saying: "This is a Data Sheet.  It contains Data.  If you want Information, you have to work."


    • by  Max Maxfield

      @John: :...the Omega in the Symbol font got printed as its equivalent ASCII letter "W"..."

      I have seen this so many times in so many places -- especially in electronics  hobbyist magazines -- but I'd never thought about it in the context of data sheets.

      • by  David Ashton
        W for Ohms...it's happened a fair bit in EETimes and probably here as well...


  • by  Max Maxfield

    @John: :...the Omega in the Symbol font got printed as its equivalent ASCII letter "W"..."

    I have seen this so many times in so many places -- especially in electronics  hobbyist magazines -- but I'd never thought about it in the context of data sheets.

    • by  David Ashton
      W for Ohms...it's happened a fair bit in EETimes and probably here as well...


  • by  David Ashton
    W for Ohms...it's happened a fair bit in EETimes and probably here as well...


  • by  Elizabeth Simon

    One use of data sheets that you omitted is in attempting to find replacements for parts that you've been happily using in a design for years which have been discontinued by the manufacturer. In addition to causing great weeping and gnashing of teeth, this results in engineers spending much time finding and studying data sheets to replace old parts rather than to design new circuits.

    I also used data sheets in lectures during the year I spent as an instructor.  I'd point out features to watch for on the new parts to be used in that week's lab.

  • by  Max Maxfield

    @Elizabeth: "...One use of data sheets that you omitted is in attempting to find replacements for parts that you've been happily using in a design for years which have been discontinued by the manufacturer..."

    That's a good one -- I should have remembered this for myself.

  • by  Rick Curl

    I've always felt that the benchmark for a properly-written datasheet is the  Signetics WOM

    Now there's a classic!

    -Rick

  • by  Max Maxfield

    @Rick: "...the benchmark for a properly-written datasheet is the  Signetics WOM..."

    That was a classic -- the scary thing is that this dates back to 1972 (http://bit.ly/2DcBmIV)
  • by  Max Maxfield

    @Rick: "...the benchmark for a properly-written datasheet is the  Signetics WOM..."

    Of course, the video equivalent was the Rockwell Encabulator -- I so wish I'd been part of that project (https://youtu.be/RXJKdh1KZ0w)

Add Comment

You must log-in to comment.