Tales of Real Electrical Engineering

Typical Workday Activities for Electrical Engineer in a Product Development Function 1972 to 2012

John Engelbrecht Sept 23, 2013

Audience: MS-HS STEM students, EE students

Scope: A record of real circuit-design experiences gives ideas to students about what electrical engineering is like, with an emphasis on experiences in a product-development job. It is hard to find WWW tales like these; personal write-ups like IEEE and MIT Sloan School of Management tryengineering.org tend to be written by young engineers (good) but be short and "talk about my job" in vague, general terms, not "details of what I did last week." The tales in this write-up give a lot of specifics. They reach forty years back but have a lot of relevance today. Publishing text to WWW is cheap so there are many more words here than you find on tryengineering.org. Scan through and see if anything gets your attention. Circuit-design terms are tossed in without much explanation. This is not to try to overload the reader, it lets me put in specifics even if you don't know exactly what is being talked about. Look up terms on Wikipedia if you like.

Subway Crash 1972

Oct 2 1972 Only a month into operation of the new subway, a crystal oscillator (value about $30) switched to an improper frequency when a subway train was being commanded by the computer to slow down at the Fremont terminus of the San Francisco Bay Area Rapid Transit. Instead of slowing down to 27 mph, half a mile from the station, it sped up to 70 mph before the motorman decided that the automatic controls were malfunctioning. He hit the emergency stop button, but the train had only slowed to 26 mph when it plowed through a barrier at the end of the track and ran into a sand embankment intended to catch any overrunning train. Five passengers were injured.

Three electrical engineers working for BART had monitored Westinghouse design, programming, fabrication, and testing of the automatic train controls. They each felt Westinghouse had deficiencies in their work. The engineers alerted BART management but were overruled. They did an internal whistle-blowing notification to the board of directors, and one director leaked the information to the press. The engineers were fired and couldn't find professional work for some time. The IEEE (Institute of Electrical and Electronics Engineers) filed a friend-of-the-court brief in a subsequent civil suit, saying the engineers were justified in their whistle blowing because a code of ethics requires that threats to public safety be acted on. The engineers sought $750,000 but each received only $15,000.

Daisy-Wheel Printer 1984

When microprocessors were showing up in word processors, IBM Austin developed the Displaywriter word processor. This was when the IBM PC was new, very expensive, and very limited in ability; PCs took over the word processing function in the next six years as PC hardware gained ability, inkjet printers came out, and prices fell. But in 1984, there was a market niche for a high-function, expensive, targeted word processor.

The emphasis in this tale is on the two printers for Displaywriter. One was the final use of the excellent IBM technology called the Selectric typewriter, an expensive, precision mechanical printer from pre-microprocessor days. It used a spherical "typeball" with one font and around 90 characters. Different fonts were accessed by a four-second, manual change of the typeball. The typeball was widely believed to be cast metal but actually was plastic with durable metal film evaporated onto the surface, a creation of chemists in Lexington, Kentucky.

The other printer was a pre-inkjet, mechanical printer, a "daisy-wheel" printer that, again, had one font per four-inch-diameter, spoked wheel. This was higher speed and lower noise. It was a heavy-duty version of a lightweight, competitive printer that IBM had used until it's own printer came out.

The typeball for the Selectric printer and a daisy wheel for the other printer

Richard Fr. designed the circuits that spun the wheel to place a particular character in front of the "hammer," a 1.7" solenoid that impacted the character onto an inked ribbon and the paper. This was done at maximum speed, up to 60 characters per second. An Intel microprocessor was committed to this job. ROM stored dozens of motion profiles so that maximum speed could be attained.

The motor was a heavy affair and used three "phases," not the two phases that was standard in other daisy-wheel printers. The motor was a variable-reluctance stepper motor. The mechanical engineers chose this motor to get maximum speed. But the weight of the motor required the "carriage" rails to be large and heavy, and this drove the whole printer to be large and heavy. But it was fast, precise, and reliable. It was not popular with Sales because it was so large and heavy, but customers had a good experience. There was an automatic sheet feeder that could be purchased.

