A cry for help to bing my fpv with my new controller and receiver
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:
- It consistently reports UNIFIED firmware even after flashing a specific target — flashes may not be applying correctly
- The "only transmit on stick movement" behavior originates from the TX side of the chain
- The RP2 itself appears to be functioning (telemetry, LED behavior, serialpassthrough confirms it outputs data)
- 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