Spektrum Smart ESC (SRXL2) motor output

[MrScothh]

Still a draft, but no longer an untested one: the driver has now been run against a
real Avian, and links, drives the motor and reads telemetry correctly. What remains
open is listed at the end, and one of those items is a measurement that disagrees
with an assumption rather than a gap.

What this adds

Spektrum's "Smart Throttle" is SRXL2 carried on the ESC's throttle wire: the ESC is
an SRXL2 device and the receiver, or here the flight controller, is the bus master.
The same single wire carries throttle one way and telemetry the other.

INAV can now take that master role, which makes two things available that a PWM
connection cannot:

• Thrust reverse. On an Avian this is only reachable over Smart Throttle. Wired
  as a conventional PWM ESC there is no way to command reverse at all.
• Telemetry with no extra wire. Voltage, current, rpm and temperatures arrive on
  the throttle wire, feeding the OSD, Blackbox, current estimation and the gyro RPM
  filter. There is no telemetry lead to run and no ESC telemetry pad to connect.

The ESC's signal wire goes to a UART TX pin, not to a motor pad, and the port is
opened half duplex. motor_pwm_protocol = SRXL2 selects it. One ESC per port, so a
model with several motors needs a port each; the board refuses to arm if there are
fewer ports than motors, because a motor with no port has no timer output to fall
back on.

Reverse is a mode, THRUST REVERSE. Spektrum describe the ESC's reverse channel as
a switch — "flipping the designated switch reverses motor rotation, throttle will
still control motor speed" — so it maps onto a mode rather than onto the
reversible-motor mixer state, which models a centre-zero stick and would hand the
ESC roughly half throttle where the pilot expects the motor stopped.
FEATURE_REVERSIBLE_MOTORS is therefore cleared for this protocol, next to the line
that already does the same for brushed.

There is also a throttle-range calibration, driven from the Outputs tab or
esc_calibrate in the CLI, because a Spektrum ESC learns its endpoints from the
signal present as it powers up and that normally needs a Spektrum transmitter.

Off by default except where flash is plentiful: about 3.5 KB, enabled on H7 and AT32
and on SITL, and any other target can opt in with one line in its target.h.

How it is tested

The master is written from the published specification. Spektrum's library
implements the device side only — the bus master is not part of the open release —
so it is validated against that library, compiled as the counterpart:

inav/src/main/io/motor_srxl2.c is built for the host behind thin stubs and wired to
Spektrum's spm_srxl.c configured as a Smart ESC. Two ESCs are simulated on two
ports as two independent copies of the library, compiled under renamed symbols,
because raising SRXL_NUM_OF_BUSES turns it into a hub that forwards between buses
and two Avians on two wires do no such thing.

57 checks pass, 2175 frames reach an ESC, none rejected by their parser. Covered:
handshake and baud negotiation, throttle scaling, thrust reverse, telemetry decode,
the whole calibration sequence including every refusal, per-instance isolation on a
twin, a silent ESC on one port of two, and a deliberately starved wire that holds
the transmit buffer busy across ticks — that last one exists because the deferred
baud switch depends on isSerialTransmitBufferEmpty() answering honestly, and a
harness that always claims "drained" never tests it. It found two real defects.

Also verified over MSP against a SITL build of this branch: assigning the port,
setting the protocol, rebooting, and reading back one open port and the mode
registered.

Builds: TBS_LUCID_H7_WING, AIKONF7 (feature compiled out) and SITL with
-Werror.

Measured against an Avian

Confirmed working on the Avian 70 A Smart Lite, part SPMXAE70C.

The 70 A parts are the same controller and differ only in their battery connector -
SPMXAE70B is this one with an IC3 where the C has an IC5 - so what was measured
here holds across them.

Wider than that is expectation rather than measurement, though a well founded one:
SRXL2 is a published protocol, nothing in this driver is written for a particular
model, and any Smart ESC that speaks it should work the same way. The one thing this
bench found that genuinely varies between models is the baud negotiation, and the
driver already takes whatever an ESC advertises instead of assuming - which is
exactly why it survived meeting one that advertises nothing.

The driver was not run on a flight controller for this: the same protocol code was
driven from a host over a single-wire adapter, which is why numbers rather than
impressions appear below.

The link works. The ESC is device 0x40, announces itself unprompted at
power-up exactly as specification 7.2.1 describes for a unit id whose low nibble is
zero, and answers a directed handshake. It has to be met while it is still
announcing: one that has sat powered in silence for a while stops asking and then
ignores handshakes until it is power-cycled.

Telemetry decodes as STRU_TELE_ESC assumes. 77 requests, 77 replies. Sensor
id 0x20, pack voltage 0x09A8 -> 24.72 V on a 6S, FET temperature 0x0168 ->
36.0 C, rpm and current zero at rest. Field order, big-endian packing and every
scale are as written. The 0xFFFF/0xFF no-data path is exercised too, by the BEC
fields this ESC does not populate.

It relays a second sensor. Smart Battery telemetry, sensor id 0x42, arrives
interleaved with the ESC's own. The handler already checks that byte before
decoding, so nothing changes - but anything else reading this wire needs to.

The motor runs, and the scale is right. Reported throttle tracks commanded
throttle to within a point from 10 % upwards, with a small dead band below, and rpm
rises monotonically across 25 consecutive readings. srxl2UsToValue() is now
checked against what the ESC does with the numbers rather than only against
Spektrum's own parser.

Calibration works, and turns out to be required. Uncalibrated, that ESC ignored
everything below 1238 us - the bottom quarter of the range, silently. Calibrated by
this driver's sequence, it answered from 1050 us. docs/Spektrum Smart ESC.md now
says so where someone will read it before flying. The three-second settle taken from
the published tone timings later turned out to need adjustment - see the update
below.

