Motor spins up after disarm

[karstendf]

Current Behavior

In my setup

• glider with motor
• INAV 9.1
• DSHOT600 + separate telemetry (KISS)
• ESC Hardware: ESCape32 Axe 2-6S 60A ESC (from ESCape32 project)
• ESC firmware: version 17.2
• 'Continuously trim servos on Fixed Wing' enabled

there's a ~50% chance that the motor spins up to apparently full speed for a duration of ~0.5..1 s after disarming the flight controller. This occurs after the disarm beep sequence is finished.

Not sure if this also occurs if 'Continuously trim servos on Fixed Wing' is disabled - in my tests, it did not.
However I have only tried this ~5 times, not enough to be sure. I'll keep doing further configuration / tests with continuous trim disabled to get a more clear result.

Steps to Reproduce (lab desk)

1. Remove airscrew ;-)
2. ARM the flight controller ('Continuously trim servos on Fixed Wing' enabled)
3. do some simulated flight actions - throttle up/down, moving sticks, switching modes
4. DISARM flight controller
5. wait for disarm beep code to finish
6. see the motor spin up with (very rougly) ~50% probability for ~0.5..1 s

Expected behavior

Motor stays off after disarm

Suggested solution(s)

tbc.

Additional context

current INAV configuration

---

• FC Board name and vendor: Radiomaster NEXUS-XR
• INAV version string:

  INAV/NEXUSX 9.1.0 Jul 8 2026 / 02:10:25 (1531750),

• ESCape32 version: Firmware revision 17 (patch 2)

[sensei-hacker]

I definitely want to look into this.
Can you please kindly attach your diff?

And two weird questions that have a low probability, but I'm going to ask anyway:

1. You don't happen to be in the Dallas area, do you?

2. Do you happen to have a pocket oscilloscope or a Pi Pico laying around?

[error414]

Diff is in Additional context section

[karstendf]

On the weird questions:

• I was in Dallas a few times when we were working wit TI, but that's some years ago.. I live in Germany, no trip to Dallas planned right now ;-)
• I do have a (digital) scope. I was thinking about attaching it to the DSHOT wire, but didn't do it yet as I have no clue what to trigger on. I think the scope can trigger on patterns, probably also on serial ones, but haven't used this feature yet.

[karstendf]

I have set up the oscilloscope, and learned some things about DSHOT from waveforms and especially from Claude AI - Claude is quite well informed. What hits the eye immediately - the DSHOT600 frames come up quite irregulary - typically every 75us, but sometimes up to 280us (between start of frames).
Now what should I look for?

[sensei-hacker]

Awesome. I am curious how the Dshot pattern changes as you disarm and then the motor spins up.
Do you see a pattern of high and low that are much longer than normal Dshot just before the spin up? ANything else you see that;s different?
I'm also going to try it on my Nexus, but I don't have ESCape32

[karstendf]

