12
\$\begingroup\$

My last question brought up some discussion about application notes and (bad?) practice. See the comments under the various answers.

Until now I thought: "Ok these application notes are written by electrical engineers working at some big companies, who probably know what they are doing."

But after reading the comments from my last question, I dont know whom to trust. If I had been studying electrical engeneering or had enough pratical experience, I probably would have enough knowledge to see bad practice / wrong application notes. But I am just a hobbyist.

So what should I do? Just go ahead and hope, that everything works fine, until something breaks. So I know the next time: dont do this. According to the comments in the linked question, this could be realy frustrating, because some faults come and go randomly. Maybe I do not even realize, that the design I took from the application note was wrong. I would probably search for a mistake in my design, because I am the unexperienced guy...

One thing I have learned so far from the comments in the other question is, that I should always look through the datasheets and search for things that exceed the operation ratings of the devices (it is not safe to just stay within the maximum ratings).

Is there anything else I should check in an application note, so I could identify a probably bad design and ask someone (e.g. here), whether it is realy bad design?

\$\endgroup\$
1
  • \$\begingroup\$ This has great value to many users, I am sure, but I think it needs to be CW. I am converting it so that this can be even more of a popularity contest. \$\endgroup\$
    – Kortuk
    Feb 1, 2012 at 19:25

4 Answers 4

15
\$\begingroup\$

Ask Olin :-) - but wear a flame suit.

Unlike data sheets, which SHOULD be holy writ (but often don't quite make it), Application Notes are a very "mixed bag". It does not pay to just take what is in an AN as gospel, although you'd hope it was at least usable without magic smoke.

The following is opinion (of course).
people are most welcome to offer counterpoints to any assessment I make.

Code: When it comes to sample code that comes with AN's, you can expect that it is liable to be "somewhat rushed" if it was written speifically for the AN, and of perhaps grater quality if it builds on existing applications and libraries. Olin, who is far more qualified to speak on this than I am, will tell you that MOST AN code is poor or dangerous. It happens that Olin's company are top Microchip representatives and that Olin is the sort of perfectionist that you'd want as your developer and not want as your boss ;-). ie you can probably be slightly lss scathing about AN code that Olin is, but listen carefilly to his advice.

Hardware: With reference to hardware, you'd hope that an AN writer was highly competent. If the AN is regarding a reference design that they suggest you can use as the basis for a commercial product then you'd also hope they had put their top people on it. BUT if you make a lot of ICs and you want to suggest ways that people can use YOUR product then you can expect "the boy" to write at least some of them. SO be discerning - look at what is suggested and be prepared to find some bloopers.

Chip bloat: A factor which I recalled again tonight when looking at a TI app note is that there is a tendency to "gild the lily' - to use many ICs where fewer may do. Anyone would think they had some sort of interest in getting the IC's into circulation, or something.

Writer reputation counts for much - this is one place where "appeal to authority" has some merit. If Jim Williams wrote it then trust it. Jim died recently and all too many of the other classically trustable names have gone the same way.

Company reputation counts somewhat.

LT are usually good. Mainly with Jim to blame.

AD / Analog devices are usually very good.

NatSemi are a bit of a mixed bag with much good but nothing certain.

Microchip make great products but do rather tend to churn out the app notes.

Burr Brown tend to be keepers of the Holy Grail [tm} but having been acquired by TI the name could get used differently.

TI are usually quite good over many decades. They have acquired NatSemi and BurrBrown and others in recent years and will hopefully bring th average up and not down.

Zetex (acquired by Diodes Inc) make great great great parts (great!) but have been known to write less than perfect app notes.

Nichia tend not to write app notes but if they did you could probably frame them.

Luxeon/Lumileds / Ghost of Philips past write superb technical notes for LEDs. LLP understand LEDs unlike almost any others on the market and can be used to grow your knowledge base when looking at other products.

Atmel/AVR: Should stick to digital which they know very well. Actually usually very good - using body diodes as zero crossing detectors was a fit of momentary madness.

Hewlett Packard: Old School HP technical stuff was utterly utterly utterly superb. Utterly. Novo Riche HP if they produce app notes of relevance should be treated with care. Pass by on other side if in doubt. Agilent carries much of the mantle of the old HP and can largely be trusted.

Motorola of old not too bad at all. On Semi followed fairly well. Spun off children maybe also.

...

\$\endgroup\$
1
  • \$\begingroup\$ "Agilent" -- you mean Avago for the former HP semiconductor unit (LEDs, optoisolators) \$\endgroup\$
    – Jason S
    Feb 1, 2012 at 13:17
9
\$\begingroup\$

My solution with app notes: Simply ignore them. Think of them as Electronics for Dummies, too often written by dummies.

You may think that app notes are written by the same skilled people that designed the part, but that's just not true in many cases. I have seen company structures where most app notes were generated by the customer technical reps, and even marketing in a few cases. The tech reps write them because they are tired of answering the same question or finding the customer doing the same stupid thing over and over again. Marketing writes them because they want to show off how to use the product in a particular application they'd like to sell more into. Of course every company has at least some process for vetting app notes, but don't count on that being too rigorous. In some cases the design engineer may not even see the app note before it goes out. In other cases he's got real work to get on with and can't spend the proper time critiquing a flood of marginal app notes so sighs and gives approval or passes it off to a junior engineer who is too scared to say no to senior people.

Basically, the really good engineers are too valuable to write app notes. At best this is done by "application engineers".

The ultimate truth is in the datasheet. If you know what you're doing, there's really no need for app notes. At best they didn't screw up something. If you don't know what you're doing you shouldn't be responsible for the design. I suppose app notes can be adjunct material to help demystify things, but it's best to consider them as written by dummies for dummies because too many are.

As Russell said, different companies and different authors (when that is even known) have different cultures that you can learn are more reliable than others. However, be very careful with that. What may appear to be a company culture may be a single engineer in that company driving things. When he leaves, the quality may change significantly. About the only thing to trust is app notes written by select individuals who you recognize and know they uphold high standards. There are very very few of those.

Even "big names" can have bad days. A long long time ago in 1980 when I was a fresh engineer right out of school working for Hewlett Packard, it was strongly suggested to me by a senior engineer to use a new voltage to frequency converter chip from National Semiconductor in my design. The senior engineer said the part was designed by this guy Bob Pease who was supposed to be some kind of analog semiconductor god. So I read the datasheet carefully and a appnote written by said Bob Pease about using this part to make a high resolution A/D. The datasheet made sense, but the app note was seriously suggesting you could make a 22 bit A/D with this thing. The circuit in the app note had obvious sources of error way way exceeding 1/4 part in a million. I thought I must be misunderstanding something, so I did the math and proved my case carefully enough to show the senior engineer. He looked at it and agreed with me and kindof laughed saying "Yeah, BoB Pease seems to be a loose cannon lately, I think National is trying to reign him in a bit". It surprised my he was so tolerant and not more upset for something I considered blatantly wrong. Then he said "That's just a appnote anyway, it still looks like a good part". That's when I understood app notes are casually written and not meant to be taken more than casually.

\$\endgroup\$
18
  • 7
    \$\begingroup\$ Sorry Olin, are you implying that application engineers are by definition not really good engineers? IMO application engineers have to be good and have a good understanding of a part to be able to apply it best: make use of the parts best features and avoid its traps, and do so in the most economic way. For this you need to have a good understanding of the datasheet. A company can afford to have its ANs written by a "really good engineer" if it helps customers to use the part properly, so that a well-designed part gets the credit it deserves. Just my two cents. \$\endgroup\$
    – stevenvh
    Feb 1, 2012 at 14:26
  • 2
    \$\begingroup\$ See - I told you what Olin would say :-). I'll admit to loving to look through app notes. There may be ideas or bits and pieces that get lodged in the brain and later on dredged out and used some other way. I have almost never built anything from an app note directly - they provide inspiration and seed material. As long as you understand what an IC should do and can do then an app note is a good guide. Rely on it over a datasheet and you may end up using body diodes to zero crossing detect mains or something else equally silly :-) \$\endgroup\$
    – Russell McMahon
    Feb 1, 2012 at 14:29
  • \$\begingroup\$ @stevenvh: There are good app notes out there and some are written by competent engineers, but the reverse is also certainly true. You can't rely on quality. Some apps engineers are very good, some not so, just like any other group of professionals. Apps engineers seem to be more focused on getting a job done than considering every nuance of the parts. Again, there are good ones and bad ones. For example, if John Day (top notch field engineer for Microchip) says something, I'll take it seriously. Coming from others I'll do a lot more checking. \$\endgroup\$ Feb 1, 2012 at 15:07
  • 1
    \$\begingroup\$ Many data sheets leave such substantial areas of ambiguity that it would be practically impossible for an engineer to make a useful design which didn't rely upon things which aren't actually specified. For example, suppose a latch has no specified minimum propagation time, a specified hold time of -5ns at 25C, and 5ns from -40C to +85C. Would it be safe to assume that connecting /Q to D would yield a circuit that would toggle the output, without going metastable, any time a clean pulse arrived on the clock input? On what basis could one assume that such a circuit would work at even 25.6C? \$\endgroup\$
    – supercat
    Feb 1, 2012 at 18:58
  • 3
    \$\begingroup\$ Some app notes offer designs that seem to assume a chip is capable of withstanding some amount of current (typically between 1uA and 1mA) on the protection diodes, but a lot of data sheets don't even guarantee that 1aA (i.e. about 6 electrons per second) would be safe. What should one assume about what one will be able to 'get away with' on present or future silicon? \$\endgroup\$
    – supercat
    Feb 1, 2012 at 19:12