Another thing that increased printer weight was that there was a separate Intel processor for daisy wheel, carriage drive, and probably platen drive, besides the main OS processor. This was Austin IBM's first use of microprocessors, and the managers built in so many processors so there would be no conflict among programmers.

Richard used creative circuit design to drive up to 34 volts and two amps into each of the three motor phases. He had three, identical drive circuits to amplify the processor signals. He put a lot of work into minimizing the amplifier circuit, to minimize the size of the printed circuit board. He was so creative that IBM awarded him a corporate-level award.

Richard was not allowed to do custom analog-IC design because there wasn't time to get that done. He used standard ICs. He did have a newly qualified, fast, power transistor to use in the 25 kHz switch-mode output, which minimized heat.

The IBM 5218 daisy-wheel printer without sheet feeder

Ed, who worked on the carriage-motor design, also worked with the power-transistor vendor on two versions of this switching transistor. Ed wrote the spec sheet in consultation with the vendor, which is where the circuit designers got their voltage, current, and power constraints to design to. The sizes for the power-transistor heat sinks were selected based on the transistor power encountered during submicrosecond-level switching and during ten microsecond "on" time. Much lab time was spent with oscilloscopes and prototypes to uncover switching peculiarities. One bothersome phenomenon turned up: instead of evenly spaced current pulses at 25 kHz, sometimes the pulses would come in closely spaced pairs with wider spacing between, and this caused an irritating whine to come from the motors at 12.5 kHz. This would have been a show-stopper for customers, and there was a several-days-duration crisis while engineers confirmed this problem and found a fix. I do not recall the solution.

A key step in Ed's work on the switching transistors was to get them through an IBM-qualified, 1000-hour, life test with high temperatures, cycling temperatures, vibration, and high current and voltage. (1000 hours is about 40 days.) This test was not expected to be too tough, since the transistors were in hermetic, metal packages, not plastic. Ed and Purchasing found a vendor which did this work. The problem that showed up was that the switching-regulator test circuits, built on around twenty custom boards, were unstable due to terrific switching noise. The question arose, if there is a failure, is it due to all the noise on the test boards, or is it due to the semiconductors being unsuitable for our circuits? This is a big unknown when you are starting a load of circuits on an expensive, 40-day test. The result: they passed! What a relief.

All the motors were switch-mode. This approach causes extra electromagnetic interference (EMI), which is regulated by the Federal Communications Commission, FCC. The engineers had to supervise printed circuit board layout to minimize EMI, and also use capacitors and filters. We had little experience in this and had to test prototypes in the in-house EMI facility in Austin. When the interference levels were too high, we had to make modifications. My hammer driver had to be modified. We were advised by EMI engineers who had experience with circuits from the past, though they didn't have experience to do the detail circuit design.

Switch-mode power circuits had been around for a decade, so the IBM Austin engineers were not breaking new ground. It can be noted that all personal-computer power supplies are switch-mode, and the very lightweight, wall-plug-in power supplies, like for rechargers, are switch-mode.

The processor programming, using an early version of C language, was done by the logic EEs. The logic EEs worked closely with the electromechanical EEs, who worked closely with the MEs. Technicians and draftsmen drew up and sourced PC boards and many mechanical parts, just like with today's inkjet and laser printers, which still have lots of parts. Each part has to have a drawing with dimensions, tolerances, and finish specs. The mechanical designers had an enormous job of selecting dimensions that wouldn't bend under stress but be cheap to make, and fit in with all the other parts into as compact a space as possible. This is a very complex job, and requires techs and engineers who can cooperate and do detail work.

There are manufacturing engineers who don't do design, they just know factory processes and negotiate design modifications so the product is cheaper to build. Since Asian and Mexican manufacturing has become so cheap, current products might be designed in the U.S. but be built elsewhere, so much work is done by Internet to coordinate, and one side or the other has translators. Lawyers have to be involved to minimize misunderstandings that could blow up into lawsuits.