As to be expected, a little difficult to reproduce once instrumented.. I have a recording of an error case, but no way to view it :-(
In case you are able to analyze a Rigol .bin file, I'm happy to make this available (100+ MB)

What I've seen:

• no inversion of signal or long-time high states - no obvious problems
• motor seems to spin up with no apparent reason - DSHOT throttle data do NOT explain this
• when motor runs, there's quite some GND shift (see picture) - need to check why, but it's obviously not causing the spin up
  (the picture is from a different recording with intentionally started motor - hence the non-zero DSHOT data)

• the only remarkable thing is quite a long interruption (around 10ms) in DSHOT frame output before the motor spinup starts. Similar interruptions occur on other occasions as well but maybe this one is a little longer.

[breadoven]

Are you thinking this is the same issue as #11260 ? I commented there I have the issue of the ESC rebooting on disarm even with that PR #11260 (comment). The issue remains although the motors never run, just the ESC reboots but only when settings are saved not otherwise.

[error414]

@karstendf could you please attach screenshot of dshot frame in the time when motor spins and should not. You said that DSHOT frame does not explain motor spinning, did you decode dshot frame?

[karstendf]

@breadoven - yes, may be - the sounds I interpreted as 'disarm' may as well be ESC reboot. That leaves the question why the ESC would spin up on reboot?

@error414 - yes, I did decode DSHOT frames which is easy enough (as per Claude ;-):

Bit encoding:

• A 1 bit: high for ~2/3 of the bit period
• A 0 bit: high for ~1/3 of the bit period

Frame structure — 16 bits total, sent MSB first:

• | 11 bits: throttle value | 1 bit: telemetry request | 4 bits: CRC |
• Throttle (11 bits): values 0–47 are reserved for special commands (beep, 3D mode, settings, etc.), 48–2047 map linearly to the actual throttle range. Bit 10 goes out first, down to bit 0 last.
• Telemetry request bit: set by the FC to ask the ESC to send a telemetry response back (this is what triggers bidirectional DSHOT's reply, in my case KISS telemetry data via separate wire).
• CRC (4 bits): checksum over the preceding 12 bits, so the ESC can reject corrupted frames. Computed over the preceding 12 bits (throttle + telemetry bit) as crc = (value ^ (value >> 4) ^ (value >> 8)) & 0x0F, then those 4 bits go out last.

Regarding providing a screenshot, I can't directly, since that silly oscilloscope can't read the files it did save itself.
However, I found a tool to convert recorded data so they can be analyzed in sigrok / PulseView.

this is (almost) the full recording - motor spinup is where the trace gets blown up (@ ~ 1280ms)

the spin-up phase in total

early spin up, slight GND shift, DSHOT data at zero (there are some occasional telemetry request bits, but not in this picture)

GND shift at it's max, I'd interpret this as max. current flow during acceleration of the motor. DSHOT data still at zero.

For reference, here's a frame with telemetry request bit set:

interestingly, telemetry request bits seem to be completely missing in the later part of the process.

[error414]

You measured exactly same what I measured on my F722 board, My board does not use DMAR but the result on pin is exactly, same. Around eeprom saving three gaps in dshot sending 10ms long. I bought flyingrc mini ESC, it should be compatible with ESCape32, but it take some time to flash bootloader and ESCape32 .

And could you please upload somewhere the 100MB log from osciloscope?

[karstendf]

I have put it to my nextcloud - you should be able to download it from here - mark file spinup_10.bin & click button 'Herunterladen'. Let me know once you have downloaded it.

[karstendf]

Next thing for me to check is the signal on the telemetry line - maybe there‘s a hint on what‘s going wrong.

[LYNHQQ]

我已经设置好了示波器，并从波形图以及 Claude AI 的讲解中学习了一些关于 DSHOT 的知识——Claude 的知识非常渊博。最明显的问题是，DSHOT600 的帧出现非常不规律——通常是每 75 微秒一帧，但有时帧起始间隔可达 280 微秒。 现在我应该关注什么呢？

In case it helps, INAV doesn't rely on the gyro interrupt pin; the gyro/PID tasks are polled within the main while(1) loop. Because of this, a slight amount of jitter is expected, so seeing some fluctuations in the DShot packets is completely normal.

[LYNHQQ]

@breadoven ——是的，也许是这样——我之前理解的“解除武装”的声音也可能是电调重启的声音。这就引出了一个问题：为什么电调会在重启时启动？

@error414是的，我解码了DSHOT帧，这很容易（正如Claude所说 ;-):

位编码：

• 1 位：高电平持续时间约为位周期的 2/3
• 0 位：高电平持续时间约为位周期的 1/3

帧结构——总共16位，先发送最高有效位（MSB）：

• | 11 位：油门值 | 1 位：遥测请求 | 4 位：CRC 校验和 |
• 油门（11 位）：值 0–47 保留用于特殊命令（蜂鸣声、3D 模式、设置等），48–2047 与实际油门范围线性对应。第 10 位最先输出，最后输出到第 0 位。
• 遥测请求位：由飞控设置，以请求电调发送遥测响应（这会触发双向 DSHOT 的回复，在我的例子中，KISS 遥测数据通过单独的线路发送）。
• CRC（4 位）：对前 12 位进行校验和计算，以便电调能够拒绝损坏的帧。计算公式为：crc = (value ^ (value >> 4) ^ (value >> 8)) & 0x0F，计算前 12 位（油门位 + 遥测位），然后最后输出这 4 位。

至于提供屏幕截图，我无法直接提供，因为那台破示波器无法读取它自己保存的文件。 不过，我找到一个工具可以转换记录的数据，以便在 Sigrok/PulseView 中进行分析。

这几乎是完整的记录——电机启动时波形开始失真（大约在 1280 毫秒），

启动阶段整体处于

早期阶段，地线轻微偏移，DSHOT 数据为零（偶尔会出现一些遥测请求位，但图中未显示）。

地线偏移达到最大值，我将其解释为电机加速期间的最大电流。DSHOT 数据仍然为零。

作为参考，这里有一帧遥测请求位已设置：
有趣的是，在流程的后期，遥测请求部分似乎完全缺失了。

In case it helps, INAV currently lacks an implementation for bidirectional DShot, which is why the telemetry bit has no effect. (Configuring motor direction or 3D mode still works as expected, as those rely on standard unidirectional DShot.)
Bidirectional DShot needs an inverted line that idles high, with its signal polarities flipped compared to unidirectional DShot. Only with this inverted signaling can the ESC be triggered to return RPM and telemetry data.

[error414]

If bin file from #11954 (comment) is when motor start spinnig after eeprom save, then it's super weird.

d:\decode-dshot>python dshot_decode.py spinup_10.bin
Loading spinup_10.bin (offset 172)...
50,000,000 samples = 1.600 s of capture
Levels: low~-0.0419 V, high~2.8033 V, threshold 1.3807 V
Found 364,725 pulses
Total frames: 22,794

--- Inter-frame gaps ---
Average gap: 44.27 us
Longest gap: 10055.65 us (at 1.037457 s)
Average frame period: 69.85 us (~14316 frames/s)

--- Frames (zero runs collapsed) ---
    0.000043 - 0.633918 s  value 0 (disarm/stop)  x7080
    0.634009 s  COMMAND 1
    0.644069 - 1.037350 s  value 0 (disarm/stop)  x4498
    1.037431 s  COMMAND 1
    1.047513 - 1.127952 s  value 0 (disarm/stop)  x929
    1.128052 s  INCOMPLETE frame (26 bits)  [!] 1x bad CRC
    1.128099 - 1.360713 s  value 0 (disarm/stop)  x7765
    1.360743 s  INCOMPLETE frame (27 bits)  [!] 1x bad CRC
    1.369575 - 1.591955 s  value 0 (disarm/stop)  x2517
    1.592159 s  COMMAND 1

There are only frames with all zero, or command 1 (beep). and two broken frames. Both broken frames are at the begining of 10ms gap.

there are only two suspisious things, tree 10ms gaps. I see same gaps when I tested saving to eeprom in my F722 board (DMA). Radomaster nexus X propably uses DMAR.