TL;DR — if your ExpressLRS receiver won’t lock on a MicoAir743v2-AIO under PX4, move it off the RC pads. The RX6 pin has an SBUS inverter permanently wired to it, and a CRSF receiver can’t share that line. Any other UART works.
Posting this because I lost most of a day to it and found nothing when I searched. Hopefully it saves someone else the trouble.
Setup
- Board: MicoAir743v2-AIO-35A (board ID 1179)
- Firmware: PX4 v1.16.2, git
54f0455, built 22 Apr 2026,Build uri: localhost(vendor build — this board only landed upstream at 1.16.0) - Receiver: HappyModel EP2, ExpressLRS 4.1.0, Serial 1 Protocol
CRSF, baud420000 - Handset: 250 Hz packet rate, receiver bound and solid LED (linked) throughout
Symptoms
rc_input statussits atsearching for signal: CRSFforeverUART RX bytesclimbs steadily — data is arriving, so it’s not a dead wirepublish intervalstays at zero or creeps up a few events- Occasionally one valid frame lands with completely plausible channel values, then nothing for minutes
- QGC Radio page shows no stick movement
- Receiver LED solid the entire time
The solid LED is what makes this so confusing. Every indicator says the radio link is healthy, because it is.
The diagnostic that cracked it
rc_input status has what you need, but you have to do a little arithmetic. The driver runs at 250 Hz:
elapsed seconds = cycle events × 0.004
byte rate = UART RX bytes ÷ elapsed seconds
A CRSF RC channels frame is 26 bytes, so compare against your packet rate:
| ELRS packet rate | Expected bytes/sec |
|---|---|
| 50 Hz | ~1,300 |
| 150 Hz | ~4,000 |
| 250 Hz | ~6,500 |
| 500 Hz | ~13,000 |
Run it twice ~10 s apart and take the delta — more reliable than since-boot totals.
Also watch publish interval. That counter only increments when a frame parses and passes CRC. Bytes climbing while publishes stay flat means the data is arriving corrupted, not missing. That distinction is the whole ballgame — it rules out wiring, baud, inversion and protocol in one shot, and points at signal integrity.
The numbers
Same board, same receiver, same session, same settings. Only the UART changed.
RX6 (UART6, ttyS5) |
RX1 (UART1, ttyS0) |
|
|---|---|---|
| Byte rate | ~580 B/s | 6,527 B/s |
| Expected @ 250 Hz | ~6,500 B/s | ~6,500 B/s |
| Frames parsed | ~1 in 500 | 6,365 |
| Effective rate | sporadic | 240 Hz |
| State | searching forever |
found: CRSF, held |
On RX6:
nsh> rc_input status
INFO [rc_input] Max update rate: 250 Hz
INFO [rc_input] UART device: /dev/ttyS5
INFO [rc_input] UART RX bytes: 34782
INFO [rc_input] RC state: searching for signal: CRSF
rc_input: cycle time: 15832 events, 104239us elapsed, 6.58us avg
rc_input: publish interval: 4 events, 194020.00us avg
On UART1, nothing else changed:
nsh> rc_input status
INFO [rc_input] Max update rate: 250 Hz
INFO [rc_input] UART device: /dev/ttyS0
INFO [rc_input] UART RX bytes: 172959
INFO [rc_input] RC state: found: CRSF
INFO [rc_input] CRSF Telemetry: yes
rc_input: cycle time: 6626 events, 104259us elapsed, 15.73us avg
rc_input: publish interval: 6365 events, 4162.75us avg, min 2238us max 12053us
Root cause
From MicoAir’s own docs for this board:
The default RC input is configured on the UART6. The SBUS pin is inverted and connected to RX6. Non SBUS, single wire serial inputs can be directly tied to RX6 if SBUS pin is left unconnected. RC could be applied instead at a different UART port such as UART2, UART4 or UART8.
SBUS is an inverted protocol, so the board puts a hardware inverter in front of RX6. That inverter’s output is permanently wired to the RX6 node — not switched, not gated, not firmware-controlled.
An inverter output is a push-pull driver. So is your ELRS receiver’s TX pad. Two push-pull outputs on one node fight: whichever is stronger wins each bit, and the loser’s data is corrupted. You get a stream at roughly the right volume, mangled past CRC recovery, with the rare frame surviving by luck.
Note the “if SBUS pin is left unconnected” caveat is misleading. A floating inverter input does not produce a high-impedance output — it produces a driven output at whatever level the floating input resolves to. Nothing was connected to the SBUS pad or the HD VTX connector at any point in my testing. Leaving it empty does not remove the contention.
ArduPilot users don’t hit this because ArduPilot’s default RC path on this board expects SBUS through that inverter. And the vendor documents the caveat only under a heading titled “RC Input (Ardupilot)” — directly below a PX4 UART mapping section. A PX4 user has no reason to scroll into the ArduPilot section, and the pads are labelled for RC, so using them is the obvious move.
The fix
Rewire to any spare UART. I used UART1 (TELEM1, /dev/ttyS0):
- Receiver
T→ FC RX1 - Receiver
R→ FC TX1 - Receiver
+→ 5V,−→ GND
TELEM1 is claimed by a MAVLink instance by default — clear it first or two drivers will fight over the port:
param show MAV_0_CONFIG
param show RC_PORT_CONFIG
param set MAV_0_CONFIG 0
param set RC_PORT_CONFIG 101
param set RC_INPUT_PROTO 6
param save
reboot
Read the enum param show RC_PORT_CONFIG prints rather than trusting 101 — numbering can differ between builds. Then confirm rc_input status reports UART device: /dev/ttyS0 before reading anything else into the output.
Things that are NOT the problem
All tested and eliminated before the UART move:
- Packet rate / buffer overrun — identical failure at 250 Hz and 50 Hz
- CRSF telemetry from the FC — identical with ELRS Telem Ratio set to Off
- DShot DMA contention —
PWM_MAIN_TIM0 400,dshot not running, no change. This is not the ARK FPV issue (PR #24573), which has similar symptoms from a different cause. If you got here from that thread, they’re separate faults. - RX/TX swapped — would give zero valid frames ever. Occasional good frames prove the receive path is correct.
- Receiver config — EP2 web UI confirmed CRSF @ 420000, not inverted, not SBUS
- Solder / connector / wiring — inspected and metered; valid frames travelled through it
- PX4 params —
RC_INPUT_PROTO 6saved and in use,RC_PORT_CONFIGdefaultRCcorrectly resolving to/dev/ttyS5
Loose ends, if anyone wants to dig
I did not test the crsf_rc driver. My build uses the legacy rc_input scanner. It’d be genuinely useful to know whether crsf_rc behaves any differently on the shared RX6 node — I’d guess not, since the corruption is electrical, but nobody has checked.
PX4’s rc_input CRSF parser caps frames at 30 bytes (CRSF_FRAME_SIZE_MAX, src/lib/rc/crsf.h) against a protocol max of 64. Longer frames force a resync. Not the cause here, but worth knowing, and a reason to prefer crsf_rc if you’re building your own firmware — it also brings RC_CRSF_PRT_CFG and RC_CRSF_TEL_EN.
QGC may not offer firmware for this board. Board ID 1179 is missing from older QGC manifests and it mislabels the board as “PX4 DurandalV1”. Update QGC, or use Advanced settings → Custom firmware file.
Happy to run further tests on this board if anyone wants specific data.