Other engineers knew about UL safety requirements about temperatures, voltages, and pinch points. We consulted with them early on so that there wouldn't be a violation designed in by accident, which would require a massive redesign and shipment slip. For example, the power voltage for the motors was selected to be 36V. 36V plus a 10% tolerance was just under an IBM safety requirement, for when customers and assemblers could possibly touch exposed voltages. Marketing people forecast competition and advised the engineering managers about deadlines.

When the prototype printed circuit boards were being laid out, a technician made a mistake. The spacing of the PCB "fingers" that are gold plated and fit down into the "edge connectors" needed .1" spacing. There were about 35 contacts per board. The tech worked on a 4x zoom layout. He measured each .1" spacing, zoomed to .4", by measuring from the adjacent contact, not knowing to measure each finger from Pin 1, and he had a cumulative error at the 35th contact of about .15", more than one contact width. This was not detected until the prototype boards were built up and ready to insert in the motherboard. The problem was instantly seen and was very embarrassing to the tech, and it was a schedule crisis because the layout had to be redone and new boards built. This is just one problem that happened. Each manager tried to monitor his employees so that such errors wouldn't happen in his "shop."

Another problem was with the daisy-wheel hammer solenoid. Material, dimension, solenoid-turns, and power-supply variations meant that the "flight time" of the hammer varied about .7 ms, from logic signal to when the hammer hit the ribbon and paper, and also the energy of impact varied and caused the ink density on the paper to be too light at one tolerance extreme, or wear out the plastic daisy-wheel from excessive force, at the other extreme. A way had to be found to measure the flight time and adjust a six-bit digital to analog converter to trim up solenoid current, as a closed-loop control.

A high-level engineer in the plant was called in to advise. The sensing could be by a vibration sensor on the printer frame, by some sort of optic sensing, or by a tiny magnet mounted on the hammer and sensed by a tiny coil on the back of the solenoid. The last of these three approaches was selected. The electrical connector on the carriage, which took wires to the hammer and daisy-wheel motor, had to be expanded by two wires, and contacts were added to the boards. A coil amplifier was added to the board. There were enough pins on the processor to feed six D/A lines to the DAC. This was a pretty big, bothersome rip-up but it didn't threaten the project schedule. Surely some marketing people were very bothered that the engineers couldn't control things better, but there were about eight factors that affected flight time and impact energy.

The hammer circuit was one of my jobs. The six-bit DAC could have been a commercial IC but it was cheaper to make a binary-weighted resistor network and use a logic buffer IC to drive the resistors. We were using "resistor packs" for some of our resistors, to improve accuracy and reduce board space, so I added to my allotment of resistor packs, designed the R pack, and submitted the design to the IBM plant that had these parts made. The packs came in a month or so and worked just right--much care had to be exercised to make it work without a rework cycle.

But the tolerance problems cascaded. Between the resistor tolerances and the varying voltage drops on the IC, and even at such a modest bit depth of six bits, I couldn't guarantee that the DAC output was "monotonic." It took two days to decide this, then I had to go to my manager and report this. He was not pleased! He did what I knew he would do, he sent me to the logic engineer, who thought it over and decided that it wouldn't matter at all. Maybe I should have checked with the logic designer first.

In the automatic sheet feeder, DC motors were selected by the MEs to do the feeding. These motors had brushes, and there was so much brush sparking that FCC EMI limits were exceeded. I knew the most about radio frequency among our group, and I designed a little PC board to solder on the motor pins to filter the noise. There were two dual-winding ferrite beads and three capacitors. The cost of these filters turned out to be higher than people wanted. The solution was found by John O. in the EMC lab. He had noted a new commercial part from AMP, Inc. It was a little, three-leaded part with integrated ferrite and capacitor. He personally ordered some, tried it as a substitute for my filter board, and found it to work. The economics favored the AMP part. MEs designed a copper cup that this part was soldered into, and the cup fit on the motor. It turned out to be smaller and cheaper, and it filtered better. This was so significant that John got a corporate award!