The receive timeout is real. 200 ms of silence survived, 400 ms did not, and the
link recovered by itself afterwards - consistent with the 0.25 s the manual states,
and twelve times the driver's 20 ms interval. Turnaround from request to reply
measured 0.5 to 1.8 ms.

400000 baud does not exist on this ESC, and forcing it is destructive. It
advertises baudSupported = 0x00. Sending the broadcast at 400000 anyway leaves it
unreachable until the battery is pulled. The driver already cannot do this - the
agreed rate is SRXL2_BAUD_BIT_400K & baudSupported, which is zero here - and that
line turns out to be the one thing standing between this protocol and a dead link in
flight.

Two collisions this rebase turned up

Both were invisible against the older base and both would have been silent.

Serial function bit 28 is already assigned to the MassZero thermal camera in the
Configurator, whose firmware side is not on this branch. SRXL2 takes 29 instead. Say
so if the camera is going elsewhere and this can move back.

BOXTHRUSTREVERSE collided with AUTO SPEED, TERRAIN AGL HOLD and IN FLIGHT MENU; it
is now 63 with permanent id 72.

Still open

• The reported current may be the motor's, not the pack's. The ESC reported
  2.85 A while the bench supply feeding it measured 0.999 A at the same instant, at
  about 40 % throttle - the relationship expected of a converter, where pack current
  is roughly motor current times duty. One operating point cannot separate that from
  a plain scale error in the ESC's sensor, so this is stated and not concluded. It
  matters only for current_meter_type = ESC; the documentation says to prefer a
  board's own shunt meanwhile. Readings across several throttle settings against an
  instrumented supply are the next measurement.
• Whether reverse is a switch or a proportional scale. Spektrum word it both
  ways: "flipping the designated switch reverses motor rotation, throttle will
  still control motor speed" in one place, and "when selected transmitter channel
  is positioned between 0 - 100% travel, the motor will run in reverse" in the
  programming instructions. The driver assumes the first.
  docs/Spektrum Smart ESC.md describes the bench check, propeller off.
• The parameter reply framing is moot. Section 7.4 specifies the request and
  never the reply, and this ESC simply ignores 0x50 - 16 queries, no answer, with
  telemetry still flowing throughout to prove the link was up. Whatever configures
  an Avian is not this packet, so nothing in this PR depends on it.
• Companion Configurator PR: Spektrum Smart ESC (SRXL2) support in Ports and Outputs inav-configurator#2770

🤖 Generated with Claude Code

---

Update, 16 September: a longer bench session, with the numbers

Everything below was read off the ESC's own telemetry on an Avian 70 A, motor
connected except where stated. Several of these exist because the first answer was
wrong, and where an earlier claim in this PR is contradicted the measurement that
replaces it is given in full.

Asking for telemetry on every frame stops the throttle

Fixed 1250 us command, two channels in the frame, one power-up, only the request
rate changing:

requests	throttle reported	rpm	telemetry frames in 4 s
every 4th frame, 12.5 Hz	14.0 %	6606	32
every 3rd frame, 16.7 Hz	14.0 %	6605	43
every 2nd frame, 25 Hz	14.0 %	6610	64
every frame, 50 Hz	0.0 %	0	128

The link does not drop: at 50 Hz the ESC answers more often than ever and simply
stops obeying. Both the failure and the recovery happened twice in that single
power-up, so it is the rate and not an accident of ordering. The driver now clamps
to every second frame, and esc_srxl2_telemetry_rate no longer offers 50 Hz.

The rate setting was named for the wrong thing

The ESC answers about two requests in three and rotates its reply between three
sensors, so ESC data arrives at roughly a ninth of the request rate. Measured over
20 s per row:

requests/s	ESC frames/s	text page	battery	ESC
25.0	2.70	8.0/s	5.3/s	2.7/s
10.0	1.10	3.2/s	2.1/s	1.1/s
5.0	0.50	1.6/s	1.1/s	0.5/s
2.0	0.20	0.7/s	0.5/s	0.2/s

The setting's values are now named for what arrives: 3HZ, 2HZ, 1HZ, 0_5HZ,
0_2HZ, default 1HZ - which is the same behaviour the old 10HZ default had.

The block of eight channels was a confounded measurement

The earlier reading in this PR - one channel does not arm, eight does - varied the
telemetry rate at the same time. Repeated with the rate held fixed at every third
frame, same 1250 us command, one power-up:

channels in the frame	throttle	rpm
throttle only	14.0 %	6606
throttle + ch2	14.0 %	6618
throttle + ch7	14.0 %	6617
first four	14.0 %	6608
all eight	14.0 %	6610

The same five masks with telemetry requested on every frame gave 0.0 % and 0 rpm,
the single-channel mask included - the very mask that had appeared to be the cure.
So the frame now carries the throttle and the reverse channel and nothing else,
which is twelve bytes a frame less on a wire the telemetry reply has to share.

Verified through the driver itself, reading the wire between a SITL build and the
real ESC:

esc_srxl2_reverse_channel	channels on the wire
7	ch1, ch7
9	ch1, ch9
0	ch1
1 (the throttle - refused)	ch1

The calibration timings were too short

Three seconds high and five low sound the tones and store nothing. Four and seven
store it. Measured by sweeping the raw channel value and reading back the throttle
the ESC reports, motor disconnected:

	3 s / 5 s (no effect)	4 s / 7 s
starts responding at	12220 (1178 us)	2687 (1029 us)
saturates at	50820 (1781 us)	64307 (1993 us)
share of the channel used	59 %	94 %

Uncalibrated the response is linear but displaced - 0.16 % per microsecond, zero
around 1162 us and full scale around 1787 us - so 41 % of INAV's range does nothing
and full power arrives at about three quarters stick, with nothing to say so.
Calibrated, what the ESC reports tracks what INAV commands across the whole range:

