Motor desync at spin-up→closed-loop handoff — regression from previous firmware

[NosTrain]

Setup: M0138-1 ESC

motor kV=650
running firmware `39.25`
spinup_type=1 (sinusoidal), spinup_bemf_comp=1, timing_advance=60, sense_advance=20, demag_timing=1

already set per the low-kv tuning guide.

Key finding: these same motors/ESCs/params run fine (no desync) on an older firmware version. Nothing in the mechanical setup or param file changed — only the firmware. That's why we don't think this is purely a spin-up/commutation tuning gap.

Reproduction (unloaded motor, bench):

Constant RPM step from rest to 1000–1500 RPM: clean, stable.

Constant RPM step from rest to 3000 RPM: desyncs right at the spin-up→closed-loop handoff (~1.5s in, ~1000 RPM actual), gets stuck oscillating around ~640 RPM with elevated current, does not recover.

Threshold is consistent:
clean below ~2400 RPM target, desyncs above ~2500 RPM target.
A sinusoidal power sweep through the same RPM range shows intermittent desync but does recover — likely because the commanded value keeps sweeping back down, unlike a fixed high target.

python3 voxl-esc-spin-step.py --id 2 \
    --power 20 --step-amplitude 10 --step-frequency 0.5 \
    --waveform-type sinusoidal --cmd-rate 500 \
    --temperature-limit 70 --timeout 5 \
    --skip-prompt true --enable-plot 1

We've reproduced this on 39.RC11, 39.25, and 39.26

python3 voxl-esc-spin.py --id 0 --rpm 2500 --timeout 2.5 --skip-prompt true --enable-plot 1

The same command on the same motor/ESC does not desync on an older firmware version:

Board      : version 42: ModalAi 4-in-1 ESC (M0138-1)
UID        : 0x2030303355465716005A003A
Firmware   : version  39.00, hash e4f576a0
Bootloader : version    184, hash e1c038de

Questions for you:

Is there a known change between 39.00 and 39.RC11+ affecting the spin-up→closed-loop handoff, feedforward power calculation, or commutation timing near low RPM?

Is there a known interaction between spinup_bemf_comp/spinup_power/spinup_time_ms and large commanded RPM steps arriving right as spin-up completes?

Could you provide the 39.00 firmware binary?
We can't find this version in the GitLab history and it's currently our fastest path to confirming this is a regression.

What's the best way to debug this desync event more directly on our end — is there a debug/verbose logging mode on the ESC itself (e.g. raw BEMF/zero-crossing timing) beyond what the voxl-esc-tools plots already show?

Happy to share full logs/plots if useful.

Thanks,
Finn

[Alex Kushleyev]

Hello @nostrain

Please take a look at the ESC firmware changelog:
https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/blob/master/voxl-esc-tools/firmware/FIRMWARE_CHANGELOG.md

• support for the M0138 FPV ESC has been added in firmware V39 RC10, which is likely what you received (i assume the ESC is reasonably old, since we are now shipping with latest firmware)
• please note that only starting version V39.15, the ESC firmware sends back the exact version in format Vxy.ab -- so 39.00 could mean 39.10-39.15
• also note that the firmware hash that you have (e4f576a0) is not listed in our firmware changelog, but it is essentially the V39 RC10 release (39.10).

We will look into the changes. To help with this, are you able to share the approximate motor specs? (motor kv and what supply voltage you are using)? We can try to replicate.

Are you able to test the firmware from this release and tell me how it behaves? https://gitlab.com/voxl-public/voxl-sdk/utilities/voxl-esc/-/tree/366d652e3680bb769d87dfca94f76b226481a6db/voxl-esc-tools/firmware . Initially we had a few releases that were not documented in the changelog (v0_39_RC10_a7f0bccb)

Thank you

Alex

[NosTrain]

Hi Alex,

I've rerun the above ramp tests with the RC10 firmware but the same desync event is occuring.
It's a 650kv motor with tests ranging between 18 - 19 V from a 5S battery into the ESC board.

To be clear this is unloaded. Repeating this exact test with load on the motor (i.e. prop) the desync event does not occur.

Many thanks,
Nos

[Alex Kushleyev]

hi @nostrain ,

Thank you for providing an important detail regarding unloaded motor. I am going to test that condition with a similar motor.

I am a bit hesitant to ask you to go back to the older firmware since we have had a number of improvements since the original firmware, so we will try to figure out how to make this work.

In general, the ESC with unloaded motor should not be doing this, even while running in RPM control mode (which has been tuned for optimal response with a propeller). Ideally, the unloaded performance should not fail (while would behave differently from loaded motor).

Meanwhile, i am not sure how much value it is to do RPM step response tests with unloaded motor, because RPM controller assumes a loaded motor and the RPM controller is using the tuning parameters you provided. However, the motor behavior is extremely different without the propeller. To test realistic conditions, we typically run robustness tests like this with propeller on.

One more request, are you able to repeat the same test with the original firmware (that currently works) and set the demag_timing ESC parameter to 0. This was a feature originally put in for testing to help with low kv motors, but we later decided that this feature was not complete / robust enough to cover general use cases and it was removed. I am curious if it is helping in this case.

Alex