During the middle of the circuit designing, I recognized a serious, potential problem. I had heard about a failure in an IBM grocery-store bar-code-scanning point-of-sale (POS) terminal. (IBM was the first vendor for these products, back in the 1980s.) The motherboard of this product used little, standard, tantalum capacitors, which must be inserted plus to plus. One particular motherboard had one cap backwards. It didn't fail for weeks, then it shorted and actually caught the motherboard on fire, a smoldering, smoky, stinky fire. This was in a grocery store, and it was a major embarrassment to IBM and surely caused some IBM customers to wonder about IBM product reliability. This was a multimillion-dollar threat to IBM income, and it could have caused problems with UL certifications.

IBM engineers rapidly decided that the cap had to be redesigned to make the plus pin of the cap larger diameter, and the motherboard holes different sizes. This would prevent the cap from being inserted backwards. In all IBM products before, various things had happened to prevent or mask this problem, and the grocery scanner was merely the one that caused a fire and got the notice of the press. I do not know how many hundreds of thousands of dollars were spent inspecting fielded motherboards for problems and replacing motherboards, and how many product lines had to be considered. But an IBM safety engineer wrote a report about it and the solution. I was the one engineer in the printer group who saw this and ordered the report. (I had to mail-order the report from an IBM source, this was before Internet.) Our printer was using the new cap, so there was not a fire danger.

But my hammer-driver circuit put out 2.5 amps into the hammer, which had seven ohms of wire resistance. If the processor failed, or if my drive circuit failed, the hammer could be driven full-time, not just 15% of the time, and the poor solenoid would overheat in seven minutes to where it would smoke. I tried it with an old hammer sealed in a cardboard box, and it was a stinking mess. I knew from the capacitor report that the consequences could be enormous. Alone of all the motors and electromechanical devices in the printer, the hammer was a potential fire risk. I was not a state-licensed, professional engineer, but I knew something had to be done.

It happened that another engineering change gave a place to put a fix. The other change was that the hammer driver was putting a big, pulsed load on the power supply, and the supply was sagging whenever the hammer fired. The solution by the supply group was to put an inductor in the supply for just my hammer feed, and a big cap on my circuit. But this would require a rip-up in the supply wiring, connectors, and motherboard. My alternative was to use a big cap on my circuit, indeed, but limit current coming from the supply with a little transistor circuit. This was cooking just fine when I received the report about the grocery scanner fire. I saw that if I added a fuse to my circuit, it would give adequate protection. And I added the fuse between two ten-watt resistors that were in my little limiter circuit, to where a hammer-current fault would be heating the resistors, heating the fuse, and aiding the fuse to blow.

I needed to prototype this arrangement to see if the hammer would smoke before the fuse blew. I had prototyping materials to rapidly simulate the setup. I set it up outside in case it caused a fire or smoke. I turned on the supply with 100% drive on the hammer and noted the time. By the time the fuse blew, in four minutes, the hammer was really hot (hot enough to cause the insulation to fail) but it was not very stinky. Even though this was a "typical" situation, not a worst case, I figured that it was never going to cause a customer to be alarmed. If a printer were to fail in the field, the customer would probably notice that the hammer was stuck in the "out" position, breaking spokes off the plastic wheel and making a racket, and she would shut down the printer and call service. In fact, I never heard about one single incident.

I wrote a brief technical report about this and filed it away. If there ever was a printer fire or customer complaint about a stuck hammer, I could pull out my report that showed I had exercised caution. I did not highlight this very much to my manager or the safety department. I drew attention to it only to justify the parts cost of the fuse. I wonder if IBM should have given me an award for preventing a problem.

One last note about this unusual experience. The ten-watt resistors that heated the fuse were large, ceramic-housed parts that mounted tight to the fiberglass board. During a fault, and before the fuse blew, they got so hot that the fiberglass was charring and stinking. There was a cheap solution. It was to extend copper on the two-sided board so that there was solid, 1.5 mil copper below the resistors. This would help dissipate power and lessen charring. I shepherded this measure all the way through the production-level layout of the PC board.