commanded	reported
1050 us	5.0 %
1113 us	11.0 %
1300 us	30.0 %
1500 us	50.0 %
1691 us	69.0 %
1847 us	84.5 %
2000 us	100.0 %

SRXL2_CAL_SETTLE_MS is now 4000 and SRXL2_CAL_LOW_MS 7000.

Driving it as the mixer does

Values as the driver receives them, after calibration:

command	throttle	rpm
1000 (mincommand, disarmed)	0.0 %	0
1080 (armed, throttle_idle 8 %)	8.0 %	3520
1100	10.0 %	4480
1200	20.0 %	-

Worth knowing: uncalibrated, this ESC does not turn at INAV's armed idle at all;
calibrated, it does. Arming goes from a still propeller to a turning one, which is
correct and is the point of throttle_idle, but it changes on the day the
calibration is done.

Thrust reverse, including with the motor running

Reverse engages from rest and at speed. Engaged at 4490 rpm against an unchanged
1100 us command, the motor changed direction: one telemetry sample caught it at
0 rpm during the transition and the next had it back at the same speed the other
way, with no current step large enough to read at that load. Direction was confirmed
by eye, counter-clockwise and clockwise alternating with the channel, four passes.

Through the flight controller rather than the bench harness: with SITL armed and
THRUST REVERSE active the configured channel goes to 2000 on the wire and back to
1000 when released, alongside an unchanged throttle channel.

Finding an ESC: the polling finds nothing

An Avian announces itself six times in the 300 ms after it gains power and is mute
from then on. Against a running one, with the bus otherwise quiet:

attempt	frames sent	replies
handshake to its own address	128	0
handshake broadcast	128	0
handshake across 0x40..0x4F	128	0
control data requesting telemetry	319	0

So the link is made at power-up or not at all. A board that reboots under a battery
that stayed connected never links, and arming into that state commands a motor that
is not listening - the model arms, the telemetry looks sane, and the propeller does
not turn.

Arming is therefore refused while the link is missing. Where ESC and board come
up together this clears in about a second and is never seen. Verified both ways
against the real ESC: with the wire idle arming is refused and the OSD reports the
hardware; with the ESC linked the same configuration arms and drives it.

What is still not tested

• Only one ESC model. The usable band, the reverse channel range and its default
  vary across Avians, so nothing here assumes them.
• Throttle through SITL, which cannot emit it: the motor-writing block in mixer.c
  is compiled out under SITL_BUILD, so the throttle path was exercised against the
  ESC directly and only the frame shape, telemetry and reverse paths were checked
  through the firmware.
• The bench supply limits current to one ampere, so nothing above about 20 % throttle
  has been run under load.

