FPV Drone Won’t Arm in Betaflight? Read the Disable Flags 2026 Guide

There is nothing more frustrating than plugging in a fresh battery, flipping your arm switch, and getting nothing but a sad buzz from your motors. If your FPV drone won’t arm in Betaflight, the disable flags are the fastest path to a real answer. Betaflight runs a stack of pre-arm safety checks before it will ever let your motors spin, and when one of those checks fails, it logs a short code that tells you exactly what went wrong.

The mistake most pilots make is guessing. They rebind the receiver, reflash the firmware, swap the flight controller, and still the quad will not arm. Reading the arming disable flags first eliminates 90 percent of that wasted effort because Betaflight already diagnosed the problem for you. You just have to know where to look.

In this guide I will walk through how to read the flags three different ways, decode all 26 current Betaflight arming disable codes, and explain the most common causes pilots hit in 2026. I have pulled real edge cases from IntoFPV and r/fpv so the weird problems are covered too, not just the textbook ones.

What Betaflight Arming Disable Flags Actually Are

Betaflight arming disable flags are status codes the flight controller sets whenever one of its pre-arm safety checks fails. Think of them as a checklist the FC runs every time you move the arm switch. If even one item on the list fails, arming is blocked and the responsible code is displayed so you can fix it directly.

These flags are not bugs. They are a deliberate safety system designed to stop motors from spinning up when something is unsafe. A quad that arms with the throttle stuck at 25 percent, with no receiver signal, or while the FC still thinks it is plugged into USB is a quad that can hurt you. The disable flags are what prevent that.

How to Check Arming Disable Flags in Betaflight

You have three ways to read the flags, and you should learn all three because each one works in different situations.

1. Read the Flags in the OSD

The easiest method is to enable the arming disabled warning in your OSD elements. In Betaflight Configurator, go to the OSD tab, scroll to the Warnings section, and make sure “Arming Disabled” is checked. Now when you try to arm, the active flag names scroll across your goggles.

One catch I hit on a Mobula6 was that the warning was enabled but the message was clipped by the camera aspect ratio. If you see a partial flag name, lower your OSD element count on that side of the screen or move the warning higher.

2. Read the Flags in Betaflight Configurator

Plug in via USB, open Betaflight Configurator, and go to the Motors tab. Near the top, the active arming disable flags are listed in plain English. This is great when you are bench testing, but remember that plugging in USB itself triggers the MSP flag, so this view always shows at least MSP as active.

The Configurator view is most useful for confirming that your fixes worked. Unplug USB, plug in the battery, then plug in USB again to refresh the view and see which flags cleared.

3. Read the Flags With the CLI status Command

The most detailed method is the CLI. Open the CLI tab in Betaflight Configurator and type:

status

The output prints two relevant lines. “Arming Disable Flags” lists the active flag names, and “Arming disable flags” with a numeric value gives you the bitmask if you ever need it. The CLI also shows CPU load, gyro health, and baro status in the same output, which helps when you are chasing a LOAD or NOGYRO flag.

One forum tip worth keeping: if you ever see a flag the documentation does not mention, run status twice. Some flags, particularly DSHOT_TELEM, only print on the second call after a fresh FC boot.

Complete Betaflight Arming Disable Flags Lookup Table

This is the complete list of arming disable flags in current Betaflight releases. When more than one is active, Betaflight shows them all so you can address each issue.

