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
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
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