The failure report usually arrives as a stack of plots: a limit line, a trace above it, and a frequency marked in red. To the person receiving it, an EMC failure can look random - one board passes, a nearly identical one does not. In practice it is not random. The same handful of causes account for most EMC failures we see, and knowing them before testing starts is worth far more than any fix applied after.
This article goes through the causes in the order they actually show up, with the fixes that work and the ones that waste a retest cycle.
What the test is actually checking
First, a frame of reference, because "failed EMC" can mean several different measurements. For a typical electronics product tested to the emissions part of standards like CISPR 32 / EN 55032, the two headline items are:
- Conducted emissions - noise the product pushes back onto the mains port, measured roughly from 150 kHz to 30 MHz.
- Radiated emissions - noise radiated into the space around the product, measured from 30 MHz upward (and at higher frequencies when the product's internal clocks go high enough to require it).
Depending on the standard, there are also immunity items - electrostatic discharge (ESD), electrical fast transients, surge, RF field immunity - where the product has to keep working or recover within defined criteria while disturbances are applied.
The product does not have to be silent. It has to stay under the limit line with margin. Most failures are therefore about noise that found a path out of the product, not about a product that is hopelessly noisy. That distinction matters because the fix is usually about the path, not a full redesign.
Cause 1: The power supply stage - the classic conducted emissions failure
For mains-powered products, the single most common conducted emissions source is the switching power stage: the SMPS or the external adapter. Switching converters are efficient, and they are also switching kilohertz-to-megahertz edges into the input rail. Without adequate input filtering - the common-mode choke, the X and Y capacitor arrangement - that noise walks straight down the mains cable and the conducted test shows it.
This is also where a familiar project scenario lands. A product is quoted and designed around one adapter, and shortly before testing it is swapped for a cheaper one with the same voltage and current rating. Nothing on paper says they differ. But the filtering inside the two adapters is not the same, and the conducted emissions plot suddenly has a peak sitting over the limit line. The adapter is part of the tested configuration, exactly like the PCB - swapping it after the quote without telling the laboratory is one of the most predictable ways to arrive at a FAIL.
What fixes it: an input filter stage that matches the converter's actual noise, or going back to the adapter that was originally specified. What wastes time: moving components around the board hoping the peak shifts - the source is the power stage, and it will still be there.
Cause 2: Ground and return paths - the classic radiated failure
High-frequency return currents want to flow back directly under the trace that carried them out. When a ground plane is split, when a trace crosses between two islands, or when a two-layer board leaves return currents to find their own way, that loop becomes a radiating antenna. On four-layer boards this is usually designed out; on cost-reduced two-layer boards it is the most common radiated emissions cause we see.
A related version: a board revision comes back from the fab with the ground plane pour reduced or re-shaped to make routing easier, and a product that passed radiated emissions on the previous revision now fails. Nothing "broke" - the return paths changed.
What fixes it: continuous return paths under signal and power routing, ground stitching across any unavoidable splits, and decoupling placed where the switching currents actually are. This is board work, not shielding work - wrapping the product in foil treats the symptom and the peak usually finds another gap.
Cause 3: Cables and connectors acting as antennas
An unshielded I/O cable, a long internal wire to a display or sensor, or a DC cable exiting the enclosure next to a noisy section of the board will happily carry common-mode current and radiate it. The cable does not need to be connected to anything noisy itself - it just needs to pick up the noise and be long relative to the problem frequency's wavelength.
This is also why a product can pass on the bench and fail in the chamber: the test configuration includes every cable and accessory in the shipping configuration, terminated the way the standard requires. If the sample arrives with a different cable than the production one - unshielded where shielded was quoted, or two meters where the market standard length differs - the radiated plot reflects that.
What fixes it: routing high-speed or noisy traces away from cable exit points, grounding cable shields properly at the connector (a shield drained through a thin pigtail often makes things worse, not better), and common-mode filtering at the port. A clamp-on ferrite on the offending cable is a legitimate diagnostic step - if the peak drops, you have confirmed the cable is the radiator - but as a production fix it has to be built into the BOM and re-verified, not left as a lab-only snap-on.
Cause 4: The enclosure - shielding that was never designed in
An unshielded plastic enclosure is transparent to RF. If the board inside radiates, the only things standing between the noise and the antenna are distance and luck. Shielding helps, but only when it is designed: a shield can with seams in the right places, conductive gaskets where the enclosure splits, apertures kept small relative to the wavelength, and display or speaker openings treated as RF apertures rather than afterthoughts.
ESD failures often trace here too. When a product passes emissions and fails the ESD immunity item, the discharge usually found a path through a seam, a connector, or an uninsulated accessible point and upset the electronics. The fix is in the enclosure design and the grounding of accessible metal - not in firmware robustness hacks.
Cause 5: Clock and oscillator layout
Crystal and clock traces routed long, routed near board edges, or without series termination turn the board's timing reference into a small transmitter - and radiated plots tend to show peaks at the clock frequency and its harmonics. The fix is layout-level: keep clock loops small, add series damping resistors where the edges allow it, and keep clock lines away from connectors and cable exits.
A second-source version of this catches people: the BOM is cost-reduced and the crystal is replaced with a different part with faster rise-time edges. Same frequency, noisier harmonics, and a product that was comfortably under the line is suddenly fighting a peak at a harmonic. Component substitutions on EMC-critical positions deserve a check before they ship.
When the "failure" is a configuration problem, not a design problem
Not every FAIL is an electronics problem. A recurring pattern: a product with several wireless modes - say Bluetooth plus a proprietary 2.4 GHz mode - gets quoted and tested on one mode, and the spurious emissions plot is run against a configuration that does not match how the product actually ships. Or the firmware tested was an older build with different duty-cycle behavior than the production build. The report then does not cover what is being sold, and the gap surfaces as a failure or a scope dispute later.
This is not an EMC design flaw - it is configuration drift between what was quoted, what was tested, and what ships. It is also the cheapest category to prevent: freeze the shipping configuration before formal testing and declare every wireless mode the product will use, not just the main one.
Which fixes work - and which waste a retest cycle
| Fix | Works when |
|---|---|
| Input filter changes on the power stage (choke, X/Y caps) | Conducted emissions failures - usually the highest-value fix for mains products |
| Ground / return path rework on the PCB | Radiated failures tracing to board loops and plane splits |
| Shielded cable or proper connector grounding | Peaks confirmed to ride on a specific I/O or DC cable |
| Clamp-on ferrite (into the production BOM, re-verified) | Common-mode cable radiation with enough margin once the ferrite is on |
| Enclosure shielding / gasket / seam redesign | Radiated failures and ESD discharge points tied to the housing |
| Copper tape everywhere, no analysis | Rarely - the peak moves to the next gap and the retest repeats |
| Changing the crystal frequency to move a harmonic | Almost never - the noise mechanism stays, the peak relocates |
| Firmware "robustness" changes for an ESD failure | Only after the discharge path itself is fixed; otherwise the upset just changes shape |
One more thing worth saying plainly: the goal of a fix is margin, not just a pass. A configuration that squeaks under the limit line on the test day has no room for production variation - a different crystal lot, a different adapter from a second supplier, a cable from a new vendor - and it will fail in someone else's compliance check later. Ask for the margin in the retest report and aim comfortably under the line.
If the failure has already happened
A FAIL is a localized diagnosis, not a verdict on the whole design. Most of the causes above map to a specific fix on a specific part of the product, and the retest that follows usually covers only the affected items - not the full project from zero. What makes the difference between one retest and three is whether the fix is based on the actual measurement data rather than a guess. The step-by-step of what to do after a failure notice is covered separately; the short version is: get the data, fix the path, re-verify before booking the retest.
If you are holding a failure report right now - or a pre-scan that is too close to the line for comfort - send over the failing item, the frequencies involved, the plots or data you received, and what has changed on the product since it was quoted.
We will tell you which of the causes above the data actually points to, what the realistic fix path looks like, and which retest scope it implies - before you commit to a fix that turns into three.