Your ESC protocol determines how fast motor commands travel from the flight controller to the ESC — and whether those commands arrive intact. Choose wrong, and you get desyncs on punch-outs, mid-throttle oscillations that no PID tune can fix, or a motor that twitches instead of spinning. Here’s how each protocol works and when to use which.
How ESC Protocols Actually Work
Analog protocols (PWM, OneShot125, OneShot42, Multishot) encode throttle values as pulse widths. The flight controller sends a voltage pulse, and the ESC measures how long the pulse stays high. A 1000µs pulse means 0% throttle. A 2000µs pulse means 100% throttle. The ESC reads the rising edge, starts a timer, and converts pulse duration to motor output.
The problem: analog signals degrade with every centimeter of wire. Electrical noise from the motors, ESC switching transients, and ground loops all distort the pulse width. A Multishot pulse at 25µs for 100% throttle might arrive at the ESC measuring 24µs or 26µs — a 4% throttle error from noise alone.
Digital protocols (DShot150, DShot300, DShot600, DShot1200, ProShot) send throttle values as binary numbers with a CRC checksum. The ESC receives a 16-bit frame: 11 bits for throttle (0-2047), 1 bit for telemetry request, and 4 bits for CRC. If the checksum doesn’t match, the ESC discards the frame and holds the last valid throttle value.
This is the fundamental advantage of digital protocols: a corrupted frame is rejected, not interpreted as the wrong throttle. An analog protocol mistakes noise for a throttle change. DShot knows it received garbage and ignores it.
Protocol Comparison Table
| Protocol | Type | Max Update Rate | Frame Size | Error Detection | Latency (end-to-end) | Bidirectional Support |
|---|---|---|---|---|---|---|
| PWM | Analog | 50Hz (standard) / 490Hz (OneShot) | N/A (pulse) | None | 2-20ms | No |
| OneShot125 | Analog | 125Hz-250Hz | N/A (pulse) | None | 1-8ms | No |
| OneShot42 | Analog | 420Hz | N/A (pulse) | None | 0.5-2.4ms | No |
| Multishot | Analog | Up to 32kHz (theoretical) | N/A (pulse) | None | 0.25-1ms | No |
| DShot150 | Digital | 150Hz (37.5kHz effective) | 16 bit + CRC | 4-bit CRC | ~6.7ms | Yes (Bidirectional DShot) |
| DShot300 | Digital | 300Hz (75kHz effective) | 16 bit + CRC | 4-bit CRC | ~3.3ms | Yes |
| DShot600 | Digital | 600Hz (150kHz effective) | 16 bit + CRC | 4-bit CRC | ~1.67ms | Yes |
| DShot1200 | Digital | 1200Hz (300kHz effective) | 16 bit + CRC | 4-bit CRC | ~0.83ms | No (timing too tight) |
| ProShot1000 | Digital | 1000Hz | 16 bit + CRC | 8-bit CRC | ~1ms | Yes |
DShot Deep Dive: Which Speed to Use
DShot600 is the default for 99% of modern builds. It’s supported by every BLHeli_S and BLHeli_32 ESC manufactured since 2018, runs stable on F4 and F7 flight controllers, and supports bidirectional DShot for RPM filtering.
DShot300 exists for F3 flight controllers and older ESCs where DShot600 timing is unreliable. On an SPRacing F3, DShot600 frames occasionally collide with the MCU’s interrupt handling, causing dropped frames. Dropping to DShot300 solves this with zero perceptible flight difference — 3.3ms vs 1.67ms update latency is indistinguishable in the air.
DShot1200 was briefly popular on 32kHz-capable ESCs but has largely been abandoned. The 300kHz bitrate means each bit is only 3.3µs wide — noise that a DShot600 frame shrugs off will corrupt a DShot1200 bit. The CRC catches the corruption, but at 1200Hz you’re getting frame rejections every few hundred packets. Rejected frames mean the ESC holds the last throttle value, which introduces micro-stutters that are worse than the slightly slower update rate of DShot600.
DShot1200 also doesn’t support bidirectional DShot, so you lose RPM filtering. For 2026, stick with DShot300 or DShot600. The extra speed of DShot1200 is theoretical — the practical reliability cost isn’t worth it.
Multishot: Where It Still Makes Sense
Multishot at 32kHz sounds faster on paper than DShot600 at 600Hz. And for raw update rate, it is. But update rate isn’t latency — and the noise immunity gap makes Multishot less reliable in practice.
The one place Multishot still wins: legacy builds with BLHeli ESCs that don’t support DShot. A 2016-era KISS ESC running Multishot at 8kHz will fly smoother than the same ESC running OneShot125. The protocol is analog and noise-prone, but it’s the best option available on old hardware.
For anything built after 2018, there’s no reason to use Multishot over DShot. The CRC error detection alone makes DShot the right choice.
ProShot: The New Contender
ProShot1000 is an open-source digital protocol developed as a DShot successor. It uses 8-bit CRC instead of DShot’s 4-bit, making it 16x more resistant to undetected bit errors. The 1000Hz update rate splits the difference between DShot600 and DShot1200, with timing margins that tolerate typical FPV electrical noise.
ProShot is supported by AM32 ESCs and a growing number of BLHeli_32 alternatives. It natively supports bidirectional telemetry without the timing constraints that make Bidirectional DShot tricky at high RPMs. If you’re building with AM32 ESCs (available on most new AIO boards in 2026), ProShot1000 is the right choice — it combines DShot’s error detection with Multishot’s update rate in a modern protocol.
Common Protocol Mistakes
Mistake 1: Running DShot600 on an F3 Flight Controller
The F3’s interrupt handling can’t keep up with DShot600’s bitrate. Frames get dropped, the ESC holds the last throttle value, and the quad develops a micro-stutter that feels like an unfixable oscillation. Dropping to DShot300 solves it instantly.
Fix: On F3 boards, use DShot300. On F4/H7, DShot600 is fine. Check your flight controller target in the Betaflight CLI with version — if it says STM32F3, cap at DShot300.
Mistake 2: Enabling Bidirectional DShot Without Checking ESC Compatibility
BLHeli_S ESCs need the JESC or Bluejay firmware to support bidirectional DShot. Stock BLHeli_S firmware will appear to work — the RPM filter tab shows data — but the reported RPM values are garbage (random numbers, values that jump between 0 and 50000 RPM). This feeds garbage into the RPM filter, which amplifies motor noise instead of canceling it.
Fix: Flash Bluejay (open-source) or JESC (paid) to BLHeli_S ESCs before enabling bidirectional DShot. Verify RPM values are stable at idle by checking the Motors tab — each motor should report consistent RPM within ±50 of each other.
Mistake 3: Not Matching ESC Protocol to Motor Pole Count
Bidirectional DShot divides electrical RPM by (motor poles / 2) to get mechanical RPM. If your motor pole count is set wrong in Betaflight, the RPM filter operates on the wrong frequency and filters noise that isn’t there while passing noise that is.
Fix: Check your motor specs. Most 5-inch FPV motors are 12N14P (12 stator poles, 14 magnet poles). Enter 14 in Betaflight’s “Motor Pole Count” field under the Configuration tab. Count your magnets physically if you’re unsure — it’s 30 seconds that prevents a misconfigured RPM filter.
⚠️ Regulatory Notice: The ESC configuration and motor control protocols described in this article should be used in accordance with the latest 2026 drone regulations in your country or region. Some jurisdictions restrict transmitter power and operating frequencies that may interact with ESC switching noise. Always verify local laws regarding UAV electronics and RF emissions. Regulations vary significantly between the FAA (US), EASA (EU), CAA (UK), CAAC (China), and other authorities.
For a complete motor and ESC setup guide, see our BLHeli_32 configuration article. If you’re experiencing motor desyncs under load, check our motor desync diagnosis guide.
A reliable ESC stack running DShot600 with bidirectional support is the backbone of a clean-flying quad. The SpeedyBee F405 V4 stack, carried by uavmodel, handles DShot600 natively with native Bluejay support out of the box — no firmware flashing required for RPM filtering.