Precision resistors and tolerance stackup in general

This must be the season for great graphics. After seeing the solar cell output over temperature graph a couple days ago, today I see this great article about the reality of using precision resistors. It is from the great folks at Vishay, by way of my former co-workers at ECN Magazine.

Vishay shows what can happen to their beautiful resistors once you and your customers get your grubby hands on them. TCR means temperature coefficient of resistance.

The same chart got used in an article in EDN, where I worked. The graph also saw use in an Electronic Design article about foil and thin-film resistors. The mother lode was from a Vishay app note by Yuval Hernik.

If you are using a resistor to measure current you should not trivialize the accuracy problems that come with the real world. You can see in the chart that the ±0.05% resistor you buy from Vishay can end up being a ±1% resistor after a few years in the field. It’s not Vishay’s fault. They did not stress the resistor soldering into the board. They didn’t expose it to humidity and temperature gradients that damage the device. They didn’t drop it and shock it and over-voltage it.

The point of this is that you can’t build a product that specs ±0.05% accuracy if you start with ±0.05% resistors. You customers don’t care what you buy from Vishay and they don’t care what you built. They care about they use, perhaps years later, at some horrible temperate in some inhospitable humidity over some astronomical altitude. When I was at Analog Devices they had a test for voltage references that was running for years. Years! This was to evaluate the long-term drift that the parts would exhibit. I am happy to say that the ADI parts seemed better than most.

And here is the thing— when it comes to these drift problems, no one can tell you what is going on. We simply don’t understand the physics of it. I contend we really don’t understand noise either, but that is an argument for another day. But drift, which you can think of as “dc noise” if you want mess with your head, is a universal problem. We older folks that used to wait for tube radios to “warm up” seem more comfortable with the concept. But op-amps and maybe even discrete components have to settle in as well. This is not the few microseconds it takes for the internal circuits to start working. It is the minutes or days it takes for the amplifier to come to its final dc offset error.

I have several pals that are trying to make their own test equipment to save money or just build things like a Maker movement. That is fine if you don’t really have to trust it. Believe me, Fluke and Agilent and Tektronix earns every penny they ask you for. This is why I am wary of cheap knock-off test equipment. I would rather buy used name-brand equipment that I can trust to keep accurate over their lifetime.

As to these resistor tolerance issues, one answer is that you calibrate the product every time it’s turned on, or even more often. When I did automotive test equipment at HP (before Agilent split off) my solution was to use the best voltage reference that money can buy. Back then it was Thaler. Since then (1998) I found out that the Thaler part I used was a National Semiconductor part that was hand-selected by Thaler. No matter where you get it, you have to have a low-drift and low TC (temperature coefficient) part. I also used very good initial accuracy parts, since I did not want to have to calibrate the board the first time in the factory.

This way, I had the acquisition system measure its own reference. That way I could calibrate any errors or drift in the attenuator resistors. The other aspect was using a very good crystal. This way you know voltage and time. Most everything else you can derive in firmware. I called it “a rock and a ref,” since rock was slang for the quartz crystals. I still remember Bob Shaw asking me what pots had to be adjusted on the board for manufacturing. I told him there were no trim pots or trim capacitors. He was astonished. I told him about a rock and a ref. I joked that if he really wanted pots I could add them back in. He told me no, and thanked me for designing something that did not need factory calibration, since it just calibrated itself. The other horrible thing about pots is that they are terribly unreliable components. Only electrolytic and tantalum capacitors are worse. If you have vibration, pots are a really bad idea.

OK, product pitch time, these accuracy problems are why you should think about using Atmel AFE (analog front ends). We make them for the smart power meters. And I don’t mean to imply that Atmel is the only outfit. All the semiconductor makers make AFEs for various tasks. If it can offload your accuracy problems with calibration or the precise accuracy that comes with semiconductor processes, it is always a good deal to pay for an integrated solution rather than build it yourself. For years I told National Semi that people would pay for precise ratiometric resistors. It took Linear Technology to actually make the parts.

Benchmarks for embedded processors

Crack applications engineer Bob Martin was walking by just now and we got to talking about people we both knew from our National Semiconductor days. One name that came up was Markus Levy. Bob told me about EEMBC® — the Embedded Microprocessor Benchmark Consortium.