• NOGYRO – No gyroscope detected. The FC cannot read the IMU. Usually a hardware failure or a broken I2C/SPI trace. Reflash firmware first, then check the gyro chip.
• NOTRX – No receiver detected. The FC sees no RX input. Check your receiver UART wiring, verify the receiver protocol in the Ports and Receiver tabs, and confirm the receiver itself has power.
• RXLOSS – Receiver was detected but the link has been lost. Receiver failsafe is active. Rebind, check for UART conflicts, and verify your radio is on.
• BAD_RX – Receiver data is malformed. Usually a wrong receiver protocol selection. Crossfire set to SBUS, or CRSF set to FPort are common causes.
• RXFAIL – Receiver reports failsafe state. This often appears right after RXLOSS clears or when the receiver failsafe is misconfigured.
• THROTTLE – Throttle channel is above min_check. Pull the throttle stick all the way down. If it persists, your throttle end points need trimming.
• ANGLE – The drone is tilted past the maximum arm angle while angle or horizon mode is active. Set the quad flat, or raise max_arm_angle in CLI.
• BOOT_GRACE_TIME – The flight controller just booted and is still in its disarm grace period. Wait roughly five seconds after power-on before arming.
• NOPREARM – A prearm switch is configured but not engaged. Toggle your prearm switch, or disable the prearm mode if you do not use one.
• LOAD – CPU load is too high. Usually caused by bidirectional DSHOT with RPM filters on an underpowered FC, or a PID loop set too high.
• CALIBRATING – Accelerometer or gyro calibration is still running. Hold the quad still on a flat surface and wait for the calibration to finish.
• CLI – The CLI session is active. Close the CLI tab and the flag clears on the next loop.
• CMS_MENU – The OSD CMS menu is open. Exit the menu with your transmitter sticks.
• OSD_MENU – The OSD menu itself is open. Same fix as CMS_MENU, exit the menu.
• BST – Black Sheep Telemetry fault. Rare, but appears on older Taranis-linked setups.
• MSP – The FC believes it is connected to MSP, usually because USB is plugged in or because a previous MSP session did not clear cleanly.
• PARALYZE – The paralyze mode is active. This is a safety lockout typically triggered by a runaway takeoff prevention event.
• GPS – GPS rescue mode requires a fix before arming. Wait for GPS lock, or disable GPS rescue if you are indoors.
• RESC – The drone is already in GPS rescue switchover state.
• RPMFILTER – Bidirectional DSHOT is enabled but RPM data is missing. Often paired with DSHOT_TELEM. Check motor pole count and ESC telemetry.
• DSHOT_TELEM – DSHOT telemetry not flowing on a target that requires it. Newer in Betaflight 4.4 and later. Check ESC firmware and motor pole count settings.
• CRASH – Crash recovery has not finished resetting. Wait, or power cycle the FC.
• ACRO – Acro trainer or angle limits are blocking arming. Rare, usually a misconfiguration.
• MOTOR_PROTOCOL – The configured ESC protocol has not been initialized. Verify DSHOT300 or DSHOT600 is set in the Motors tab.
• ARM_SWITCH – The arm switch itself is in an inconsistent state. Often a result of an AUX channel conflict.
• HW_FAILURE – A hardware check failed. Most commonly paired with NOGYRO. Check solder joints on the IMU.

If you count them, that is 26 distinct flags. You will realistically only see five or six of them, but knowing the full list means a strange flag does not send you to a forum thread.

The MSP Warning Flag and Why USB Hangs It

The MSP flag is the single most common cause of “my drone arms on the bench but not at the field.” MSP stands for Multiwii Serial Protocol, and it is the protocol Betaflight Configurator uses to talk to the flight controller over USB. When USB is plugged in, the FC refuses to arm because arming while connected to a computer is unsafe.

The actual problem shows up after you unplug the USB cable. Some flight controllers, particularly older Omnibus and F4 boards, do not detect the USB disconnect cleanly and keep the MSP flag set. The drone will not arm until the FC reboots.

The fix is simple and one I learned from a fellow pilot named Kyle on r/fpv. Unplug the USB, then unplug the main battery, then plug the battery back in. The power cycle reboots the FC and clears the MSP flag. Some newer FCs handle this automatically, but I have seen the issue persist on a Matek F405-CTR even with current firmware.

If you want to avoid this entirely, get into the habit of bench testing with the battery, not just USB. The FC behaves more predictably when it is powered the same way it will be in flight.

The THROTTLE Flag and the min_check Threshold

