The motor controller worked. Acceleration, constant speed, deceleration. The firmware ramp looked clean on the scope. Everything my test plan asked for, the board delivered.
I picked up the thermal camera.
On the TVS sitting on the motor power input, I watched the temperature spike from around 30°C to over 150°C in a fraction of a second, every time the motor decelerated. The spike was invisible in normal operation. It lasted maybe 50 milliseconds. By the time the board was quiet again, the surface had already cooled back toward ambient. No oscilloscope trace, no logic analyzer capture, no multimeter reading would have flagged it.
This was a motor controller for an agricultural accessory on an industrial vehicle. Standard H-bridge, MOSFETs sized properly, a flyback diode on each switch. I had written a deceleration ramp for the firmware, which is the right approach: you do not want a hard stop on a mechanical system with any real inertia.
What the deceleration ramp also does is take all the kinetic energy stored in the motor’s spinning mass and the inductance of the windings and push it somewhere. In this design, “somewhere” was the TVS on the power rail. The component was doing exactly what it was designed to do: clamp the voltage spike and absorb the energy. But it was absorbing it as heat, very quickly, in a package with limited thermal mass.
The TVS was not going to fail today. It was not going to fail this month. But run that motor through enough deceleration cycles and you are accelerating the aging of that component in ways that are very hard to predict without measuring the thermal stress directly.
Why this kind of thing fails late
The functional test for a motor controller is: does the motor spin up and spin down correctly? Yes. Does the firmware handle the ramp? Yes. Do the MOSFETs stay cool? Yes, I measured those. Does the protection circuitry activate? Yes, nothing trips.
You pass that test and send the board to qualification. Qualification runs a few hundred cycles over a few days. The TVS still does not fail. You ship.
Six months into field deployment, you start getting returns with no obvious failure mode. Or worse, the motor stops responding intermittently and the customer cannot reproduce it in the lab.
Without the thermal camera, I would have caught this. But much later, at a much more expensive stage of the project.
The fix
Short-term: change the firmware. Instead of decelerating by simply reducing the drive duty cycle (which leaves the energy with nowhere to go but the TVS), brake the motor actively. On an H-bridge this means activating the appropriate low-side or high-side MOSFETs to short the winding during deceleration. The motor’s own resistance dissipates the energy. The winding gets slightly warmer. The TVS stays cool.
This is not exotic. Most H-bridge driver ICs have a braking mode. Shorting the high-side or low-side switch pair (synchronous braking) is a well-documented technique. The firmware change was around 30 lines.
Longer term, there are hardware-side improvements worth considering. More bulk capacitance on the motor rail gives the back-EMF somewhere to go before the voltage climbs high enough to trigger the TVS at all. Upgrading the TVS from a 600W device to a 1500W device adds headroom, especially if the deceleration profile needs to stay aggressive. Both are real options, but the firmware fix addressed the root cause.
What the thermal camera is actually telling you
One thing that catches people the first time they use a thermal camera for electronics: the temperature reading at the surface of a component is the case temperature, not the junction temperature.
For a MOSFET or a diode, junction temperature is what matters for reliability and for comparing against datasheet limits. The case temperature from the camera is a starting point. You then look up the junction-to-case thermal resistance in the datasheet, apply it at the power dissipation you are running, and estimate the junction temperature. Then you add your derating margin.
For a TVS absorbing short transient spikes, the thermal calculation is more nuanced because the pulse duration affects how much the package thermal mass matters. But watching the surface temperature jump 120°C in 50 milliseconds is enough to know you have a problem worth digging into, well before you need to calculate anything.
What else a thermal camera catches
Motor controller TVS stress is one data point. I have used the same tool to catch decoupling capacitors doing all the work while their neighbors sat idle (a layout problem), regulators running hotter than their datasheets suggested under the real load profile, and solder joints heating unevenly in a way that predicted a cold joint long before the board left the lab.
A thermal camera starts at a few hundred dollars for a module that clips onto a phone, and climbs to tens of thousands for a high-resolution instrument with fast frame rates. For board-level diagnostics during prototyping, a mid-range unit in the 400 to 1200 dollar range handles most situations. Next to the cost of a board respin or a field recall, it is a straightforward investment.
If you want to prototype quickly, get the right tools. Thermal camera, logic analyzer, oscilloscope, multimeter, programmable load, climate chamber, ESD gun. Each one catches a different category of invisible problem.
And yes, the thermal images are genuinely pretty.