5
\$\begingroup\$

While it is quite true that many application notes are of poor quality or dubious merit written by inexperienced engineers (I use that term loosely) in an effort to simply sell product, there is more to the story.

Taking the best case of a highly experienced engineer taking his time and attempting to do a very good job, there are still inherent limitations. In particular assuming he builds and tests the circuit being described, and it works as described in his lab, it does not necessary mean that it will work for you. Building a working prototype is a lot different from building something that is easily reproducible by others under different conditions.

When you build a circuit from an application note it is highly unlikely that your parts and methods will be identical to those used by the app engineer. Something as simple as using a PC board with a different thickness could cause issues. Consider the case of a simple oscillator, if he used a capacitor specked at plus or minus 10% and his was on the high side and yours on the low it is possible that just this much difference could mean that one fails to oscillate, or oscillates at a harmonic rather than the fundamental frequency.

Particularity with analog and RF circuits it is seldom plug and play, one needs to be concerned with adjusting drive levels, naturalizing amplifiers, tuning filters etc. Getting this stuff right takes knowledge and experience.

So don't throw the baby out with the bath water. Application notes are not perfect, but they may be a great source of ideas. Take them with a grain of salt and be prepared to do the hard work of refining and testing the circuit yourself.

\$\endgroup\$
3
\$\begingroup\$

Application notes are a huge marketing tool for companies. These highlight your product's features, eases the learning curve for your client, and shows the quality of your support structure. All of this is done to persuade engineers to put a part on a BOM.

Granted not all companies take app notes as seriously as others, and often it is the young engineers on the team that are tasked to write them. This does not dilute their intended use. It is important to remember that app notes don't do the engineering work for you. They are templates; examples to help understand datasheet subtleties. They are rarely required, designed, or expected to be cut-and-paste modules.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.