Out-of-spec problem with a long tail
In the mid-1960s, early in my career as an engineer, I found myself facing a problem that at the time appeared impossible to solve. My employer had been awarded a contract to design, develop, and produce specialized surveillance equipment related to the war effort in Vietnam.
Field testing on the initial units had gone well, and the company was in a full production swing when an unusual problem appeared. The returned modules contained a specially designed video amplifier showing inadequate gain. The only clue as to what might be wrong was a slightly out-of-spec dc bias level at the joined emitters of a long-tail pair of differential amplifiers housed in the amplifier module.
A review of the test data showed the units had met spec when they left for the field. A review of the design revealed no issues. The design used the values stipulated in the device data sheets, and the transistor data showed an adequate ac and dc beta that was within the specified temperature range.
I could find no errors in the way the units had been designed or in the selection of the parts used. I was stumped.
Keep in mind that all of this took place in the days predating the cubicle, when engineers were allowed to have offices with doors and usually shared them with an office mate. As luck would have it, my office mate happened to manage the IBM System/360 computer our company had recently purchased.
My office mate was also familiar with the problem I was troubleshooting and suggested we join forces and use the problem as a test case to show management the benefits of computer-aided analysis. (Again, these were the days when slide rules were still in common use.) The plan was for me to model the circuitry on paper and create simplified models of the devices and transistors. The transistors would be modeled in a hybrid-pi configuration using data from manufacturer data sheets.
I then wrote loop equations in matrix form compatible for programming and input into a subroutine program that inverted and processed the matrices. The input to the central IBM computer was via a time-shared teletype terminal.
The code was written in a BASIC language and comprised two parts: a separate dc simulation and an ac simulation with random number generators associated with the software to simulate the variations in parameter values due to the effects of tolerances and changes in temperature.
After several Monte Carlo sensitivity runs—which incorporated a worst-case temperature spread on suspected components, including the transistor betas—we found that when we varied the dc beta to simulate the slightly out-of-spec dc level of the returned units, the dc-beta spread of the transistors associated with the long-tailed pair became slightly broader than the spread listed on the manufacturer’s data sheet.
We set up a special test station in manufacturing and tested incoming transistors. Into one pile went the transistors that fell within a spread that was slightly smaller than that advertised in the data sheet to account for a degree of degradation. We rejected transistors that fell outside the stipulated range, as we suspected the failed units to be marginal cases.
Not long after this adjustment, the problem in the field essentially vanished. My office mate and I were hailed as heroes, the company was sold on computer-aided circuit analysis, and the experience taught me never again to put my complete trust in a data sheet.
Paul P Wollam is an engineer living in northern San Diego County. His career has spanned a frequency range from dc to light wave.