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