Calculating MOSFET Losses in H-Bridge Motor Drivers

Why Motor Driver Losses Matter

You've picked your MOSFETs, drawn up the H-bridge, and now the motor spins. Looks good, right? Not so fast. The difference between a motor driver that works on your bench and one that survives in real-world conditions often comes down to thermal design — and that starts with knowing exactly how much power each FET is burning.

Motor driver losses break down into two key categories: conduction losses (resistive heating when the FET is on) and switching losses (energy wasted during each on/off transition). Get these numbers wrong, and you'll either over-engineer your heatsink and waste precious board space, or under-spec it and watch your FETs thermal-throttle at the worst possible moment. Most engineers skip the detailed loss calculations early on and regret it later when they're debugging thermal runaway issues at 3 AM before a demo.

We'll break down the math, walk through a real example with actual numbers you might see in a brushed DC motor application, and show you how to get answers fast with our Motor Driver Power Dissipation calculator.

Conduction Loss: The Steady-State Tax

When a MOSFET is fully on, it acts like a tiny resistor — characterized by its $R_{DS(on)}$. This is the on-resistance, and while it's small (often just a few milliohms in modern power FETs), it's never zero. In a PWM-driven H-bridge, the FET isn't on 100% of the time, but for a fraction defined by the duty cycle $D$. The RMS current through the FET determines its conduction loss:

Here's something that trips people up constantly: $R_{DS(on)}$ gets worse with temperature. That nice low value in the datasheet? That's at 25°C. At 100°C, expect it to be 1.5× to 2× higher depending on the FET technology. Always design with the "hot" resistance, not the room-temperature spec. I've seen too many designs that looked great on paper at 25°C but turned into space heaters once they hit operating temperature.

The duty cycle term makes sense when you think about it — if you're only driving the motor at 50% duty cycle, the high-side FET is only conducting half the time on average. Lower duty cycle means lower average conduction loss. That's why conduction losses scale directly with how hard you're driving the motor.

Switching Loss: The Speed Tax

Every MOSFET transition from off to on (or back) involves a brief moment where both voltage and current are high. During this transition, the FET is in its linear region — neither fully on nor fully off. The energy lost per transition approximates to:

The problem is that rise and fall times depend on your gate drive circuit, PCB layout, and a bunch of other variables that are hard to nail down precisely. A practical estimation uses gate charge $Q_g$ directly instead. Our calculator uses a simplified but effective model:

This formula captures the key insight: switching loss scales linearly with switching frequency. Cranking up switching frequency to kill audible noise or reduce output ripple? Just remember that comes with a real thermal penalty. Double the frequency, double the switching losses. There's no free lunch.

Gate charge $Q_g$ is essentially a measure of how much charge you need to pump into the gate capacitance to switch the FET. Lower gate charge means faster switching and lower losses. This is why modern FETs advertise their low $Q_g$ values — it's a direct indicator of switching efficiency.

Worked Example: 24V, 10A Brushed DC Motor Driver

Let's break down losses for a typical scenario — something you might encounter driving a medium-power brushed DC motor in a robotics or industrial application:

Note that we're using the hot $R_{DS(on)}$ value here — 8 milliohms at 100°C. The datasheet probably shows something like 5 mΩ at 25°C, but we're being realistic about operating conditions. Conduction loss per FET:

That's 100 squared times 8 milliohms times 0.75 duty cycle. Half a watt doesn't sound like much, but remember we've got four FETs in a full H-bridge, and things add up fast.

Switching loss per FET:

At 20 kHz switching frequency, the switching losses are relatively modest compared to conduction losses. But watch what happens when we change that frequency later.

Total loss per FET: Total bridge loss (4 FETs):

So we're dissipating just under 3 watts across the entire bridge. In a typical H-bridge, you've got two high-side FETs and two low-side FETs, and at any given moment, one high-side and one low-side FET are conducting (depending on motor direction).

Estimated driver efficiency:

The motor power at 75% duty cycle with 24V and 10A is approximately 180W (assuming the motor back-EMF and resistive losses eat up the rest). So:

Not bad. But notice what happens if you quadruple switching frequency to 80 kHz to push PWM noise out of the audible range: switching losses jump to 0.48W per FET, total bridge loss climbs to about 4.3W, and you've added heat with zero motor performance benefit. Efficiency drops to around 97.7%. That extra watt and a half might not sound like much, but in a thermally constrained enclosure, it's the difference between reliable operation and thermal shutdown.

Design Implications

Quick practical takeaways that actually matter in real designs:

Conduction loss dominates at low switching frequencies. Running 10–20 kHz? Focus on low $R_{DS(on)}$ FETs. Spending an extra dollar on a FET with half the on-resistance will save you way more in thermal management costs. In our example, conduction losses were 5× higher than switching losses. Switching loss takes over at high frequencies. Above 50 kHz, gate charge $Q_g$ becomes the critical parameter. You can have the lowest $R_{DS(on)}$ in the world, but if your gate charge is high, you'll burn watts every time you switch. This is where those fancy GaN FETs start to shine — their low gate charge makes high-frequency operation practical. Duty cycle affects conduction, not switching. Switching losses depend on frequency and load current, period. Whether you're running 25% or 75% duty cycle, you're still switching at the same rate, so switching losses stay constant. Conduction losses, though, scale with duty cycle because the FET is on for a longer fraction of each cycle. Thermal derating is mandatory. Our example shows 0.72W per FET — manageable in theory, but tight in constrained spaces. If you're using an SOT-23 package with minimal copper, you're going to have problems. An SO-8 with exposed pad and decent copper pour? Much more reasonable. Always check the thermal resistance from junction to ambient for your specific package and PCB layout.

When the Numbers Get Uncomfortable

If bridge losses push junction temperature past safe limits (and most MOSFETs start getting unhappy above 125°C junction temperature), you've got four moves:

Lower $R_{DS(on)}$ — Pick a bigger FET with more silicon area, or parallel multiple FETs. Two FETs in parallel cut conduction losses in half, though you've doubled your switching losses and board area. Sometimes that trade makes sense. Lower $Q_g$ — Switch to a faster-switching FET with lower gate charge. Modern superjunction MOSFETs and GaN devices excel here. The downside is they're often more expensive and can be touchier about gate drive design. Lower $f_{sw}$ — Drop your switching frequency. You'll accept more ripple current in the motor or more audible noise, but thermal problems often disappear. Going from 40 kHz to 20 kHz cuts switching losses in half. Better thermal path — Use an exposed pad package, route to thicker copper planes, add a heatsink, or improve airflow. Sometimes the answer isn't a different FET, it's better mechanical design. A few square inches of 2oz copper can work wonders.

Try It Yourself

Plug your actual parameters into the Motor Driver Power Dissipation calculator. It's the fastest way to sanity-check your FET selection before committing to a layout. Iterate on switching frequency, FET selection, and duty cycle until your thermal budget makes sense. The calculator will show you exactly where your losses are coming from and help you make informed trade-offs. Way better than discovering you need a redesign after the first prototype run.