A PX4 proposal updated in November 2026 makes the boundary visible. It would add MSP and four-way ESC configuration support to selected PX4 platforms, with particular attention to a half-duplex UART on ESC output pins, host-tool compatibility and recovery to normal flight-controller operation. The patch is substantial, and its author's hardware tests are useful, but it is still a pull request rather than a general PX4 release promise.
The important design question is not whether a browser can find the ESC. It is how the system ensures that the configurator, flight-control output driver and ESC bootloader do not all believe they own the same wire.
The ESC signal pin normally belongs to flight control
During flight, motor outputs carry time-sensitive commands. Betaflight's ESC documentation describes DShot as a digital command protocol and distinguishes bidirectional DShot telemetry from reversible motor operation. An ESC configurator needs a different conversation: identify the ESC, read configuration, possibly alter motor direction or firmware, then finish cleanly.
Those operations should not share the pin concurrently. A configuration transaction is not an extra throttle message. It may use a bootloader protocol and timeouts entirely unlike the normal motor-control path.
The PX4 PR #29680 proposes an explicit switch to an ESC configuration server. At the first configuration request, that server stops the DShot and PWM output drivers, then forwards four-way commands over a bit-banged ESC pin UART. The author describes pin ownership enforced by the output-resource manager, so the normal driver and the configuration UART refuse to claim a pin that another driver already holds.
This is the right kind of isolation to investigate. A connection method alone does not protect the motor output from two pieces of firmware trying to use it simultaneously.
Why host software expects MSP and four-way commands
Popular configuration tools, including AM32 Configurator and ESC Configurator, expect a flight controller that exposes an MSP endpoint and can relay four-way commands to ESC bootloaders. The PX4 contributor contrasts that expectation with PX4's existing MAVLink SERIAL_CONTROL passthrough facility.
The proposal says the existing serial passthrough is presented through a Linux pseudoterminal, which browser configurators cannot simply open as the physical serial interface they expect. The new server is designed to accept MSP on a real serial port and change to the four-way transaction protocol after MSP_SET_PASSTHROUGH.
That difference is easy to overlook. MAVLink is a vehicle communications protocol; MSP and four-way serve a particular configurator workflow. Translating between transports requires a server with defined session state, rather than treating a motor output as a transparent byte pipe.
ArduPilot already documents a mature but hardware-dependent version of this workflow. Its BLHeli and AM32 passthrough guide requires ESC-compatible configuration, DShot-capable outputs and the appropriate configurator. The guide also warns that passthrough is unavailable on outputs handled by certain IOMCU coprocessors; on such boards, FMU or AUX outputs are used instead.
That restriction is a practical reminder that the connector label on the outside of a controller is less important than which processor and timer actually drive it.
Timing is stricter than ordinary USB messaging
The new PX4 code describes a single-wire half-duplex UART emulated through NXP FlexIO at 19,200 baud. According to the contributor, the ESC bootloader can discard a frame if a gap exceeds roughly 260 microseconds. The proposal therefore tries to keep the transmitted frame contiguous and avoid a five-millisecond read cycle splitting the bytes.
The exact byte timing comes from the PR's implementation notes. It should not be generalized to every ESC family or every bootloader. Still, the underlying mechanism is clear: asynchronous software may queue a complete command successfully while an underlying scheduler or peripheral driver delivers the command with an unacceptable pause.
The contributor reports tests on an MR-VMU-TROPIC board with an AM32 ESC and propellers removed. In that setup, the PR lists an InitFlash transaction taking 18 ms, a 184-byte settings read taking 109 ms and a settings write taking 141 ms. The same author reports a 29 ms initialization on a Betaflight configuration of the board. These are contributor-reported bench timings, not independent performance rankings or field reliability measurements.
The proposal says NXP hardware is the main tested target. It suggests that enabling the configuration option may be sufficient on some STM32F7/H7 boards that already have the relevant backend, but explicitly notes those boards were not tested in the described work. That caveat matters more than the apparent simplicity of the configuration flag.
A safe session needs a beginning and an end
There are several ways to give a computer access to the ESC configuration server. The PX4 proposal lays out three: a parameter-selected boot mode, USB protocol detection, or an explicit server on a chosen serial device.
The parameter route sets PASSTHRU_EN=2 and reboots. In the described design, the flight startup sequence skips ordinary output-driver startup and hands USB to the ESC server. The parameter resets in that boot, and the flight controller reboots again at session end to return to normal operation. This is an explicit maintenance state, at the cost of disconnecting the usual ground-station session during configuration.
An alternative, SYS_USB_AUTO=1, attempts to detect MSP from initial USB bytes. That is closer to the way a user expects a web configurator to connect, but the PR notes that the option is not the default and that detection only happens once per USB connection. Whoever opens the port first may determine which protocol gets selected. The contributor asks reviewers whether both routes should be retained.
The distinction is operational, not cosmetic. An implicit transport handoff depends on connection order. An explicit reboot into a maintenance mode is less convenient but makes the system state easier to reason about. Neither can be judged by connection speed alone.
One further control in the proposal is the refusal to start ESC sessions while the vehicle is armed. That is a necessary guard, but it is not a complete safety procedure. ESC configuration and motor testing must occur with the propellers removed, under supervised bench conditions.
Motor direction is a configuration dependency, not an isolated setting
Changing motor direction is a common use of an ESC configurator. It also affects the assumptions in the flight controller's actuator geometry. A quadrotor can have four correctly spinning motors and still have the wrong direction pattern for its mixer.
The PX4 actuator guide emphasizes checking output assignments and spin direction with propellers removed. The ArduPilot passthrough documentation also describes combinations of configurator, firmware, DShot mode and output mapping that must match before passthrough is available.
After an ESC firmware flash or direction change, the relevant validation is end to end:
- Confirm that the configuration session closed and the normal flight-control output driver resumed.
- Verify the ESC firmware identity and the actual saved direction, rather than trusting only a success toast in the browser.
- With propellers still removed, compare each motor's physical spin with the expected vehicle geometry.
- Check actuator assignment, idle behavior and relevant telemetry before returning the aircraft to service.
A backup of the original ESC settings is useful because a successful flash can still leave a different configuration from the one the aircraft previously used. Firmware updates should be performed with stable electrical power, using the exact ESC target and vendor-supported recovery procedure.
What the proposal proves, and what remains open
The PX4 PR offers a tangible bench demonstration: the contributor says it could connect through AM32's Chrome configurator, read settings, change and restore direction, and reboot the flight controller back into its normal state. It also reports image dumping and firmware flashing on the tested ESC.
Those observations support the feasibility of that particular path. They do not establish broad support for BLHeli_S, BLHeli32 and every AM32 hardware variant; nor do they show production-grade behavior after a power interruption halfway through flashing, a dropped USB connection or a controller crash during the handoff.
Independent testing should cover interrupted transactions, unexpected disconnection, mixed ESC models on one airframe, and an attempted session while armed. It should also verify that the controller returns to a known output state after each failure. Where an ESC bootloader offers recovery paths, those should be documented for that target rather than inferred from another family.
There is a useful contrast here with routine MAVLink serial passthrough: whether the goal is talking to a peripheral UART or taking over motor pins for an ESC bootloader, the maintenance session must release its resources afterward. The protocols differ, but uncontrolled ownership transfer can leave the vehicle with communications or outputs in the wrong state.
The engineering lesson
ESC passthrough looks like a feature request from a configurator's point of view. Inside a flight controller, it is a constrained transition between two operating modes that use the same hardware.
The best evidence of quality will not be the number of configurators that connect once. It will be clear pin ownership, bounded transaction timing, explicit arming guards, reversible session setup and predictable recovery when a tool or cable fails. Only after those behaviors are demonstrated across supported boards can ESC passthrough be treated as dependable maintenance infrastructure.