The THROTTLE flag fires whenever the throttle channel reads above the min_check value. By default min_check is 1050, which means any throttle signal above 1050 microseconds blocks arming. Betaflight is protecting you from spinning up motors at partial throttle.

There are two reasons this flag shows up. The first is obvious: your throttle stick is not at the bottom. Pull it all the way down, especially if you fly with a throttle spring that does not self-center.

The second reason is more subtle and is where most pilots get stuck. Some transmitters, notably the Jumper T-Lite v1, output a throttle minimum of 990 instead of 1000. Betaflight reads this as “below normal range” and the FC rejects the signal. User Krotow on IntoFPV found the fix: open the CLI and run set min_check = 995 then save. The flag clears immediately.

If you are seeing the THROTTLE flag and your stick is at zero, check your transmitter’s channel monitor. If the throttle channel reads anything other than a clean 1000 at minimum, you have an endpoint problem and the fix is in your radio’s calibration or in the Betaflight min_check value.

The ANGLE Flag and Maximum Arm Angle

The ANGLE flag appears when your quad is tilted past the configured maximum arm angle while angle or horizon mode is active. The default max arm angle is small, often around 20 degrees, because Betaflight does not want you arming on a steep slope.

The first fix is to set the quad on a flat surface. I keep a small bubble level in my field kit for this. Even a slight tilt on a picnic table can trip the ANGLE flag.

If you need to arm on uneven ground, raise the max_arm_angle in the CLI:

set max_arm_angle = 30
save

The trade-off is safety. The lower the angle, the more conservative the check. Most pilots leave it at the default for safety and just level the quad manually.

Accelerometer calibration is also part of this. If your accelerometer thinks “level” is actually tilted, the ANGLE flag will fire even when the quad looks flat. Recalibrate the accelerometer on a known-level surface with the FC oriented exactly as it sits in the frame.

Receiver, RXLOSS, and Arm Switch Problems

Receiver problems are the second most common cause of arming failures, after MSP. The flags NOTRX, RXLOSS, BAD_RX, and RXFAIL all point to receiver issues, and the specific flag tells you which problem you have.

NOTRX means the FC sees no receiver at all. The receiver is either not wired, not powered, or not configured on the correct UART. Check the Ports tab to confirm the receiver UART is set to the correct protocol, and verify 5V and ground are getting to the receiver.

RXLOSS means the receiver was detected but the link dropped. This often appears when you plug in the battery without turning on your radio, or when the receiver goes into failsafe. A subtle cause I have hit personally is a UART conflict. User MadfishFPV traced an RXLOSS problem to SBUS and ground wires from a DJI air unit conflicting with the receiver’s communication line. Removing those wires cleared the flag.

The arm switch itself can also block arming. In the Modes tab, verify ARM is assigned to an AUX channel and that the channel range is correct. A pilot named Andy Roberts on r/fpv found his arm switch was accidentally assigned to AUX6 instead of AUX5 after a firmware flash. The Modes tab showed the channel moving, but on the wrong channel.

DJI O3 Air Unit Binding Note

If you fly DJI O3, there is a non-obvious requirement: the air unit must be bound to the goggles before the FC will arm in some configurations. This is rarely documented, but pilots on r/fpv report the FC reads the air unit’s failsafe state until binding is complete. If you see RXLOSS or RXFAIL with a healthy receiver link, bind the air unit to the goggles first.

MOTOR_PROTOCOL and DSHOT_TELEM Flags

The MOTOR_PROTOCOL flag fires when the configured ESC protocol is not actually running. On a fresh build or after a firmware flash, this usually means you forgot to select DSHOT300 or DSHOT600 in the Motors tab. Open the Motors tab, choose the correct protocol for your ESC, and save.

The DSHOT_TELEM flag is newer, appearing in Betaflight 4.4 and 4.5. It fires when bidirectional DSHOT is enabled but telemetry packets are not arriving from the ESCs. Common causes are mismatched ESC firmware (BLHeli_S versus Bluejay versus BLHeli32) and incorrect motor pole count settings.

