Outputs: changing the protocol calls off a Smart ESC calibration

[MrScothh]

Picking another motor protocol in the Outputs tab while a Smart ESC calibration is running hides the calibration
controls, Abort included, and resets them, but the firmware was not told. It went on with the sequence, holding full
throttle on the ESC wire while it waited for the battery, for up to 60 s, and would have run the calibration if the
battery was connected in that time, with nothing on screen to stop it. Leaving the tab didn't stop it either: the
controls had already been reset, so the tab no longer knew a calibration was running.

The tab now sends the same stop as the Abort button (MSP2_INAV_ESC_SRXL2_CALIBRATE with phase 0) and shows the
calibration as aborted, so going back to SRXL2 doesn't show a status that is no longer true. A status reply still on
its way when the sequence is called off is ignored, for the same reason. A start still waiting for the status that
confirms it counts as running too (c74e46d), so a protocol change in that moment, or leaving the tab, also stops it.

Tested

TBS Lucid H7 Wing with an Avian Smart ESC on SRXL2, battery out: calibration started from the tab (waiting in phase 1,
full throttle on the wire), protocol changed to DSHOT300 without saving, phase read back with
MSP2_INAV_ESC_SRXL2_STATUS:

	phase after the protocol change
maintenance-10.x	1: still holding full throttle, no Abort on screen
this PR	0

The aborted status, the ignored late reply and the start still on its way came after that test, and I've checked them in the code only.

yarn test passes, apart from the MZTC test that fails on Windows on maintenance-10.x as well (#2826 fixes it).

Found while reviewing #2815, which moves the calibration into its own box; the two merge cleanly.

[qodo-code-review]

ⓘ Qodo reviews are paused because the subscription is no longer active. Ask your workspace admin to reactivate the subscription to resume reviews. Manage billing

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Stop Smart ESC calibration when the motor protocol changes

🐞 Bug fix 🕐 10-20 Minutes

AI Description

• Stop firmware calibration when switching away from SRXL2, before the Abort control disappears.
• Show an aborted status and prevent late poll replies from restoring stale calibration progress.

Diagram

graph TD
    P["Protocol selection"] --> V["Visibility update"] --> A{"Calibration active?"} -->|Yes| S["Stop command"] --> F["ESC firmware"]
    A -->|Yes| U["Calibration status"]
    R["Status reply"] --> G{"Still active?"} -->|Yes| U
    A -->|No| U

Loading

High-Level Assessment

The focused approach is appropriate: reuse the existing firmware stop command when the controls disappear, then guard asynchronous poll callbacks against stale UI updates. A UI-only reset would leave the firmware calibration running.

Files changed (1) +10 / -0

Bug fix (1) +10 / -0

outputs.jsStop SRXL2 calibration on protocol change and ignore late polls +10/-0

Stop SRXL2 calibration on protocol change and ignore late polls

• When a different motor protocol hides the SRXL2 controls, send the calibration-off command if calibration is active and display its aborted status before resetting the controls. Ignore status-poll callbacks after calibration has stopped so an in-flight reply cannot restore stale progress.

tabs/outputs.js

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Fast protocol changes leave full throttle ✓ Resolved

Description

srxl2UpdateVisibility() sends the stop command only when srxl2Calibrating is true, but the Start
handler does not set that flag until its command and follow-up status request have both completed.
If the operator changes protocols during that interval, the new stop path is skipped and the later
status callback can mark calibration active and begin polling after the SRXL2 controls have been
hidden, while the firmware continues its calibration sequence.

Code

tabs/outputs.js[R334-335]

+                if (outputsTab.srxl2Calibrating) {
+                    MSP.send_message(MSPCodes.MSP2_INAV_ESC_SRXL2_CALIBRATE, [SRXL2_CAL_OFF], false);

Evidence

The changed condition checks only the active flag. The Start handler sets that flag after two
asynchronous MSP responses and does not recheck the selected protocol before enabling calibration;
the protocol change handler merely updates the local selection and calls the visibility function.
MSP enqueues requests, establishing a window in which the selection can change before those
callbacks run.

tabs/outputs.js[332-339]
tabs/outputs.js[376-404]
tabs/outputs.js[419-422]
js/msp.js[404-486]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Changing protocols during the asynchronous calibration-start handshake skips the stop command because `srxl2Calibrating` is still false. The later callback can activate calibration after its controls are hidden.
## Fix Focus Areas
- tabs/outputs.js[332-339]
- tabs/outputs.js[376-404]
## Recommended Fix
Track a start request as pending as soon as Start is clicked. When the protocol changes, ensure that any pending start is followed by a firmware stop, and make the start/status callbacks check cancellation before enabling calibration controls or polling.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Tip of the day

💡 Did you know, you can keep summaries lean with Findings visible per group, which tucks the rest behind a View link

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

Configurator test build ready — commit c74e46d

Download build artifacts for PR #2828

Available platforms (scroll to the Artifacts section at the bottom of the run page):

• Windows x64 (ZIP, MSI) and x32 (ZIP, MSI)
• macOS arm64 (ZIP, DMG) and x64 (ZIP, DMG)
• Linux x64 (DEB, RPM, ZIP) and aarch64 (DEB, RPM, ZIP)

A GitHub login is required to download artifacts. Build is for testing only.