The scan came back over the limit, the boards are already built, and someone is about to ask whether the layout has to change. Here is what you can fix a radiated emissions failure in firmware, what it costs to find out, and where firmware stops being enough.
Why the re-spin question gets asked before anyone has data
A board re-spin is the decisive-feeling answer. It is also the expensive one, and it usually gets proposed at the exact moment when nobody in the room can yet say which source is over the limit.
That is the moment to ask whether you can fix radiated emissions failure in firmware, because the answer decides what the next six weeks look like. What you have at that point is a plot with a few peaks on it and a lab bill accruing. What you do not have is attribution.
Firmware is the cheapest place to buy attribution, because you can change a clock, rebuild, and re-measure inside the same lab session. Layout changes cannot be evaluated that way. They have to be committed to first and measured weeks later.
So the useful question is not “firmware or re-spin.” It is “what can we learn, and possibly fix, in the next two days, before we commit to the thing that takes six weeks.”
Start with a written inventory of every clock in the system
Years ago we worked on the radiated emissions failure problem for a connected home-health hub, a cellular and Bluetooth device with a display. The first genuinely useful artifact on that program was a text file listing every clock in the product:
– PIC32 application processor, 80 MHz
– PIC24 secondary processor, 69 MHz
– Epson display controller, 90 MHz
– USB, 48 MHz
– I2C, 400 kHz
– UART, 115.2 kbps
That took an afternoon to assemble and nobody had it before. Two things fall out of it immediately.
The first is harmonic content. Every one of those is a square wave, and a square wave is not one frequency. An 80 MHz clock puts energy at 240 MHz, 400 MHz, 560 MHz and upward, with the higher harmonics falling off but not disappearing. When a peak shows up at a frequency that seems unrelated to anything in the design, it is often the ninth harmonic of something mundane.
The second is coincidence. Multiple buses configured at the same rate, which is the default because nobody had a reason to pick different numbers, put their energy in the same places at the same time. On that product the I2C buses had all been set to the same frequency simply because 400 kHz is what you type. Separating them cost nothing in system performance and removed a coherent addition.
Moving a clock relocates energy, it does not remove it
This is the part that gets oversold, so it is worth being plain about the mechanism.
Changing a clock frequency moves where the harmonics land. Spread spectrum modulation, where the oscillator is dithered so it averages the intended rate while the instantaneous frequency wanders across a band, does something different: it takes the same total energy and smears it, which lowers the peak at any single frequency. That matters because emissions limits are specified against a measurement bandwidth, so a peak spread across a wider band reads lower.
Neither one deletes energy. Both change where it sits relative to a limit line.
That distinction predicts when these levers work. If the failure is a narrow spike a few dB over in one band, moving or smearing it is a real fix. If the whole noise floor is elevated across a wide span, firmware is not going to save it, and the honest thing is to say so early rather than burn a week proving it.
There is a second cost worth watching. Spread spectrum lowers a peak by widening it, which is exactly what you do not want if a sensitive receiver is sitting nearby on the same board. On a product with a cellular radio, the clock you just smeared can land in a receive band and degrade sensitivity while your emissions plot improves. Both were in play on this program, and they pull in opposite directions.
What the cheap path costs, and what it buys
The way you converge on this is empirical. You cannot compute your way to the answer, because the radiating structure is the whole assembled product, board and enclosure and cables together, not the clock in isolation.
On that project the firmware was parameterized by clock rate and built at several settings, with pre-screen measurements taken at each: 40, 42, 48, 72 and 80 MHz, plus a variant on a different crystal, plus runs with and without a shield. The configuration that eventually fixed the radiated emissions failure sat near the middle of that range. That is a day or two of build-and-measure, not a redesign.
Put that against the alternative. A retest quote on that program, for one standard’s worth of re-running, came to just under $8,000, and that is only the lab invoice. It does not include the board revision, the fab and assembly lead time, or the slot you lose on the lab’s calendar, which on a busy quarter can be the longest pole of the three. A re-spin at that stage is measured in weeks, and the certification calendar does not care that your engineering was fast.
Geography helped. With EMC labs in Tempe and Mesa, an engineer can drive to the chamber, sit through the scan, change a build, and re-measure the same afternoon. When you are testing several configurations, that loop is the difference between converging in days and converging in weeks.
Where the firmware fix ran out
Here is the part most articles on this subject leave out.
On that program, the firmware changes did not prevent a re-spin. The board went through several revisions anyway: more layers, ground plane changes, added shielding, and a re-tuned antenna. Firmware bought margin and, more importantly, bought attribution. It told the team which sources mattered before anyone committed a layout change.
That is the accurate claim, and it is the useful one. Firmware is the fast lever, the cheap lever, and the diagnostic lever. It is sometimes the whole fix. On a product that is badly over, it is usually the thing that makes the eventual hardware change the right hardware change instead of a guess.
Anyone promising that a firmware setting will reliably rescue a radiated emissions failure is selling something. What is true is that skipping the firmware pass and going straight to layout means spending six weeks to learn what two days would have told you.
If you are inside this right now and your product just failed, our team can help you work through the clock inventory, the sweep, and the re-spin decision before you commit to the expensive path. Start here and tell us what the scan showed.
FAQ
Can a firmware change fix a radiated emissions failure?
Sometimes, and it depends on the shape of the failure. A narrow peak a few dB over the limit, traceable to a specific clock or bus, is often correctable by moving that clock, enabling spread spectrum on the oscillator, or separating buses that were configured at the same rate. A broadband elevation across a wide span usually is not a firmware problem. Either way the firmware pass is worth running first, because it is fast and it tells you which sources are responsible.
Do I need to re-spin the board, or can I fix radiated emissions in firmware?
You usually cannot answer that on day one, which is why the order of operations matters. Run the cheap firmware experiments first, not because they always work, but because they identify the dominant sources while the unit is still in the chamber. If a re-spin is still needed afterward, it is a targeted change rather than a guess, and you only pay for it once.
What causes a digital clock to show up as a radiated emissions failure?
Square waves carry substantial energy in their harmonics, so a clock at one frequency produces measurable content at three, five, seven times that frequency and beyond. A peak that appears unrelated to anything in the design is frequently a high harmonic of an ordinary system clock. Buses left at identical default rates make this worse by concentrating energy at the same frequencies.
How do you find which clock is causing an EMI failure?
Start by writing down every clock in the product, including the ones nobody thinks about such as display controllers, USB and peripheral buses. Then parameterize the firmware so clock rates can be changed and rebuilt quickly, and measure at several settings in the same lab session. The frequencies that move when a clock moves are attributable to that clock, which is information no amount of analysis will give you as reliably.
Our product just failed radiated emissions, and the launch date cannot move. Who can help?
Start with attribution, not a redesign. Inventory the clocks, build several firmware variants at different clock settings, and measure them back to back while you still have chamber time booked, because lab availability is often the constraint that actually moves a launch date. Embedded Engineering Solutions does EMC and EMI remediation on medical, industrial and connected products, frequently on hardware we did not design, and one conversation is usually enough to tell whether your failure is one that firmware can reach.
