This guide covers how to tell a real desync from its look-alikes, why it happens and what to change, in order: hardware first, then ESC settings, then Betaflight.
What a desync is
A brushless ESC on a quad has no sensor telling it where the rotor is. It works this out from the back EMF on the phase that is not being driven at the moment. When that voltage crosses the midpoint (the zero crossing), the ESC knows when to fire the next commutation step. The Bluejay wiki describes the cycle as commutation, then a demagnetisation period, then the zero crossing, and round again.
The demagnetisation period is the weak spot. Right after commutation, the inductive spike can look like a zero crossing that has already happened. The ESC has to wait it out. That wait gets longer the more current the motor draws, so it is longest on hard acceleration and under heavy load. If it runs over the real zero crossing, the ESC no longer knows when to commutate. It has lost sync with the motor, and the motor stalls.
Sometimes it recovers. Oscar describes ESCs falling back on blind commutation, estimating the rotor position without feedback in the hope of catching it again. If that works you get a short stutter and fly on. If it doesn't, the motor stops and you get the death roll.
Is it really a desync?
Oscar's rule of thumb is a good first filter:
- All four motors stop and the quad drops flat: that is not a desync. Look at failsafe or power loss.
- The quad rolls or spins violently towards one corner while the other motors keep spinning: that fits a desync.
The same picture can have other causes, and Oscar lists three: a motor that burns out under too much current, an ESC that cuts out because it overheated or hit temperature protection, and a sharp battery voltage drop that briefly takes power away from the ESC. One practical difference: after a desync the motor normally spins fine on the bench again, while a burned motor stays damaged.
Blackbox gives the clearest answer
If you log, open the log in Blackbox Explorer and look at the motor outputs around the crash. When one motor stalls, it stops producing thrust, Betaflight asks it for more and more, and that motor's command shoots to 100% while the quad still falls towards it. That spike is the signature Oscar points to. Without a log, step through the DVR frame by frame. The corner that drops first tells you which motor to look at.
If the ESCs run firmware with Extended DShot Telemetry v2.0, the ESC can report it directly. The Betaflight RPM filtering guide says EDT 2.0 adds status data that signals demag, desync and stall events, plus a maximum demag metric. The Bluejay wiki adds that this metric can be logged, which tells you whether a given motor and prop combination is close to the limit.
Check the hardware first
VoltaraRC's troubleshooting page calls a motor that stops or stutters mid-flight, tumbling the quad on a punch, typical desync behaviour. Its order of checks puts ESC settings last:
- Props and motor condition. A bent or chipped prop and a motor that took a hit are the easiest things to rule out.
- Motor bearings. Spin each motor by hand and compare. A rough one stands out.
- Phase wire solder joints and wiring. A cracked joint or a nicked wire can work for a while and then fail under vibration.
- Only then, reduce ramp-up by one step (more on that below).
If the problem keeps coming back on the same corner, swap that motor to another ESC output. VoltaraRC suggests this test for a motor that stutters on startup, and it works the same way here. If the fault follows the motor, suspect the motor (windings, bearing, debris near the magnets, the joints where the leads meet the windings). If it stays on the same output, check that output's joints, phase wires and connectors before you touch any settings.
More checks from SpeedyBee's desync page:
- Motor screws that are too long can touch the windings. That makes the motor behave erratically and can burn it out.
- KV that does not suit the cell count. SpeedyBee recommends 2300-2700KV motors for 4S and 1700-1900KV for 6S.
- PWM frequency set too high, which SpeedyBee links to stuttering and hot motors. Their approach is to start from the lowest value (usually 16 kHz), raise it step by step and feel the motors after every flight.
The capacitor and the load
Oscar treats a low-ESR capacitor on the ESC power input as a must. It reduces electrical noise, and he says noise is often the root of the problem. If the build has no capacitor, fit one before changing anything in software.
The load matters too. The Bluejay wiki explains that the demag time grows with current, so a hard-working motor is closer to the limit. It also notes that a motor spinning slower gives the demag period less chance to overrun the zero crossing, and suggests that a bigger prop pitch may help for that reason.
ESC settings that help
Change one setting at a time and test after each one. VoltaraRC says this too, and it is the only way to know what actually helped.
Bluejay (BLHeli_S ESCs)
The Bluejay wiki names three settings:
- RPM Power Protection (Rampup) limits power according to how fast the motor is spinning. Lowering it reduces power spikes on hard acceleration and can cut desyncs, at the cost of acceleration and top speed.
- Demag Compensation sets how aggressively power is cut during demagnetisation. On High, when Bluejay finds no demag event followed by a zero crossing in a commutation step, it cuts power until the next DShot frame arrives. That helps against desyncs and costs some performance.
- Motor Timing. According to the wiki, higher timing is less prone to desyncs and can give more power, at the cost of efficiency.
The Bluejay FAQ adds a less obvious one: dead time and PWM frequency. On ESCs with a dead time of 30 or more, frequent desyncs, stuttering and motors that don't spin up consistently on arm are a reason to try a lower PWM frequency.
BLHeli_32 and BLHeli_S
Oscar's suggestions for BLHeli: lower the Rampup Power (or Startup Power) to something like 0.125 on BLHeli_S or 12% on BLHeli_32, and set Demag Compensation to High. If the motors hesitate to start on arm after that, raise the rampup a little until they start smoothly. In his BLHeli_32 guide he recommends leaving Demag Compensation at its default and moving it to High only when desyncs appear, because High reduces acceleration a bit. For most setups he finds Medium enough. His short list for a desync on BLHeli_32: Demag on High, more Motor Timing, less Ramp-up Power.
AM32
For AM32, Oscar's advice on desyncs is mostly about timing. He uses 15° or Auto timing advance and warns against going much lower, except on unusually large 8-10" quads, because too little timing can cause desyncs. On recent firmware, check the Ramp rate field too. A reader under Oscar's AM32 guide found 0.1%/ms on a Seeker 3 after an update, and the quad flipped on throttle until he set it to 16. That's a single report, but it takes ten seconds to check.
VoltaraRC adds a useful distinction for timing in general: if the desync happens mainly at very high RPM, slightly more timing advance may help. If it happens mainly when the motor recovers from low RPM, less timing can sometimes make it more forgiving.
Betaflight settings that help
Dynamic Idle and motor idle
Desyncs also happen at the bottom of the throttle range, after you chop the throttle and the props slow down too far. The Betaflight RPM filtering guide says that Dynamic Idle, which uses RPM telemetry to keep idle from dropping too low, gives better protection against desync than conventional idle. It needs bidirectional DShot. If you don't have it, Oscar suggests raising the motor idle value from the default 5.5 to around 6.5 or 7, which he calls conservative for smaller quads.
VoltaraRC describes a related symptom: a slow bobble right after cutting the throttle, most common on small, powerful builds. Very fast deceleration pushes the motors into a low-RPM range where there is little thrust and sensorless tracking gets harder. Their suggestions are a softer ramp-down on the ESC, slightly higher idle if needed, and raising or disabling Dynamic Idle in Betaflight. Leave ramp-up alone if acceleration is already clean.
DShot rate, PID loop and CPU load
Use DShot. Bluejay supports nothing else. The Betaflight guide recommends DShot300 for 4k PID loops, DShot600 for 8k8k, and DShot150 with a 2k PID loop (8k2k) on older L ESCs (EFM8BB1), because their MCU is too slow to accept data reliably at faster rates.
Check the Motors tab with a battery connected. The Betaflight guide says the reported error percentage should not exceed 1%. Run tasks in the CLI too: the GYRO/PID line should match the configured loop rate within about 1%. In the comments under Oscar's desync article, two readers fixed desyncs by dropping from DShot600 and 8k to DShot300 and 4k. One of them, on an F722 board with BLHeli_32, saw peak CPU load above 100% in tasks and a few percent of RPM errors in the Motors tab, and both went away after the change. These are reports from individual builds, not a test, but an overloaded flight controller is worth ruling out.
Flying style
Oscar lists sudden speed changes among the main causes: aggressive moves and hard braking in freestyle, where the ESC may not adjust its commutation timing fast enough. Big punches also mean high current, and that is where the demag time is longest. If every other check has come back clean and the desync only shows up on one move, easing off that move while you test settings is a fair compromise.
A short checklist
- Confirm it is a desync: one corner drops, motor command at 100% in Blackbox.
- Props, bearings, phase joints, motor screws, capacitor.
- Swap the suspect motor to another output to see whether the fault follows the motor or the ESC.
- Check prop and KV against the cell count.
- ESC: rampup down one step, demag compensation to High (Bluejay, BLHeli), a little more timing if the desync happens at high RPM.
- Betaflight: Dynamic Idle or a slightly higher idle, the right DShot rate for the loop, error rate under 1% and a steady loop in
tasks.