When I read up on the organization, I was delighted to see that Markus started work on embedded benchmarks when he worked at EDN magazine, where I also worked as an editor for 5 years. Back in 1996, it was clear that the old Dhrystone MIPS benchmark was not really meaningful to embedded systems. So Markus got a bunch of industry companies together and proposed the new benchmarks. They got 12 members right off the bat and got funding to establish real-world benchmarks that would be suitable for phones, tablets, routers and other embedded systems. As their about page explains:

“EEMBC benchmarks are built upon objective, clearly defined, application-based criteria. The EEMBC benchmarks reflect real-world applications and have expanded beyond processor benchmarks, also heavily focusing on benchmarks for smartphones/tablets and browsers (including Android platforms) and networking firewall appliances.”

I was glad to see that not only is Atmel a member, but so is ARM, who invented the cores used in Atmel’s 32-bit SAM line of microprocessors and microcontrollers. When you look at Atmel’s benchmark results, You can see our original 8051 processors get a score of 0.1. An AVR 8-bit MCU like the ATmega644 will get a benchmark score of 0.54. In contrast our ARM-core SAM3 and SAM4 chips will get a benchmark score up to 3.3. When I looked at a competitor’s ARM4 offering, I was delighted to see they ranged from 2.0 to 2.8, significantly slower than Atmel’s ARM4 SAM4 chips.

This is congruent with what I hear in the hallways here at Atmel. We just didn’t slap some counter-timers on an ARM core and release it. We took the time to do it right, adapting and improving the really cool peripheral system from our XMEGA 8-bit micros. I assume these benchmarks are just for raw speed, but the cool thing about Atmel’s peripheral event system is that you can have peripherals interact and do DMA without waking up the CPU core and sucking up a lot of power. Still it’s nice that the benchmark shows us as faster. This might mean you can get some chunk of code to execute faster and then get the micro put to sleep, saving power overall. This can be non-intuitive. If the micro’s compiler has more efficient code creation, you can get way more done with the same amount or less power. I know this is true for AVR 8- and 32-bit processors. The AVR was invented and crafted by hardware engineers that understood the importance of C and computer science in general. Although the entire AVR line did not spring fully-formed from the head of Thor, there were some really crafty Norwegians involved.

While the ARM-core SAM chips run ARM instruction sets, they too are optimized for compiling. After all, AVR showed the world how to do this in 1996. And with Atmel peripheral concepts, the SAM chips are really something. Check out the new SAM D20 Cortex M0+ micro for a nice inexpensive chip that can do a whole lot on minimal power.

Bob Pease says: “My favorite programming language is solder”

The famous analog engineer and writer Bob Pease mentored me over at National Semiconductor. I was deeply saddened by his tragic death and I miss him every day. So you can imagine my delight when Lenore over at Evil Mad Scientist told me a pal had made a fun little tribute circuit board in honor of Pease.

Saar Drimer at boldport.com made up this cute PCB in honor of Bob Pease.

One of Pease’s exasperations was engineers that would rely solely on computer simulations. Bad enough they didn’t rely on real hardware, but when the real hardware did not agree with the simulation, these engineers would blame the hardware, not the computer. I touched on this tendency of engineers to rely on pretty simulations in a recent article in Electronic Design.

So when engineers would as Bob Pease what his favorite Spice or his favorite programming language, Bob would loudly pronounce “My favorite programming language is solder!” I really get his point. When I was a consultant, clients wanted to see working hardware, not computer print-outs. So my doing minimal Spice, I got prototype hardware in their hands sooner, and then we could use Spice to optimize component values, or for what it is really good for—doing Monte-Carlo simulations with your discrete component tolerances so you could see the corner cases of performance of your design.

To kid Bob Pease about his saying “My favorite programming language is solder,” I bought him this hefty 200W unit at the Silicon Valley Flea Market.

Saar Drimer was hoping that I could send one of his Pease PCBs to Bob’s widow Nancy. I will do that tonight, and I am sure she will be delighted as I was.

The backside of the Pease tribute PCB has a nice silkscreen that emulates Bob’s classic handwritten schematics.

So thanks to Saar over at Boldport, for keeping the Pease flame alive, just the way Bob would want— in some hardware.