If you see DSHOT_TELEM after upgrading to Betaflight 4.5, check three things. First, make sure your ESCs support bidirectional DSHOT. Second, flash matching ESC firmware (Bluejay is the most common choice for sub-250g quads). Third, set the correct motor pole count in the PID tuning tab so RPM can be calculated.

CPU load is the related concern. Bidirectional DSHOT with RPM filters taxes the FC, and the LOAD flag will fire if your F4 cannot keep up. Drop the PID loop to 4K, switch from DSHOT600 to DSHOT300, or disable RPM filters if your FC is the bottleneck.

Buzzer Beep Codes and How to Decode Them

If you have a buzzer installed and no goggles or USB handy, Betaflight reports arming disable flags as beep codes. The encoding is clever and worth understanding because it works without any screen.

The pattern is five long beeps followed by short beeps. The number of short beeps is the flag number from the disable flag table. For example, five long beeps followed by one short beep is flag 1, which historically corresponds to the first disable flag. Five long beeps and three short beeps is flag 3.

To count along, listen for a clear pause after the long beeps. The short beeps come quickly after that pause. If you lose count, just listen again, the pattern repeats every few seconds.

This is invaluable at the field. You do not need a laptop, you do not need goggles, and you do not even need to plug in USB. A $2 buzzer gives you the same information as the Configurator view, just encoded as sound.

NOGYRO, HW_FAILURE, and the Moron Threshold

The NOGYRO flag is the worst one to see. It means the flight controller cannot talk to the gyroscope at all, which usually indicates hardware failure. Before you replace the FC, try these steps.

First, reflash the firmware with the correct target. A wrong target can misconfigure the IMU bus and produce NOGYRO even on healthy hardware. Second, inspect the solder joints around the IMU chip. A cracked via or cold solder joint on the SPI bus will break communication. Third, check for physical damage. A hard crash can crack the IMU chip itself.

If none of that helps, the FC is likely dead and replacement is the only option.

Related to gyro health is the so-called “moron threshold,” officially known as gyro_calib_noise_limit in Betaflight CLI. When the FC boots, it samples gyro noise to confirm the sensor is working. If the noise floor is too high (typically from vibration or a bad sensor), calibration fails and arming is blocked. The gyro_calib_noise_limit value sets the threshold, and raising it can mask a real problem, so use it only as a diagnostic step, not a permanent fix.

Run get gyro_calib_noise_limit in the CLI to see the current value. The default is conservative for a reason. If you raise it to clear the flag, your FC is accepting noisier gyro data than it should, and flight performance may suffer.

Quick Pre-Arm Checklist

Before every flying session, run through this checklist. It catches the 90 percent of arming failures that are preventable.

1. Radio on first, then battery. This prevents RXLOSS from the receiver failing to link.
2. Throttle stick all the way down and at the bottom of its travel.
3. Quad on a flat, level surface.
4. Arm switch off, then on, with a half-second pause between.
5. If arming fails, read the OSD warning before doing anything else.
6. If the OSD warning is unclear, plug into Configurator and read the flag list.
7. If you just unplugged USB, power cycle the battery to clear the MSP flag.
8. For a new build, confirm DSHOT protocol and motor pole count are set.

This list takes 10 seconds and saves hours of forum posting.

Conclusion

If your FPV drone won’t arm in Betaflight, the disable flags are not the problem. They are the answer. Betaflight has already diagnosed the issue for you, and your job is simply to read the code and apply the matching fix. Once you learn the three readout methods (OSD, Configurator, and CLI) and the 26-flag lookup table in this guide, arming failures become a 30-second fix instead of an afternoon project.

Start with the easy wins. Power cycle the battery to clear MSP, pull the throttle fully down, set the quad on a flat surface, and verify your arm switch is on the right AUX channel. Those four checks clear the vast majority of arming failures. If a flag still persists, work through the specific section for that flag and you will be back in the air within minutes.