[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

Add SRXL2 motor output for Spektrum Smart ESCs

✨ Enhancement 📝 Documentation ⚙️ Configuration changes 🕐 40+ Minutes

AI Description

• Adds half-duplex SRXL2 motor control and telemetry for Spektrum Smart ESCs.
• Supports thrust reverse, endpoint calibration, multi-ESC ports, and link-aware arming safeguards.
• Exposes configuration, MSP/CLI controls, SITL support, and comprehensive operating documentation.

Diagram

graph TD
  CFG["Settings and Ports"] --> MIX["Motor Output"] --> DRIVER["SRXL2 Master"] --> UART["Half-Duplex UART"] --> ESC["Smart ESC"]
  ESC -->|Telemetry| DRIVER --> SENSOR["ESC Telemetry"] --> CONSUMERS["OSD and Filters"]
  UI["CLI and MSP"] -->|Calibration| DRIVER

Loading

High-Level Assessment

The current approach is appropriate. A dedicated INAV bus master is necessary because Spektrum's published library implements only the device side, and independent UARTs avoid relying on unavailable ESC unit-ID configuration. Reusing the existing motor-output, ESC telemetry, task, mode, CLI, and MSP abstractions minimizes downstream changes while preserving explicit safety checks.

Files changed (25) +2110 / -5

Enhancement (13) +1653 / -2

pwm_mapping.cIntegrate SRXL2 with motor resource validation +20/-0

Integrate SRXL2 with motor resource validation

• Registers SRXL2 as a non-timer motor protocol and rejects configurations with fewer opened SRXL2 ports than mixer motors. This prevents partially driven multi-motor aircraft from arming.

src/main/drivers/pwm_mapping.c

pwm_mapping.hDefine the SRXL2 motor protocol identifier +4/-0

Define the SRXL2 motor protocol identifier

• Appends the persistent SRXL2 protocol value without renumbering existing stored motor protocol identifiers.

src/main/drivers/pwm_mapping.h

pwm_output.cRoute motor writes through the SRXL2 driver +15/-0

Route motor writes through the SRXL2 driver

• Initializes assigned SRXL2 ports, applies reverse and telemetry settings, and installs the SRXL2 staging function as the motor writer. It deliberately provides no PWM fallback.

src/main/drivers/pwm_output.c

cli.cAdd SRXL2 throttle calibration CLI +86/-0

Add SRXL2 throttle calibration CLI

• Adds automatic and manual 'esc_calibrate' commands with phase reporting, safety refusals, timeout guidance, and abort support.

src/main/fc/cli.c

fc_init.cApply SRXL2 startup constraints and SITL initialization +29/-0

Apply SRXL2 startup constraints and SITL initialization

• Disables incompatible center-zero reversible-motor behavior for SRXL2. It also opens SRXL2 ports directly under SITL, where the hardware motor-output layer is absent.

src/main/fc/fc_init.c

fc_msp.cExpose SRXL2 status and calibration over MSP +45/-0

Expose SRXL2 status and calibration over MSP

• Adds MSP handlers for calibration commands and reports phase, connectivity, refusal reason, opened ports, and required motor count.

src/main/fc/fc_msp.c

fc_msp_box.cRegister the THRUST REVERSE flight mode +25/-0

Register the THRUST REVERSE flight mode

• Adds a permanent THRUST REVERSE mode and exposes it only when SRXL2 is selected with a configured reverse channel.

src/main/fc/fc_msp_box.c

fc_tasks.cProcess SRXL2 buses from the PWM driver task +28/-1

Process SRXL2 buses from the PWM driver task

• Runs the SRXL2 state machines at 200 Hz and maps the armed THRUST REVERSE mode onto the ESC reverse channel. The existing PWM driver task is enabled whenever SRXL2 is active.

src/main/fc/fc_tasks.c

rc_modes.hAllocate the THRUST REVERSE mode ID +1/-0

Allocate the THRUST REVERSE mode ID

• Adds the non-conflicting internal mode identifier for SRXL2 thrust reverse.

src/main/fc/rc_modes.h

motor_srxl2.cImplement the SRXL2 Smart ESC bus master +1106/-0

Implement the SRXL2 Smart ESC bus master

• Implements independent per-UART handshakes, safe baud negotiation, framed throttle and reverse output, telemetry scheduling and decoding, stale-link recovery, and connectivity reporting. It also provides guarded automatic and manual endpoint calibration with measured timings and timeout protection.

src/main/io/motor_srxl2.c

motor_srxl2.hDefine the SRXL2 motor driver API +221/-0

Define the SRXL2 motor driver API

• Declares driver lifecycle, throttle staging, reverse control, telemetry access, connectivity, calibration phases and results, supported rates, and the four-motor limit.

src/main/io/motor_srxl2.h

msp_protocol_v2_inav.hAllocate SRXL2 MSP command identifiers +3/-0

Allocate SRXL2 MSP command identifiers

• Defines MSPv2 command IDs for SRXL2 status retrieval and calibration control.

src/main/msp/msp_protocol_v2_inav.h

esc_sensor.cFeed SRXL2 telemetry into existing ESC consumers +70/-1

Feed SRXL2 telemetry into existing ESC consumers

• Adapts SRXL2 voltage, current, temperature, and electrical RPM into the common per-motor ESC sensor data path. This makes the data available to OSD, Blackbox, current estimation, telemetry backends, and RPM filtering without a separate telemetry port.

src/main/sensors/esc_sensor.c

Bug fix (1) +6 / -1

config.cPreserve SRXL2 on builds without DSHOT +6/-1

Preserve SRXL2 on builds without DSHOT

• Narrows DSHOT validation to explicit DSHOT protocol values so non-DSHOT builds do not rewrite SRXL2 configurations to MULTISHOT.

src/main/fc/config.c

Documentation (3) +339 / -0

ESC and servo outputs.mdClarify UART-based Smart ESC output mapping +6/-0

Clarify UART-based Smart ESC output mapping

• Explains that SRXL2 Smart ESCs connect through UARTs rather than timer-backed motor outputs and links to the dedicated guide.

docs/ESC and servo outputs.md

Settings.mdDocument SRXL2 ESC settings +30/-0

Document SRXL2 ESC settings

• Documents the reverse channel, telemetry enablement, and measured telemetry-rate options, including the shared-wire bandwidth constraint.

docs/Settings.md

Spektrum Smart ESC.mdAdd comprehensive Spektrum Smart ESC guide +303/-0

Add comprehensive Spektrum Smart ESC guide

• Adds wiring, setup, multi-motor mapping, calibration, telemetry, RPM filtering, thrust reverse, reboot recovery, and safety guidance. It also records measured Avian behavior and known telemetry limitations.

docs/Spektrum Smart ESC.md

Other (8) +112 / -2

CMakeLists.txtBuild the SRXL2 motor driver +2/-0

Build the SRXL2 motor driver

• Adds the SRXL2 motor source and header to the common firmware source list.

src/main/CMakeLists.txt

fc_core.cBlock arming when SRXL2 links are missing +21/-1

Block arming when SRXL2 links are missing

• Treats any unconnected configured SRXL2 ESC as a hardware failure, preventing arming when motor commands would not reach every ESC.

src/main/fc/fc_core.c

settings.yamlConfigure SRXL2 protocol and ESC options +27/-1

Configure SRXL2 protocol and ESC options

• Adds SRXL2 to motor protocol settings and defines telemetry, delivered telemetry rate, and reverse-channel options. The rate table preserves a safe default for older stored configurations.

src/main/fc/settings.yaml

mixer.cInitialize SRXL2 motor configuration defaults +5/-0

Initialize SRXL2 motor configuration defaults

• Sets defaults for the reverse channel, telemetry enablement, and telemetry delivery rate when SRXL2 support is compiled.

src/main/flight/mixer.c

mixer.hPersist SRXL2 motor settings safely +26/-0

Persist SRXL2 motor settings safely

• Extends motor configuration with SRXL2 reverse and telemetry fields. A compatibility padding byte prevents older parameter-group data from overwriting new defaults without discarding existing motor settings.

src/main/flight/mixer.h

serial.hReserve the SRXL2 ESC serial function +3/-0

Reserve the SRXL2 ESC serial function

• Assigns serial function bit 29 to Spektrum Smart ESCs while leaving bit 28 available for the Configurator's MassZero camera assignment.

src/main/io/serial.h

target.hEnable SRXL2 support in SITL +9/-0

Enable SRXL2 support in SITL

• Opts SITL into the SRXL2 driver so simulated ESCs can connect through TCP-backed UARTs for integration testing.

src/main/target/SITL/target.h

common.hEnable SRXL2 by default on larger targets +19/-0

Enable SRXL2 by default on larger targets

• Enables SRXL2 automatically on STM32H7 and AT32F43x targets while allowing flash-constrained targets to opt in explicitly.

src/main/target/common.h

[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. Slow telemetry drops the ESC link ✓ Resolved 🐞 Bug ≡ Correctness

Description

srxl2MotorSetTelemetryRate() maps the 0.2 Hz setting to one request every 25 control frames,
exactly 500 ms, while SRXL2_RUNNING declares the link dead after 500 ms without receiving a frame.
Before the first reply to that request can be drained, the same processing pass meets the >= 500
timeout, returns the port to low baud, and leaves the powered ESC behind at the negotiated baud.

Code

src/main/io/motor_srxl2.c[R816-823]

+    static const uint8_t divisor[] = { 5, 2, 3, 10, 25 };
+
+    uint8_t every = (rate < ARRAYLEN(divisor)) ? divisor[rate] : SRXL2_TELEM_REQUEST_DEFAULT;
+
+    /* Clamped here as well as in the table, so that no future entry - or a
+     * configuration written by an older build, where index 1 meant every
+     * frame - can ask at a rate the ESC answers but will not fly at. */
+    telemRequestEvery = (every < SRXL2_TELEM_REQUEST_MIN) ? SRXL2_TELEM_REQUEST_MIN : every;

Evidence

Control frames run every 20 ms, making divisor 25 exactly 500 ms. The running state sends the
request and then immediately evaluates a 500 ms receive timeout, so no response to the newly sent
frame can have arrived yet.

src/main/io/motor_srxl2.c[154-185]
src/main/io/motor_srxl2.c[811-824]
src/main/io/motor_srxl2.c[1011-1029]

Agent prompt

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

## Issue description
The 0.2 Hz telemetry mode schedules its next possible reply no earlier than the link timeout, so the driver disconnects before receiving it.
## Fix Focus Areas
- src/main/io/motor_srxl2.c[184-188]
- src/main/io/motor_srxl2.c[811-824]
- src/main/io/motor_srxl2.c[1011-1029]
## Recommended Fix
Base the link timeout on the selected request interval with allowance for multiple unanswered requests, or use a separate sufficiently frequent link-health exchange independent of the telemetry delivery rate.

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

---

2. Powered ESCs can receive full throttle ✓ Resolved 🐞 Bug ☼ Reliability

Description

srxl2MotorCalibrationManual() checks only armed state and port presence before accepting the
manual-high phase, omitting the battery-presence guard used by unattended calibration. Running
esc_calibrate high or sending the corresponding MSP command while a sensed battery is connected
makes the next control frame command 2000 microseconds to an ESC that can already drive the motor.

Code

src/main/io/motor_srxl2.c[R867-875]

+srxl2CalResult_e srxl2MotorCalibrationManual(srxl2CalPhase_e phase)
+{
+    const srxl2CalResult_e common = srxl2CalCommonChecks();
+    if (common != SRXL2_CAL_ACCEPTED) {
+        return (calLastResult = common);
+    }
+
+    calPhase = phase;
+    calPhaseMs = millis();

Evidence

The common manual checks omit battery state, and the accepted phase is directly interpreted as the
2000 µs calibration endpoint. The automatic path already demonstrates the required safety check by
rejecting the same powered condition.

src/main/io/motor_srxl2.c[638-648]
src/main/io/motor_srxl2.c[826-859]
src/main/io/motor_srxl2.c[867-876]
src/main/fc/fc_msp.c[3831-3834]

Agent prompt

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

## Issue description
Manual-high calibration can command full throttle while a battery-sensed ESC is already powered.
## Fix Focus Areas
- src/main/io/motor_srxl2.c[826-876]
- src/main/fc/cli.c[4807-4812]
- src/main/fc/fc_msp.c[3831-3834]
## Recommended Fix
For `SRXL2_CAL_HIGH_MANUAL`, reject the request with `SRXL2_CAL_REJECT_BATTERY_PRESENT` whenever battery sensing is configured and the battery state is not `BATTERY_NOT_PRESENT`; retain the manual fallback only where voltage cannot be sensed.

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

---

3. Unsupported boards can leave every motor unwritten ✓ Resolved 🐞 Bug ≡ Correctness

Description

validateAndFixConfig() preserves PWM_TYPE_SRXL2 when USE_MOTOR_SRXL2 is absent, although the
branch assigning motorWritePtr and the SRXL2 link-health arming check are compiled out while the
protocol remains selectable and classified as non-timer-based. Selecting or restoring SRXL2 on such
firmware retains the null motor writer, bypasses timer initialization and the insufficient-output
error, and can still permit arming without functional motor output.

Code

src/main/fc/config.c[R269-275]

+    // Named explicitly rather than tested as "above BRUSHED". This is a DSHOT
+    // check, and the enum has since grown a UART protocol above DSHOT600 that a
+    // build without DSHOT can still drive perfectly well - a range test would
+    // quietly rewrite it to MULTISHOT on every boot.
+    if (motorConfig()->motorPwmProtocol >= PWM_TYPE_DSHOT150 &&
+        motorConfig()->motorPwmProtocol <= PWM_TYPE_DSHOT600) {
motorConfigMutable()->motorPwmProtocol = PWM_TYPE_MULTISHOT;

Evidence

The configuration validation retains the appended SRXL2 value without checking whether the SRXL2
feature is compiled, and the settings table exposes the protocol unconditionally. Meanwhile, both
the only SRXL2 motor-writer assignment and its link-health arming check are guarded by
USE_MOTOR_SRXL2; because the protocol properties always mark SRXL2 as not using hardware timers,
unsupported builds skip timer allocation and return successfully with the null writer rather than
reporting a PWM initialization or port-count failure.

src/main/fc/config.c[267-277]
src/main/drivers/pwm_output.c[599-634]
src/main/drivers/pwm_mapping.c[66-94]
src/main/drivers/pwm_mapping.c[435-455]
src/main/fc/settings.yaml[29-37]
src/main/drivers/pwm_output.c[599-633]
src/main/drivers/pwm_mapping.c[413-455]
src/main/fc/fc_core.c[307-324]

Agent prompt

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

## Issue description
Firmware built without `USE_MOTOR_SRXL2` can retain and select `PWM_TYPE_SRXL2` even though no compiled driver case assigns a motor writer and the SRXL2 link-health arming check is absent. Since SRXL2 is classified as a non-timer output, timer allocation is also bypassed, leaving motor writes as no-ops without a visible PWM initialization or insufficient-output error.
## Fix Focus Areas
- src/main/fc/config.c[267-277]
- src/main/drivers/pwm_output.c[599-634]
- src/main/drivers/pwm_mapping.c[66-94]
- src/main/drivers/pwm_mapping.c[438-455]
## Recommended Fix
Add explicit validation for builds without `USE_MOTOR_SRXL2` so `PWM_TYPE_SRXL2` is rejected or replaced with a supported protocol such as `PWM_TYPE_MULTISHOT`, with a visible configuration or output error where rejection is used. Keep the existing DSHOT-specific validation separate, prevent unavailable firmware from advertising SRXL2 as selectable, and ensure an unsupported protocol cannot reach the non-timer initialization path.

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

---

View high (1)

4. Some Smart ESCs can never establish a link ✓ Resolved 🐞 Bug ≡ Correctness

Description

srxl2ProcessEsc() always sends discovery handshakes only to SRXL2_ESC_ID_FIRST (0x40) despite
accepting device IDs through 0x4F. An ESC configured with a nonzero unit ID does not announce
itself and is never addressed by this poll, so its port remains in polling and arming stays blocked.

Code

src/main/io/motor_srxl2.c[997]

+            srxl2SendHandshake(e, SRXL2_ESC_ID_FIRST, SRXL2_BAUD_BIT_400K);

Evidence

The driver defines and accepts the full 0x40–0x4F ESC range, and its own polling comments state that
nonzero unit IDs require polling. The actual transmitted poll is nevertheless hard-coded to the
first ID only.

src/main/io/motor_srxl2.c[74-77]
src/main/io/motor_srxl2.c[498-506]
src/main/io/motor_srxl2.c[980-998]
src/main/fc/fc_core.c[307-325]

Agent prompt

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

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
Issue description
SRXL2 discovery polls only device ID `0x40`, although the driver recognizes ESC IDs `0x40` through `0x4F` and documents that nonzero-unit ESCs require polling because they do not announce. Such an ESC therefore cannot complete the handshake.
Fix Focus Areas
- src/main/io/motor_srxl2.c[74-77]
- src/main/io/motor_srxl2.c[980-998]
Recommended Fix
Track a discovery device ID per ESC instance and rotate through `0x40` to `0x4F` while polling, resetting the scan when a valid handshake is received. Preserve the one-ESC-per-port behavior and only finalize negotiation with the ID that replied.

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

---

5. Slow telemetry vanishes between samples ✓ Resolved 🐞 Bug ≡ Correctness

Description

srxl2MotorGetTelemetry() rejects every reading after a fixed one-second age, and
escSensorUpdate() then increments its age on every busy-loop callback rather than on expected
telemetry opportunities. At the offered 0.5 Hz rate, readings disappear for roughly half of each
interval, while consumers using voltage, current, temperature, and combined ESC data repeatedly see
no valid sensor.

Code

src/main/io/motor_srxl2.c[R187-188]

+/* Telemetry older than this is reported as stale rather than current. */
+#define SRXL2_TELEM_STALE_MS        1000

Evidence

The driver offers 0.5 Hz and 0.2 Hz delivery but makes every sample invalid after one second. The
ESC sensor adapter is called from a documented busy-loop callback, causing its failure branch to
advance to invalid almost immediately once that timestamp expires.

src/main/io/motor_srxl2.c[811-824]
src/main/io/motor_srxl2.c[1094-1103]
src/main/sensors/esc_sensor.c[282-303]
src/main/fc/fc_core.c[1092-1108]

Agent prompt

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

## Issue description
The fixed one-second freshness window is shorter than supported telemetry intervals and invalidation is advanced at busy-loop frequency.
## Fix Focus Areas
- src/main/io/motor_srxl2.c[187-188]
- src/main/io/motor_srxl2.c[1094-1103]
- src/main/sensors/esc_sensor.c[273-303]
## Recommended Fix
Derive freshness from the configured delivery interval with jitter and missed-response allowance, and update `dataAge` only when an expected sample opportunity is missed rather than on every realtime callback.

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

---

6. Missing telemetry becomes a zero reading ✓ Resolved 🐞 Bug ≡ Correctness

Description

srxl2DecodeEscTelemetry() clears every field and skips sentinel-valued measurements, but then sets
one overall valid flag without recording which individual values were absent. When an ESC omits
current, voltage, temperature, or RPM while reporting other fields, downstream consumers receive a
fresh zero rather than an unavailable measurement.

Code

src/main/io/motor_srxl2.c[R490-491]

+    t->lastUpdateMs = millis();
+    t->valid = true;

Evidence

The decoder recognizes per-field sentinel values but merely leaves those fields at the zero
established by memset, after which it marks the whole structure valid. The adapter copies those
zeroes into standard ESC telemetry without any per-field validity check.

src/main/io/motor_srxl2.c[462-492]
src/main/io/motor_srxl2.h[52-69]
src/main/sensors/esc_sensor.c[282-299]

Agent prompt

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

## Issue description
Per-field no-data sentinels are converted into valid zero readings because telemetry has only one aggregate validity flag.
## Fix Focus Areas
- src/main/io/motor_srxl2.c[462-492]
- src/main/io/motor_srxl2.h[52-69]
- src/main/sensors/esc_sensor.c[282-299]
## Recommended Fix
Add validity flags for each exported measurement and propagate them into consumers, or reject/retain fields explicitly so sentinel values are never presented as fresh numeric zeroes.

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

---

7. Reverse mode always reports inactive ✓ Resolved 🐞 Bug ≡ Correctness

Description

initActiveBoxIds() advertises BOXTHRUSTREVERSE, but packBoxModeFlags() never copies
IS_RC_MODE_ACTIVE(BOXTHRUSTREVERSE) into the outgoing active-box bitmask with CHECK_ACTIVE_BOX.
When the reverse switch is active, the motor driver can consume its runtime state internally while
Configurator and other MSP clients still receive a clear bit and display the mode as inactive.

Code

src/main/fc/fc_msp_box.c[R417-419]

+    if (motorConfig()->motorPwmProtocol == PWM_TYPE_SRXL2 && motorConfig()->srxl2ReverseChannel != 0) {
+        ADD_ACTIVE_BOX(BOXTHRUSTREVERSE);
+    }

Evidence

The active-box list includes thrust reverse and determines its position in the MSP bitmask, while
the motor driver reads the mode's runtime state. However, the complete serialization population list
has no corresponding entry, and serialization emits only bits whose activeBoxes entries were
populated, so the advertised thrust-reverse bit remains zero regardless of the switch's actual
state.

src/main/fc/fc_msp_box.c[399-419]
src/main/fc/fc_msp_box.c[426-525]
src/main/fc/fc_tasks.c[335-340]
src/main/fc/fc_msp_box.c[400-419]

Agent prompt

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

## Issue description
The new Thrust Reverse mode is advertised in the active-box list and consumed internally, but omitted from MSP active-mode status serialization, preventing MSP clients from displaying its active state.
## Fix Focus Areas
- src/main/fc/fc_msp_box.c[399-419]
- src/main/fc/fc_msp_box.c[426-525]
- src/main/fc/fc_tasks.c[335-340]
## Recommended Fix
Add `CHECK_ACTIVE_BOX(IS_RC_MODE_ACTIVE(BOXTHRUSTREVERSE), BOXTHRUSTREVERSE)` to `packBoxModeFlags()` alongside the other mode-state serialization entries. Apply the same feature conditions used when advertising the box so the serialized flag corresponds to its active-box-list position.

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

---

View medium (3)

8. Invalid reverse settings fail silently ✓ Resolved 🐞 Bug ≡ Correctness

Description

The setting range accepts channels 1 through 4 and initActiveBoxIds() advertises reverse for every
nonzero value, although the documented ESC range is 5 through 9 and channel 1 aliases throttle. A
user can therefore configure and activate a visible reverse mode that either gets disabled
internally or sends a channel the ESC does not support, with no validation error.

Code

src/main/fc/settings.yaml[R884-890]

+      - name: esc_srxl2_reverse_channel
+        description: "For an SRXL2 Smart ESC, the 1-based auxiliary channel its \"Thrust Rev.\" setting selects to arm reverse. Spektrum allow channels 5 to 9 and ship channel 7 by default. Must match how the ESC was programmed, because nothing on the wire advertises it. 0 disables reverse."
+        default_value: 7
+        field: srxl2ReverseChannel
+        condition: USE_MOTOR_SRXL2
+        min: 0
+        max: 9

Evidence

The YAML constraint is only 0–9 even though its own description states 5–9. Mode registration tests
only nonzero, while the driver silently converts channel 1 to disabled and does not enforce the
ESC's 5–9 restriction for channels 2–4.

src/main/fc/settings.yaml[884-890]
src/main/fc/fc_msp_box.c[414-419]
src/main/io/motor_srxl2.c[761-808]

Agent prompt

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

## Issue description
Configuration accepts unsupported reverse channels and still advertises an operational reverse mode.
## Fix Focus Areas
- src/main/fc/settings.yaml[884-890]
- src/main/fc/fc_msp_box.c[414-419]
- src/main/io/motor_srxl2.c[761-808]
## Recommended Fix
Validate the value as exactly zero or 5 through 9 during configuration loading, reject invalid CLI/MSP writes, and advertise the mode only when the normalized channel is usable.

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

---

9. Some builds lose the calibration CLI ✓ Resolved 🐞 Bug ≡ Correctness

Description

Both cliEscCalibrate() and its command-table entry are nested under USE_USB_MSC in addition to
USE_MOTOR_SRXL2, despite calibration having no mass-storage dependency. SRXL2 builds without the
optional MSC feature—including the explicitly enabled SITL configuration and applicable H7 and AT32
targets—omit the documented esc_calibrate command while retaining the driver and MSP calibration
paths.

Code

src/main/fc/cli.c[R4745-4747]

#ifdef USE_USB_MSC
+#ifdef USE_MOTOR_SRXL2
+static void cliEscCalibratePrintResult(srxl2CalResult_e r)

Evidence

The implementation and command registration are both visibly enclosed by the pre-existing
USE_USB_MSC guard, while build logic enables USB mass storage only for targets carrying the
optional MSC feature. SITL explicitly enables SRXL2 without defining USB mass-storage support, and
the calibration implementation resides entirely in the SRXL2 driver with its own safety checks; MSP
likewise exposes calibration under only USE_MOTOR_SRXL2, demonstrating that the USB dependency is
unrelated.

src/main/fc/cli.c[4745-4828]
src/main/fc/cli.c[5107-5114]
src/main/target/SITL/target.h[57-65]
src/main/fc/fc_msp.c[3815-3839]
src/main/fc/cli.c[4745-4827]
src/main/fc/cli.c[5107-5115]
cmake/stm32.cmake[327-338]
src/main/io/motor_srxl2.c[826-876]

Agent prompt

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

## Issue description
The SRXL2 calibration CLI implementation and command registration are accidentally compiled only when unrelated USB mass-storage support is enabled. SRXL2 targets without the optional MSC build feature therefore cannot use the documented CLI calibration flow even though the driver API requires only SRXL2 support.
## Fix Focus Areas
- src/main/fc/cli.c[4745-4828]
- src/main/fc/cli.c[5107-5115]
- src/main/target/SITL/target.h[57-65]
- cmake/stm32.cmake[327-338]
- src/main/io/motor_srxl2.c[826-876]
## Recommended Fix
Move the SRXL2 calibration helper and command registration outside the `USE_USB_MSC` blocks while retaining their `USE_MOTOR_SRXL2` guards. Leave only the existing `msc` command under `USE_USB_MSC`.

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

---

10. Malformed traffic can corrupt link negotiation ✓ Resolved 🐞 Bug ☼ Reliability

Description

srxl2DrainRx() accepts every CRC-valid frame from five bytes onward, and srxl2HandleFrame()
dispatches a Handshake without requiring sizeof(Srxl2HandshakeFrame). A short frame marked as a
handshake then makes srxl2HandleHandshake() consume payload fields that were not received,
allowing stale receive-buffer bytes to determine the discovered device and baud negotiation.

Code

src/main/io/motor_srxl2.c[R604-614]

+        if (e->rxLen == 3) {
+            e->rxExpected = e->rxBuf[2];
+            if (e->rxExpected < SRXL2_MIN_FRAME || e->rxExpected > SRXL2_MAX_FRAME) {
+                e->rxLen = 0;           /* bogus length, drop and resynchronise */
+                continue;
+            }
+        }
+
+        if (e->rxExpected && e->rxLen >= e->rxExpected) {
+            srxl2HandleFrame(e, e->rxBuf, e->rxLen);
+            e->rxLen = 0;

Evidence

The parser's minimum accepted frame length is five bytes and dispatch validates only the CRC and
packet type. The packed handshake structure is 13 bytes, but its handler reads handshake payload
values after no length validation.

src/main/io/motor_srxl2.c[590-618]
src/main/io/motor_srxl2.c[498-553]
src/main/io/motor_srxl2.c[567-588]
src/main/rx/srxl2_types.h[81-86]

Agent prompt

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

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution
Issue description
The SRXL2 receive parser accepts a CRC-valid five-byte frame and dispatches it as a handshake without checking the handshake structure length. The handshake handler then reads fields outside the logical received frame, so stale buffer contents can affect link setup.
Fix Focus Areas
- src/main/io/motor_srxl2.c[498-553]
- src/main/io/motor_srxl2.c[567-588]
- src/main/io/motor_srxl2.c[590-618]
- src/main/rx/srxl2_types.h[81-86]
Recommended Fix
Before calling `srxl2HandleHandshake()`, require `len >= sizeof(Srxl2HandshakeFrame)` (or require the protocol-defined exact handshake length). Reject malformed handshake frames without updating state, device ID, handshake counters, or baud capabilities.

ⓘ 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 group findings by type and pick your Finding display, from Minimal to Full

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[MrScothh]

Thanks - all ten were real, and all ten are fixed in ac906d2. Two of them were serious, so worth spelling out:

Slow telemetry dropping the link (1) was worse than the finding says. Nothing but a telemetry reply refreshes the receive timer, because a running Avian never speaks unprompted - so the request rate is the link-liveness rate. On top of the 25-frame case landing exactly on the timeout, this ESC answers only about two requests in three, so the 10-frame setting could also miss for 600 ms. And a dropped link is unrecoverable here: the driver returns to polling, and a running Avian answers no discovery of any kind (measured: 128 handshakes to its address, 128 broadcasts, 128 spread across 0x40..0x4F, 319 control frames requesting telemetry - zero replies). So the timeout could kill a healthy motor in flight with no way back.

I removed the two slow settings rather than making the timeout elastic, which would have hidden the failure the timeout exists to catch. The table now stops at one request every five frames - a reply typically every 150 ms, three consecutive misses still inside the 500 ms window - and the constants carry that reasoning. Related, (5): the stale window was 1 s while the ESC's own readings arrive about once a second, so a healthy sensor flickered; it is 3 s now, with the link timeout doing the job of noticing a stopped ESC.

Manual calibration into a live ESC (2) - correct, and it was the worse half: the unattended wizard refused a connected battery and the hand-typed command did not. Guarded now, with boards that cannot sense the pack unaffected, which is the case that path exists for.

The rest: handshake length checked before the payload is read (10); discovery now walks 0x40..0x4F instead of only the ID that announces itself, which is what the comment claimed it did (4); THRUST REVERSE is packed into the outgoing box bitmask, so the Configurator stops showing it off while the driver acts on it (7); esc_calibrate no longer sits inside #ifdef USE_USB_MSC - it was absent from every build without mass storage, SITL included, and is verified present there now (9); a configuration selecting SRXL2 on a build without the driver falls back at boot instead of arming and driving nothing, and reverse on channel 1 is corrected to 0 rather than refused silently (3, 8); telemetry fields are tracked individually, so an ESC that does not report current no longer delivers 0.00 A for the battery estimate to believe (6).

The PR description also now carries the full bench data behind the recent changes - the rate table, the mask sweep, the calibration band before and after, and the thrust reverse measurements.

[MrScothh]

Rebased onto current maintenance-10.x (73 commits) - the conflict was an MSP number collision: MSP2_INAV_MAG_UNALIGNED landed on 0x2232, which this branch was using for the SRXL2 status command. A released command keeps its number and an unmerged one has no claim on it, so the SRXL2 pair moved up to 0x2233/0x2234.

That also closes the one review thread still open, (8). My earlier pass only normalised channel 1 - the throttle alias the driver refuses outright - and left 2 to 4 accepted, still advertising a reverse mode no Smart ESC can act on. Since the setting's range cannot express "zero, or five to nine", anything between is now corrected to zero at boot, where it is visible rather than silently ineffective. Verified by saving 3, 7 and 9 and rebooting: 3 comes back as 0, 7 and 9 survive.