Why is my RCOU output stuck while RCIN keeps moving?

The autopilot is receiving pilot input but not producing differential output. Most common causes: servo seized, ESC not armed (Copter), the SERVOn_FUNCTION mapping is wrong, or SERVOn_MIN equals SERVOn_MAX. Verify the function mapping for that channel and then bench-test the servo or ESC.

Does ArduPilot log the receiver's raw SBUS frames?

No. ArduPilot logs the decoded PWM values per channel in RCIN, after the protocol layer extracts them. If you suspect SBUS-level corruption, you need a protocol analyser on the receiver-to-FC line; the log alone can't see frame-level errors.

How do I tell radio failsafe from a servo failure in the log?

Radio failsafe writes ERR Subsys=5 ECode=1 and changes MODE.Rsn to 3 (RADIO_FAILSAFE). RCIN values typically freeze or jump to the receiver's failsafe positions. A servo failure leaves RCIN healthy but the matching RCOU channel either flatlines, hits an end-stop, or oscillates without matching the input.

What's the difference between RCIN.C3 = throttle and SERVO3_FUNCTION = throttle?

They're independent. RCIN.C3 is the third channel coming off the receiver — usually throttle by RC convention. SERVO3_FUNCTION says what physical output to drive on the third servo pin. The autopilot mixes RCIN through the flight controller into RCOU according to the SERVO function map. The two only match by convention; you can map them independently in the parameters.

How do I diagnose a stuck control surface from the log alone?

Confirm SERVOn_FUNCTION for the surface, plot the corresponding RCOU.Cn, and compare against RCIN.Cn for that channel and against the autopilot's attitude command (ATT.DesRoll/DesPitch). If RCOU moved but the airframe didn't (ATT.Roll didn't follow ATT.DesRoll), the surface itself isn't responding. If RCOU didn't move, the autopilot didn't command it — that's a mapping or mixing problem, not a servo one.

Why does RCOU show pulses when nothing was commanded?

Idle PWM. ArduPilot will hold RCOU at the configured neutral for each channel (typically SERVOn_TRIM, around 1500 µs) even when no input is present. That's not the same as a stuck output — a stuck output stays at one value when the input is moving.

Diagnosing Control Surface Failures Using RCIN and RCOU Logs

TL;DR: On an ArduPilot vehicle, control surface failures show up as a divergence between RCIN.C1-C4 (what the receiver delivered) and RCOU.C1-C4 (what the autopilot sent to the servo or ESC). If RCIN moved but RCOU stayed flat at 1500µs, you have an output-side problem — servo, ESC, or SERVOn_FUNCTION mapping. If RCIN itself froze at the last frame, the receiver lost link. Comparing the two against each other and against the SERVOn_FUNCTION mapping is the fastest path to a root cause.

What RCIN and RCOU actually log

RCIN  TimeUS  C1  C2  C3  C4  C5  C6  C7  C8  C9  C10  C11  C12  C13  C14
RCOU  TimeUS  C1  C2  C3  C4  C5  C6  C7  C8  C9  C10  C11  C12  C13  C14

Both messages carry PWM values in microseconds, typically 1000–2000µs. RCIN is the receiver's frame output after RC trim and reverse processing; RCOU is what the autopilot wrote to the servo rail after mixing, scaling, and failsafe logic. Channels 15 and 16 live in RCI2 / RCO2 for the 16-channel build. The override_mask in RCI2 tells you which channels were overridden by MAVLink (a GCS or LUA script driving outputs independent of the receiver).

The mapping you need before reading the log

RCOU.C1 is not always "motor 1". The mapping is set by SERVO1_FUNCTION, SERVO2_FUNCTION, etc. Common defaults:

On a Copter: SERVO1-4_FUNCTION = 33-36 → motors 1-4 in the firmware's frame order.
On a Plane: SERVOn_FUNCTION = 4 → aileron, 19 → elevator, 21 → rudder, 70 → throttle.
On a QuadPlane: motors 1-4 are typically wired to SERVO5-8 to keep SERVO1-4 free for forward-flight surfaces.

Verify the mapping for the airframe at hand before reading the log — the comparison only makes sense if you know which physical surface RCOU.Cn drives.

How to spot a stuck output in Mission Planner

Plot RCIN.C1 and RCOU.C1 on the same axis. Four patterns:

RCIN moves, RCOU follows: normal. The autopilot is acting on pilot input.
RCIN moves, RCOU stuck at 1500: output-side problem. Servo seized, ESC not armed, or the SERVOn_MIN/SERVOn_MAX range is collapsed to a point.
RCIN frozen, RCOU still moving: the autopilot is in an autonomous mode driving the output itself; the receiver may have lost link. Look at RCIN.C1 for >200 ms of the exact-same PWM value — that's the receiver repeating its last frame.
Both flat at one end-stop: failsafe or kill-switch active. Cross-check against MODE.Rsn for the failsafe class.

Confirming in MAVExplorer

MAV> graph RCIN.C1 RCIN.C2 RCIN.C3 RCIN.C4
MAV> graph RCOU.C1 RCOU.C2 RCOU.C3 RCOU.C4

If you suspect failsafe involvement:

MAV> messages ERR
MAV> graph MODE.ModeNum MODE.Rsn

ERR Subsys=5 ECode=1 is the radio failsafe trigger; the autopilot will hold RCOU at its configured failsafe values from that point. MODE.Rsn=3 on the same timestamp is the matching mode change.

Common failure modes — ranked

Receiver link loss. RCIN frame counter freezes, frames repeat the last value. Modern receivers (CRSF, ELRS) and SBUS with failsafe configured will instead drop to a defined failsafe channel set — check the receiver's documentation for what its failsafe frames look like in PWM.
Servo stall or dead servo. RCOU moves cleanly but the airframe doesn't respond. Mechanical, not log-visible directly — cross-check by graphing the corresponding ATT.DesRoll/ATT.Roll divergence and the rate RATE.R response. If the autopilot commanded a roll and the airframe didn't comply, a servo isn't moving.
Wrong SERVO_FUNCTION mapping. The output you thought was aileron is actually flap. RCOU moves on the wrong physical surface, controllability is gone, blame falls on the wrong subsystem. Verify the mapping matches your physical wiring before chasing other ghosts.
SBUS or CRSF channel offset. Some receivers report 16 channels but only 8 are wired through; off-by-one channel mapping looks like a control surface that doesn't respond.
ESC arming desync. On Copter, an ESC that missed the arming sequence stays at minimum throttle while the others spin. RCOU shows correct values but the motor doesn't follow — pair with our ESC desync post.

Setting up failsafe responses you can read in the log

The receiver should be configured to either drop the throttle channel or stop reporting frames entirely on link loss. ArduPilot's FS_THR_VALUE sets the throttle PWM threshold below which the autopilot declares failsafe. FS_THR_ENABLE = 1 triggers RTL on failsafe; = 3 triggers SmartRTL; = 4 triggers Land. The ERR Subsys=5 line confirms the failsafe path actually executed.

When this isn't an RCIN/RCOU problem

Bad receiver protocol. If the autopilot reports zero RC input at boot but the receiver is healthy, RC_PROTOCOLS may be set wrong. The fix is in parameters, not the channel map.
SBUS inverted polarity. Some FCs need SBUS inverted; others auto-detect. A wholly-zero RCIN trace at startup, fixing itself if you swap the input port, points here.

When LogHat helps — and when it doesn't

We flag every RCIN/RCOU divergence above a configurable threshold and correlate it with attitude rate response so you can see whether a missing control input actually mattered for the flight. What we can't tell you is which servo cable is loose — that requires you to wiggle them with the airframe on a stand.