Why did one motor stop mid-flight?

The symptom

The aircraft is flying normally. Then, usually in the middle of a hard manoeuvre or a sharp throttle change, it simply drops — or snaps into a violent roll that you did not ask for. There is no warning, no beep, no gradual degradation.

And then, very often, it recovers on its own and flies home. You land, you look at it, and nothing is broken. All four props are on, all four motors spin, all four arms are straight. That is exactly what makes desync so unnerving: the aircraft has just demonstrated it can fall out of the sky, and it has left no evidence.

On a small quad, that is a scare. On a 5 kg platform, it is usually the end of the aircraft.

Check this in 60 seconds

Before you touch a setting, rule out the things that look like desync and are not.

1. Look at the aircraft, or the wreckage. Is a prop missing? Is a prop nut loose? A prop that departed produces the same violent snap-roll, but the aircraft never recovers — and the prop is not there.
2. Wiggle every motor wire and every bullet connector, hard, with the battery out. An intermittent solder joint or a half-seated bullet gives you an identical mid-air motor cut, and it is triggered by vibration rather than by throttle.
3. Spin all four motors by hand. Gritty, notchy or stiff? That is a bearing, and bearings fail progressively, not suddenly.
4. Note when it happened. Desync is provoked by rapid throttle change and hard manoeuvres. If your cut happened during a steady cruise with no stick input, desync is a poor explanation and you should be looking at wiring.

If the aircraft is mechanically intact, the wiring is solid, and the cut happened on a fast throttle transient — you are in the right article.

What desync actually is

This is the part worth getting right, because almost every explanation you will read online stops at "the ESC lost sync" and leaves it there, as if that were an answer.

A brushless ESC does not know where the rotor is. There is no encoder, no hall sensor, nothing measuring shaft angle. The ESC drives two of the motor's three phases at any moment and leaves the third floating — and it watches the voltage on that floating phase. The spinning magnets induce a voltage in that undriven winding: the back-EMF. From the shape of that signal, principally the moment it crosses the midpoint, the ESC infers where the rotor is right now, predicts where it will be shortly, and decides when to switch to the next commutation step.

So the ESC is not measuring rotor position. It is estimating it, and it commutates on that estimate. The whole thing is a control loop running on inference.

Desync is that estimate going wrong. The ESC energises the next phase pair at the wrong moment relative to where the rotor actually is. When that happens, the torque the motor produces collapses — and if the error is large enough, the torque reverses, actively braking the rotor it was supposed to be driving. The motor stalls, or freewheels down. The ESC, now receiving a back-EMF signal it cannot make sense of, typically gives up and attempts a restart from scratch, which takes a substantial fraction of a second on a large motor.

For that fraction of a second, your aircraft has three motors.

What breaks the estimate

• Very fast throttle changes. The rotor accelerates or decelerates faster than the ESC's timing loop expects, and the estimate runs ahead of or behind reality. This is why the classic desync happens on a punch-out or on a hard throttle chop.
• High rotor inertia. Big props and heavy motor bells store a great deal of angular momentum. Commanded RPM and actual RPM diverge, because the rotor simply cannot follow the command, and the ESC's model of the motor is wrong for exactly as long as that gap persists.
• Aggressive motor timing. Timing advance is the ESC firing the next step slightly before the back-EMF says to. More advance buys efficiency and top-end RPM; it also shrinks the margin for error in the estimate.
• A weak or noisy back-EMF signal. Long or badly-routed motor wires, a marginal ESC, electrical noise from the rest of the aircraft.
• Low RPM. Back-EMF is proportional to speed. Near idle it is small, so the signal-to-noise ratio is at its worst exactly where you spend a lot of your descents.

Why heavy builds are the problem case

Look at that list again and notice that the top two items describe a heavy quad by definition. A 5 kg platform swinging large, high-inertia props is the single most desync-prone configuration there is — the rotors are heavy, they cannot follow a throttle command quickly, and the divergence between commanded and actual RPM that provokes desync is a permanent feature of the airframe rather than an occasional event.

And a heavy aircraft has no margin. A 250 g racer that loses a motor for 300 ms falls a few centimetres, catches itself, and carries on. A 5 kg aircraft under-thrusted by 25 % for 300 ms, while yawing hard because the reactive torque is now unbalanced, is in an attitude it will not fly out of. On a heavy build, desync is not a nuisance. It is the crash.

The causes, ranked

