It never fails. After I test a product, observe susceptibility responses or noncompliant emissions and report my findings to the design team, panic and hysteria immediately erupt. Design engineers grab their "fix-it" kits and rush into the fray. Capacitors, inductors, resistors and ferrite beads are thrown into the mix (design). This reaction is understandable. Electromag-netic compatibility’s (EMC) importance increases as technology advances. One volt interference coupled onto today’s device is just not the same as one volt interference imposed on a vacuum tube device from yesterday. EMC awareness has also grown. Manufacturers, customers and consumers are bombarded with information from the media: Jet crashes blamed on equipment malfunction--experts unable to find reason for crash; unsubstantiated claims of cancer linked to cell phone radiation. Despite the engineer’s best intention for compliance, the design retaliates. It balloons in one direction and then another. The design is defiant to the very end, proving Murphy was a competent EMC engineer!

Traditional Design Engineer vs. EMC Design Engineer; Separate Problem-solving Approaches
Over the years, I have learned about the difference between the traditional design engineer and an EMC-competent design engineer. You may think they are one and the same, but they’re not. The difference is their approach to an EMC problem and the time it takes them to design the "fix".
Typically, the design engineer’s approach is to review the data, interpret the symptoms, and intellectually determine the "root cause". Then the traditional engineer installs filters here and there until finding the perfect component mix. The "fix" is then verified by repeating the test. This process is repeated as often as necessary until the design meets the objective, compliance.
Alternatively, an EMC-competent design engineer’s method is to review the data, interpret the symptoms, intellectually determine possible "root cause(s)," design a set of experiments to verify the hypothesis and repeat this procedure until all the variables have been discovered. Understanding the "whole" picture enables the EMC-competent engineer to provide a low cost-effective solution.

Avoiding the "Hocus-Pocus"EMC Test Event
Given the two different methods, one may believe the typical design engineer’s approach is acceptable. It appears to achieve the objective quicker and everyone knows the importance of meeting schedules.
However, we must keep in mind what I call the hocus-pocus EMC event. Adding a capacitor here, installing a bead there, leads to achieving compliance over the suspect frequency range. Full frequency testing shows the noncompliance event has moved down the block and has invited family. This process is repeated over and over. Eventually, one loses count and sight over the components that finally made compliance a reality.Testers/engineers do not have time to remove unnecessary components and retest. The product cost consequently sky rockets. So we, EMC engineers and technicians, must effectively assist (mentor) engineers on how to troubleshoot their designs. We can’t afford just to conduct the test, document our findings and make recommendations to the design team. We must actively support design engineers to ensure they follow a systematic approach for problem solving.

Three Trouble-Shooting Blocks For Finding Cost/Time Effective Solution
There are three major troubleshooting blocks for finding a cost/time effective solution: Analysis; background investigation; and corrective action.

Block 1:ANALYSIS
The basic analysis steps appear below.

1. Symptom Recognition/Redundancy
   (a) Test Setup: Could the test setup induce erroneous errors?
   Re-check the test setup. The support equipment’s signals and power measurements should be verified that they are within acceptable norms and/or standards. Since mistakes are inevitable, redundancy is critical for uncovering setup errors. It is always better to discover any mistake oneself and to correct it rather than have someone else find them.
   For example, during conducted immunity (susceptibility) sinewave injection testing, I ran across an interesting event. Every time I injected the sinewave interference, the device under test operation failed. I repeated the test over and over. The response repeated. I checked and re-checked my setup. Everything appeared in order. Line Impedance Stabilization Networks (Artificial Networks), decoupling capacitors and input/output lines were correct. Everything was laid out just as the test plan directed. I cheerfully reported my findings and waited. After reviewing the setup, my supervisor suggested I monitor the device under test power and inputs signals. I discovered the power supply itself was susceptible. Its output dropped as the interference levels were raised. I never thought to look at the supply or device’s input signals as I had used this same supply for other devices and never experienced a problem. Why, I reasoned, should this device change the supply’s operation? However, there was a difference. The device could not operate normally below five volts. I learned a valuable lesson: to monitor the device’s inputs and supply as well as its outputs.
   (b) Is the response or emanation the root cause or the symptom of the problem?
   Reference the conducted immunity sinewave injection example above. The symptom was the device’s abnormal operation and the "root cause" turned out to be its support equipment--the power supply. It is critical to identify device symptoms correctly from "root cause". Chasing the symptom is equivalent to a dog chasing its tail; it might be fun but you are not going anywhere.

2. Symptom Elaboration
   Is there a different test or another method you can perform to verify a device’s fault condition? For example, a radiated immunity test could be substituted for a conducted immunity bulk current injection test, depending on the symptom frequency range or vice versa. Similarly, the conducted emissions current probe method could be substituted for the radiated emissions, depending on the symptom frequency range. Different test methods provide a better understanding of the coupling mechanisms involved and provide clues to the type of fixes required.
   Does the failure mode change if you change the device’s loads from minimum to maximum and/or change the device’s operational parameters? Different configurations will indicate coupling mechanisms. Listen to the data.

3. List possible root causes
   Keep in mind the device’s block diagram. It will aid your understanding of the circuitry and how individual circuits interact. Use the block diagram to develop fault isolation experiments.

4. Fault Isolation Experiments
   Perform experiments in order to isolate and determine the root cause. I uncovered a radiated immunity problem while testing a prototype ignition module. After talking with the software and hardware design engineers, we opted to isolate the microprocessor’s inputs and created special microprocessor software, then programmed an EEPROM. The "special" microprocessor software disabled all interrupts and generated a fire signal every 50 milliseconds. There were three functional blocks left in the module: voltage regulator, reset circuitry and our special microprocessor. I conducted an RF sweep and recorded the results. Next, I enabled one interrupt and its associated input signal, then repeated the RF sweep and recorded the results. This process was repeated until all input signals and associated interrupts were enabled. We thereby quickly discovered the "root cause" and corrected the issue prior to production.

The next step is designing the fix.
1. Disregard design constraints, the objective is compliance.
2. Create a "green wire" or simulated hardware/software fix(es).
3. Re-conduct the test.
4. Verify the analysis conclusion.

Block 3:CORRECTIVE ACTION
Wait for the "new improved version", then retest. Compliant test results closes this item. Noncompliance observations during verification testing starts the process all over.

Summary
It sounds simple, but executing the ABCs within a design schedule is a challenge. It is always easier to say how to do it rather than just doing it, especially when the fires are raging.
When Program Managers and customers demand the solution overnight (at no additional cost), everyone is pulling their hair, gnashing their teeth and praying that the next experiment will show the root cause.

The best way to avoid noncompliant issues is early problem recognition.
• Assist the design engineers at design conception through prototypes and into production.
• Actively participate in design reviews.
• Review pcb layout and schematics prior to builds.

Top of Page

Back to The NARTE News page