The Betaflight Configurator GUI hides half the settings you actually need. Resource remapping, filter debugging, DMA conflict resolution, and configuration diffs all live in the CLI — and the GUI either can’t do them or does them poorly. After maintaining a fleet of 15+ quads across multiple Betaflight versions, the CLI is where I spend 40% of my tuning time. Here are the commands you’ll actually use.
Essential CLI Commands Every Pilot Should Know
Step 1: Configuration Backup and Diff
This is the first command you run on any quad — before you change a single setting.
diff all
diff all outputs every setting that differs from the Betaflight defaults for your target. It’s clean, it’s human-readable, and you can paste the entire output into a new FC’s CLI to clone your configuration. Always save a diff all to a file named with the quad and date before making changes.
What dump does vs diff: dump shows every single setting including defaults — 2000+ lines. diff all shows only what you changed — typically 50-150 lines. Use diff all for config backup, dump only when debugging low-level issues.
Step 2: Resource Mapping and Conflict Resolution
When a peripheral doesn’t work on its expected UART, you need to see what’s actually mapped:
resource show all
This shows every pin assignment on the FC — which timer, DMA stream, and peripheral each pin is connected to. A motor that won’t spin on the expected output? resource show all reveals if the timer is shared with another function.
Remapping a motor resource:
resource MOTOR 5 NONE
resource MOTOR 5 B06
save
This frees the old pin and assigns the motor to a new one. You’ll need this when: an ESC pad lifts, you’re using a different target, or you want to use an LED strip pad as a motor output.
DMA conflict check:
dma show
DMA (Direct Memory Access) channels handle bidirectional DShot and other high-speed peripherals. If two peripherals share a DMA channel, one of them fails silently. dma show lists every DMA assignment — conflicts appear as the same DMA index on two different pins. The fix is reassigning one peripheral’s pin to a DMA-free resource.
Step 3: Filter and Gyro Diagnostics
When your quad oscillates and you can’t figure out why, these CLI commands diagnose faster than the GUI:
status
Shows CPU load, gyro rate, and armed time. If CPU load is above 30% at 8kHz PID loop, reduce the loop rate — the FC is struggling and jitter in the loop timing shows up as noise. Also shows: arming disable flags, which is the fastest way to debug “why won’t this arm.”
tasks
Lists every task running on the FC and its average and max execution time. The PID controller task should stay under 125μs at 8kHz. If it’s close to or above that, you’re near the CPU ceiling — reduce the PID loop rate or disable non-essential features.
gyroregisters
Raw gyro register dump — useful only when you suspect hardware gyro failure. A stuck register or wildly fluctuating value indicates a bad gyro chip. If this output looks normal but the quad flies terribly, the issue is filtering or mechanical, not hardware.
Step 4: VTX and Receiver Diagnostics
vtx_info
Shows the current VTX state as seen by SmartAudio/Tramp: current band, channel, frequency, power level, and whether the VTX is responding. If vtx_info shows a frequency that doesn’t match what you set in the OSD, your VTX table is wrong or the VTX isn’t responding to commands.
rxrange
Shows the RC channel ranges. If your roll stick only goes from 1100-1900 instead of 1000-2000, rxrange is where you fix it — no need to recalibrate the radio. Also the first place to check when a channel is reversed in Betaflight but correct on the radio.
CLI Command Reference Table
| Command | What It Does | When to Use |
|---|---|---|
diff all |
Shows all non-default settings | Config backup before any change |
dump |
Shows every setting including defaults | Deep debugging, sharing full config |
resource show all |
Lists every pin/timer/DMA assignment | Motor won’t spin, UART conflict |
dma show |
Shows DMA channel assignments | Bidirectional DShot failure, LED strip issues |
status |
CPU load, gyro rate, arm flags | “Why won’t it arm?” diagnostics |
tasks |
Task execution time breakdown | CPU overload, stutter at high loop rates |
gyroregisters |
Raw gyro hardware register values | Suspected gyro hardware failure |
vtx_info |
Current VTX band/channel/power/frequency | VTX not responding to OSD changes |
rxrange |
RC channel endpoint ranges | Stick endpoints wrong, channel direction |
defaults |
Reset to Betaflight defaults | Clean slate before importing a new config |
bl |
Reboot into bootloader | Firmware flashing without holding boot button |
Common Mistakes With Betaflight CLI
Mistake 1: Running diff instead of diff all.
The consequence: diff without all only shows profile-specific settings — it misses rates, PIDs, and filter settings that live in the profile. You paste the output into a new FC and your rates are gone. The fix: Always use diff all. There is no scenario where diff alone is the right command.
Mistake 2: Changing resources without checking DMA conflicts first.
The consequence: You move a motor to a new pin, save and reboot, and the motor doesn’t spin — or worse, it spins erratically because it’s sharing a DMA channel with another motor. The fix: Run dma show before remapping. Look for the pin you want to use; if it has a DMA assignment that conflicts with another motor, find a different pin.
Mistake 3: Using defaults without a diff all backup first.
The consequence: defaults wipes every custom setting. Your resource remapping, UART configuration, OSD layout — everything. If you didn’t save a diff all, you’re rebuilding from scratch. The fix: diff all → save to file → defaults → paste back diff all for the settings you want to keep. Never defaults without a backup.
Mistake 4: Pasting a full dump into CLI to restore a configuration.
The consequence: dump includes target-specific defaults that differ between FCs. Pasting a Mamba F405 dump into a JHEMCU F411 board overwrites hardware-specific settings and can brick the config enough that the FC won’t boot. The fix: Only restore using diff all — it contains only your changes, not hardware defaults.
Mistake 5: Ignoring CPU load warnings in status.
The consequence: Betaflight doesn’t prevent you from running 8kHz PID loop on an F411 even though the CPU can’t keep up. The loop jitter introduces timing errors that show up as mid-throttle oscillations indistinguishable from mechanical noise. The fix: Check status after enabling new features. If CPU load is above 30%, drop the PID loop rate to 4kHz or disable features you don’t use.
⚠️ Regulatory Notice: The flight recommendations in this article should be followed in accordance with the latest 2026 drone regulations in your country or region. Always verify local laws regarding flight altitude, no-fly zones, remote ID requirements, and registration before flying. Regulations vary significantly between the FAA (US), EASA (EU), CAA (UK), CAAC (China), and other authorities.
CLI commands are essential when recovering from a bad flash or firmware mismatch. Our Betaflight firmware backup and recovery guide shows how to save and restore your configuration across firmware versions. And when a resource remap involves the physical wiring, our flight controller wiring guide covers UART mapping and peripheral connections in detail.
For quads where you’re pushing the CPU hard with RPM filtering and high loop rates, the T-Motor F7 Pro FC handles it without breaking a sweat. The F722 processor runs 8kHz/8kHz PID loop with bidirectional DShot and GPS rescue enabled while staying under 15% CPU load — plenty of headroom for whatever Betaflight 4.6 adds next.