1. ESC firmware. This is the first thing to change and the most likely fix. Stock BLHeli_S does expose demag compensation and motor timing, so it is not helpless — but it gives you no RPM telemetry and limited control over PWM frequency and damping, which is exactly what a heavy, high-inertia build needs most. Bluejay (which runs on BLHeli_S hardware) adds bidirectional DShot RPM telemetry and selectable PWM frequency; AM32 is a separate, more capable codebase on supported ESCs. If you are flying a heavy build on stock BLHeli_S, that is where to start — and note the sting in the tail: the definitive diagnostic below needs bidirectional DShot, and stock BLHeli_S cannot do it. The readers most likely to have this fault are the ones who cannot yet run the test that proves it. Reflashing is the first step for both reasons.

2. Motor timing set too aggressively. Timing advance trades sync margin for top-end performance. On a heavy, high-inertia build you do not need the top end and you very much need the margin. Lower timing is the conservative choice here. Exact values and menu names differ between firmwares, so read your firmware's own documentation rather than a number you found in a forum thread — a setting copied from a 5-inch racer is how people get here in the first place.

3. Demag compensation set too low. Demagnetisation compensation is the ESC's defence against precisely this failure: it detects the conditions where the back-EMF estimate is going bad — typically hard load transients — and backs off the drive to recover sync rather than pressing on and stalling. Raising it costs a little efficiency and top-end power. On a heavy lifter that is a trade you should take without hesitation.

4. Idle RPM too low. Back-EMF is weakest at low RPM, so the region just above idle is where the ESC's estimate is least reliable. Dynamic idle (which holds a minimum RPM rather than a minimum throttle value) or simply a higher idle keeps the motors out of that region. This also helps prop wash recovery, so you are not paying much for it.

5. Wiring and the ESC itself. Long, unshielded, or badly-routed motor wires degrade the back-EMF signal. And an ESC that is genuinely failing will desync repeatedly, on the same arm, under conditions the other three shrug off. That pattern — same corner, every time — is not a tuning problem. Replace it.

Desync, or something else?

What you see	Almost certainly
Snap roll, no recovery, prop missing from the wreckage	Prop came off. Not desync
Intermittent cuts, no throttle correlation, triggered by rough air	Broken solder joint or bullet connector
Progressive: rough, then rougher, then it fails	Bearing. Desync is instantaneous
Repeats on the same arm, every flight	Dying ESC. Not a tune
Cut on a punch or a hard chop, then it recovers and flies home	Desync

That last row is the signature. Recovery is the tell. A mechanical failure does not undo itself.

The definitive diagnostic

Everything above is inference. Here is proof.

Enable bidirectional DShot and log RPM. That gives the flight controller the actual measured RPM of each motor, fed back from the ESC, and Betaflight will write it into the Blackbox log alongside the commanded motor output.

Now go and look at a log from a flight where it happened. A desync is unmistakable: one motor's measured RPM collapses to zero or to garbage, while the flight controller's commanded output for that motor stays high — or climbs, as the FC frantically demands more thrust from a corner that has stopped producing any. That gap, between what was asked for and what actually happened, is the whole fault in one picture.

Nothing else in a log looks like that. A broken wire produces the same collapse but with no throttle correlation. A stiff bearing produces a small RPM deficit, not a collapse. Only desync gives you a full-command, zero-RPM motor that then spins back up on its own.

If you fly a heavy build and you have not enabled bidirectional DShot, do it. It costs nothing, it makes RPM filtering work, and it turns this failure from a mystery into a measurement.

How to know you actually fixed it

Not "it has not happened for a while." Desync is provoked, so provoke it.

• Fly the manoeuvre that caused it, deliberately, at altitude, over something soft. Punch-outs, hard throttle chops, aggressive flips — whatever the log says was happening when it cut.
• Do it with RPM logging on, and then read the log. Measured RPM should track commanded output through the whole transient, with no dropouts.
• Do it on a full battery and a nearly-flat one. Sag changes the picture.
• Then repeat on a different day, in different air. A fault you have made rarer rather than fixed will find you eventually.

Honestly

Desync is one of the few failures in this hobby that can be genuinely, straightforwardly dangerous, and it is one of the few where the aircraft does not tell you anything afterwards. It hides. Firmware and settings will get you a long way — Bluejay or AM32, conservative timing, real demag compensation, a sane idle — but on a heavy, high-inertia airframe you are managing a risk rather than eliminating one.

So instrument it. Bidirectional DShot and an RPM log turn the whole thing from an argument into a fact, and that is worth more than any setting on this page.