Yet another tolerance problem came up with the "reflective opto-electronic" sensor that sensed the end of the inked ribbon. The part was a standard, reflective-style, LED-phototransistor sensor that worked at a .15" distance from the ribbon. When black ribbon was present, there wasn't much infrared light reflected back into the phototransistor. But there was a clear leader at the end of the ribbon, and there was a shiny, nickel-plated metal plate that reflected lots of IR into the phototransistor. So it was a standard sensor setup, and there was a comparator on the PCB to discriminate between black ribbon and clear leader.

I decided that a worst-case analysis was needed to set the best threshold voltage for the sensor's comparator. There was a terrific number of variables. There was a wide tolerance on phototransistor current with 100% reflectivity, so that the sensor didn't have to be selected for sensitivity at the factory. Then there were reductions that could happen due to distance not being .15", tilt of the sensor, the nickel plating not giving 100% reflection, aging of the LED, light coming in from other than the LED (like from room lighting), a little absorption in the clear leader, and maybe a little dust collection reducing the LED return. Then there were purely electrical tolerances such as offset voltage in the comparator, supply tolerance, and resistor drift with time and temperature. When I put reasonable tolerances on all these variables and set up a worst-case analysis, it showed there was inadequate margin, in the worst case. In fact, there was negative margin. I took this data to show the mechanical engineers. You can imagine they were displeased to hear an EE say "this isn't going to work in the worst case." One of the MEs may have looked over the numbers, but in the end I just chose a threshold that was for the middle of the data, and that worked in the long term.

However, this opto sensor gave trouble in the near term. A printer from early production was being used with a Displaywriter in a Texas state commission in downtown Austin. It was not sensing end-of-ribbon. That was my circuit, and I was assigned to go with a field engineer to look at the printer. He briefed me to not blab too much around the customer, standard IBM protocol. I was surprised that he parked in the loading dock of the eight-story building, instead of looking for a rare, empty parking spot. The customer was a resourceful man who seemed to know that this particular little, black part was the end-of-ribbon sensor. We tried loosening the little screw that held the sensor in place, to scoot the sensor closer or further back. There was a .15" slot to allow this adjustment. We found that the sensor had been pushed all the way forward during product assembly in the Austin plant. We played with the adjustment on this printer and left it working, with some margin. Then I told my manager what we found. I went along with two other Development engineers to the assembly line to check on things. The chief manufacturing engineer for this printer was not pleased that there was no line instruction to take care of this adjustment. The requirement never made it onto an assembly drawing. Furthermore, it had to be a best-effort, slide-it-to-the-middle-before-tightening-the-screw adjustment, not a thing that is good to have in assembly. But I guess they took care of it, and I didn't get any more calls. I don't know if field engineers had to visit dozens or hundreds of other printers to make the adjustment.

There is a story from IBM history that is along these lines. It involved an optical sensor in a vacuum-column tape drive, which IBM patented about 1963. The setting was an IBM facility in the Northeast U.S. A number of these big tape drives was either under test or in production use in a mainframe computer. One evening, one of the drives had a fault. Someone pushed a reset button and it came back online. The next evening, the fault recurred. This continued for several nights. No one could tell if it was a hardware problem or some programming problem tied to the time of day. After some period of days, the problem was found. There were windows in the computer room. Second shift was coming to work, and auto headlights from a particular car were beaming through the window and triggering an optical sensor. When the workers covered up the problem window, there were no more problems.

ESD Crisis With the Selectric Printer

The Selectric printer option for Displaywriter was designed by another group. But the later EMI work for both printers was done by me, as far as design work went. There are several stories that can go with this, but the one I include here is about static discharge and the Selectric printer.

Static discharge is called ESD, electrostatic discharge. It is where you build up a charge through your shoes from nylon and other carpet fibers, on dry days, then you get a nasty shock when you touch a metal door frame or a steel file cabinet. Or you might touch metal on your electronic office equipment or PC, and that can cause a momentary glitch in the electronics. ESD can be a show-stopper for any electronic product, even mainframe computers. It must be tested for early, in case product changes are needed, and it has to be tested for as a product design is firmed up. It is the responsibility of managers to schedule testing, and ESD is much feared by managers because the ways to fix it are arcane. (I could talk about why this is, but that would make this write-up too long.)

