I got this issue with both Air65II & AIR75II

Radiomaster Pocket ELRS 3.3.1 LBT,

Tried packet rates 50-250hz, Output 25-50hz (any higher and RXLOSS aswell)

AIO is fine, antenna too, solderjoint is flawless

Lowered baudrate in internal module settings.

Model match off.

Happens every 15-20sec, rapid RXLOSS, then reconnect, repeat.

It's random sometimes this goes on forever, then again everything is fine for 3 or 4 packs.

I don't have this issue with my Nazgul or Jeno25 and use the same controller with those aswell.

Please help, it's driving me insane!

Is it just a lack of software or is hardware missing? If so, what hardware exactly?

this is a cry for help, the following text is fully generated by claude which tried to help me debug for a week now. im also too tired at this point to reexplain everything.

(yes, I'm ashamed of this ai writing for me approach)

(thank you SO MUCH for taking your time if you want to challenge yourself reading this)

ELRS Setup: Binding Works, Zero Controls in Betaflight — Full Debug Log

Hardware Involved

Component	Details
Flight Controller	SpeedyBee F405 V3
Receiver	RadioMaster RP2 v1.2 (2.4GHz ELRS)
TX Module	Jumper AION NANO 2.4GHz TX (also listed as AION 2G4NANO TX)
Radio	RadioMaster Pocket (originally CC2500, no integrated ELRS)
Betaflight Version	4.5.2
ELRS Version (both devices)	4.0.0
EdgeTX Version	Fresh flash from EdgeTX Buddy (previously RMFactory 2023-07-27)

The Problem

The controller binds to the receiver. This is confirmed by:

• ELRS LED on the RP2 stops flashing when bound
• Telemetry lost/recovered messages appear on the Pocket when the drone battery is unplugged/replugged
• ExpressLRS Lua script shows Bad/Good: 0/250 — perfect link quality, zero bad packets

However, in Betaflight, the Receiver tab shows no bar movement whatsoever. All channels are black/frozen. Attempting to arm the drone does nothing. The arming disable flags include RXLOSS, meaning Betaflight sees the receiver as completely absent despite the RF link being confirmed solid.

This issue existed before any firmware flashing was attempted (both used to be on version 3.3.4 I think). Flashing both the TX module and RX to ELRS 4.0.0 was done in an attempt to fix it, but the issue predates and persists after those flashes.

What Has Already Been Checked and Ruled Out

Betaflight Configuration

• UART with serialrx enabled: confirmed correct (serial 1 64 = UART2 with serialrx flag)
• Serial Receiver Provider: CRSF (confirmed via get serialrx_provider)
• Receiver Mode: Serial (via UART)
• serialrx_inverted: tested both ON and OFF — no change either way, currently OFF
• Tested on UART1, UART2, and UART3 — same result on all three
• TX/RX wires swapped multiple times across all UARTs — same result every time
• tryed diffrent voltage and ground pads.

Wiring

• RP2 powered from 5V pad on FC
• Connected to T2 and R2 pads (UART2) currently
• Wiring has been verified multiple times

Radio (RadioMaster Pocket)

• External RF mode: CRSF
• Baudrate: 921600 (set to match ELRS 4.0 requirement)
• Status: 250Hz
• Channel range: CH1-16
• Internal RF: OFF
• EdgeTX was on RMFactory (2023-07-27) — suspected culprit, reflashed to latest proper EdgeTX via EdgeTX Buddy
• Model mixer is properly set up with sticks assigned to channels

Key Diagnostic Finding: serialpassthrough Test

Running serialpassthrough 1 420000 in Betaflight CLI (UART2, 420000 baud = CRSF rate) and watching for raw serial output from the RP2 revealed the following:

Data IS flowing from the RP2 — but only when sticks are moved.

When sticks are centered and nothing is touched, zero data comes through. When sticks are moved, bursts of gibberish appear. After flashing fresh EdgeTX, behavior changed slightly — occasional single bursts appear every 5-10 seconds at idle, plus bursts on stick movement.

This is wrong behavior. ELRS at 250Hz should output a constant, uninterrupted stream of CRSF frames 250 times per second regardless of stick position. Betaflight declares RXLOSS because it expects continuous frames and receives near-silence.

This strongly suggests the TX module (AION NANO) is not transmitting continuous channel packets, only transmitting on change. The RP2 faithfully outputs whatever it receives — which is almost nothing.

Binding UID Mismatch — Found and Fixed

At one point during debugging, the Binding UIDs were checked on both devices:

• RP2: 0,0,15,32,140,132
• AION NANO: 164,240,15,32,140,132

The first two bytes were completely different. Despite the LED indicating "bound," the devices were not truly paired — coincidental frequency overlap was causing a false bind indication.

Fix applied: Both devices were reflashed with an identical custom binding phrase via ELRS Configurator. UIDs now match: 208,168,93,103,21,22 on both.

Result: No change in behavior. Serialpassthrough still shows data only on stick movement.

Firmware Target Investigation

RP2 Firmware Info (from device WiFi page)

Product:      RadioMaster RP2 2.4GHz RX
Firmware:     UNIFIED_ESP8285_2400_RX
Version:      4.0.0
Git Hash:     d9fc3
Radio:        SX128X
Domain:       ISM2G4

AION NANO Firmware Info (from device WiFi page)

Product:      Jumper AION Nano 2.4GHz TX
Firmware:     UNIFIED_ESP32_2400_TX
Version:      4.0.0
Git Hash:     d9fc3
Radio:        SX128X
Domain:       ISM2G4

Both devices are running UNIFIED targets. The AION NANO was reflashed using the specific Jumper AION Nano 2.4GHz TX target from ELRS Configurator, but the device still reports UNIFIED_ESP32_2400_TX after flashing. This suggests the specific-target flash is not actually sticking, or the Configurator is still writing a unified binary.

Current Suspicion

The AION NANO TX module is the most suspicious component because:

1. It consistently reports UNIFIED firmware even after flashing a specific target — flashes may not be applying correctly
2. The "only transmit on stick movement" behavior originates from the TX side of the chain
3. The RP2 itself appears to be functioning (telemetry, LED behavior, serialpassthrough confirms it outputs data)
4. All Betaflight config has been verified correct multiple times

What Has NOT Been Tried Yet

• Confirming whether the AION NANO flash is using Build and Flash vs just Flash in ELRS Configurator (wtf does he mean)
• Testing the AION NANO module on a different radio to isolate whether the issue is module-specific or Pocket-specific (i cant really do this)
• Checking if there is a specific ELRS Configurator version needed for 4.0.0 targets

Help Needed

• Why is the AION NANO only transmitting on stick movement instead of a continuous 250Hz CRSF stream?
• Why does the AION NANO continue to report UNIFIED firmware after flashing a specific target?
• Is there a known incompatibility between ELRS 4.0.0 and the AION NANO T-Pro / Nano TX hardware?
• Is there anything in the Betaflight CLI output below that looks wrong?

Full serial CLI output:

serial 20 1 115200 57600 0 115200
serial 0 131073 115200 57600 0 115200
serial 1 64 115200 57600 0 115200
serial 2 0 115200 57600 0 115200
serial 3 1 115200 57600 0 115200
serial 4 1024 115200 57600 0 115200
serial 5 0 115200 57600 0 115200

Full status CLI output:

MCU F40X Clock=168MHz (PLLP-HSE), Vref=2.59V, Core temp=42degC
Stack size: 2048, Stack address: 0x1000fff0
Configuration: CONFIGURED, size: 3774, max available: 16384
Devices detected: SPI:1, I2C:1
Gyros detected: gyro 1 locked dma
GYRO=BMI270, ACC=BMI270, BARO=DPS310
OSD: NONE (37 x 105)
BUILD KEY: 99eab4a36d165e30a998fa7e9dec3b87 (4.5.2)
System Uptime: 94 seconds, Current Time: 2026-05-09T23:16:58.818+00:00
CPU:19%, cycle time: 316, GYRO rate: 3164, RX rate: 15, System rate: 9
Voltage: 1 * 0.01V (0S battery - NOT PRESENT)
I2C Errors: 0
SD card: Startup failed
GPS: NOT ENABLED
Arming disable flags: RXLOSS CLI MSP