It does not always work arming when DSHOT150/300/600 is setted.

[DaniilProgMath]

My issue is related to incorrect arming. It consists in the fact that when i setting the protocols dshot150, dshot300, dshot600, the model is not always armed. Most of the time I get an error with the following flag ARMING_DISABLED_ARM_SWITCH.

All other arm checks have been successfully passed.

A similar problem has already been encountered, but was closed without any solution #9119

As in that case, when I set multishot, it arms normally.

Current Behavior

Arming happens every other time.

Screenshots from the configurator and a small video proof

  https://github.com/iNavFlight/inav/assets/55910597/80863832-bd23-46db-a9ee-a5f8e957af49

Steps to Reproduce

1. Set Dshot150, Dshot300, Dshot600 motor protocol.
2. Try to see arming flag ARMING_DISABLED_ARM_SWITCH.

Expected behavior

Successful arming every time you launch with Dshot protocols.

Suggested solution(s)

I have no guesses. It would be great to receive instructions on how to disable this flag or fix the problem through the configurator. Or release a firmware fix.

Additional context

This cannot be a hardware or model build issue as these protocols work successfully through betaflight.

CLI dump: https://pastebin.com/df85Neir

---

• FC Board name and vendor: SpeedyBee F405V4 + esc 55A bls https://www.speedybee.com/speedybee-f405-v4-bls-55a-30x30-fc-esc-stack/
• INAV version string:

# version
# INAV/SPEEDYBEEF405V4 7.0.0 Dec  5 2023 / 11:06:00 (895a4f31)
# GCC-10.3.1 20210824 (release)

[MrD-RC]

ARMING_DISABLED_ARM_SWITCH means that it thinks the arm switch is already in the arming position. So can’t arm. There must be something else blocking arming. What do you get if you type status in to CLI?

[DaniilProgMath]

Thank you for the quick response.

status before bad arming

``` INAV/SPEEDYBEEF405V4 7.0.0 Dec 5 2023 / 11:06:00 (895a4f31) GCC-10.3.1 20210824 (release) System Uptime: 20 seconds Current Time: 2041-06-28T01:04:00.000+00:00 Voltage: 11.84V (3S battery - OK) CPU Clock=168MHz, GYRO=ICM42605, ACC=ICM42605, BARO=SPL06 STM32 system clocks: SYSCLK = 168 MHz HCLK = 168 MHz PCLK1 = 42 MHz PCLK2 = 84 MHz Sensor status: GYRO=OK, ACC=OK, MAG=NONE, BARO=OK, RANGEFINDER=NONE, OPFLOW=NONE, GPS=NONE ESC Temperature(s): Motor Count = 4 ESC 0: 0°C, ESC 1: 0°C, ESC 2: 0°C, ESC 3: 0°C, SD card: Startup failed Stack size: 6144, Stack address: 0x10010000, Heap available: 1828 I2C Errors: 0, config size: 9551, max available config: 131072 ADC channel usage: BATTERY : configured = ADC 1, used = ADC 1 RSSI : configured = ADC 3, used = none CURRENT : configured = ADC 2, used = ADC 2 AIRSPEED : configured = none, used = none System load: 12, cycle time: 515, PID rate: 1941, RX rate: 9, System rate: 9 Arming disabled flags: CLI OSD: MAX7456 [30 x 16] VTX: not detected ```

status during bad arming

``` INAV/SPEEDYBEEF405V4 7.0.0 Dec 5 2023 / 11:06:00 (895a4f31) GCC-10.3.1 20210824 (release) System Uptime: 78 seconds Current Time: 2041-06-28T01:04:00.000+00:00 Voltage: 11.82V (3S battery - OK) CPU Clock=168MHz, GYRO=ICM42605, ACC=ICM42605, BARO=SPL06 STM32 system clocks: SYSCLK = 168 MHz HCLK = 168 MHz PCLK1 = 42 MHz PCLK2 = 84 MHz Sensor status: GYRO=OK, ACC=OK, MAG=NONE, BARO=OK, RANGEFINDER=NONE, OPFLOW=NONE, GPS=NONE ESC Temperature(s): Motor Count = 4 ESC 0: 0°C, ESC 1: 0°C, ESC 2: 0°C, ESC 3: 0°C, SD card: Startup failed Stack size: 6144, Stack address: 0x10010000, Heap available: 1828 I2C Errors: 0, config size: 9551, max available config: 131072 ADC channel usage: BATTERY : configured = ADC 1, used = ADC 1 RSSI : configured = ADC 3, used = none CURRENT : configured = ADC 2, used = ADC 2 AIRSPEED : configured = none, used = none System load: 12, cycle time: 534, PID rate: 1872, RX rate: 128, System rate: 9 Arming disabled flags: ARMSW CLI DSHOTBEEPER OSD: MAX7456 [30 x 16] VTX: not detected ```

I was just messing around with the modes settings and discovered something. My "Angle" mode is activating together with arming, and they are assigned to the same switch. When I turned off the activation of the "Angle" mode, arming started to work correctly, turning on every time I requested it, instead of every other time.

It's strange that a similar problem doesn't occur with other ESC protocols.

[MrD-RC]

Angle shouldn’t cause problems. But it’s not a good idea to have it on the same switch as arming.

It days that DSHOTBEEPER is active when trying to arm. That may be signalling a problem?

[breadoven]

It's probably to do with DSHOTBEEPER. Was never convinced it worked properly, seems to interfere in certain circumstances. The problem is it prevents arming if it's trying to beep for something at the time you arm, e.g. beeps for mode change to Angle. By the time it's finished beeping (allowing arming again), the arm switch is already in the arm position so the arm switch then blocks arming. Turn of DSHOTBEEPER or make sure nothing is going to happen that causes beeping when you arm. This is a timing issue which needs fixing properly really.

[DaniilProgMath]

Yes, you are right, when I disabled dshotbeeper, arming began to always run. I checked many times.

Another offtopic micro-question, why is it not recommended to assign angle and arming modes to one switch?

[MrD-RC]

Another offtopic micro-question, why is it not recommended to assign angle and arming modes to one switch?

Because you’re mixing two completely different attributes on a single switch (arming and flight modes). You’re best to keep them separate. So a channel for arming (which needs to be 5 if using WLRS). Then a separate channel for your flight modes. With Angle active all the time you are armed. You’d never be able to fly in Acro.

[b14ckyy]

Closing as the support issue is solved. For the dshot timing stuff we should make a new one to track

[breadoven]

@DaniilProgMath out of interest, was the switch used for Arming and Angle just a basic 2 position switch ?

[DaniilProgMath]

@MrD-RC

You’d never be able to fly in Acro.

I see what you mean, But I have a specialized case. I am developing an AI-controlled drone that follows certain objects (not military =)). Maximum stability in the air is important here, and the acro mode is not very suitable for this purpose because it significantly complicates the logic of the control algorithm. To avoid accidentally activating it, I combined arming with angle mode. Basically i switched to INAV because it allows for more precise control of the drone's position and stabilizes its flight. While configuring the platform, I discovered this bug with the DShot beeper.

out of interest, was the switch used for Arming and Angle just a basic 2 position switch ?

@breadoven Yes, arming and angle mode were assigned to a 2-position switch.