The Selectric printer was failing the ESD test, as most products do, early in design. There was a failure randomly, but after maybe 1000 discharges, where the product really needs to be reliable to 20,000 discharges. But a quick solution was not found.

I had a feeling that the ESD susceptibility was about the operating system that the processor was running. The ESD effect is a submicrosecond phenomenon, since sparks happen in the nanosecond regime. Furthermore, the body capacitance (simulated in the tester device) is only 150 picofarad, but the voltage can be up to 15,000 volts, causing a short current pulse up to eight amps. This current never gets onto the processor pins, but enough field couples to the processor to cause a data or address or interrupt transient.

My suspicion about a processor transient was not something that could be looked for using a logic analyzer. You couldn't hook any instruments to your product under test, because every wire added acts as an antenna, feeding spark energy directly to processor or memory pins and completely camouflaging what you are trying to measure. So ESD work is really done in the dark. You can't be recording your product function, and you can't see where the spark energy is flowing in the product. It is very challenging work. Only one in 500 design EEs does this work. It requires hope, patience, and knowledge of radio frequencies. But it usually doesn't pay anything extra.

I had a new idea. It was to design a custom, compact, logic-waveform recorder that could fit between the boards in the printer. It would record eight-bit data, 18 address lines, and one channel for the spark, the spark being received by a two-inch wire sticking a little outside the card cage. The recorder would record into static RAM at each clock cycle (about 4 MHz), for a depth of about 900 samples after the spark, and 124 samples before. Though we couldn't attach a big logic analyzer to the product during sparking, we could use this little recorder to record what the operating system was doing before and after the spark. After a product hang due to a spark, just leave product power on, stop the sparking, attach a real logic analyzer to the custom recorder, and read out the recorder's data to the logic analyzer and check out whether the processor hang could be blamed on anything that had been recorded. That was my plan.

I had a hope that a little, tacked-on recorder would not itself be susceptible to ESD applied to the outside of the product, and that it wouldn't substantially enhance the processor susceptibility. It turned out that these hunches were correct. Here is how the story played out. This is an example of how engineering is often not by the book.

I needed a little, custom logic waveform recorder. It only needed 13 small ICs, and the design was pretty simple. But there wasn't three weeks to go have one made. The solution lay in the fact that I specialized in stocking prototyping materials. I had supplies to build up a custom board in three days. It was all hand wiring, and there were 300 connections! They all had to be reliable. But the supplies I had were up to this challenge. I got my manager's approval, and I got the board made. It seemed to work on the bench, then it was time to wire up the dozens of wires from the processor and memories to this little recorder. That was a lot of work, and I didn't have a technician to do it.

Once wired into the printer, I tested the board to see if it was recording real address and data. That seemed to be OK, as judged by a logic analyzer. All the lights were green, and I went for the real test, with the sparker on. I was able to get a recording of a product hang, with the spark 128 samples into the recording. I stopped the spark and brought the logic analyzer close. Carefully grounding the product and analyzer before attaching any of the 28 logic signals, I got the recording transferred into the analyzer. Four days of hard work was about to pay off or be found to not matter.

There was a distinct pattern to the post-spark recording. It looked like the operating system had been clobbered and the processor was in a tight loop of about 25 instructions. I interrupted the lunch break of a software writer to tell him I had a clue about the ESD problem. He dropped his sandwich and came to look. He knew how to interpret the analyzer display, and he wasn't bothered too much about the bizarre equipment that had generated the display. He brought out a ten-pound printout of the operating system and located the loop. He didn't say too much, but disappeared for an hour. From the pre-spark recording, he decided there was some sort of susceptible state of the OS. Maybe the processor was waiting for very long periods for interrupts from the mechanism, and maybe he added a sampling loop that only did an occasional check rather that a full-time check. Whatever he changed, he did a quick compile and EPROM program. He brought the new OS EPROM to the product and changed it out. Then we stood back and let the spark run. It hung up again but not for a long time, long enough that the product would pass the ESD test.

