Debugging built-in ELRS: packet CRC errors on the TFC1

The plan and the problem

The TFC1 was designed with an integrated SX1281 LoRa transceiver for ExpressLRS (ELRS) — eliminating the need for a separate receiver module. This is the same approach used by BetaFPV and other compact flight controllers. The theory was straightforward: connect the SX1281 via SPI to the RP2354B, configure BetaFlight’s ELRS driver, and fly.

In practice, the pairing process consistently failed with packet CRC errors. The TX15 transmitter and TFC1 receiver appeared to be on the same frequency, but the CRC checksums on received packets never matched.

The investigation

The debugging process followed a systematic approach:

1. Frequency verification

Through the debug UART, we confirmed that the TFC1’s frequency settings were correct. A BetaFlight pull request (#15014) that closed SX127X support introduced an array index offset bug in the ELRS common code — when ELRS 2.x support was removed from BetaFlight, the RP2350 platform’s timer implementation was missing, causing incorrect frequency configuration. This was fixed by an early merge of the alarm-api pull request into our firmware branch (based on the 2026-03-15 BetaFlight fork).

After the fix, the initialization sequence showed:

domain from eeprom = 0 (ISM2400)
enumRate = 9 (LORA 500Hz)
UID = 0000D6028D94 (bind phrase)
switchMode = 0 (Wide)
tlmInterval = 2 (1 telemetry packet per 128)

These matched the TX15 settings exactly.

2. Packet structure analysis

ELRS OTA packets are fixed at 8 bytes, similar in structure to CAN bus frames. The first byte contains both the packet type (2 bits) and the high CRC byte (6 bits):

• Packet types: 0x00, 0x01, 0x02, 0x03 (sometimes 0x04 when crcHigh = 1)
• Each packet: 8 bytes total with CRC in the first and last bytes

Every test session showed that the first byte was always correct — one of 0x00 through 0x03. If the RF frequency were wrong, we’d see random garbage across all bytes, not just CRC failures. This meant the frequency planning was correct, and the issue was specifically in the packet integrity.

3. The inductor hypothesis

The critical clue came from examining the RF front-end circuit. The reference design for the ZeroDrag Nexus1 ELRS receiver specifies a 3nH inductor: muRata LQW15AN3N0B00D. However, the JLCPCB assembly used Sunlord SDCL1005C3N0STDF — a different part with different response frequency and Q factor characteristics.

These two inductors, despite having the same nominal inductance, behave differently at 2.4 GHz. The Q factor and self-resonant frequency directly affect the impedance matching network’s performance, which in turn affects signal integrity and CRC accuracy.

The test procedure was clear: desolder the inductor from a working ELRS receiver module (SX1281 circuit) and solder it onto the TFC1 as a controlled experiment. If the CRC errors disappeared with the correct inductor, the hypothesis would be confirmed.

4. Protocol-level debugging

The ELRS packet structure revealed by serial logging:

[16:46:28.919] INFO: ttyUSB0: ./src/main/rx/expresslrs.c:935: 
(0x2) 02.B0.2E.18.C8.5F.A0 (<SYNC>) inCRC: 0x3A59, calculatedCRC: 0x1B0D, nonceValidator: 0)

The inCRC and calculatedCRC mismatch confirmed that packets were being received at the correct frequency and with correct SPI/DMA buffering, but the actual payload data was corrupted — consistent with an RF front-end impedance mismatch.

The bigger picture

A parallel investigation revealed that ELRS SPI receiver support in BetaFlight has been effectively deprecated. The official ELRS reference implementation lives in the dedicated ELRS repository (not in BetaFlight), and the BetaFlight community considers ELRS protocol details to be external to the flight controller firmware.

Most flight controllers in the ecosystem now use external ESP32-based ELRS receiver modules connected via UART, rather than integrated SPI receivers. The only exceptions are ultra-compact boards like the BetaFPV models, which maintain their own ELRS SPI implementations.

The decision

With the CRC issue not fully resolved and external ELRS receiver modules readily available, the decision was made to use external receiver modules for the time being. This is the industry-standard approach and avoids the complexity of integrated RF design on a flight controller board.

The debugging notes, packet captures, and inductor comparison data were preserved as a reference for any future attempt to integrate ELRS directly on the RP2354B platform. The exercise provided valuable insight into the RF design considerations that go into even “simple” wireless receiver circuits.

Shifting focus

With ELRS sidelined, development focus shifted to the companion computer interface and computer vision pipeline. The Raspberry Pi + optical flow combination offered a more immediately productive path toward autonomous hovering capabilities.