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