This was a dramatic success. Not only was I able to build a logic recorder that could help diagnose an ESD problem, I was correct in attacking just the right problem, the software writer was able to interpret the recording and do a quick fix, and there was no secondary ESD problem that was lurking just below the surface.

I reported to my manager how the software writer had a fix. That was such good news. Engineers were free to proceed with the final stages of the product design, and the official ESD and EMI tests continued to pass at an adequate level. The product shipped.

Junior Engineer Gets the Software Sequence Working

In 1973, the original floppy drive, using an 8" floppy disk, was intended for a big IBM word processor, a standalone product being designed at IBM Austin. The drive was designed and built at an IBM plant in Minnesota. A prototype was shipped to Austin. The Austin engineers on this part of the project, the manager Jim and junior engineer Jack, had some exercising hardware hooked up to the prototype drive to see that it worked and verify that various software commands would cause reads, writes, and track stepping. They were trying to get it working for several days, without success. They would get out the product spec and their exercising plans and see if they could spot any incompatibility. They were using an oscilloscope to look at individual signals (there were no logic waveform recorders available, yet). There was, of course, some amount of doubt that the prototype drive was functional. There was just one prototype in Austin. They didn't want to take the drive all the way back to Minnesota to verify it.

I was working on some other part of the product across the room. It was about lunch time. Jack was working and working on the floppy drive. I heard him exclaim about something. He had found a way to get some little part of the drive to work, using the many switches on his exerciser and the basic lab equipment they were using. In short order, he had a significant part of the drive working, and within days it was all working. The junior engineer and manager had both been working on this major problem, and the junior engineer was the one who got it working.

After some time, I was assigned to learn about the parts of the floppy drive in case it developed problems later. To do this, I asked manager Jim for the IBM top-secret technical spec. He checked it out to me. I found a little sentence that needed checking on. The sentence said the orientation of the drive must be with the floppy axis horizontal. Well, in the Austin product, the drive was mounted low and tipped back 15 degrees to let the seated operator see better to insert the floppy. That placed the floppy with axis horizontal, but there was some doubt in my mind whether the drive could be tipped. I brought this up to the manager. He was alarmed by the sentence, and he quickly telephoned Minnesota to see if tipping the drive was OK. It turned out fine.

Logic Design with Programmable Logic

This section, like the others, throws out a lot of terms without being long enough to explain the terms. But the intent is not to give understanding but to give a feel for everyday activities of an electrical engineer.

In 2013, I am using an Atmel product, ATF1504AS, to do logic and state machines for home projects. The latest project is a fan controller for a seven-hard drive file server. The logic does a clock divide-down from 50kHz and a MUX of seven fan tachometers so you can hear the fan speeds. The ATF1504AS for this project is a 44-pin device. All input-output pins but one are in use.

This Atmel chip is what they call a complex programmable logic device, CPLD. It has 64 flip flops and propagation delay like 10 ns. I use both 44-pin devices and 84-pin. This is so many pins that it is a challenge to put it on homemade PC boards. Either the pins are so tiny on the 44-pin package or you have to drill 84 pins in the board for a PLCC socket. 100MHz clocking makes me want to decouple 5V to ground at all eight Vcc pins, and just that number of SMD caps blocks a lot of traces to the I/O pins. Output-pin current is like 35 mA; three paralleled pins handle PCI bus.

A good thing about this part is that it is in-system reprogrammable by a JTAG port, from the parallel port of a MS Windows PC, though only half the PCs I try are able to handle both WinCUPL and ProChip. ProChip does a poor job of "keeping" pins as you are trying to do minor changes; a few pins get swapped around, which requires rewiring on the PCB. WinCUPL, a crusty old pin-spec and equation compiler, has cryptic, marginally helpful error messages. $100 gets you the 44-pin TQFP evaluation board and parallel port-to-JTAG cable, and WinCUPL and ProChip. These chips are $6 to $9. They have up to three global clocks. Synchronous clocking to more than four flip flops, as for a state machine, has given me trouble, as if there is clock skew despite the global clock, so I concentrate on master-slave state machines that tolerate slow or ringing clocks. AND-OR gating works well with this part, as is true with all PLD. More than five-way ORing incurs additional delay.

This chip does a fine job of fast address generation for SRAM when using linear feedback shift register, as depicted on the web site for New Wave Instruments.

The expensive (multiple $1000) software packages such as Verilog probably do a superior job for this chip but a home hobbyist doesn't want to spend that much. But on the other hand, I have read that all such programs are buggy. The normal-sized, 18-pin GAL devices are cheaper and easier to solder, but you have to buy $500 programmer. So any way you turn for programmable logic, there are drawbacks. 84-pin socketed CPLD would do great with a home-designed PCB that handles decoupling and makes I/O available as .1" pins, but I don't have the CAD program that generates the files.

Atmel's PLDs are not the main way they make income, so they don't put a lot of maintenance into WinCUPL and ProChip.

Logic design is a college-level course for gates and DeMorgan, and the second-semester course handles sequential and state machines. These courses haven't changed too much in forty years, there is no quick way to become a beginning logic designer. High schoolers with enough interest and a mentor can learn the material. Two new things in forty years are one-hot state machines and LFSR.

The most ambitious logic project I have planned is to give the logic and memory to use a TI pipelined ADC, 60 Msamples/s, 8 bit, $6. This would make a great digital sampling oscilloscope for a parts cost of $50. But there has to be some clock adjustability for accepting ADC data into a buffer on the way to 10 ns SRAM, and the adjustment has to be at two different clock pins. The adjustment can be by twisted-pair delay lines with LVDS. By the time the circuits are all on a schematic, it is a pretty daunting surface-mount job. I have one board of two that are needed to do it, and a functioning CPLD (60MHz state machine with LFSR addressing and control state machine function at least at low speed) is soldered and programmed on the one board, but one little error renders the project useless, and I haven't spent $250 on a commercial DSO to let me debug. $650 buys a commercial DSO that does the function, with all the user interface done, so I keep letting other projects delay the homemade DSO.

A straightforward project would be a 250ksamples/s, 16-bit DSO for which I have the ADC and memory. These could be coupled to an Arduino for data transmission to a PC by USB, then any programming language can do data display and Fourier transform for spectrum analysis.

A Difference Between Scientists and Engineers

College-educated scientists, such as biologists and physicists, usually have to get a master's degree to be employed "in their field." Engineers typically get a first technical job with a bachelor's degree. About a quarter of engineers go on eventually to get a master's degree. New MS-HS teachers in technical fields generally have a bachelor's degree in science, then add the "education courses" to learn how to teach. (Used to be that teachers got an education degree, and during the four undergrad years took enough science courses to be somewhat competent. But since 1985, the emphasis is being a scientist, then add the education courses.)

Scientists have more trouble with job volatility. When a business is having a hard time, the scientists tend to be laid off before the engineers, since the engineers can limp along without scientists to make new products and keep the revenue stream up. But since 1998, with the Internet improving communications, it is increasingly the case that engineers with specific job skills get contracted to do a project, then they have to find a new project. But there are some engineering fields that have more job stability, such as power engineering (electrical engineering in utility companies).

It is common for both engineers and scientists to migrate from technology jobs to management, or away from tech jobs to other jobs where the technical training gives an advantage.

Doctorate-level scientists often teach and research in universities. A young person seeking this route needs to get acquainted with some middle-age professors and see what the real academic environment is like. Check out "publish or perish." There is a tension between being a star researcher and serving the needs of the undergrad students. Few professors are good teachers, they haven't had teacher training. Tech-area professors often have to seek grants to fund research projects. Check out "grant writing." Prominent professors have been successful in establishing an empire. Real science in universities is plagued by egos and orthodoxy, it is not the pursuit of the scientific method.