Chapter 1: The Five Link Types

Every drone in the air right now is using between one and five simultaneous radio links. Most operators can name two. This chapter covers all five.

The Problem Nobody Talks About

A racing quad has two links — RC control and video. Simple. But the moment you add GPS return-to-home, you've added a third (telemetry). Add a companion computer with a mesh radio and you're at four. Add a payload camera with its own downlink and you're at five.

Each link has its own frequency, its own protocol, its own antenna, its own failure mode, and its own opinion about which direction the drone should go. When they disagree, things get interesting. Review needed: configuration / failure mode Flag this

Understanding the five link types is the foundation of everything else in this handbook. If you don't know what's talking on your drone, you can't diagnose why it stopped talking.

The Five Links

Link 1: Manual Control (RC)

What it does: Carries stick commands from the pilot to the flight controller. The link that keeps a human in the loop.

Protocols: ELRS (ExpressLRS), CRSF (TBS Crossfire), GHST (IRC Ghost), SBUS (FrSky), IBUS (FlySky), PPM (legacy).

Frequencies: - 2.4 GHz — most common (ELRS 2.4, CRSF, Ghost, FrSky ACCST) - 900/868 MHz — long range (ELRS 900, Crossfire, FrSky R9) - Sub-GHz proprietary — tactical (IRONghost dual-band)

What you need to know: - Latency and freshness matter across RC, video, telemetry and sensor/control pipelines. A 500 Hz update interval is 2 ms; it is not a measured stick-to-actuator delay. Record protocol/mode and the complete measurement boundary. - Loss of this link triggers failsafe. Every FC firmware handles failsafe differently. Know yours before you need it. - ELRS and Crossfire use serial protocols (CRSF wire format) that carry bidirectional telemetry inside the RC link. This blurs the line between Link 1 and Link 2 — your RC receiver is also a telemetry radio. This is efficient but means RC loss also kills your telemetry. Review needed: performance / configuration Flag this

Common problems: - RC and video on the same frequency band (both 2.4 GHz) causing desense. Solution: different bands, or physical antenna separation. - Wrong UART baud rate in FC configurator — CRSF wants 420000, not 115200. - ELRS binding phrase mismatch after firmware update.

Link 2: Telemetry / Command & Control (C2)

What it does: Bidirectional data link between the drone and a ground station. Carries flight data down (position, battery, attitude) and commands up (waypoints, parameter changes, mode switches).

Protocols: MAVLink v2 (ArduPilot, PX4), MSP (Betaflight, iNav), LTM (Lightweight Telemetry), FrSky S.Port/F.Port.

Transport options: - Embedded in RC link — CRSF/ELRS carry MAVLink or custom telemetry inside the control channel. No separate radio needed. - Dedicated telemetry radio — SiK (3DR), RFD900x, MicroHard P900. Separate frequency, separate antenna, separate failure mode. - WiFi — ESP32 bridge, companion computer WiFi, mesh radio backhaul. - Cellular — LTE modems for beyond-visual-line-of-sight (BVLOS). Review needed: regulatory / failure mode Flag this

What you need to know: - MAVLink is the lingua franca for autonomous platforms. If you're running ArduPilot or PX4, everything speaks MAVLink. If you're running Betaflight, everything speaks MSP. If you're running a mixed fleet, you need both. - Telemetry bandwidth matters more than telemetry latency. You don't need millisecond position updates on the ground — 1-10 Hz is fine. But you do need all the data fields to arrive intact. - Dedicated telemetry radios (RFD900x, SiK) are point-to-point. They don't scale to multiple drones without a mesh layer on top.

Common problems: - MAVLink stream rate misconfigured — too high floods the link, too low makes the GCS look frozen. Use the exact firmware's stream-rate interface; SRx is not universally a physical serial-port number. - SiK radio firmware mismatch between air and ground units. - UART conflict — telemetry and GPS both assigned to the same UART.

Link 3: Video Downlink

What it does: Sends camera feed from the drone to the pilot's goggles or ground station monitor. The link that lets you see.

Technologies: - Analog video — composite capture, RF modulation and receiver/display processing; measure the complete path. - DJI digital / Walksnail / HDZero — product-specific camera, radio and display ecosystems; supported modes and latency depend on the exact hardware/release. - OpenHD / WFB-ng / OpenIPC — open software stacks with specific adapter/image/camera requirements. RTL8812EU is included in OpenHD's published adapter support since 2.6.3; see the OpenHD reference.

A glass-to-glass result includes camera and display. The previous generic numerical comparisons mixed measurement boundaries and are withdrawn.

What you need to know: - Video is almost always 5.8 GHz. This means it's on the same band as 5 GHz WiFi, some mesh radios, and the 5.8 GHz ISM band that everyone assumes is uncontested. In practice, 5.8 GHz is crowded. - Analog video uses 40 channels across 5.8 GHz. At a race event with 8 pilots, frequency management is a real operational problem. At a tactical deployment with multiple teams, it's a coordination requirement. - Digital video links (DJI, HDZero) are frequency-hopping or wideband. They're harder to interfere with but also harder to coordinate. You can't just "pick a channel" the way you can with analog. - The RTL8812AU chip that OpenHD/WFB-ng depends on has been discontinued by Realtek. The RTL8812EU replacement does NOT support monitor mode in the same way. This is slowly killing the open-source digital FPV ecosystem. OpenIPC is moving to other solutions.

Common problems: - 5.8 GHz video transmitter (VTX) too close to 2.4 GHz RC antenna causes receiver desense. Minimum 10 cm separation, more is better. - VTX power set too high for proximity flying — at 800 mW you're heating the VTX and potentially interfering with your own RC. 25-200 mW is enough for most LOS operations. - Wrong VTX table in Betaflight — mismatched power levels, missing channels, or wrong band assignments.

Link 4: Payload Data

What it does: Carries data from a mission payload — mapping camera, multispectral sensor, LiDAR, SAR, SIGINT receiver, delivery mechanism confirmation. Distinct from the FPV video feed (Link 3).

Technologies: - Ethernet (wired, on companion computer) - USB (camera to companion) - WiFi (payload-specific AP) - Dedicated RF downlink (separate frequency, separate antenna) - Store-and-forward (record on board, download after landing)

What you need to know: - Most consumer and racing drones don't have Link 4. It shows up on commercial mapping drones, agricultural platforms, and defense ISR platforms. - Payload data is usually high bandwidth and tolerant of latency. A mapping camera generates gigabytes per flight — you're not streaming that in real time. You're storing it and downloading after landing. - When payload data IS streamed (tactical video from a gimbal camera, SAR data, EW sensor output), it competes for bandwidth with telemetry and video. This is where mesh radios with QoS become important — prioritize C2 over payload, always. - The companion computer is the integration point. Payload connects to companion via USB/Ethernet/GPIO. Companion decides what goes down the RF link and what gets stored.

Common problems: - Payload drawing too much power from the FC's 5V/12V rail. Payload should have its own BEC or regulated supply. - USB bandwidth contention between payload camera and companion computer's other USB devices. - Payload data timestamps not synchronized with flight controller timestamps. Use GPS time or NTP on the companion for correlation.

Link 5: Mesh / Swarm Coordination

What it does: Drone-to-drone communication for fleet operations. Position sharing, intent coordination, task allocation, sensor data relay. The link that turns individuals into a team.

Technologies: - ESP-NOW — Espressif peer-to-peer, 2.4 GHz, ~250 byte packets, no infrastructure needed. Good for ground operations (Tooth mesh, pre-flight sync). Not suitable for in-flight swarm at range. - Linux WiFi mesh — batman-adv or 802.11s on an explicitly supported Linux/network stack. - Vendor MANET — model-specific waveforms and management interfaces. IP/Ethernet compatibility does not establish an open WiFi air interface. Silvus identifies its technology as MN-MIMO; do not infer batman-adv from a Linux management environment. - MAVLink over a network — addressing/routing/freshness remain application concerns independent of the radio waveform.

What you need to know: Measure throughput, delay and recovery using the exact node topology, traffic, radio mode and conditions. There is no universal three-hop throughput percentage. Mesh integration distinguishes IP integration from waveform implementation.

Common problems: - Mesh radio on 2.4 GHz interfering with 2.4 GHz RC link. Solution: different bands (mesh on 900 MHz or 5 GHz). - Routing convergence depends on implementation, traffic and topology. Use documented settings and a measured recovery test rather than a universal OGM interval. - IP address conflicts in the mesh. Use a consistent addressing scheme: 10.0.0.{system_id} with system_id matching MAVLink ID.

How They Interact

The five links are not independent. They share spectrum, share power, share the FC's limited UARTs, and share the operator's limited attention.

Frequency Deconfliction

The rule: no two links on the same band within the same airframe unless they're designed to coexist. ELRS 2.4 GHz and an ESP32 WiFi AP on the same drone will fight. ELRS 900 MHz and an RFD900x telemetry radio will fight. Plan your frequency layout before you build.

UART Allocation

A typical F405 flight controller has 3-6 UARTs. They get consumed fast:

Running out of UARTs is one of the most common integration problems on F4-class FCs. Solutions: use soft serial (limited baud rate), upgrade to an H7 FC (more UARTs), or use a companion computer to multiplex multiple data streams over a single UART.

Power Budget

Every link has a radio that draws power. Every radio has an amplifier that draws more power. On a 5-inch FPV quad with a 1300 mAh 6S battery, your total electronics budget (FC + ESCs + radio + VTX + GPS + receiver) is typically 2-5W continuous. Adding a mesh radio at 1-2W is significant. Adding a companion computer at 3-10W changes your flight time.

Know your power budget before you add links.

The Operator's Decision

Not every drone needs all five links. Most don't. The right number of links depends on the mission:

More links = more complexity = more things to break = more things to diagnose. Add links because the mission requires them, not because the hardware supports them.

Next

• Chapter 2: Frequency Bands and Regulatory Reality — the rules that govern where your links can operate, and the gaps between the rules and reality.
• Chapter 8: UART Layout and Why It Matters — the practical constraint that limits how many links you can actually use.

Every link you add is a complication. Know what it costs before you add it.

Chapter 2: Frequency Bands & Regulatory Reality

The regulations tell you what you're allowed to do. The physics tell you what will actually work. They don't always agree.

The Bands That Matter

Drone operations live in a handful of frequency bands. Here's where everything sits and why.

900 MHz (902–928 MHz in the US, 868 MHz in EU)

What lives here: Long-range RC links (ELRS 900, TBS Crossfire), telemetry radios (RFD900x, SiK, MicroHard P900), some mesh radios, LoRa, and a surprising amount of industrial IoT.

Why it matters: Sub-GHz propagation is king. 900 MHz bends around obstacles, penetrates foliage, and reaches farther per milliwatt than any other band you'll use. A 100 mW ELRS 900 link will outrange a 1 W 2.4 GHz link in most real-world environments.

Regulatory: - US: ISM 902–928 MHz, up to 1 W conducted + antenna gain (FCC Part 15.247) - EU: 868 MHz band, 25 mW ERP with duty cycle limits (ETSI EN 300 220) - The EU/US split is the single biggest cross-border problem in drone operations. 900 MHz hardware built for the US market doesn't work in Europe, and vice versa. ELRS handles this with region-specific firmware builds. Many other systems don't. Review needed: regulatory / configuration Flag this

What the regulations don't tell you: The 900 MHz ISM band is shared with utility meters (smart grid AMI), industrial SCADA, agricultural sensors, and LoRaWAN gateways. In urban environments, the noise floor at 900 MHz can be 20+ dB higher than rural. Your range will be shorter in the city.

2.4 GHz (2400–2483.5 MHz)

What lives here: Most RC links (ELRS 2.4, Ghost, ACCST, IBUS), WiFi (802.11b/g/n/ax), Bluetooth, ZigBee, microwave ovens, baby monitors, wireless cameras, mesh radios, and roughly half of all wireless devices ever manufactured.

Why it matters: 2.4 GHz is the default for everything. It's globally harmonized (same band everywhere), license-free, and supported by every chip on the market. If you don't know what frequency to use, you use 2.4 GHz. So does everyone else.

Regulatory: - Global ISM band, generally 100 mW–1 W EIRP depending on jurisdiction - FCC: up to 1 W conducted, 4 W EIRP with directional antennas (Part 15.247) - EU: 100 mW EIRP (ETSI EN 300 328) - Japan: 10 mW/MHz (effectively limits wideband signals) Review needed: regulatory Flag this

What the regulations don't tell you: 2.4 GHz is a war zone. At any given moment at a race event, fly-in, or urban deployment site, you're sharing spectrum with: - Every phone's WiFi and Bluetooth - Every laptop's WiFi - Every smart home device - Other pilots' RC links - Nearby mesh radios - The microwave in the food truck

The saving grace is that modern protocols (ELRS, Ghost, CRSF) use frequency hopping, which spreads the signal across the entire band and makes them resilient to narrowband interference. But when the entire band is congested, even FHSS degrades.

The 2.4 GHz deconfliction problem: If your RC link is 2.4 GHz AND your mesh radio is 2.4 GHz AND your companion computer's WiFi is 2.4 GHz, you have three transmitters on the same band in the same airframe. Even with different channels and different protocols, the front-end receivers will desense each other. The fix is simple: put at least one of them on a different band.

5.8 GHz (5725–5875 MHz)

What lives here: Analog FPV video, digital FPV video (DJI, HDZero, Walksnail), 5 GHz WiFi (802.11a/n/ac/ax), some mesh radios, radar, and weather services.

Why it matters: 5.8 GHz is the FPV video band. Virtually every drone with a camera transmits video on 5.8 GHz. The band has enough bandwidth for analog and digital video, and the higher frequency means smaller antennas.

Regulatory: - ISM 5.725–5.875 GHz in most jurisdictions - FCC: 1 W conducted (Part 15.247) - EU: 25 mW EIRP (yes, really — ETSI EN 300 440). Most VTX modules shipped into the EU are technically non-compliant at any setting above 25 mW. - The broader 5 GHz UNII bands (5.15–5.35, 5.47–5.725 GHz) are used by WiFi but have DFS (Dynamic Frequency Selection) requirements due to radar coexistence. DFS can force your radio to change channels mid-flight. Not ideal. Review needed: regulatory Flag this

What the regulations don't tell you: - 5.8 GHz has significantly higher path loss than 2.4 GHz. In free space, 5.8 GHz loses ~7.7 dB more than 2.4 GHz at the same distance. In practice this means roughly half the range per milliwatt. You compensate with power and antenna gain. - 5.8 GHz does not penetrate foliage, buildings, or terrain well. If you fly behind a tree, your video will break before your RC link does (assuming RC is on 2.4 GHz or 900 MHz). - At FPV race events, analog 5.8 GHz channel management is critical. 40 channels sounds like a lot until 8 pilots are in the air and their harmonics are stepping on each other. Digital systems (DJI, HDZero) are wideband and harder to deconflict — they don't fit neatly into the 40-channel system.

Sub-GHz Below 900 (433, 315, 169 MHz)

What lives here: LoRa long-range, some RC systems (FrSky R9 at 433 MHz in some regions), key fobs, garage door openers, tire pressure monitors, and very long-range telemetry.

Why it matters: Lower frequency = better propagation = longer range. 433 MHz LoRa links can reach 10+ km with tiny antennas and milliwatts of power. But bandwidth is measured in kilobits, not megabits.

Regulatory: - 433 MHz ISM: 10 mW in EU, not ISM in the US (amateur band, requires ham license for non-ISM use) - 315 MHz: US ISM for low-power devices - 169 MHz: EU smart meter band, very restricted

When you'd use it: Very long-range telemetry (LoRa), sub-floor FHSS detection (listening, not transmitting), or interoperability with existing infrastructure on these bands.

Military and Licensed Bands

L-band (1–2 GHz): Some tactical mesh radios (Doodle Labs HelixL+S). Military satellite. GPS (L1 at 1575.42 MHz, L2 at 1227.60 MHz). No ISM access — requires licensing or government authorization.

S-band (2–4 GHz): Overlaps 2.4 GHz ISM. Some military radar. Weather radar. Tactical links.

C-band (4–8 GHz): Doodle Labs C-Band radios, satellite downlinks, some military comms. Requires licensing in most jurisdictions.

You don't need to operate on these bands unless you're working with military or government platforms. But you do need to know they exist because: (a) military radar on S-band and C-band can overwhelm your receivers, and (b) GPS signals on L-band can be jammed or spoofed, affecting your drone's navigation.

The Gap Between Rules and Reality

What Operators Actually Do

The regulatory framework assumes static, ground-based transmitters in controlled environments. Drone operations are none of those things.

In practice: - FPV pilots routinely fly 600–800 mW VTX power despite EU limits of 25 mW - Long-range operators use 900 MHz at full power in countries where the band allocation is ambiguous - "1 W EIRP" limits are rarely enforced at hobby flying fields - Military operators have blanket spectrum authority in their operational areas and don't worry about ISM band rules

This handbook doesn't tell you to break the rules. It tells you the rules exist, what they are, and acknowledges that the enforcement reality differs from the regulatory text. Know your jurisdiction's rules. Make your own informed decisions.

Frequency Coordination at Events

At any gathering of more than 4-5 pilots:

1. Assign video channels before anyone powers up. Analog 5.8 GHz has 40 channels across 6 bands (A, B, E, F, R, L). Use non-adjacent channels. Band F (Fatshark / IRC) and Band R (RaceBand) are the most common for events.

2. Separate RC bands. If half the pilots are on 2.4 GHz ELRS and half are on 900 MHz Crossfire, that's actually ideal — no RC interference between the two groups.

3. Power down when not flying. A VTX broadcasting 800 mW on the ground creates more interference than one in the air at 200m, because ground-level signals have direct paths to every other receiver in the pit area.

   Review needed: performance / failure mode Flag this

4. Know your VTX table. Betaflight's VTX table maps power levels and channels for your specific VTX hardware. Verify it matches reality — misconfigured VTX tables can put you on the wrong channel or the wrong power level.

Frequency Coordination for Fleet Operations

At a commercial or tactical deployment with multiple drones:

1. Map all five links for each platform. Build a frequency plan before the operation, not during it.

2. Separate bands where possible. RC on 900, telemetry on 2.4, video on 5.8, mesh on a different 5 GHz channel. The more band separation, the less self-interference.

3. Document what's transmitting. If you're operating near other teams, other companies, or military assets, knowing exactly what frequencies you're using — and at what power — prevents problems and demonstrates professionalism.

4. Plan for interference. If your operation is near an airport, military base, or large venue (stadiums use a LOT of 2.4 and 5 GHz), your range predictions from a clean test site are optimistic. Budget a 50% range reduction in congested spectrum environments.

   Review needed: performance / failure mode Flag this

Quick Reference: Band Comparison

The universal trade-off: lower frequency = longer range and better penetration but less bandwidth. Higher frequency = more bandwidth but shorter range and worse penetration. Everything in RF engineering is a version of this trade-off.

The regulatory side of "reality"

Spectrum is licensed and operations are regulated. The rules sit with the regulator, not with a vendor or a forum post. These are the canonical, publicly accessible sources — go to them, not to a summary.

United States

International

Two operator habits worth keeping: Part 107 is the floor, not the ceiling — state and local law (see NCSL) add restrictions the FAA does not; and the ASIAS incident reports are a real corpus — the failure modes repeat, so read them before flying an unfamiliar profile. Review needed: regulatory / failure mode Flag this

The full list, including industry/research sources (AUVSI, ASSURE, UAS Magazine) and a machine-readable copy, is in appendices/appendix-f-regulatory-resources.md and data/erau_resources.json.

Next

• Chapter 3: Antennas for People Who Aren't RF Engineers — how to choose, orient, and not break your antennas.
• Chapter 1: The Five Link Types — frequency deconfliction in the context of a complete drone system.

The spectrum is a shared resource. Know what you're transmitting, where, and at what power. The drone next to you is sharing the same resource.

Chapter 3: Antennas for People Who Aren't RF Engineers

The antenna is the most important and least understood component on your drone. A $200 radio with a bad antenna loses to a $30 radio with a good one.

The One Rule

Match your antenna to your link.

That's it. Everything else in this chapter is explaining what that means and how to do it.

What an Antenna Does

An antenna converts electrical signal into radio waves (transmit) and radio waves back into electrical signal (receive). It doesn't amplify — it shapes. An antenna with "5 dBi gain" isn't creating energy. It's focusing the energy that's already there into a narrower pattern, the same way a flashlight focuses light from a bulb into a beam.

More gain = narrower beam = longer range in one direction, shorter range in every other direction.

This is the fundamental trade-off in antenna selection. There is no antenna that's better in all directions. There are only antennas that trade coverage pattern for range.

Antenna Types You'll Actually Use

Dipole / Whip

What it is: A straight stick. The stock antenna on most receivers, telemetry radios, and mesh radios.

Pattern: Donut-shaped. Good coverage in all horizontal directions, weak directly above and below the antenna axis.

Gain: 2–5 dBi

When to use it: Default choice for anything where you don't know which direction the other radio will be. RC receivers, telemetry, mesh nodes on drones that fly in all orientations.

Orientation matters: A vertical dipole radiates horizontally. A horizontal dipole radiates vertically. On a drone, the receiver antenna should point down or sideways — NOT parallel to the frame. Two antennas at 90 degrees to each other (antenna diversity) covers all orientations.

Patch Antenna

What it is: A flat rectangle. Common on GPS modules, some directional links, and video receivers.

Pattern: Directional — strong in front, weak behind. Like holding up a book and only hearing what's in front of it.

Gain: 6–14 dBi depending on size

When to use it: On the ground station pointing at the drone. GPS antennas (patch facing sky). Video receiver antennas in goggles (facing forward). NOT on the drone itself unless you know exactly where the ground station will be.

The goggle antenna mistake: Many pilots fly with stock goggle antennas (usually small omnis) and wonder why they get video breakup at 500m. Replacing one goggle antenna with a directional patch that points toward the flying area can double or triple video range with no change to the drone.

Helical Antenna

What it is: A coil of wire. Comes in two types: normal-mode (small, used as compact omni) and axial-mode (larger, highly directional, used for long range).

Pattern: Axial-mode helix is a focused beam — high gain, narrow coverage. Normal-mode is similar to a dipole.

Gain: 8–15+ dBi (axial mode)

When to use it: Ground-station tracking antenna for long-range operations. Paired with an antenna tracker that points it at the drone. Not practical on the drone itself (too large, too directional).

Pagoda / Lollipop / Stubby

What it is: Compact circular-polarized antenna. The standard FPV video antenna on both the drone and the goggles.

Pattern: Roughly omnidirectional with circular polarization.

Gain: 1–3 dBi

When to use it: 5.8 GHz FPV video. Both the VTX antenna on the drone and the receiver antenna on the goggles should be circular polarized and the same handedness (both RHCP or both LHCP). Mixing handedness costs you ~3 dB (half your signal).

Why circular polarization for video: When a linearly polarized signal bounces off a surface (multipath), its polarization can rotate. If your receive antenna is linear and the signal arrives at the wrong angle, you lose it. Circular polarization doesn't have this problem — it receives equally regardless of rotation. The trade-off is ~3 dB less gain than an equivalent linear antenna.

PCB / Ceramic Chip Antenna

What it is: A tiny antenna printed on the circuit board or bonded as a ceramic chip. Found inside ESP32 modules, Bluetooth devices, GPS modules, and small receivers.

Pattern: Roughly omnidirectional but with significant nulls depending on PCB ground plane and nearby components.

Gain: -2 to 2 dBi (often negative gain compared to an ideal isotropic radiator)

When to use it: When size and cost matter more than range. The ESP32-C6 on a Tooth uses its built-in PCB antenna for mesh communication at short range. For anything beyond 100m, use an external antenna via the U.FL/IPEX connector if available. Review needed: performance / commercial Flag this

Polarization

Radio waves vibrate in a specific orientation. If the transmit antenna sends vertically polarized waves and the receive antenna is oriented horizontally, you lose ~20 dB of signal. That's the difference between a clear link and no link.

The rules: - Linear antennas (dipole, whip): orient both the same way. Both vertical, or both horizontal. On a drone that changes orientation constantly, this is hard — which is why diversity (two antennas at 90 degrees) helps. - Circular polarized antennas (pagoda, lollipop): match handedness. Both RHCP or both LHCP. Don't mix. - Cross-polarization loss: linear TX → circular RX (or vice versa) costs ~3 dB. Not ideal but survivable.

Connectors

The small connectors used in drone antennas are fragile. Know them.

The U.FL problem: U.FL (also called IPEX or MHF) connectors are rated for about 30 connect/disconnect cycles. After that, the spring contact weakens and the connection becomes intermittent. Every time you unplug and replug a U.FL antenna, you're using one of those 30 cycles. On a racing drone that gets rebuilt weekly, this matters.

Fix: Don't disconnect U.FL antennas unless you have to. Route the antenna wire so it stays connected during maintenance. If a U.FL connection becomes intermittent (video cuts out when you flex the cable), replace the pigtail — the connector is worn out.

Antenna Placement on a Drone

Where you put the antenna matters as much as which antenna you choose.

Do

• Mount RC receiver antennas pointing away from the frame at 90 degrees to each other (diversity). The classic "V" shape with antenna tubes works.
• Mount GPS antenna on top of the frame with a clear view of the sky. No carbon fiber between the GPS patch and the satellites.
• Mount the VTX antenna where it won't get hit in a crash. Rear-facing on a standoff is common.
• Keep transmit antennas (VTX, mesh radio) as far from receive antennas (RC receiver, GPS) as physically possible on the frame.

Don't

• Don't run antenna wires parallel to power wires. Motor current creates magnetic fields that induce noise in antenna cables.
• Don't let antenna wires cross each other at sharp angles.
• Don't fold or kink antenna wires. The coax impedance changes at the bend and reflects signal back instead of radiating it.
• Don't mount antennas inside a carbon fiber enclosure. CF attenuates RF. If the antenna is inside a CF tube, you're losing signal.
• Don't forget the ground plane. A 900 MHz dipole needs a ground plane (the FC, the frame, or a dedicated ground plane element) to radiate properly. Hanging in free space with no ground reference, it underperforms.

Range Estimation (Quick and Dirty)

You don't need to calculate a full link budget to estimate range. Here's the shortcut.

Start with the manufacturer's claimed range. Divide by 3. That's your real-world range with obstacles, interference, and non-ideal antenna placement. Review needed: performance / failure mode Flag this

If you're doing better than 1/3 of claimed range, your setup is good. If you're doing worse, check antenna orientation, connections, and interference from other on-board transmitters. Review needed: performance / failure mode Flag this

If you need more range: 1. Better antenna on the ground station (cheapest improvement) 2. Higher VTX/radio power (easy but wastes battery) 3. Better antenna on the drone (limited by weight/size) 4. Lower frequency band (900 MHz instead of 2.4 GHz) 5. Higher gain directional antenna with tracker (most effective, most complex)

The order above is also the order of cost-effectiveness. A $15 directional antenna on your goggles does more for range than a $50 amplifier on the drone. Review needed: performance / commercial Flag this

The Antenna You Already Have

Before buying new antennas, check the ones you have:

• Is it the right band? A 5.8 GHz antenna on a 2.4 GHz radio is a $0 dummy load. It will not work. At all. This sounds obvious but it happens.
• Is it connected? Flex the cable gently at the connector. If the signal changes, the connection is bad.
• Is it damaged? A cracked antenna element, kinked coax, or corroded connector all kill performance.
• Is it oriented correctly? Rotating an antenna 90 degrees can cost 20 dB. Try different orientations before buying a new antenna.

Long-Range Antenna Setups (What Actually Gets You 20km)

When you see someone post a 20km flight on a wifibroadcast system like OpenHD, they're not using stock dipoles. They're using a high-gain directional antenna on the ground pointed at the drone, usually with an antenna tracker. The drone side stays omni.

This is the same principle as TV broadcasting. The TV tower has a high-power omnidirectional transmitter. Your house has a directional antenna (the dish, the yagi on the roof) pointed at the tower. One side broadcasts everywhere, the other side listens in one direction very well. Wifibroadcast systems work identically.

Stock Antennas: Set Realistic Expectations

The math is simple. Every 6 dB of additional antenna gain roughly doubles your range. Going from a stock dipole (3 dBi) to a panel array (18 dBi) adds 15 dB — that's about 5.6× the range. 3 km × 5.6 = ~17 km.

OpenHD's own range calculations (from openhdfpv.org/hardware/antennas, assuming -93dBm Rx sensitivity and 10dB link margin) confirm this:

Their FAQ states it directly: "1–3km is easy to achieve, even with low power WiFi cards and the antennas that come with them. Carefully chosen WiFi cards, antennas, and optionally an antenna tracker should put 20km+ within reach."

Air Side: Stay Omnidirectional

The drone changes orientation constantly — banks, turns, pitches. A directional antenna on the drone would lose link every time it turns away from you. Use omnidirectional antennas:

• Cloverleaf / Skew-Planar (RHCP): 2-3 dBi, circular polarized. Better multipath rejection than linear dipoles. The standard upgrade from stock.
• Pagoda (RHCP): 3-5 dBi, still mostly omni. Slight gain improvement over cloverleaf.
• Stock dipole: Works fine under 2 km. Replace for anything serious.

Use matching polarization on both ends — vertical/vertical or horizontal/horizontal. Cross-polarization costs 3 dB (half your power). RHCP circular polarization works for multipath rejection but most wifibroadcast community setups use linear vertical since the common directional ground antennas (panels, yagis) are linear vertical.

Ground Side: This Is Where Range Comes From

Antenna Trackers

Once your ground antenna exceeds ~10 dBi, the beam is narrow enough that you need to physically point it at the drone. An antenna tracker does this automatically using the drone's GPS position from the telemetry stream.

Dual Antenna Diversity (Best Practice)

Run two antennas on the ground: one omni + one directional on a tracker. The receiver picks the strongest signal per packet.

This gives you reliable close-range coverage (omni catches the drone overhead, behind you, during takeoff/landing) AND long-range capability (directional catches it at 15km). No switching, no manual pointing for nearby flights.

Most wifibroadcast systems (OpenHD, Ruby) support antenna diversity natively — plug in two adapters and it works.

Next

• Chapter 4: Link Budgets Without the Math — estimating range from specs without a calculator.
• Chapter 1: The Five Link Types — which antenna goes with which link.

The best antenna is the one that's pointed the right way, connected properly, and on the correct frequency. Everything else is optimization.

Chapter 4: Link Budgets with Evidence

Updated: October 1, 2026. A free-space reference model with explicit inputs; not a guaranteed operating range.

Use the RF calculator to enter a configuration and export the result, working, sources, and publication release.

Describe your configuration

Record hardware and firmware revisions, frequency, packet/data mode, antennas, cables, connectors, and geometry. The receiver threshold must apply to that configuration. Unknown sensitivity remains unknown.

Convert transmit power

dBm = 10 log10(P_mW). These are mathematical conversions, not permitted-power limits or recommended settings.

Calculate free-space loss

ITU-R P.525-5 Annex section 2.3 gives the practical rounded form:

FSPL_dB = 32.4 + 20 log10(frequency_MHz) + 20 log10(distance_km)

The table below is derived from that formula. Path loss is positive and subtracted from the budget. These values do not include obstructions, polarization mismatch, multipath, measured cable losses or interference.

Received power and margin

Received_dBm = TX_dBm + TX_gain_dBi + RX_gain_dBi - FSPL_dB - other_losses_dB
Margin_dB = Received_dBm - receiver_threshold_dBm

A positive margin says only that modeled received power exceeds your supplied threshold. It does not establish reliable connectivity, acceptable latency, permitted operation or aircraft authority. Unknown losses or an inappropriate threshold can dominate the answer.

Replace range shortcuts with evidence

The former fixed environment multipliers were not supported by a documented test method or configuration and have been withdrawn. Generic device sensitivities, obstacle-loss allowances, noise floors and legal-power labels were also removed pending configuration-specific sources.

Use Report / add field evidence to contribute a measurement. Include equipment and revisions, firmware/mode, antennas and placement, distance and geometry, date, conditions, measurement method and units, and uncertainty. A result applies to its recorded setup rather than every device in its band.

Keep measured losses separate from estimates. A noise-floor increase is not a universal subtraction from sensitivity; assess the receiver, bandwidth and measurement method.

Correction record

Proposed October 1 rewrite: unsupported range multipliers and categorical range conclusions withdrawn; configurable thresholds; explicit loss signs; sourced formula-derived tables. Publication remains subject to review.

Frequency Planning Worksheet

You have 6 drones, each with a control link, video link, and GPS. That's 18 RF links sharing the same airspace. If you don't plan your frequencies, your own fleet will jam itself before the enemy gets a chance to. This guide is the practical worksheet for deconflicting multi-drone operations.

Format: Print the assignment table. Fill it in before every multi-drone op. Cross-references: Frequency Bands · Link Budgets · Antennas · CRSF & ELRS Protocol · Video Transmitters · EW Countermeasures · Comms & Datalinks

The Three Links Per Drone

Every FPV drone has at minimum two active RF links, sometimes three:

GPS is receive-only and shared across all drones — it doesn't need deconfliction. Control and video are the two links you must plan.

Telemetry rides on the control link (CRSF/ELRS telemetry is bidirectional on the same channel). It does not need a separate frequency assignment.

MAVLink telemetry over a separate radio (SiK, mLRS, DroneBridge) is a fourth link that DOES need its own frequency assignment.

Frequency Band Map

900 MHz Band (ELRS 900 / MafiaLRS / mLRS)

Self-interference risk: Low for control links because ELRS uses frequency hopping (FHSS). Two ELRS transmitters on different binding phrases will hop independently and rarely collide. However, if you run 6+ drones on 900 MHz ELRS simultaneously, aggregate interference increases. Monitor LQ.

2.4 GHz Band (ELRS 2.4 / Ghost / WiFi)

Self-interference risk: HIGH. This band is crowded. WiFi from ground stations, Bluetooth from phones, and multiple ELRS transmitters all compete. ELRS FHSS helps but doesn't eliminate the problem. If running 4+ drones on 2.4 GHz ELRS, expect LQ degradation.

WiFi conflict: if using a DroneBridge ESP32 or companion computer with WiFi (Raspberry Pi, VOXL 2) on the same drone, the WiFi radio can interfere with a 2.4 GHz ELRS receiver. Use 900 MHz ELRS with 2.4 GHz WiFi, or vice versa. Never stack same-band RC and WiFi on the same drone.

5.8 GHz Band (Video)

This is where frequency planning matters most. Analog VTX channels are narrowband and can easily interfere with each other.

Critical rule: adjacent Raceband channels (e.g., R1 and R2) have enough spacing for 2 drones. Adjacent channels on other bands may NOT — some overlap. When mixing bands, use a frequency chart to verify no channel is within 30 MHz of another active channel.

Raceband is the standard for multi-pilot operations because its channels are deliberately spaced to minimize adjacent-channel bleed. Use Raceband unless you have a specific reason not to.

Non-Standard Video Bands

The Assignment Table

Print this and fill it in before every multi-drone operation.

┌──────────────────────────────────────────────────────────────────┐
│              FREQUENCY ASSIGNMENT — DATE: ________              │
├──────┬───────────┬──────────┬──────────┬──────────┬─────────────┤
│ Drone│ Callsign  │ RC Band  │ RC Notes │ VTX Chan │ VTX Power   │
├──────┼───────────┼──────────┼──────────┼──────────┼─────────────┤
│  1   │ _________ │ ________ │ ________ │ ________ │ ________    │
│  2   │ _________ │ ________ │ ________ │ ________ │ ________    │
│  3   │ _________ │ ________ │ ________ │ ________ │ ________    │
│  4   │ _________ │ ________ │ ________ │ ________ │ ________    │
│  5   │ _________ │ ________ │ ________ │ ________ │ ________    │
│  6   │ _________ │ ________ │ ________ │ ________ │ ________    │
├──────┴───────────┴──────────┴──────────┴──────────┴─────────────┤
│ Telem radio (if separate): Band ________ Chan ________          │
│ GCS WiFi: Band ________ Chan ________                           │
│ Mesh radio (if used): Band ________ Chan ________               │
│ Notes: ________________________________________________________ │
└──────────────────────────────────────────────────────────────────┘

Assignment Rules

Rule 1: Separate RC and Video Bands

Never put control and video on the same frequency band on the same drone. Standard pattern:

• RC on 900 MHz + Video on 5.8 GHz — the most common and safest combo
• RC on 2.4 GHz + Video on 5.8 GHz — also safe, but 2.4 GHz is crowded
• RC on 900 MHz + Video on 1.2 GHz — long range combo, check for GPS harmonic interference Review needed: performance / failure mode Flag this
• RC on 433 MHz + Video on 5.8 GHz — MafiaLRS config, maximum separation

Never: RC on 2.4 GHz + Video on 2.4 GHz. Never.

Rule 2: ELRS Binding Phrases Are Your Friend

ELRS frequency hopping means two drones on the same band won't directly interfere — they hop independently. But they share the same spectral space. The binding phrase ensures each TX only talks to its paired RX.

For multi-drone ops, use unique binding phrases per drone (or use model match IDs if sharing a binding phrase across a fleet).

Rule 3: VTX Channel Spacing

For analog video, minimum 30 MHz between any two active VTX channels. Raceband channels are pre-spaced for this:

6 drones on Raceband (maximum safe assignment):

Note: R3 (5732) and R6 (5843) skipped to maintain wider spacing. With 8 Raceband channels, 6 drones is the practical maximum for simultaneous analog video without interference.

Digital video (DJI, Walksnail, HDZero) handles channel management internally with wider bandwidth per channel. Maximum simultaneous drones varies by system — check manufacturer documentation. Generally 4–8 simultaneous digital feeds per band.

Rule 4: Telem and Mesh on Their Own Channels

If running a separate telemetry radio (SiK 915 MHz, mLRS, DroneBridge):

• Don't put it on the same band as your RC link
• If both are 900 MHz, ensure different channel/frequency settings and verify they don't overlap using the manufacturer's channel plan
• mLRS and ELRS 900 MHz can coexist if on different LoRa channels, but test before trusting in the field

Mesh radios (Silvus, Doodle Labs, Rajant) typically operate on their own managed spectrum and self-deconflict within the mesh. But they can still interfere with RC or video if in the same band. Check the mesh radio's operating frequency before assignment.

Rule 5: Ground Station RF Discipline

Your ground station emits RF too:

• Laptop/tablet WiFi — 2.4 GHz and 5 GHz. If parked next to your goggle patch antenna, the 5 GHz WiFi can interfere with 5.8 GHz video. Disable 5 GHz WiFi on ground devices or position them away from antennas.
• Phone hotspot — same issue. Keep phones away from receiver antennas.
• Mesh radio ground node — ensure its antenna isn't pointed at your video receiver antenna.

Scenario Templates

Scenario A: 2 Drone FPV Team (Standard)

Drone 1: ELRS 900 MHz / R1 (5658 MHz) / 400 mW
Drone 2: ELRS 900 MHz / R4 (5769 MHz) / 400 mW

Simple. Maximum VTX channel separation. Both on 900 MHz ELRS with different binding phrases — no RC conflict.

Scenario B: 4 Drone Squad (Mixed Recon + Strike)

Recon 1:  ELRS 900 MHz / R1 (5658 MHz) / 200 mW (low signature)
Recon 2:  ELRS 900 MHz / R4 (5769 MHz) / 200 mW
Strike 1: ELRS 900 MHz / R6 (5843 MHz) / 600 mW
Strike 2: ELRS 900 MHz / R8 (5917 MHz) / 600 mW

Recon drones run lower VTX power to reduce detectability. Strike drones run higher power for better video at speed. All on 900 MHz ELRS with unique binding phrases.

Scenario C: 6 Drone Max Density + GCS

Drone 1-3: ELRS 900 MHz / R1, R2, R4 / 400 mW each
Drone 4-6: ELRS 2.4 GHz / R5, R7, R8 / 400 mW each
GCS telem: mLRS 900 MHz (separate LoRa channel from ELRS)
GCS WiFi:  5 GHz only (disabled 2.4 GHz)

Split RC across bands to reduce aggregate spectral load. GCS WiFi on 5 GHz only to avoid 2.4 GHz interference. Telem radio on different LoRa channel than the 900 MHz ELRS units.

Scenario D: Contested Environment (EW Threat)

Drone 1-2: MafiaLRS 433 MHz / 1.2 GHz video / 1 W
Drone 3-4: MILELRS 900+2.4 multiband / R1, R4 (5.8 GHz) / 600 mW
Drone 5:   Fiber optic (no RF video/control)
Drone 6:   ELRS 900 MHz / 7.2 GHz video / 200 mW

Maximum frequency diversity. No two drones share the same link stack. Fiber optic drone is immune to all RF jamming. 7.2 GHz video is outside most jammer coverage. MafiaLRS on 433 MHz is below standard jammer bands. MILELRS multiband provides failover if one band is jammed.

Harmonics and Interference Gotchas

1.2 GHz Video ↔ GPS L1

1.2 GHz VTX 2nd harmonic = 2.4 GHz (interferes with 2.4 GHz RC). 1.2 GHz VTX at high power can also desense the GPS L1 receiver (1.575 GHz) if the VTX antenna is near the GPS module. Use physical separation (GPS on top, VTX antenna on bottom) and a bandpass filter on the GPS if available.

5.8 GHz Video ↔ WiFi 5 GHz

5 GHz WiFi (5150–5825 MHz) overlaps with low 5.8 GHz video channels. If running a companion computer with 5 GHz WiFi, avoid VTX channels below 5800 MHz, or disable 5 GHz WiFi and use 2.4 GHz WiFi instead.

Motor Noise ↔ Everything

ESC switching noise generates broadband EMI. On poorly shielded builds, this can raise the noise floor across all bands. Countermeasures: capacitors on ESC power leads, twisted signal wires, physical separation between power wiring and RF components, ferrite beads on USB and signal cables.

Spectrum Analyzer: What to Look For

If you have a spectrum analyzer (even a cheap RTL-SDR works for basic analysis), sweep the operating area before launch:

• Existing transmitters — are there other operators, WiFi APs, or known jammers active? Avoid their frequencies.
• Noise floor — how loud is the ambient RF? A high noise floor on a specific band means poor performance on that band regardless of jamming.
• Your own emissions — power up one drone at a time and check for spurs, harmonics, and unintended emissions.

See: ELINT for Drone Operators (planned) for advanced spectrum analysis techniques.

Sources

• ExpressLRS frequency hopping documentation
• Oscar Liang, multi-pilot frequency planning guides
• Forge troubleshooting database (video interference entries)
• FPV community race frequency coordination practices
• Field experience from multi-drone training operations

Chapter 37: Packable Antennas — Range You Can Carry

The best long-range antenna is worthless if it doesn't fit in the bag you actually brought. This chapter is about the antennas that give you real range and still pack down — and the one polarization mistake that quietly throws away half your signal on a WiFi link.

The Three-Way Trade

Chapter 3 covered the gain-versus-pattern trade. In the field there is a third axis: how small it packs and how fast it deploys. You are now trading three things against each other, not two:

• Gain — range, but only in the direction the antenna points.
• Beamwidth — how forgiving it is about aiming (and, on a mesh, how many neighbors it can hear).
• Pack size / deploy time — whether it rides in a pouch and sets up in ten seconds, or needs a mast, a tripod, and a tracker.

There is no antenna that wins all three. A grid dish is 24 dBi and packs like a trash-can lid. A rubber-duck packs to nothing and gives you 2 dBi. The useful middle — flat CP patches and dual-band panels, 8–13 dBi, that pack flat — is where a field-portable long-range link actually lives.

The Polarization Trap on WiFi Links

This is the single most common way to lose 3–20 dB on a WiFi-broadcast or mesh link (WFB-NG, OpenHD, or a raw ad-hoc/mesh setup on cards like the MediaTek MT7612U), and almost nobody checks it.

The antenna sets the polarization, not the radio. An MT7612U USB card is fed as a linear (dipole) device, but if you bolt a circularly polarized antenna onto it, the link radiates circular. What matters is the pair of antennas across the link, not the chipset.

Two rules fall out of this table:

1. If you run CP on one end, run same-hand CP on the other. A 3 dBic CP omni on the air side and a CP patch on the ground must be the same handedness (both RHCP or both LHCP). Opposite hands is not a 3 dB penalty — it is a 20–30 dB hole that looks like a dead radio.
2. Don't mix CP and linear to "save money." Putting a linear panel (e.g. an Alfa APA-M25) against a CP air antenna costs a flat 3 dB. It works, but you gave away a quarter of your range for nothing. If you want linear panels on the ground, run a linear antenna on the air side too.

The CP-to-linear 3 dB is at least consistent — it does not swing with airframe rotation the way linear-to-linear misalignment does (which is why CP is preferred on things that bank and roll in the first place). That consistency is the only reason a mixed setup is tolerable.

Mesh Topology Changes the Antenna Choice

If the link is a true mesh — a routing protocol such as Babel (RFC 8966, a loop-avoiding distance-vector protocol built for dynamic wireless mesh) picking paths across several moving nodes — then a narrow directional antenna on a node is a liability. The node can only hear neighbors inside its beam; anything behind it is invisible to the routing table, and the mesh can't route around a link it can't see.

The practical read: put the gain on the fixed end pointed at the operating area, keep the moving ends omni, and prefer a wide-beam patch (like the TrueRC X-Air's ~120° pattern) over a narrow yagi so the mesh keeps discovering neighbors across a sector instead of a pencil line. A tracker only earns its complexity once the beam gets narrow enough (below ~15–20°) that a human can't keep it pointed.

Babel doesn't change RF range — it changes what the link needs to stay routed: a healthy path in both directions. A big patch on the gateway does nothing if the moving node's little omni can't be heard on the way back. Budget the weaker direction, not the stronger one.

The Packable Menu

Gains and pack characteristics below are from manufacturer specs and field use. Treat gain as a comparison guide, not a guarantee — axial ratio and real pattern vary.

Air / moving side — stay omni, stay light

Don't chase gain on the moving end — a directional antenna there loses link every time the airframe turns away.

Ground / fixed side — this is where range is won

The sweet spot for "range you can carry" is the flat CP patch (X-Air / X²-Air) or the dual-band linear panel (APA-M25) — 8–13 dBi, rides flat in a pouch, wide enough beam to cover a sector by hand. That band of the table is the whole point of the chapter.

Worked Example: MT7612U Mesh, CP Both Ends

The setup that prompted this chapter, run through the Chapter 4 method so the numbers are honest:

• Radios: MT7612U USB cards both ends. Box says 23 dBm; the Linux driver caps these at ~18 dBm and they famously ignore higher power settings — budget 18 dBm, not 23.
• Air antenna: 3 dBic CP omni.
• Ground antenna: TrueRC X-Air, ~10 dBic CP directional patch, same handedness as the air antenna (this is not optional — see the polarization trap above).
• Polarization loss: 0 dB (matched CP-CP). Cable/connector: ~1 dB.
• Effective one-way budget: 18 + 3 + 10 − 1 = 30 dB of power + gain to spend against path loss.
• RX sensitivity (WFB-NG-style, MCS0/1, long GI): ~−91 dBm at the raw decode edge.

Two range numbers, both assuming clear line of sight and a clear first Fresnel zone:

Read those two columns as the envelope, not a promise. "Theoretical" is the distance where the signal just reaches the decode threshold with nothing held back — one gust of multipath and it drops. "Expected" holds back 10 dB for fading, imperfect aiming, and Fresnel intrusion, which is what you actually plan around. Reality lands between them and drifts toward the left column only in a clean rural RF environment.

Three things move these numbers more than anything else:

1. Band. 2.4 GHz buys ~3× the range of 5.8 GHz for the same gear (13 dB less free-space loss at the same distance). If regulations and spectrum congestion allow it, run the link on 2.4.
2. The MT7612U's real 18 dBm. That's ~5 dB under the box number — about a 45% range haircut baked in before you leave the truck. Measure your card's actual output; don't trust the label.
3. Fresnel, not just line of sight. At 4 km on 2.4 GHz the first Fresnel zone is ~11 m in radius at midpoint. Ground clutter eating the bottom of it is most of the gap between the two columns above.

Anatomy of a Range Record

The packable setup above lands in single-digit kilometres. WiFi-broadcast systems like OpenHD have flown 60–75 km on the same physics. The record is not one exotic component — it is the discipline of stacking every lever at once. Free-space loss at 60 km on 5.8 GHz is ~143 dB; closing that with margin takes roughly 58 dB of TX power + antenna gain combined. Here is where that comes from, in order of contribution:

The air side stays omni through all of this — the aircraft banks and turns and can't point anything. Every one of these knobs lives on the ground or in the flight profile. That is the whole lesson of this chapter at its extreme: put the gain on the end that isn't moving, give the signal a clean path to fly across, and never rely on a single trick.

The failure mode of chasing records: each lever narrows your operating envelope. A 15° beam that loses tracking lock drops the link. A 5 MHz channel gives you a slideshow, not video. MCS0 at the margin means one terrain intrusion is a dropout, not a blur. Records are flown by people who accept those constraints deliberately — they are not a config you leave on for everyday flying.

Recommendations

If you keep CP (your air antenna is CP): Ground end → TrueRC X-Air (matched hand, ~10 dBic, flat, no tracker for a sector). Air end → keep the 3 dBic CP omni or step to a Singularity-class stub. This is the smallest-bag, no-mismatch path and needs zero changes to your polarization scheme.

If you'll commit the whole link to linear: Ground end → Alfa APA-M25 (dual-band, 8/10 dBi, packs flat, native RP-SMA for the Alfa cards). Air end → linear dipole. Slightly cheaper, dual-band in one panel, but only correct if both ends are linear.

Either way: - Run 2.4 GHz for range unless the band is unusable. - Point the fixed patch at the operating sector, not a pinpoint — the wide beam is doing you a favor on a moving target and on a mesh. - Add a tracker only when the ground gain climbs past ~15 dBi and the beam gets too narrow to hold by hand.

Failure Modes

• Wrong-hand CP. RHCP against LHCP looks exactly like a dead radio or a broken cable. Before you tear the build apart, confirm both CP antennas are the same handedness. This costs 20–30 dB.
• Trusting the box power. "23 dBm" on an MT7612U is ~18 dBm in practice. Every downstream range estimate inherits that 5 dB error.
• Directional antenna on a mesh node. Narrow-beam gain on a moving or peer-facing node blinds the routing table to neighbors outside the beam. Keep gain on the fixed end.
• One-way budgeting. A big ground patch that the air node can't be heard back through gives you a downlink and no uplink. Babel needs the return path; budget the weaker direction.
• Ignoring the Fresnel zone. "I have line of sight" is necessary, not sufficient. Clutter in the bottom of the first Fresnel zone pulls you off the theoretical number long before the geometry says it should.

Next

• Chapter 3: Antennas for People Who Aren't RF Engineers — gain, pattern, and polarization from the ground up.
• Chapter 4: Link Budgets Without the Math — the method behind the worked example above.
• Chapter 2: Frequency Bands & Regulatory Reality — before you "just run 2.4 GHz for range," check what you're allowed to transmit.

Range you can't carry to the field is range you don't have. Pick the antenna that packs, match your polarization, and put the gain on the end that isn't moving.

Chapter 5: Four Flight Controller Firmware Ecosystems

This guide covers Betaflight, INAV, ArduPilot and PX4. Select an exact board target, firmware version and matching configuration application. A protocol name alone does not establish support for a particular message, sensor or vehicle.

Functional requirements

This is a requirements checklist. It does not rank flight feel, community size, safety or compatibility.

Betaflight

Betaflight 2025.12 introduces Altitude Hold and Position Hold when included in the build. GPS is required for Position Hold and a magnetometer is strongly recommended in the project's documentation. GPS Rescue, position holding and waypoint missions are distinct capabilities. Check the current release rather than extrapolate from older descriptions.

The Betaflight App is a web application with platform-specific packaging; it replaces the former Chrome-app description. Match the app/firmware compatibility table and release channel. The release watchlist separately records newer versions whose capabilities require checking.

MSP provides versioned message/command interfaces; CLI configuration backups such as diff all and dump all have different scope. Preserve the original firmware/defaults and read back migrated configuration after an upgrade.

Sources checked 2026-10-07: 2025.12 Position Hold, App guide, and official releases. These establish the stated feature/version scope rather than compatibility with every board.

INAV

INAV publishes firmware, board targets and a matching configurator through its project repositories. Consult the exact release notes for supported vehicles, navigation modes, sensors and MSP interfaces. Do not transfer Betaflight CLI commands or defaults merely because both projects expose MSP and a CLI.

INAV project documentation and Configurator releases. The release watchlist separates stable releases from release candidates.

ArduPilot

ArduPilot documentation and parameters are vehicle- and version-specific. Use the selected vehicle's parameter reference and board documentation. Parameter counts vary with the build and are not a measure of integration capability.

MAVLink supports published telemetry and request/command services. Stream-rate control depends on the firmware and MAVLink interface instance; it does not map universally to a physical UART. Verify message support, addressing, units, frames and command acknowledgements separately.

ArduPilot vehicle documentation, message-rate requests, and Copter 4.7.1 parameter reference, checked 2026-10-07. See GNSS integration for the scoped parameter audit.

PX4

PX4 has versioned board, vehicle and interface documentation. Its Offboard mode requires the documented proof-of-life stream and valid estimator/control prerequisites. Message support, reference frames and loss behavior must match the selected release. Main-branch documentation can describe unreleased changes.

PX4 v1.17 Offboard, checked 2026-10-07. See multiclient telemetry for observer versus command-owner boundaries.

Upgrade and integration checks

• Record board revision, exact firmware/application versions, enabled features and configuration exports.
• Match sensor/interface support to the exact build, with electrical levels and pinout checked separately.
• Preserve logs and test the configuration/recovery path in software and on a propeller-free bench before field acceptance.
• Use backup and recovery, software failure replay, UART layout, and MAVLink.

A changed release opens a new check; it does not authorize copying parameters or changing an aircraft automatically.

Chapter 6: MSP Protocol — The Betaflight/iNav Language

MSP is a question-and-answer protocol. You ask the FC a question (send a request with a function code). It answers (sends a response with the data). No streaming, no subscriptions, no surprises.

What MSP Is

MSP (MultiWii Serial Protocol) is the serial communication protocol used by Betaflight and iNav. It's been around since the MultiWii days and has evolved through several versions. The current version is MSP v2, which supports 16-bit function codes and CRC8 checksums. Review needed: performance / configuration Flag this

MSP is simple by design. It runs over any serial connection (UART, USB, TCP, Bluetooth) at any baud rate. There are no connection handshakes, no sessions, no state. Send a request, get a response.

Packet Format

MSP v2 Request (outgoing)

Byte:  0     1     2     3     4-5       6     7-8       9..N     N+1
       $     X     <     flag  func_id   0x00  payload   payload  crc8
       0x24  0x58  0x3C  0x00  [16-bit]  0x00  size[16]  [data]   [crc]

MSP v2 Response (incoming)

Byte:  0     1     2     3     4-5       6-7       8..N     N+1
       $     X     >     flag  func_id   size      payload  crc8
       0x24  0x58  0x3E  0x00  [16-bit]  [16-bit]  [data]   [crc]

Same structure but with > (0x3E) instead of < (0x3C).

The Messages That Matter

Identity

These are the first messages to send on any new connection. They tell you what firmware is running, what version, and what hardware it's running on.

Auto-detect pattern: Send MSP_FC_VARIANT. If you get "BTFL", it's Betaflight. If "INAV", it's iNav. If no response within 2 seconds, it's not an MSP firmware (try MAVLink).

PID Tuning

Each value is 0-255. The FC interprets these differently by firmware version (scaling factors change between BF 4.3 and 4.4, for example). Always record the firmware version alongside PID values.

Rates

Rate payload format depends on the configured rate type (Betaflight rates, Actual rates, KISS rates, Quick rates). Read rates_type from the RC tuning response to know how to interpret the values.

Filters

Battery

Blackbox

Blackbox download is the most bandwidth-intensive MSP operation. At 115200 baud, downloading 2 MB of flash takes ~3 minutes. At 921600 baud (via ESP32 bridge), it takes ~20 seconds.

Motor Control

MSP_SET_MOTOR bypasses the PID controller and directly sets motor outputs. Props must be removed when using this. This is for motor direction testing, not flight.

EEPROM

Always send MSP_EEPROM_WRITE after SET commands. Without it, your changes are lost on the next reboot.

Write Safety Pattern

Never write to an FC without this sequence:

1. Read the current value (snapshot before)
2. Show the diff to the operator (before vs after)
3. Get approval (operator confirms)
4. Write the new value via MSP_SET_*
5. Read back to verify the FC accepted it
6. Compare read-back to what you wrote
7. EEPROM write after all changes in the batch
8. Log every change with timestamp, old value, new value

Step 5 is critical. Some FC firmware versions silently clamp values to valid ranges. If you write P=200 and read back P=150, the FC clamped it. Your operator needs to know.

Practical Tips

Baud rate: MSP works at any baud rate, but the FC UART must be configured to match. Betaflight defaults MSP-configured UARTs to 115200. You can change this in the Ports tab. For blackbox download speed, 921600 is recommended. Review needed: performance / configuration Flag this

Timeout: If you send a request and don't get a response within 100 ms, the FC didn't understand it (wrong function code, wrong firmware version, or the UART isn't configured for MSP). Retry once, then try a different approach.

Versioning: MSP function codes and payload formats change between firmware versions. A message that works on BF 4.4 may not exist on BF 4.2. Always detect the firmware version (MSP_FC_VERSION) before sending version-specific messages.

Multiple MSP ports: An FC can have multiple UARTs configured for MSP simultaneously. This is useful for connecting both a configurator and a companion computer. Each port operates independently.

MSP over WiFi: The ESP32 bridge (Tooth, SpeedyBee adapter) wraps MSP in TCP. The byte stream is identical to serial — the same parser works on both USB and TCP transport. The only difference is the connection setup.

Next

• Chapter 7: MAVLink Protocol — the other language, for ArduPilot and PX4.
• Chapter 8: UART Layout — where to put your MSP connections.

MSP is simple. That's its strength. Ask a question, get an answer. No handshakes, no state, no negotiation. The protocol stays out of the way so you can focus on the data.

Chapter 7: MAVLink Protocol — The ArduPilot/PX4 Language

MAVLink is a publish-subscribe protocol. You tell the FC what streams you want, and it sends them continuously. You send commands when you need something done. Both directions flow at the same time.

What MAVLink Is

MAVLink (Micro Air Vehicle Link) is the communication protocol used by ArduPilot, PX4, and their ecosystems. It's been the standard for autonomous drone communication since ~2009.

Unlike MSP (request-response), MAVLink is a streaming protocol. The FC continuously publishes telemetry at configured rates, and the GCS/companion sends commands as needed. Both directions are independent — you can receive telemetry while sending a command.

MAVLink v2 is the current version. v1 is deprecated but still supported for backward compatibility. Always use v2 for new development. Review needed: performance / configuration Flag this

Packet Format (MAVLink v2)

A MAVLink v2 packet has a 10-byte header. With payload length L, the CRC occupies bytes 10+L and 11+L; a signed packet then adds a 13-byte signing trailer.

The checksum accumulates the message-specific CRC_EXTRA after the packet bytes covered by the CRC. CRC_EXTRA is not the checksum's initial seed. Signing authenticates messages; it does not encrypt the payload.

Primary references: serialization, signing and common definitions, checked 2026-10-07.

System and Component IDs

Every device on a MAVLink network has a system ID and component ID.

System ID: Identifies the vehicle. Drone 1 = system 1, Drone 2 = system 2. GCS is typically system 255. In a swarm, each drone must have a unique system ID.

Component ID: Identifies a subsystem within the vehicle. - 1 = Autopilot (the FC) - 100 = Camera - 154 = Gimbal - 191 = Companion computer (Wingman uses this) - 250 = GCS

Why this matters: When you connect to a mesh with 10 drones, you'll receive MAVLink messages from all of them. The system ID tells you which drone sent each message. If two drones have the same system ID, you can't tell them apart. This is one of the most common mistakes in multi-vehicle setups.

Setting the system ID: - ArduPilot: SYSID_THISMAV parameter - PX4: MAV_SYS_ID parameter

The Messages That Matter

HEARTBEAT (msg_id = 0) — The Keepalive

HEARTBEAT rates and timeout rules are implementation-specific; 1 Hz is common. It's how devices discover each other and know the connection is alive.

Fields:
  type          = vehicle type (2=quadrotor, 1=fixed wing, etc.)
  autopilot     = firmware (3=ArduPilot, 12=PX4)
  base_mode     = armed/disarmed flag (bit 7)
  custom_mode   = current flight mode (firmware-specific number)
  system_status = boot/calibrating/active/critical/emergency

Auto-detect pattern: Send a HEARTBEAT with system ID 255 (GCS). Wait for a response. Read the autopilot field: 3 = ArduPilot, 12 = PX4. This is the equivalent of MSP_FC_VARIANT for the MAVLink world.

A missed heartbeat can indicate congestion, a stopped process or a transport fault. Configure and document a timeout for the application; a five-second rule is not part of the universal wire format.

Parameter Protocol

MAVLink parameters are named floating-point values. ArduPilot has ~1,200. PX4 has ~900.

Full parameter pull: 1. Send PARAM_REQUEST_LIST 2. FC streams PARAM_VALUE messages (one per parameter) 3. Track received indices — if any are missing after the stream ends, request them individually with PARAM_REQUEST_READ

A full pull of ~1,200 ArduPilot parameters at 115200 baud takes 5-15 seconds depending on link quality.

Writing a parameter: 1. Send PARAM_SET with param_id (name) and param_value 2. FC responds with PARAM_VALUE confirming the new value 3. If the confirmed value differs from what you sent, the FC rejected or clamped the value

Parameters persist across reboots (stored in EEPROM/flash). No separate save command needed, unlike MSP's MSP_EEPROM_WRITE.

Telemetry Streams

Request telemetry streams by sending REQUEST_DATA_STREAM or SET_MESSAGE_INTERVAL.

Key telemetry messages:

Setting stream rates: Prefer MAV_CMD_SET_MESSAGE_INTERVAL where the exact firmware supports it. ArduPilot SRx_* indices identify MAVLink instances; they do not universally equal physical SERIALx port numbers. Multiple clients can overwrite each other's rate requests. ArduPilot stream-rate documentation, checked 2026-10-07.

Commands

MAVLink commands are sent via COMMAND_LONG or COMMAND_INT and acknowledged via COMMAND_ACK.

Arm command:

COMMAND_LONG:
  target_system = 1    (drone's system ID)
  command = 400         (ARM_DISARM)
  param1 = 1.0          (1=arm, 0=disarm)
  param2 = 0.0          (0=normal, force variants are excluded from this example)

Wait for COMMAND_ACK. MAV_RESULT: 0 ACCEPTED, 1 TEMPORARILY_REJECTED, 2 DENIED, 3 UNSUPPORTED, 4 FAILED, 5 IN_PROGRESS. Acceptance is a command-protocol result; confirm the resulting vehicle state separately.

Mission Protocol

Upload waypoint missions to the FC:

1. Send MISSION_COUNT (number of waypoints)
2. FC requests each with MISSION_REQUEST_INT
3. Send each MISSION_ITEM_INT
4. FC confirms with MISSION_ACK

Download existing mission: 1. Send MISSION_REQUEST_LIST 2. FC sends MISSION_COUNT 3. Request each with MISSION_REQUEST_INT 4. FC sends each MISSION_ITEM_INT

Offboard Control (PX4)

PX4's offboard mode lets the companion computer directly command position, velocity, or attitude setpoints:

SET_POSITION_TARGET_LOCAL_NED:
  x, y, z = position in local NED frame (meters)
  vx, vy, vz = velocity (m/s)
  type_mask = which fields are valid

Requirements for offboard mode: 1. Companion must stream setpoints at > 2 Hz (PX4 requires continuous updates or it exits offboard mode) 2. RC switch must be set to offboard mode 3. Vehicle must be armed

This is the control path for Wingman L3 (Delegate) autonomous operations on PX4.

ArduPilot vs. PX4: MAVLink Differences

Both speak MAVLink v2, but they differ in important ways:

Implication for tools: Any tool that works across both ArduPilot and PX4 (QGroundControl, MAVSDK, Wingman) must handle these differences. The MAVLink wire format is identical — the interpretation of mode numbers, parameter names, and command behaviors differs.

Practical Tips

Always send heartbeats. Your GCS or companion must send HEARTBEAT at 1 Hz to the FC. If the FC doesn't receive GCS heartbeats, it may trigger GCS failsafe (ArduPilot: FS_GCS_ENABLE).

Monitor packet loss. MAVLink packets have a sequence number. If you see gaps in the sequence, you're losing packets. At > 5% loss, the link is degraded. At > 20%, it's unreliable for commands.

Don't flood the link. Sending commands faster than the FC can process them causes buffer overflow and dropped messages. One command at a time, wait for COMMAND_ACK before sending the next.

Use MAVSDK or pymavlink, not raw parsing. MAVLink has 300+ message types with varying payload formats. Writing a parser from scratch is an error-prone waste of time. MAVSDK (for control) and pymavlink (for analysis) handle the parsing.

Test with SITL. Both ArduPilot and PX4 have Software-In-The-Loop simulators that emulate a real FC over a simulated MAVLink link. Test your companion software against SITL before connecting to real hardware.

Next

• Chapter 6: MSP Protocol — the simpler alternative for Betaflight and iNav.
• Chapter 8: UART Layout — where MAVLink connections go in the FC's serial port map.

MAVLink is a conversation. The FC talks continuously. You listen and speak when you have something to say. The protocol handles the rest.

Chapter 8: UART Layout and Why It Matters

You will run out of UARTs before you run out of ideas. Planning the layout before you build saves hours of rewiring later.

What a UART Is

A UART (Universal Asynchronous Receiver/Transmitter) is a serial port. Two wires: TX (transmit) and RX (receive). Every device that talks to the flight controller — RC receiver, GPS, telemetry radio, companion computer, ESC telemetry, Bluetooth module, mesh radio — needs a UART.

The flight controller has a fixed number of UARTs. Once they're allocated, they're gone. Adding another device means either freeing a UART or getting a different FC.

How Many UARTs You Actually Get

"Usable" is lower than "hardware" because: - One UART is typically dedicated to USB (VCP/CDC) for configurator access - Some UARTs share pins with SPI (used for gyro, OSD, flash) and can't be used - Some UARTs have inverted-only pads on the PCB (for SBUS) and can't be repurposed without hardware modification

Check your FC's documentation for which UARTs are actually available on pads. The schematic may show 6 UARTs, but if only 4 have TX/RX pads on the board, you have 4 usable UARTs.

The Standard Allocation

For a typical FPV quad with GPS and telemetry:

That uses 4 of your ~5 usable UARTs and you haven't added a companion computer, mesh radio, or Bluetooth module yet.

What Eats UARTs

Every peripheral that communicates over serial needs its own UART. Here's the complete list of things that might want one:

Strategies When You Run Out

1. CRSF Telemetry Passthrough

If your RC receiver uses CRSF protocol (ELRS, Crossfire, Ghost), it already has a bidirectional link to the transmitter. You can send telemetry data (battery, GPS, attitude) through the RC link instead of using a separate telemetry radio.

Saves: 1 UART (the one that would have gone to a telemetry radio)

Trade-off: Telemetry bandwidth is limited to what CRSF can carry (basic flight data, not full MAVLink). If you need full MAVLink telemetry (parameter editing, mission upload), you still need a separate radio.

2. Soft Serial

Betaflight and iNav support "soft serial" — bit-banging a UART on any GPIO pin. It works for low-baud-rate devices.

Saves: 1 hardware UART

Trade-off: Limited to ~19200 baud reliably. Not suitable for CRSF (420000), GPS at high rate, or MAVLink. Good for: SmartPort telemetry, serial LED, low-rate telemetry.

3. Companion Computer as Hub

Instead of connecting multiple devices to the FC, connect them to a companion computer and use one UART between the companion and FC.

Before (4 UARTs on FC):
  FC UART1 ← RC receiver
  FC UART2 ← GPS
  FC UART3 ← Telemetry radio
  FC UART4 ← Mesh radio

After (2 UARTs on FC):
  FC UART1 ← RC receiver
  FC UART2 ← Companion computer (MAVLink)

  Companion ← GPS (USB)
  Companion ← Telemetry radio (USB or Ethernet)
  Companion ← Mesh radio (Ethernet)

Saves: 2+ UARTs on the FC

Trade-off: Adds weight, power consumption, and complexity. The companion computer becomes a single point of failure for everything except manual RC control.

4. I2C Instead of Serial

Some peripherals (compass, barometer, rangefinder, optical flow) are available in both serial and I2C versions. I2C uses a shared bus — multiple devices on the same two wires (SDA, SCL).

Saves: 1 UART per device moved to I2C

Trade-off: I2C is slower than serial and can have bus contention issues with multiple devices. But for low-bandwidth sensors, it's fine.

5. DMA and UART Sharing (Advanced)

On STM32H7 FCs, DMA (Direct Memory Access) allows the CPU to handle UART traffic more efficiently. Some advanced configurations use UART inversion and protocol detection to share a single UART between two devices that take turns.

This is fragile, FC-specific, and not recommended unless you know exactly what you're doing.

The UART Planning Template

Before building, fill this out:

Platform: _______________
FC: _______________
MCU: _______________
Available UARTs: _______________

| UART | Device | Protocol | Baud Rate | Required? |
|------|--------|----------|-----------|-----------|
| 1    |        |          |           |           |
| 2    |        |          |           |           |
| 3    |        |          |           |           |
| 4    |        |          |           |           |
| 5    |        |          |           |           |
| 6    |        |          |           |           |

Devices that didn't get a UART:
  _______________ → moved to I2C / soft serial / companion / dropped

UARTs remaining after allocation: ___

If you fill this out and you're already at zero remaining UARTs before adding the companion computer you wanted, you need a different FC or a companion-as-hub architecture.

Platform-Specific UART Maps

Typical F405 (4 usable UARTs)

UART1 → USB VCP (configurator) — not available for peripherals
UART2 → RC Receiver (CRSF @ 420000)
UART3 → GPS (UBX @ 115200)
UART4 → Available
UART5 → Available
UART6 → ESC Telemetry (if DShot bidirectional)

Two free UARTs (4 and 5) for telemetry radio, companion, mesh, or Bluetooth.

Orqa H7 QuadCore (6+ usable UARTs)

USART1 → USB VCP
USART2 → Available
USART3 → RC (GHST/IRONghost @ 420000)
UART4  → Available
USART6 → MAVLink telemetry (ATAK/TAK @ 115200)
UART7  → GPS (UBX @ 115200)
UART8  → ESC telemetry

Three free UARTs (2, 4, plus potential soft serial). The H7's extra UARTs are why it supports more complex integrations than F4.

PX4 on Pixhawk 6X

TELEM1 → MAVLink GCS (115200 or 57600)
TELEM2 → MAVLink companion computer (921600)
GPS 1  → GPS (auto-detect)
GPS 2  → Second GPS or compass
RC IN  → RC receiver (SBUS/CRSF)
DEBUG  → Console / NSH shell

PX4 labels its ports by function rather than UART number. The mapping to hardware UARTs is in the board configuration.

Common Mistakes

1. Wrong baud rate. CRSF is 420000. Many people set 115200 because that's the "default" they're used to. The receiver will not connect. Always check the protocol's required baud rate.

2. TX/RX swap. FC TX connects to device RX, and vice versa. This is wrong more often than any other wiring mistake. If a serial device doesn't respond, swap TX and RX as the first diagnostic step.

3. Voltage mismatch. Most FCs output 3.3V serial. Most peripherals accept 3.3V. But some older devices are 5V serial and can damage 3.3V inputs. Check before connecting.

4. Two devices on one UART. You can't connect a GPS and a telemetry radio to the same UART and expect both to work. Serial is point-to-point. Use a companion computer or multiplexer if you need to share.

5. Forgetting the configurator UART. If you reassign the USB/VCP UART to a peripheral, you may lose the ability to connect Betaflight Configurator. Always keep at least one path to the configurator available (USB or MSP-over-other-UART).

Next

• Chapter 6: MSP Protocol — the protocol that rides on these UARTs when talking to Betaflight and iNav.
• Chapter 13: Adding a Companion Computer — the architecture that solves the "not enough UARTs" problem.

Plan your UARTs before you solder. Desoldering a GPS module because you need that UART for a companion computer is not how you want to spend a Saturday.

Appendix B: UART Maps for Common Flight Controllers

Auto-generated from firmware source repos by mine_firmware_configs.py

Use this reference to identify which UARTs are available on your FC, what MCU it runs, and which gyro(s) are onboard. Essential for wiring receivers (ELRS/CRSF), GPS, VTX telemetry, and DJI air units.

Betaflight (187 boards)

iNav (94 boards)

ArduPilot (130 boards)

PX4 (5 boards)

Full dataset: forge_firmware_configs.json (1,717 targets) Search: python3 miners/firmware/mine_firmware_configs.py --match "YourBoard"

CRSF & ELRS Protocol Deep Dive

CRSF (Crossfire) is the serial protocol that carries RC channel data and telemetry between the receiver and flight controller. ExpressLRS uses CRSF as its wire protocol. Understanding CRSF at the protocol level matters because it's the foundation for ELRS, MafiaLRS, MILELRS, and every military fork in the ecosystem.

Cross-references: UART Layout · Five Link Types · ELRS Airport Mode · MafiaLRS · Military Firmware Forks · Comms & Datalinks

What CRSF Is

CRSF is a bidirectional serial protocol designed by TBS (Team BlackSheep) for their Crossfire system. When ExpressLRS was developed, it adopted CRSF as the wire-side protocol between the receiver and the flight controller rather than inventing a new one. This means every ELRS receiver speaks CRSF over its UART connection.

CRSF carries two data streams in opposite directions:

• Downlink (RX → FC): RC channel data (stick positions, switches, aux channels)
• Uplink (FC → RX → TX → GCS): Telemetry (battery voltage, GPS position, attitude, RSSI, link quality, custom sensors)

CRSF Packet Structure

Every CRSF frame follows the same structure:

[Address] [Length] [Type] [Payload...] [CRC8]

Maximum frame size is 64 bytes total.

Key Frame Types

RC Channel Encoding

The 0x16 frame packs 16 channels into 22 bytes using 11-bit resolution per channel (0–2047). Channel values map to:

• 172 = 988 µs (minimum)
• 992 = 1500 µs (center)
• 1811 = 2012 µs (maximum)

This gives 1624 discrete steps per channel — significantly better resolution than SBUS (which also uses 11 bits but has lower effective resolution due to its encoding).

CRSF Baud Rate

CRSF runs at 420000 baud by default. This is hardcoded in Betaflight, iNav, and ArduPilot. The baud rate must match between the FC UART configuration and the receiver.

In Betaflight, set the UART to "Serial RX" with provider "CRSF":

serial 1 64 115200 57600 0 115200
set serialrx_provider = CRSF

The 420000 baud rate allows up to 500 Hz packet rate, which is the maximum ELRS supports.

ExpressLRS Packet Rates

ELRS uses CRSF on the wire but has its own over-the-air protocol. The packet rate determines how often the transmitter sends an update to the receiver:

Lower rates = longer range because the receiver has more time to accumulate signal energy. This is a fundamental LoRa tradeoff.

FLRC (Fast Long Range Communication) is a Semtech mode available on SX1280/SX1281 chips (2.4 GHz only). It's faster than LoRa but shorter range. Used for the 333/500 Hz modes.

Telemetry

CRSF telemetry is bidirectional — the FC sends sensor data to the RX, which relays it over the air to the TX module, which passes it to the radio via CRSF. The radio (EdgeTX/OpenTX) can display this data on screen or pass it to Lua scripts (like Yaapu Telemetry).

Link Statistics (0x14)

The most important telemetry frame. Sent by the RX on every packet:

Link Quality (LQ) is the single most important metric for control link health. It represents the percentage of expected packets that actually arrived. LQ of 100 = every packet received. LQ below 70 indicates a stressed link. Below 50 is dangerous. At 0, failsafe triggers.

This is the data that MILELRS extends — adding per-frequency-band LQ breakdown, EW signal detection, and direction-finding data into extended telemetry frames that MILBETA renders on the OSD.

Binding

ELRS binding establishes a unique association between a TX module and an RX. The binding phrase (set during firmware compilation or via Lua script) is hashed into a UID that both sides must share.

Stock ELRS: binding phrase is a human-readable string hashed into a 6-byte UID. Anyone who knows the phrase can bind to your receiver.

MILELRS: adds encrypted per-transmitter keys. Each TX module gets a unique cryptographic key that must be generated and paired. This prevents an adversary who captures a receiver from binding their own transmitter to it.

Model Match

CRSF supports model matching — the TX sends a model ID, and the receiver only responds if the ID matches. This prevents accidentally controlling the wrong drone if you have multiple quads on the same binding phrase.

In EdgeTX/OpenTX, each model slot has a model match ID. The receiver stores the expected ID. Mismatch = no arm.

Airport Mode (ELRS Backpack)

ELRS Airport mode repurposes the CRSF serial link for general-purpose serial data passthrough. Instead of RC channels, the link carries arbitrary serial data between two endpoints. This enables:

• MAVLink telemetry relay over ELRS
• Serial device bridging (GPS, sensors)
• Wireless servo control

See: ELRS Airport Mode

CRSF vs SBUS vs Other Protocols

CRSF advantages over SBUS: - No signal inversion needed (SBUS requires an inverter or a hardware UART that supports inverted signal, which is why some FC pads are labeled "SBUS" specifically) - Built-in bidirectional telemetry (SBUS is one-way; telemetry needs a separate wire/protocol like S.Port) - Higher baud rate supports faster packet rates - More extensible frame format

Why CRSF dominates: ExpressLRS adopted it, and ELRS is now the dominant open-source RC system. Every ELRS receiver speaks CRSF. TBS Crossfire receivers speak CRSF. Orqa Ghost uses GHST (similar to CRSF). This means the majority of modern builds use CRSF or a close variant.

Wiring

CRSF needs only 4 wires between the receiver and FC:

Connect RX TX → FC RX pad, and RX RX → FC TX pad (crossed). The UART must be configured for Serial RX with CRSF provider in the firmware.

See: UART Layout and Appendix B: UART Maps for FC-specific wiring.

Sources

• TBS CRSF protocol specification (github.com/crsf-wg/crsf)
• ExpressLRS documentation (expresslrs.org)
• Betaflight serial RX implementation
• EdgeTX CRSF telemetry documentation
• Oscar Liang, ELRS setup guides

DShot & ESC Protocols

DShot is the digital protocol between the flight controller and ESC. It replaced analog PWM/OneShot protocols and enabled bidirectional communication — the FC tells the ESC what throttle to apply, and the ESC reports back motor RPM. This bidirectional data is the foundation of RPM filtering, which is arguably the single biggest advance in FPV flight performance in the last five years.

Cross-references: ESCs · Motors · PID Tuning · UART Layout · Propulsion Matching · Appendix B: UART Maps

Protocol Evolution

DShot600 with bidirectional DShot is the current standard for FPV builds. Everything before DShot is considered legacy.

How DShot Works

DShot is a digital protocol — it sends binary data (0s and 1s) as different pulse widths on the motor signal wire. No calibration needed, no analog noise issues, no ESC drift.

Packet Structure

Each DShot frame is 16 bits:

[11-bit throttle value] [1-bit telemetry request] [4-bit CRC]

Throttle values 1–47 are reserved for special commands (DShot commands): motor direction change, save settings, ESC info request, LED control, etc. Value 0 = motor stop. Values 48–2047 = throttle range (2000 steps of resolution).

Bit Encoding

DShot uses pulse-width encoding on a single wire:

• Bit 1: high for 75% of the bit period
• Bit 0: high for 37.5% of the bit period

The bit period depends on the DShot speed:

Bidirectional DShot (RPM Telemetry)

Bidirectional DShot (also called "DShot telemetry" or "RPM filtering DShot") reuses the same signal wire for both sending throttle commands and receiving eRPM data back from the ESC.

How It Works

1. FC sends a DShot frame with the telemetry request bit set
2. FC switches the pin to input mode
3. ESC responds with a 21-bit frame containing eRPM (electrical RPM) data
4. FC processes the eRPM and calculates actual motor RPM
5. FC uses the RPM data for notch filters that track motor harmonics

The ESC response uses GCR (Group Code Recording) encoding — 4 data bits are encoded as 5 signal bits for DC balance and clock recovery.

RPM Filtering

This is why bidirectional DShot matters. When the FC knows the exact RPM of each motor, it can place gyro notch filters precisely on the motor vibration frequencies and their harmonics. This dramatically reduces noise without the phase delay of static notch filters.

Before RPM filtering: pilots used multiple static notch filters at estimated frequencies, which added latency and never perfectly matched the actual vibration frequencies.

After RPM filtering: a single dynamic notch per motor tracks the real fundamental frequency. Less total filtering needed = less latency = better flight feel and faster reaction times.

In Betaflight: enable bidirectional DShot in the Configuration tab, then enable RPM filtering in the Filter tab. The gyro RPM filter tracks motor harmonics automatically.

ESC Firmware

The ESC firmware determines which protocols the ESC supports and how it drives the motor. Three main ESC firmware families:

BLHeli_S

Legacy 8-bit firmware for older ESCs. Supports DShot150/300/600 but does NOT support bidirectional DShot or RPM filtering. No longer actively developed. If your ESC runs BLHeli_S, you're missing RPM filtering — the single biggest performance improvement available.

BLHeli_32

32-bit commercial firmware. Full DShot support including bidirectional. RPM filtering works. Supports advanced features like variable PWM frequency, LED control, and comprehensive ESC telemetry via a separate telemetry wire (voltage, current, temperature, RPM per motor). Review needed: performance / configuration Flag this

BLHeli_32 is the incumbent standard. Closed-source but well-supported.

AM32

Open-source 32-bit ESC firmware. Full feature parity with BLHeli_32 including bidirectional DShot. Growing in popularity because it's free and community-developed. The Orqa 3030 70A ESC runs AM32.

Key advantage: AM32 can be flashed onto many BLHeli_32-compatible ESCs, giving you open-source firmware on existing hardware.

Bluejay

Open-source firmware for 8-bit ESC hardware (the same chips that run BLHeli_S). Adds bidirectional DShot support to hardware that BLHeli_S doesn't support it on. If you have a BLHeli_S ESC and can't replace it, flashing Bluejay gives you RPM filtering.

ESC Telemetry (Separate Wire)

In addition to bidirectional DShot (which only carries RPM), some ESCs provide full telemetry over a separate serial connection:

This telemetry wire connects to a spare FC UART. Betaflight can display per-ESC data on the OSD (individual ESC temps, voltages). Useful for diagnosing motor or ESC issues — one hot ESC indicates a motor problem on that arm.

Configuration in Betaflight

Enabling DShot600 + Bidirectional

In Betaflight Configurator → Configuration tab:

1. ESC/Motor Protocol: DShot600
2. Bidirectional DShot: Enable
3. Motor Poles: set to your motor's actual pole count (typically 14 for most FPV motors — count the magnets and divide by 2)

Motor pole count must be correct for accurate RPM calculation. Wrong pole count = RPM filter on wrong frequencies = worse performance than no filter.

Enabling RPM Filtering

In Betaflight Configurator → Filters tab:

1. Gyro RPM Filter: Enable
2. Harmonics: 3 (tracks fundamental + 2 harmonics per motor)
3. Min Frequency: 100 Hz (below this RPM filtering disengages)

With RPM filtering active, you can typically reduce or remove static notch filters, lowering total filter delay.

DShot Commands

The reserved throttle values (1–47) are used for special commands:

These commands are sent by the FC firmware — pilots don't interact with them directly. Betaflight uses them for motor direction configuration (reversible via CLI/Configurator without re-soldering motor wires).

Troubleshooting

RPM Filtering Not Working

1. Bidirectional DShot not enabled — must be toggled on in Configuration
2. Wrong motor pole count — count magnets, divide by 2
3. ESC firmware doesn't support it — BLHeli_S does not. Flash Bluejay or upgrade to BLHeli_32/AM32 hardware.
4. Wiring too long — long signal wires between FC and ESC can corrupt the high-speed bidirectional signal. Keep wires short.

Motor Desync

Symptoms: motor stutters, stops mid-flight, or makes grinding noise.

Causes: DShot timing issues, ESC timing too aggressive, motor KV too high for battery voltage, damaged motor winding.

Fix: lower ESC timing (via BLHeli_32/AM32 configurator), check motor for physical damage, try DShot300 instead of DShot600 if desync persists.

Sources

• Betaflight DShot implementation (github.com/betaflight/betaflight)
• BLHeli_32 documentation
• AM32 project (github.com/am32-firmware/AM32)
• Bluejay project (github.com/mathiasvr/bluejay)
• Oscar Liang, DShot and RPM filtering guides

Ghost RC Link — Operator Configuration Reference

Part 7 — Field Operations Complete binding, configuration, and integration guide for the ImmersionRC/Orqa Ghost RC control system. Covers all transmitter modules, receivers, and flight controller integration.

Quick Reference

Binding Procedures

Method 1 — FPV.Ctrl App (Recommended)

This is the primary binding method for the Orqa FPV.Ctrl radio with Ghost UberLite module.

1. Power on the Orqa transmitter.
2. Open the Orqa FPV.Ctrl app on your phone/tablet.
3. Connect to the transmitter via Bluetooth (app walks through pairing on first use).
4. Navigate to Ghost Menu within the app.
5. If the receiver is new, it auto-enters bind mode on power-up. For a previously bound receiver, power it up and press the button next to the antenna connector within 30 seconds — the LED turns blue (searching).
6. In the Ghost Menu, select your desired protocol (GHST recommended). Set Rx ID (only matters if flying multiple drones simultaneously).
7. Tap Start Bind. Wait for "Success" message.
8. Restart both drone and transmitter after successful bind.

Method 2 — Quick Bind (No App)

For field situations where the app isn't needed and default settings are acceptable:

1. Power on the Orqa transmitter.
2. Press the button on the back of the antenna module — LED turns blue (bind mode).
3. Power up the receiver and put it in bind mode (press button near antenna connector within 30 seconds of power-on — LED turns blue).
4. Both devices cycle through color sequences, then settle on solid green.
5. Bind complete. No settings changes possible via this method.

Method 3 — JR/xLite Module with OpenTX

For the Ghost JR or xLite module on third-party transmitters (Taranis, Jumper, etc.):

1. In your transmitter's model settings, set External RF module to GHST protocol.
2. On the Ghost module OLED, navigate to the bind menu.
3. Put the receiver in bind mode (same button procedure as above).
4. Select Bind on the module's OLED interface.
5. Confirm successful bind (both go solid green).

Critical OpenTX setting: The ADC Filter function (global by default) must be set to OFF for Ghost. If left on, you will get jittery or unresponsive channel outputs.

For EdgeTX users: set the radio into ONEBIT mode for proper GHST communication.

Firmware Updates

Transmitter Module (JR / xLite)

1. Download the Ghost Updater/Installer from ImmersionRC's website (under Firmware/Downloads → Utility Software).
2. Windows: Install the ImmersionRC USB drivers + Zadig if needed. Mac: No drivers required.
3. Connect the module to your computer via USB.
4. Open Ghost Updater — it should auto-detect the module on the correct COM port.
5. Click Update Ghost. The program auto-selects the latest firmware if connected to internet.
6. Wait 1–2 minutes for completion + success message.
7. After updating the Tx module, rebind to all receivers — they will automatically receive firmware updates during the bind process.

Orqa FPV.Ctrl Transmitter

The FPV.Ctrl transmitter and UberLite module have separate firmware. The transmitter firmware updates through the FPV.Ctrl mobile app. The UberLite module firmware requires the Ghost Updater desktop application (same as JR/xLite modules above).

Receiver Firmware

Receivers (Átto, Átto Duo, Zepto) auto-update when binding to a transmitter that has been updated to the latest firmware. No separate receiver update process needed.

Flight Controller Integration

Protocol Selection

GHST is the recommended protocol for all Ghost setups. It provides lower latency, more channel resolution, and native telemetry compared to SBus fallback. Review needed: performance / configuration Flag this

ModalAI VOXL 2

1. Connect Ghost Átto to the correct UART port (see VOXL 2 pinout documentation).
2. SSH into the VOXL 2.
3. Edit /etc/modalai/voxl-px4.conf.
4. Set RC_INPUT to GHST.
5. Restart PX4.

Pin connections (Átto to VOXL 2):

ModalAI notes that having Tramp Telemetry connected to Tx does not cause issues, and enables swapping between Ghost and ELRS receivers without re-wiring (using the Harwin rectangular connector on MCBL-89-01).

ModalAI VOXL Flight / Flight Core

Use cable MSA-D0001-1-02, connected to J1003 and J1004:

Set RC_INPUT_PROTO to GHST in QGroundControl.

Betaflight

In Betaflight Configurator 10.9+:

1. Go to Ports tab. Enable Serial Rx on the UART connected to the Ghost receiver.
2. Go to Configuration tab. Under Receiver, set Serial Receiver Provider to GHST.
3. Save and reboot.

ArduPilot / PX4

For ArduPilot on the Orqa F405 3030 FC:

1. Set SERIAL*_PROTOCOL = 23 (RC Input) on the UART connected to the Ghost receiver.
2. Set RC_PROTOCOLS to include GHST.
3. For PX4: set RC_INPUT_PROTO to GHST.

RF Mode Selection Guide

Field tip: ModalAI found that Normal mode can introduce perceptible lag compared to Race mode. For tactical or time-critical operations, use Race mode as the default and only drop to Normal/Long Range when range demands it.

Receiver LED States

Antenna Considerations

Ghost operates on 2.4 GHz. Antenna size is compact — the supplied dipoles are 2.1 dBi. Key considerations:

Transmitter side: The JR module runs Tx-side antenna diversity by default (two antennas). Single-antenna mode is one menu option away. For maximum range, a directional antenna on the transmitter can double expected range — 2.4 GHz directional antennas are physically small enough to be practical.

Receiver side: The Átto has a single U.FL antenna. The Átto Duo has two U.FL antennas providing true diversity (two independent receiver channels, not just two antennas on one channel). For race builds where diversity matters, the Duo is recommended.

Coexistence: Ghost's LoRa/FHSS modulation handles 2.4 GHz congestion well, but the standard deconfliction rules apply — if your mesh radio AND Ghost AND companion computer WiFi are all on 2.4 GHz, expect desensitization. See the Handbook's frequency bands chapter for the full 2.4 GHz deconfliction discussion.

Troubleshooting

External Resources

• ImmersionRC Ghost Manual (comprehensive): https://www.immersionrc.com/?download=6746
• ModalAI Ghost integration docs: https://docs.modalai.com/orqa-ghost/
• ArduPilot OrqaF405 board docs: https://ardupilot.org/copter/docs/common-OrqaF405.html
• Orqa support portal: https://orqafpv.freshdesk.com/support/home
• Ghost Updater download: https://www.immersionrc.com/fpv-products/ghost/#specifications (under Firmware/Downloads → Utility Software)

Last updated: March 2026

ELRS Airport Mode — Transparent Serial Bridge

The most common ELRS mistake: trying to use a SkyGuy or generic TX module as an external CRSF input. It won't work. Airport mode is the solution you actually want.

The Problem Airport Mode Solves

Standard ELRS modules on generic TX targets reject external CRSF input. If you're trying to build a wireless serial bridge — relaying MAVLink telemetry, triggering a servo remotely, connecting two systems over RF — you'll hit a wall with the standard approach.

Airport mode bypasses this entirely by turning both modules into a transparent serial bridge: whatever bytes go in one end come out the other. No RC frames, no CRSF protocol overhead. Just bytes.

How It Works

Both modules stay on RX firmware. Neither runs TX firmware. One module is connected to your serial source; the other is connected to your serial destination. The RF link between them is completely transparent.

[Device A] <-> UART <-> [ELRS RX module A] <-> RF <-> [ELRS RX module B] <-> UART <-> [Device B]

Both modules run RX firmware. Airport mode is configured via the ELRS Configurator on each module independently.

Configuration

Requirements

• Two ELRS modules (same frequency band — both 900MHz or both 2.4GHz)
• Both flashed with RX firmware (not TX)
• ELRS Configurator 3.x+

Steps

1. Flash both modules with RX firmware for your target
2. Connect each module to your PC via USB or UART passthrough
3. Open ELRS Configurator and connect to the module
4. Navigate to the Airport tab
5. Set baud rate to 115200 on both modules
6. Set the same UID/binding phrase on both modules
7. Power both modules — they will link automatically
8. Verify with a loopback test: bytes sent into module A appear at module B

Baud Rate

115200 is the standard for most use cases (MAVLink, CRSF passthrough, servo triggers). The link is bidirectional and full-duplex at this rate.

Real-World Applications

Wireless Servo Trigger

Connect XIAO ESP32-C6 to ELRS RX module A on the transmitting end. Connect ELRS RX module B to a servo driver on the receiving end. The ESP32 sends a byte; the servo fires. No RC transmitter involved.

Hardware used in testing: - XIAO ESP32-C6 + DroneBridge carrier board - Two ELRS modules on 2.4GHz RX firmware - Airport mode at 115200 baud

MAVLink Telemetry Bridge

Relay MAVLink packets between a companion computer and a ground station over an ELRS RF link, without using the RC control channel.

Serial Data Relay

Any UART serial data — sensor output, debug logs, command streams — can be relayed wirelessly between two points within ELRS RF range.

What Doesn't Work

Troubleshooting

Modules won't link: Verify same frequency band, same firmware version, same UID. Try re-flashing both to the same firmware build.

Data corruption at high baud rates: Drop to 57600 or 38400. ELRS Airport mode is reliable at 115200 for most payloads but RF conditions affect throughput.

One-way only: Airport mode is bidirectional. If only seeing data one way, check UART wiring — TX/RX may be swapped on one side.

Latency spikes: Expected on packet loss. Design your protocol to tolerate 10-50ms latency and occasional gaps. Review needed: performance / configuration Flag this

Related

• ELRS Binding and Configuration
• Companion Computer Integration
• ESP32 Wireless Projects

Firmware Backup, Upgrade and Recovery

An upgrade changes a versioned configuration contract. Preserve enough evidence to restore the previous tested state rather than assume a parameter dump transfers across versions.

Change record

For Betaflight, dump all and diff all provide different views; retain the version/target with the output. Do not paste an old dump into a different target or release without migration checks. Betaflight CLI reference, checked 2026-10-07.

Software rehearsal

Use an isolated configuration and simulator/replay where available. Compare parameter names, types, units and accepted values; a missing or clamped value is a migration result to investigate. Interrupt an upload in a software adapter and verify that partial state is not reported as a complete backup. Reconnect and read back rather than infer persistence from a successful send.

Hardware flashing and bootloader recovery follow the exact board/firmware documentation with propulsion disabled. A simulator cannot establish USB bootloader behavior or motor-output correctness. After a real change, run props-off bench checks and the applicable aircraft acceptance procedure before operation.

Track upstream release dates and relevant migration notes in the update watchlist. ArduPilot firmware reference, checked 2026-10-07.

CAN, DroneCAN and Cyphal

CAN describes a transport/physical interface. DroneCAN and Cyphal define higher-level communication contracts. A CAN connector does not establish application-protocol compatibility.

Integration matrix

DroneCAN maintains its own specification and data types. Cyphal was known as UAVCAN before its renaming; name history does not make the two application protocols wire-compatible. DroneCAN specification and OpenCyphal guide/specification, checked 2026-10-07.

Observe before configuring

In software, replay a known capture with the matching decoder/data-type definitions. Record node-status messages, identity changes, missing transfers and decoder errors. Test duplicate node identity and absent data types explicitly. SocketCAN vcan can exercise software frame handling, but does not model electrical noise, power, termination or a particular peripheral's protocol behavior. Review needed: performance / configuration Flag this

For a physical installation, use the exact manufacturer's wiring and termination documentation. Do not apply generic pinouts or terminate every node. A powered-bus test is separate from a decoder test. DroneCAN hardware guidance and Linux SocketCAN, checked 2026-10-07.

Retain the capture, decoder version and physical test boundary in the evidence record.

Chapter 9: Preflight, Bench Checks and Flight Readiness

Use the aircraft and firmware manufacturer's checklist alongside this integration checklist. Record the exact airframe, battery chemistry, firmware and configuration. A short check cannot establish readiness after a repair or software change.

Props-off bench checks

Remove every propeller before motor-output, receiver-loss or arming tests. Keep the aircraft secured, disconnect propulsion power before touching it, and follow the board/ESC manufacturer's test procedure. Never tilt an armed aircraft by hand or use a throttle blip as a ground control-direction test. Review needed: safety / performance Flag this

• Confirm board orientation and sensor directions in the configuration tool while disarmed.
• Verify receiver channels, mode assignments, arming switch and command ownership.
• Verify motor numbering and rotation using the firmware's documented props-off test facility.
• Save/read back the configuration and check battery monitoring against a reference instrument.
• Exercise documented link-loss and recovery behavior with props removed. Record receiver output on loss, firmware failsafe stage, selected action, timeout and reconnection behavior.

A bench test can establish output/state transitions. It cannot prove airborne landing, return, GPS rescue or obstacle clearance. Validate those separately through the aircraft's approved test procedure and suitable operating conditions. See software failure testing and firmware recovery. Review needed: configuration / failure mode Flag this

Before each flight

Satellite count alone is not a navigation quality test. Use the installed firmware's fix, estimator and arming requirements. Battery internal resistance depends on pack construction, temperature, state of charge and measurement method; trend like-for-like measurements and use manufacturer retirement criteria. The former universal resistance thresholds and satellite minimum are withdrawn. Review needed: safety / configuration / failure mode Flag this

Failsafe is a configuration-specific choice

Betaflight documents different Stage 2 procedures, including Drop, Landing and GPS Rescue. ArduPilot and PX4 have different mode, sensor and link prerequisites. A failsafe action appropriate for one aircraft or location may be unsuitable for another. Read the exact release's documentation; do not substitute a universal action from this handbook.

Betaflight failsafe documentation, checked 2026-10-07. This reference explains firmware behavior; it does not validate a particular installation.

After flight or repair

Disarm and disconnect propulsion power before handling. Inspect damage, unusual heating, connectors and battery condition using manufacturer limits. Preserve logs before they are overwritten, note configuration changes, and return to bench validation after repairs, receiver changes, firmware upgrades or altered failsafe settings. Charge and store batteries using the exact chemistry manufacturer's guidance. Review needed: performance / configuration Flag this

Use the evidence record to retain what was actually checked and what remains open.

Chapter 10: Blackbox Logs — What They Tell You

The blackbox doesn't lie. Your memory does. Pull the log.

What Gets Logged

A blackbox log records everything the flight controller knows at high sample rate (typically 1–4 kHz on Betaflight, 100–400 Hz on ArduPilot/PX4). This includes:

How to Pull Logs

Betaflight (Flash-Based)

Betaflight stores blackbox data on the FC's on-board flash chip (typically 2–16 MB) or an SD card.

Via Configurator: 1. Connect USB 2. Blackbox tab → Download Flash → Save .bbl file

Via MSP (what Wingman does): 1. MSP_DATAFLASH_SUMMARY → get used bytes 2. MSP_DATAFLASH_READ in 4 KB chunks → stream raw data 3. Save as .bbl file

Important: Flash fills up. If it's full, new flights overwrite old ones. After a session where you need the data, pull logs before the next flight. Or switch to SD card logging if your FC supports it.

ArduPilot (SD Card)

ArduPilot writes .bin DataFlash logs to the SD card.

Via Mission Planner: DataFlash Logs → Download Via MAVLink: LOG_REQUEST_LIST → LOG_REQUEST_DATA → stream Via SD card: Pull the card, copy .bin files directly

PX4 (SD Card)

PX4 writes .ulg (ULog) files to the SD card.

Via QGroundControl: Analyze → Log Download Via SD card: Pull the card, copy .ulg files

Reading the Traces

The Gyro Trace Is Everything

The gyroscope trace is the single most important data in a blackbox log. It shows the actual angular rate of the drone on each axis, sampled at 1–4 kHz. Everything else is derived from or compared against the gyro.

A clean gyro trace looks like smooth curves that follow the stick inputs. When you push the stick right, the roll gyro shows a clean step to the commanded rate, holds, then returns to zero when you release.

A noisy gyro trace looks like the clean curve with fuzz, spikes, or oscillation layered on top. The noise is real — the drone is actually vibrating. The question is where the vibration comes from and whether it matters.

The Five Patterns That Indicate Real Problems

Pattern 1: High-frequency noise on all axes, increasing with throttle.

What it looks like: Fuzz on the gyro trace that gets worse as you increase throttle. Consistent across roll, pitch, and yaw.

What it means: Mechanical vibration from the motors/props is reaching the FC. The motors are the only thing on the drone whose vibration scales with throttle.

What to check: Prop balance, motor bearings, FC soft mount, frame arm tightness. If the noise is broadband (not at a specific frequency), it's probably multiple sources. Fix the biggest one first — usually props.

Pattern 2: Oscillation at a specific frequency, visible as regular waves.

What it looks like: A sine wave overlaid on the gyro trace. Consistent frequency regardless of stick input. May be present on one axis more than others.

What it means: Resonance. Something on the frame has a natural frequency that's being excited by the motors. The FC's filters are either not catching it or are making it worse.

What to check: Look at the frequency (use the Betaflight Blackbox Explorer's spectrum analyzer). Common resonances: - 80–150 Hz: Frame flex (arms, standoffs) - 150–300 Hz: Prop/motor mechanical resonance - 300–600 Hz: Gyro noise floor (filter issue, not mechanical)

If the dynamic notch filter is enabled, check if it's tracking this frequency. If not, adjust the notch range.

Pattern 3: D-term noise spikes, especially on yaw.

What it looks like: The D-term trace (visible in debug mode) is noisy or spiky, even when the gyro trace looks relatively clean. Yaw axis is typically worst.

What it means: The D-term is the derivative of gyro error. It amplifies high-frequency noise by design — that's how it reacts quickly to changes. If the gyro has even small amounts of high-frequency content, D amplifies it into large motor corrections.

What to check: Lower D-term gain (try -20%). If that helps significantly, the issue is D sensitivity to noise, not mechanical. Also check: D-term lowpass filter cutoff (lowering it reduces D noise at the cost of slower D response), dynamic notch filter (should be catching the frequencies that D is reacting to).

Pattern 4: Motor output asymmetry — one motor consistently higher.

What it looks like: In the motor output traces, one motor is always running at higher output than the others. The difference is consistent across throttle levels.

What it means: The FC is compensating for something that makes the drone want to rotate toward the weak motor's side. Possible causes: - Motor or ESC weaker on one side (dying motor, marginal ESC) - Center of gravity offset (battery mounted off-center) - Bent motor mount changing thrust angle - Damaged prop generating less thrust

What to check: Swap the suspect motor to a different arm. If the asymmetry follows the motor, it's the motor. If it stays on the same arm, it's the mount or frame. If it moves to the diagonal, it's CG.

Rule of thumb: Up to 5% asymmetry is normal. 5–10% is worth investigating. Above 10% is a problem that will get worse.

Pattern 5: Voltage sag correlating with performance loss.

What it looks like: Battery voltage drops sharply during aggressive maneuvers. At the same time, motor outputs hit 100% (full throttle commanded but can't produce it), and the gyro shows the drone not achieving the commanded rate.

What it means: The battery can't deliver enough current. The voltage sags, the ESCs can't spin the motors fast enough, and the drone loses authority. This is a power system problem, not a tuning problem.

What to check: Battery internal resistance (measure with a charger that shows IR per cell). IR above 15 mΩ/cell means the pack is aging. Voltage sag below 3.3V/cell under load is concerning. Below 3.0V/cell is damaging the battery.

Don't tune around bad batteries. If the battery is sagging, no amount of PID tuning will fix the performance loss. Replace the battery.

Blackbox Analysis Workflow

Step 1: Pull the log. Immediately after the flight you want to analyze. Don't fly again first.

Step 2: Open in the right tool. - Betaflight: Betaflight Blackbox Explorer - ArduPilot: Mission Planner → DataFlash Log tab, or UAV Log Viewer - PX4: Flight Review or PlotJuggler

Step 3: Look at the gyro first. Always. Before looking at PIDs, motor outputs, or anything else. The gyro tells you what actually happened. Everything else tells you what the FC tried to do about it.

Step 4: Compare setpoint to gyro. The setpoint is what the FC was trying to achieve. The gyro is what actually happened. The gap between them is the error. A well-tuned drone tracks setpoint closely. A poorly tuned one lags, overshoots, or oscillates around it.

Step 5: Check motor outputs. Are they even? Are any hitting 100%? Are there sudden spikes? Motor output tells you how hard the FC is working to maintain control.

Step 6: Check battery voltage. Does it hold steady or sag under load? Voltage sag during aggressive maneuvers is normal. Voltage sag during hover is a problem.

Step 7: If you found a problem, change ONE thing. Fly again. Pull another log. Compare. This is how tuning works — iterative, data-driven, one variable at a time.

What Logs Don't Tell You

• Why the pilot made a decision. Logs show what the drone did, not what the operator intended. If a flyaway log shows the drone going north, you don't know if the pilot pushed north or if the drone went north on its own without checking the stick inputs.

• External conditions. Wind, temperature, air density, obstacles — none of these are in the log. A drone that oscillates on a windy day and flies clean on a calm day isn't broken. It's dealing with turbulence. Logs won't show you the wind.

• What happened after the crash. If the drone hits something and the FC loses power, the log ends. The last few hundred milliseconds of data may be corrupt or missing. The moments before the crash are usually there.

Next

• Chapter 11: PID Tuning for People Who Fly — using blackbox data to improve your tune.
• Chapter 12: When Things Go Wrong — the diagnostic tree that starts with symptoms and uses logs to find causes.

The log is the flight's memory. It remembers what you don't. Pull it. Read it. Trust it over your recollection.

Chapter 11: PID Tuning for People Who Fly, Not Simulate

PID tuning is not magic. P reacts to error. I removes steady error. D resists change. That's it. The rest is learning what each one feels like through the sticks.

What P, I, and D Actually Do

P (Proportional) — The Reaction

P pushes back proportional to how far off the drone is from where it should be. Big error = big correction. Small error = small correction.

Too high: The drone overshoots its target and corrects back, creating fast oscillation. Feels like the quad is vibrating or buzzing, especially visible on a punch-out or sharp turn.

Too low: The drone feels mushy, soft, unresponsive. It drifts through commands instead of snapping to them. Slow to respond to stick input.

What to listen for: P oscillation is fast — 10-50 Hz range. It sounds like a buzz or rattle. If you hear a high-pitched buzzing that increases when you do aggressive maneuvers, P is too high.

I (Integral) — The Memory

I accumulates error over time. If the drone is consistently a little off in one direction (wind pushing it, CG offset, motor imbalance), I builds up a correction to counter it.

Too high: The drone feels "stuck" or slow to change direction. Overshoot on sustained moves. After a long turn, it keeps turning briefly after you release the stick. In extreme cases, I windup causes the drone to suddenly lurch as the accumulated correction releases.

Too low: The drone drifts. In a hover, it doesn't hold position well. In forward flight, wind pushes it off course and it doesn't correct. The quad won't hold a steady rate in a turn.

What to feel for: I issues are slow. If the drone seems to "remember" what it was doing and resists changing, I is too high. If it can't hold a line in wind, I is too low.

For most operators: Leave I at the default. It's the least sensitive of the three terms and the default is usually close enough. Only touch I if you have specific drift or windup problems.

D (Derivative) — The Brake

D resists change. It's proportional to how fast the error is changing, not how big it is. D slows down both the drone's response AND oscillation.

Too high: Motors run hot. D amplifies noise (see Chapter 10, Pattern 3). The drone feels "dampened" — controlled but lacking snap. In extreme cases, motors make a grinding sound from rapid micro-corrections driven by noise.

Too low: The drone overshoots on quick maneuvers. Feels bouncy at the end of rolls and flips. P oscillation becomes harder to control because D isn't there to brake it.

What to listen for: D noise is a constant, low-level motor buzz that's present even in smooth flight. It gets worse with throttle because motor vibration (which D amplifies) increases with RPM.

The D dilemma: You need enough D to control overshoot but not so much that it amplifies noise. This is the core tension in PID tuning and why filters exist — filters clean the gyro signal so D can do its job without reacting to noise.

The Field Tuning Workflow

This workflow assumes you're starting from a reasonable default (Betaflight defaults are a good starting point for most 5-inch builds). If you're building from scratch on unusual hardware, start with community presets for your motor/frame size.

Step 0: Mechanical First

Before touching PIDs, confirm: - Props are balanced and undamaged - Motors spin freely with no grit or catch - FC is soft-mounted properly - Frame has no loose screws or cracked arms - Battery is secured and not shifting in flight

If any of these are wrong, no amount of PID tuning will fix it. See Chapter 12 (Troubleshooting), Step 2.

Step 1: Fly the Default

Fly a representative flight — hover, forward flight, some rolls and flips, a punch-out, some turns. Pay attention to: - Does it feel mushy or sharp? (P) - Does it hold a line in wind? (I) - Does it bounce at the end of maneuvers? (D) - Is there any buzzing or vibration? (P too high or D noise)

Pull a blackbox log.

Step 2: Adjust P

P is where most of the feel comes from. Adjust P first.

• If mushy/soft: raise P by 10%. Fly. Repeat until it feels responsive but not buzzy.
• If buzzy/oscillating: lower P by 10%. Fly. Repeat until the buzz goes away but it still feels locked in.

Adjust roll and pitch P together unless you have a reason not to (asymmetric frame, different prop spacing). Yaw P is usually set independently and is less sensitive.

Step 3: Adjust D

Once P feels right, check D:

• If bouncy at the end of flips/rolls: raise D by 10%.
• If motors are hot or buzzing at idle: lower D by 10%.
• If blackbox shows D-term noise: lower D, then check filters.

D and P interact — raising P often requires raising D to maintain damping. If you raised P in Step 2, you may need more D.

Step 4: Leave I Alone (Usually)

I is rarely the problem for freestyle and racing. If the default works, keep it.

• If the quad drifts in hover or can't hold a turn rate in wind: raise I by 10-20%.
• If the quad feels sluggish to change direction or has overshoot on sustained turns: lower I.

Step 5: Check Filters

If you can't get P and D where you want them because noise starts before you reach the desired gain, the issue is filters, not PIDs.

• Enable dynamic notch filter if not already enabled.
• Check gyro lowpass filter cutoff. Betaflight default (250 Hz for gyro lowpass 1) is fine for clean builds. Noisy builds may need 150-200 Hz.
• Check D-term lowpass. This is the most impactful filter for D noise. Lowering it from 150 Hz to 100 Hz significantly reduces D noise but also slows D response.

The filter-PID relationship: Filters remove noise so PIDs can run higher without reacting to it. A well-filtered build can run higher P and D, which means sharper and more responsive flight. A poorly filtered build (or a build with mechanical vibration issues) must run lower PIDs to compensate.

Step 6: Fly, Log, Compare, Repeat

After each change: 1. Fly a representative flight (same maneuvers as before) 2. Pull blackbox 3. Compare gyro traces to the previous flight 4. Did it get better or worse? If better, keep the change. If worse, revert.

One change at a time. If you change P, D, and filters simultaneously, you won't know what helped and what hurt.

Rates vs. PIDs

Rates and PIDs are different things. People confuse them constantly.

Rates control how fast the drone rotates per degree of stick deflection. Higher rates = faster rotation at full stick. Rates affect how the drone FEELS to fly but they don't affect stability.

PIDs control how well the drone FOLLOWS the rate command. Higher P = more aggressively follows the command. Higher D = more damped following.

If the drone feels slow: it might be rates (increase max rate), not PIDs.

If the drone feels floaty: it might be PIDs (increase P), not rates.

If the drone rotates at the right speed but wobbles while doing it: that's PIDs.

Tuning for Different Flight Styles

Freestyle

• Higher P for crisp, snappy response
• Moderate D for controlled stops after flips
• Lower I is acceptable (you're not holding position)
• Slightly higher rates (800-1200 deg/s max)

Racing

• Moderate P — not as high as freestyle because you need predictability, not snap
• Higher D to damp oscillation in high-speed turns
• Higher I to hold lines through corners and in prop wash
• Lower rates than freestyle (600-900 deg/s) for precision

Cinematic / Smooth

• Lower P for gentle, smooth movements
• Lower D to avoid any micro-corrections visible in footage
• Standard I
• Low rates (400-600 deg/s) for butter-smooth pans

Long-Range / GPS Cruise

• Default PIDs are usually fine
• I matters more here (wind rejection, position hold)
• D can be lower (less aggressive flying = less noise)
• Rates are less important (you're not doing flips at 5 km)

When to Stop Tuning

The tune is "good enough" when: - No audible buzz or vibration in normal flight - The drone responds to stick inputs without delay or overshoot - Blackbox gyro traces are clean (no sustained oscillation) - Motors are warm after flight, not hot (hot = D noise or P oscillation making the ESCs work too hard) - You stop noticing the quad and start noticing the flying

Most pilots overtune. The difference between a "good" tune and a "perfect" tune is 2-3% performance improvement that you'll never notice in real flying. Get it to "no oscillation, responsive, motors not hot" and go fly.

Next

• Chapter 10: Blackbox Logs — reading the data that drives these tuning decisions.
• Chapter 12: When Things Go Wrong — when the problem isn't PIDs at all.

The best tune is the one that lets you forget about the quad and focus on the flying. If you're thinking about PIDs in the air, you're not done tuning. If you're not thinking about PIDs in the air, you probably are.

Chapter 12: When Things Go Wrong

This is the chapter you read at the field with a broken drone in your hands. Start with the symptom. Follow the tree.

How to Use This Chapter

Find your symptom in the list below. Follow the diagnostic steps in order. Each step either solves the problem or narrows it down. Don't skip steps — the obvious cause is often not the actual cause.

Symptom: Won't Arm

The FC refuses to arm. This is the most common field problem and the one with the most possible causes.

Step 1: Read the arming flags. - Betaflight: CLI → status → look for arming disable flags - iNav: CLI → status → same - ArduPilot: GCS → Messages tab → pre-arm check failures - PX4: QGC → Vehicle Setup → Summary → pre-arm checks Review needed: safety Flag this

Step 2: Common arming flags and fixes. Review needed: safety Flag this

Step 3: If no flags show but still won't arm. - Check switch assignment. Arm switch might be on a channel that isn't configured or is inverted. - Check throttle endpoints. Some FCs require throttle below 1050 µs. - Power cycle everything. Receiver, FC, ESCs. In that order.

Symptom: Oscillation / Vibration in Flight

The quad shakes, wobbles, or makes a buzzing sound in flight. Could be mechanical or electronic.

Step 1: Determine if it's always present or speed-dependent. - Always present (even at hover): likely filter or PID issue - Only at high throttle: likely mechanical — prop balance, motor bearing, loose standoff - Only after a crash: prop damage, bent motor shaft, cracked frame arm

Step 2: Check mechanical first. Always. Before touching PIDs. - Spin each motor by hand. Feel for grit, catch, or uneven resistance. One bad bearing can cause the whole quad to oscillate. - Check props for damage. Even a tiny nick changes balance. Replace suspect props — they're the cheapest component. - Check motor mounting screws. Loose motor = oscillation source. - Press on each arm. Flex = vibration transmission path. Carbon fiber arms don't flex. Cheap 3D-printed arms do. - Check FC mounting. Soft mount grommets should be intact and the FC should not contact the frame directly.

Step 3: Pull a blackbox log. If mechanical checks pass: - Look at gyro traces. Clean gyro = clean flight. Noisy gyro = something is shaking the FC. - Compare pre-filter and post-filter gyro. If pre-filter is noisy but post-filter is clean, your filters are working hard. Consider addressing the source instead of filtering harder. - Look for a specific frequency peak. A resonance at a consistent frequency often indicates a specific mechanical source: - Prop-speed frequency: prop balance issue - Frame resonance (usually 100-300 Hz): frame flex - Motor bearing: broadband noise that increases with throttle

Step 4: If it's a filter/PID issue: - Lower D-term first. D is the most noise-sensitive PID term. Drop D by 20% and fly again. - Check dynamic notch filter. If not enabled, enable it. If enabled, check that it's tracking the right frequency range. - Lower gyro lowpass filter cutoff. Default is usually fine, but noisy builds may need 150 Hz instead of 200 Hz. - As a last resort, lower P-term. But if you need to drop P significantly to stop oscillation, the problem is mechanical, not tuning.

Symptom: Flyaway / Unexpected Movement

The drone moves in a direction the pilot didn't command.

Step 1: Did it respond to stick input during the event? - Yes, but drifted: likely sensor issue (compass interference, GPS glitch, accelerometer drift) - No response to sticks at all: likely failsafe triggered, mode switch, or loss of RC link

Step 2: Check flight mode. Did the mode change unexpectedly? - A mode switch bumped during handling can change from acro to angle to GPS hold, causing unexpected behavior. - ArduPilot/PX4: check mode channel (usually CH5) assignment and thresholds. - Betaflight: check mode tab for overlapping ranges on the aux channels.

Step 3: Check compass and GPS. For GPS-assist modes: - Compass interference from power wires is the #1 cause of GPS-mode flyaways. The compass reads the magnetic field from the battery leads as a heading change and "corrects" by turning. - Fix: move the compass (external GPS/compass module) as far from power wires as possible. Use a GPS mast. - Check for GPS glitch in the log. A sudden position jump causes the FC to "correct" toward the wrong position. Review needed: performance / failure mode Flag this

Step 4: After landing, pull logs immediately. Don't fly again until you understand what happened. Logs will show stick inputs, actual motor outputs, sensor readings, and mode changes. The cause is almost always visible in the data.

Symptom: Video Loss / Breakup

FPV video feed drops, goes to static, shows artifacts, or freezes.

Step 1: Analog or digital?

Analog 5.8 GHz: - Gradual static/snow = range limit or obstruction. Normal degradation. - Sudden black screen = VTX failure, antenna disconnect, or power loss to VTX. - Rolling lines or interference pattern = self-interference from another transmitter on the same airframe (RC, mesh radio). - Check antenna connector. IPEX/U.FL connectors are fragile. A crash can unseat them without visible damage. Reseat and check. - Check VTX power. Is it set to the right level? Too low = no range. Too high = overheating (some VTXs thermal throttle or shut down). Review needed: performance / failure mode Flag this

Digital (DJI, HDZero, Walksnail): - Frozen frame = link degradation. Digital doesn't gracefully degrade like analog — it works perfectly until it doesn't, then freezes. - Gray screen / "No Signal" = complete link loss. - Latency spike = the link is fighting to maintain connection. Reduce range or increase power. - Check firmware versions. DJI goggles and air unit firmware must match. Mismatched firmware can cause connection failures. Review needed: performance / configuration Flag this

Step 2: Is it consistent or intermittent? - Consistent at a specific distance/direction = range or obstruction. Normal. Adjust flight pattern or antenna. - Intermittent at close range = self-interference, loose antenna, or power supply issue. Check that VTX is getting clean power (no voltage sag from motor current). - Only happens at high throttle = voltage sag pulling VTX supply below minimum. Add a capacitor on the VTX power input or use a dedicated BEC. Review needed: performance / failure mode Flag this

Symptom: Motor Desync / Stuttering

One or more motors stutters, stops momentarily, or makes grinding sounds.

Step 1: Is it one motor or all? - One motor: likely ESC or motor issue (bearing, winding, timing) - All motors: likely FC signal issue (DShot errors, wiring)

Step 2: Swap the suspect ESC and motor. If the problem follows: - The motor: bad bearing or winding - The ESC: bad ESC - Neither (stays on the same arm): wiring issue on that arm

Step 3: Check motor timing. In BLHeli_S/BLHeli_32/AM32: - Stock timing is usually fine. If someone has adjusted it, try resetting to default. - High timing + high KV + low battery voltage = desync recipe.

Step 4: Check DShot settings. - Bidirectional DShot (for RPM filter) can cause desyncs on some ESC/motor combinations. Try disabling it to test. - DShot300 is more reliable than DShot600 on longer signal wires. If wires from FC to ESC are >10 cm, try DShot300.

Symptom: Failsafe Triggered in Flight

The drone enters failsafe (lands, returns home, or drops) unexpectedly.

Step 1: Determine which failsafe. - RC failsafe (lost RC link): check RC RSSI in the log. Was signal actually lost or did the FC misinterpret a signal issue? - Battery failsafe: check voltage in the log. Did voltage sag below threshold under load? - GPS failsafe (geofence, GPS loss): check GPS data in log. - GCS failsafe (ArduPilot/PX4): lost MAVLink heartbeat from GCS.

Step 2: RC failsafe diagnosis. - Check RSSI history in the log. A gradual decline to zero = range. A sudden drop = obstruction, interference, or antenna issue. - Check failsafe settings. Betaflight: failsafe_procedure. ArduPilot: FS_THR_ENABLE + FS_THR_VALUE. PX4: COM_RC_LOSS_T. - Is failsafe set to the right response? "Drop" is rarely what you want. "Land" or "RTH" are usually better. But RTH requires GPS — if GPS isn't locked, RTH failsafe may not work. - Check RC receiver failsafe behavior. Some receivers output "no pulses" on signal loss (correct). Others output last-known values (dangerous — FC doesn't know signal is lost). Others output a pre-set failsafe position. Verify your receiver's behavior. Review needed: performance / failure mode Flag this

Step 3: Battery failsafe diagnosis. - Voltage sag under load can briefly dip below the failsafe threshold even when the battery has plenty of capacity. - Fix: lower the failsafe voltage threshold, or use mAh-consumed instead of voltage as the trigger (more reliable). - Check battery internal resistance. An aging battery sags more under load. If your pack used to fly 5 minutes and now triggers failsafe at 3 minutes, the battery is dying. Review needed: performance / failure mode Flag this

Symptom: GPS Glitch / Toilet Bowl / Position Drift

In GPS-assist modes, the drone circles, drifts, or jumps to a wrong position.

Step 1: Check satellite count. Below 8-10 satellites, GPS position accuracy degrades significantly. Don't use GPS modes with < 8 sats.

Step 2: Check HDOP. Horizontal Dilution of Precision. Below 1.5 is good. Above 2.5 is unreliable. Above 4.0, don't trust GPS position at all.

Step 3: Toilet bowl = compass problem. The classic circular drift pattern means the compass heading is wrong, so the FC "corrects" in the wrong direction, overshoots, corrects again, and orbits. - Calibrate compass away from metal, cars, buildings. - Move external compass away from power wires and motors. - Check compass orientation matches FC configuration. - If using internal compass on an FC near ESCs: disable it and use external compass only.

Step 4: Position jumps = multipath or interference. - Near buildings, GPS signals bounce off walls, creating phantom positions. This is normal in urban environments. No fix except dual-band GPS (L1+L5) which is more resistant to multipath. - Near military installations or during exercises, GPS can be jammed or spoofed. If GPS suddenly shows you 50 km away, that's not a hardware problem.

The Universal Diagnostic Rule

When something breaks:

1. Don't change multiple things at once. Change one thing, test, observe. If you change PID, filter, and rates all at once, you won't know what fixed (or broke) it.

2. Pull logs before flying again. The data is in there. Every time you fly without understanding why it broke, you're gambling.

3. Trust the instruments, not your memory. "I think it was oscillating on roll" is less useful than "gyro roll axis shows 200 Hz peak at 40% throttle." Log it. Read it. Then fix it.

4. The simplest explanation is usually right. Loose prop nut causes more crashes than firmware bugs. Check the physical hardware first.

Next

• Chapter 10: Blackbox Logs — What They Tell You — how to read the data that diagnoses everything in this chapter.
• Chapter 11: PID Tuning for People Who Fly — the tuning workflow that addresses oscillation and performance issues.

Something broke. That's normal. The question is whether you understand why, or whether you're about to break it again.

Crash Recovery & Field Repair

You crashed. Now what? This guide covers post-crash assessment, field- repairable damage vs return-to-bench issues, and getting back in the air as fast as possible. For high-volume operations (training, military), crash recovery speed is a force multiplier.

Cross-references: Preflight · Troubleshooting · Frames · Motors · ESCs · Propellers · Blackbox

Immediate Post-Crash

1. Disarm and disconnect battery. Don't approach a crashed quad with a live battery. Props can spin unexpectedly. If the quad is inverted, flip it before disconnecting — some ESCs re-arm on flip detection.

2. Check for smoke or heat. An ESC burning smells like burnt electronics. A shorted LiPo smells acrid and may swell. If the battery is puffing, hot, or damaged, move it to a safe area immediately. Do not attempt to charge a crashed battery without inspection.

3. Visual sweep. Before touching anything, look at the quad from multiple angles. Note what's broken, bent, or missing. Take a photo if this is a build you're tracking in Tooth.

Damage Assessment Checklist

Work through this in order — each step catches issues that affect downstream components.

Props

Most common crash damage. Check all four props for chips, bends, cracks, or stress whitening at the root. Replace any damaged prop — they're the cheapest component and an unbalanced prop stresses everything else.

Arms

Flex each arm gently. A cracked carbon arm may look intact but flex at the fracture. Listen for creaking. Check the arm-to-body bolts (if replaceable arm design). Loose bolts = the arm absorbed impact force. Retorque.

Motors

Spin each motor by hand with the prop removed. They should spin freely and smoothly with no grit, grinding, or catching. Check for:

• Bent motor shaft — the bell wobbles visibly when spun. Replace the motor or the shaft (some motors have replaceable shafts).
• Bearing damage — grinding feel, rough spots, or excessive play in the bell. Replace the motor.
• Bell dent — the motor bell hit the ground and is deformed. May still spin but will vibrate. Replace.
• Magnet shift — rare but possible on hard impacts. Motor feels "coggy" when turned by hand (distinct detent positions). Replace.

Camera

Check the lens for cracks. Check the mount for breaks. TPU mounts absorb impact — check that the TPU hasn't torn. If using a naked action camera (GoPro/Insta360 board), check the ribbon cables and board for cracks.

VTX Antenna

Check the antenna connector (SMA, MMCX, UFL). A bent SMA connector or a pulled UFL pigtail is a common crash failure. A damaged antenna connector reduces video range dramatically and may not be obvious until you fly.

Stack

Open the top plate and visually inspect the FC and ESC. Check for:

• Loose standoffs — retorque
• Cracked PCB — visible crack lines, especially near mounting holes
• Dislodged components — SMD parts knocked off the board
• Loose connectors — JST-SH and wire-to-board connectors can pull free

Battery

Inspect the LiPo:

• Dented or punctured — STOP. Remove to safe area. Do not use.
• Puffed — the pack has swelled. Mild puffing after crash impact is common and often acceptable. Significant puffing = internal damage. Retire the pack.
• Connector damage — bent XT60 pins, cracked solder joints on the balance lead.
• Cell voltage check — use a cell checker. If any cell is below 3.0V after crash, the battery may have been shorted internally. If cells are unbalanced by more than 0.3V, the pack may be damaged.

Field-Repairable vs Bench-Required

Field Kit

Minimum field repair kit for FPV operations:

• Spare props (at least 2 full sets)
• Spare battery straps (they break)
• M3 and M2 hex drivers (frame and stack bolts)
• Small zip ties
• Electrical tape
• Spare antenna (pigtail with connector)
• Cell checker / battery tester
• Small flush cutters
• Tweezers (for re-seating connectors)
• XT60 pigtail (for battery connector swap)

For military/training operations at scale, add: spare motors, spare arms, solder kit with battery-powered iron, conformal coating pen, and a spare FC.

Post-Crash Flight Test

Before committing to a full mission after crash repair:

1. Arm at low throttle — listen for abnormal motor sounds, vibrations, or oscillations.
2. Hover at 1 meter — check for drift, wobble, or toilet-bowling (GPS compass issue from magnetized frame/motor).
3. Gentle maneuvers — roll, pitch, yaw at low rates. Check for sluggish or uneven response.
4. Check OSD — verify battery voltage reads correctly, GPS lock is normal, RSSI/LQ is expected.
5. Land and inspect — check motor temps by touch (brief touch — they should be warm, not burning). One hot motor = possible bearing damage or bent shaft adding load.

If anything feels wrong, land and inspect. Flying a damaged quad risks losing it entirely.

Crash Logging

For builds tracked in Tooth (maintenance/forensic tracking):

• Log the crash with date, flight number, and severity
• Note which components were damaged and what was replaced
• Attach photos of damage
• Track cumulative crash count per component — motors and ESCs have fatigue limits

For Blackbox-equipped builds, the crash flight's Blackbox log can reveal what happened — control input spikes, motor output saturations, gyro vibration signatures, and failsafe triggers.

See: Blackbox for log analysis.

Sources

• Field experience and training program best practices
• Oscar Liang, crash recovery and motor inspection guides
• Forge troubleshooting database (58 entries)

Thermal & Night FPV Operations

Night-capable FPV changed the war. Ukrainian units like Wild Hornets' "Night Hornets" team pioneered night strikes using low-lux cameras and IR illumination. Both sides now operate 24-hour FPV cycles. This guide covers the operator-level knowledge for flying FPV in darkness — camera selection, IR integration, OSD configuration, cold-weather battery management, and the operational patterns that work at night.

Cross-references: FPV Cameras · Thermal Cameras · Video Transmitters · Batteries · EW Countermeasures

Night Vision Tiers

Not all "night capable" is equal. There are three distinct tiers of night FPV capability, each with different hardware and operational tradeoffs.

Tier 1: Low-Lux Analog Camera (Passive)

The simplest approach. Use a camera with very low minimum illumination and rely on ambient light — moonlight, starlight, urban glow, fires.

Key insight: "Starlight" cameras (0.0001 lux) can see under moonlight and urban ambient conditions. They cannot see in total darkness (cave, deep forest canopy, moonless overcast). For total darkness you need active illumination (Tier 2) or thermal (Tier 3).

Color vs mono: some cameras switch to black-and-white mode in low light to maximize sensitivity. Mono cameras like the RunCam Night Eagle are always B&W but extract maximum photons. Color is useless at night — accept the mono image.

Tier 2: Low-Lux Camera + IR Illuminator (Active)

Add an infrared LED illuminator to the drone. The camera sees IR reflected off objects. Works in total darkness but the IR emission is detectable by enemy night vision equipment.

IR illuminator specs:

850 nm vs 940 nm: 850 nm produces a faint red glow visible to the naked eye at close range and bright to any NVG. 940 nm is invisible to the eye and dim to Gen 2 NVG, but cameras are less sensitive to it — shorter effective range. Choose based on threat: 940 nm if operating near enemy with NVG, 850 nm if detection risk is low.

Mounting: mount the IR LED below or beside the camera, angled to illuminate the camera's field of view. Avoid mounting above — downwash from props can vibrate the illuminator and cause flickering on video.

Wiring: most IR LEDs run on 3.3V or 5V DC. Wire to a spare BEC output or directly to a regulated pad on the FC. Use a switch channel (AUX) to toggle IR on/off in flight — the pilot should be able to kill the IR if detection risk increases.

Tier 3: Thermal Camera (Passive, All-Conditions)

Thermal (LWIR) cameras detect heat radiation, not light. They work in complete darkness, through smoke, and in conditions where optical cameras are blind. But they produce low-resolution imagery with no texture detail — you see heat signatures, not visual features.

For thermal camera hardware, see: Thermal Cameras

FPV integration: most thermal cameras output analog composite video (PAL/NTSC) that connects directly to the VTX like any other FPV camera. Some output digital (USB/MIPI) and require a companion computer to convert to analog for the VTX.

Thermal + optical dual feed: some operators run two cameras — a thermal for detection and a low-lux optical for the final approach. Switch between feeds via an AUX channel controlling a video switcher. This requires two camera inputs and a video switch module, adding weight and complexity.

OSD Configuration for Night

The OSD must be readable at night without overwhelming the pilot's dark-adapted vision.

Brightness and Contrast

• Reduce OSD brightness if your OSD chip supports it. Standard daytime OSD brightness is blinding on a night low-lux feed.
• Use minimal OSD elements — only what you need: battery voltage, LQ/RSSI, altitude/distance, heading, flight mode. Remove decorative elements, timers, and non-critical data.
• Position OSD elements at edges — keep the center of the image clear for target identification.

Critical Night OSD Elements

Goggle Settings

• Reduce goggle brightness to minimum comfortable level. Your pupils need to stay dilated for the low-lux feed.
• If using OLED goggles (Orqa FPV.One): OLED blacks are true black, which helps low-lux contrast. LCD goggles have backlight bleed that washes out dark scenes.
• DVR recording: always record. Night footage is harder to review in real-time — DVR lets you analyze after landing.

Cold Weather Battery Management

Night operations often mean cold operations. Battery performance degrades significantly below 10°C and becomes dangerous below 0°C.

LiPo Cold Behavior

Field Practices

• Pre-warm batteries before flight. Keep them in an insulated bag with hand warmers. Target 20-25°C at launch.
• Reduce flight time estimates by 20-30% in cold conditions. A battery that gives 8 minutes at 20°C may give 5-6 minutes at 5°C.
• Monitor voltage sag under load — cold batteries sag harder. If voltage per cell drops below 3.3V under throttle, land immediately. Cold sag can recover when the battery warms up, but pushing a cold battery risks permanent cell damage.
• Land with more reserve than daytime. 3.5V/cell landing voltage instead of the typical 3.3V/cell.
• Don't charge cold batteries. Charging below 5°C causes lithium plating and permanent capacity loss. Warm the battery above 10°C before charging.

Night Operational Patterns

Launch and Recovery

• Mark the launch site with an IR chemlight or low-power IR LED visible to your goggles but not to naked eye. You need to find home in the dark.
• Launch vertically, climb to safe altitude before translating. Obstacles invisible at night are at ground level.
• Recovery approach: use GPS distance and heading on OSD to navigate back to launch. Descend slowly — you cannot judge ground proximity visually on a low-lux feed. Consider a dedicated landing camera (downward-facing) if the platform supports it.

Navigation

• Fly by instruments, not visuals. At night, the camera feed gives situational awareness but not reliable distance/altitude perception. Trust your OSD heading, altitude, and distance readouts.
• Use GPS waypoints if firmware supports them (iNav, ArduPilot). Pre-plan the route with waypoints at known positions. The OSD will guide you between points.
• Terrain awareness: if operating in terrain with elevation changes, know the terrain profile before launch. AGL (above ground level) can differ significantly from altitude over the launch site.

Target Engagement (Strike)

• IR illuminator on for final approach only. Fly dark to the target area using ambient light, then activate IR for the last 200-500m when you need precision.
• Thermal for detection, optical for terminal. If running dual cameras, use thermal to locate the target (heat signature stands out at range), then switch to low-lux optical for the final approach where you need texture/shape detail for positive identification.
• Video frequency at night: enemy ELINT may be lower priority at night, but your VTX emission is still detectable. Consider reduced VTX power or non-standard frequencies for night operations where stealth matters.

Hardware Checklist: Night Build

Sources

• Wild Hornets, Night Hornets team operational reporting
• TAF Industries, Kolibri 10 thermal variant specs
• Oscar Liang, low-light FPV camera reviews
• LiPo cold weather performance studies
• Ukrainian FPV operator training materials (public)

Repeater & Relay Deployment

FPV range is limited by line of sight between the pilot and the drone. Terrain, buildings, and vegetation block the signal. A repeater drone — flown to altitude as a communication relay — extends operational range beyond direct LOS. TAF Industries produces the Kolibri 13 FR1 purpose-built repeater. This guide covers the generic principles for deploying any drone as a relay, whether purpose-built or improvised.

Cross-references: Frequency Planning · EW Countermeasures · Link Budgets · Comms & Datalinks · Video Transmitters · C2 Datalinks

Why Repeaters

RF signals travel in straight lines. At ground level, the Earth's curvature, terrain, trees, and buildings create blind spots where your control link and video link cannot reach. A repeater at altitude solves this by creating two shorter line-of-sight paths instead of one blocked long path:

Without repeater:
  Pilot ----X---- [hill] ----X---- Drone
  (no LOS = no link)

With repeater:
  Pilot -------- Repeater (200m AGL) -------- Drone
  (two clear LOS paths)

The altitude advantage is enormous. At 200m AGL, the radio horizon extends roughly 50 km in every direction (assuming flat terrain). Even modest altitude (100m) clears most urban and forested terrain.

Repeater Architectures

Type 1: Dedicated Relay Drone

A separate platform whose only job is to hover at altitude and relay signals. No camera, no payload — just radios, battery, and GPS hold.

Advantages: purpose-optimized, maximum endurance (no payload weight), can use larger battery, simplest operational concept.

Disadvantages: consumes an entire drone and operator for relay duty, single point of failure for all NLOS platforms.

Example: TAF Industries Kolibri 13 FR1. Half the cost of a DJI Matrice-based relay. Ready to use out of the box. One day operator training.

Type 2: Mother Drone with Relay Function

A larger drone (7" or 10"+) that carries FPV drones as payload AND acts as a signal relay while the FPV drones operate. The mother drone provides both transport and communication relay.

Advantages: dual-purpose, extends FPV range to 60-70 km (mother drone range + FPV range from mother), reduces total platforms needed.

Disadvantages: complex operations, mother drone loss = loss of all carried FPVs, higher cost platform.

Type 3: Fixed Repeater (Ground-Based)

A mast-mounted or building-mounted relay station. Not a drone — a fixed radio installation at elevation.

Advantages: unlimited endurance (wired power), no flight operations needed, can be hardened/concealed.

Disadvantages: fixed position (can't reposition quickly), vulnerable to detection and targeting, requires physical access to install.

Example: IRONghost QS ground station with mast-mounted antenna provides 1 km operator standoff via CAT5 cable.

Link Budget for Relay

A relay adds a second hop to every link. Each hop has its own path loss. The total system performance is limited by the weaker of the two hops.

Control Link (Ground → Repeater → Drone)

Ground TX → [path loss A] → Repeater RX
Repeater TX → [path loss B] → Drone RX

The repeater receives the control signal and retransmits it. Total latency increases by the repeater's processing time (typically 1-5 ms per hop for digital systems). For CRSF/ELRS at 250 Hz, 2-5 ms added latency is imperceptible to the pilot.

Video Link (Drone → Repeater → Ground)

Drone VTX → [path loss B] → Repeater video RX
Repeater video TX → [path loss A] → Ground RX (goggles)

Analog video relay: the repeater receives the analog video signal and retransmits it on a different channel. Each relay hop adds noise to the analog signal. After one relay hop, video quality is noticeably degraded. After two hops, it's often unusable. One relay hop is the practical maximum for analog video.

Digital video relay: digital signals don't degrade per hop (they either work or they don't). Digital relay adds latency (decode + re-encode) but maintains image quality. This is a significant advantage for relay operations.

Power Budget

Each hop must have sufficient link margin independently. If either hop is weak, the relay doesn't help.

Rule of thumb: the repeater needs at least the same TX power as the ground station for the ground-to-repeater hop, and the drone's VTX/RC link must have enough power for the drone-to-repeater hop at the intended operating distance.

Deployment Procedures

Site Selection

1. Altitude: 100-300m AGL is the sweet spot. Higher = more coverage but more wind exposure and more visible to enemy. Lower = less coverage but less conspicuous.
2. Position: ideally at the midpoint between the ground station and the operational area. If terrain is the problem, position the repeater to clear the specific obstruction.
3. Wind: the repeater must hold position in wind. GPS hold mode is essential. In strong wind, the drone will drain battery fighting to hold station. Monitor battery consumption rate and plan endurance accordingly.

Pre-Flight

1. Bind the repeater to the ground station (its own binding, separate from operational drones)
2. Assign VTX channel for the repeater if it has video (separate from operational drone channels)
3. Verify GPS lock on the repeater (strong lock needed for stable hold)
4. Plan relay endurance: how long can the repeater hold at altitude on its battery? Subtract 20% safety margin for wind. Review needed: safety / performance Flag this
5. Plan recall procedure: what happens when repeater battery hits minimum? All NLOS drones must be recalled BEFORE the repeater lands.

Launch Sequence

1. Launch repeater first
2. Climb to planned altitude and enter GPS hold / position hold / loiter
3. Verify relay links are active (test control + video through relay)
4. Only then launch operational drones for NLOS mission
5. Monitor repeater battery continuously throughout operation

Recovery Sequence

Critical: reverse order. Recovery must happen in this sequence:

1. Recall all NLOS operational drones to within direct LOS of ground station (or land them)
2. Verify all operational drones are safe (landed or within direct link)
3. Only then recall the repeater
4. Land the repeater

If repeater battery is critical: emergency recall all NLOS drones immediately. Do not wait for them to complete their mission. A dead repeater means instant loss of all NLOS links.

Frequency Management

The repeater adds RF links to the frequency plan. Key rules:

Repeater Control Link

The repeater needs its own control link from the ground station. This consumes one RC channel/binding on the ground side.

• If using IRONghost: the repeater gets its own IRONghost binding on the same or different band as operational drones
• If using ELRS: separate binding phrase for the repeater
• If using a commercial relay (DJI Matrice, etc.): uses its own proprietary link

Video Relay Channels

If the repeater receives video from operational drones and retransmits to the ground:

• Receive channel: must match the operational drone's VTX channel
• Transmit channel: must be DIFFERENT from the receive channel (otherwise the repeater jams itself). Minimum 60 MHz separation between receive and transmit channels on the repeater.
• Directional antenna on receive side (pointed at operational area) and omnidirectional on transmit side (back to ground station) helps isolate the two channels.

Avoid Self-Interference

The repeater is simultaneously receiving and transmitting. If the transmit signal leaks into the receive path, the repeater will create a feedback loop (howl/oscillation) or desense its own receiver. Mitigation:

• Maximum frequency separation between RX and TX channels
• Directional antennas to isolate TX and RX paths
• Physical separation of TX and RX antennas on the repeater airframe
• Power management: use minimum necessary TX power on the repeater

Failure Modes

The fundamental risk: repeater failure is a cascading failure. Every platform relying on the repeater loses its link simultaneously. This is why relay operations require disciplined battery management and a standing recall plan.

Endurance Planning

Practical relay time = hover endurance minus 20% safety margin minus climb/descent time. Review needed: safety / performance Flag this

For operations requiring longer relay time than a single battery provides, plan battery swaps: land repeater, swap battery, relaunch. All NLOS drones must be within direct LOS during the swap window.

Sources

• TAF Industries, Kolibri 13 FR1 repeater specifications
• Orqa GCS-1 / IRONghost QS ground station documentation
• RF link budget fundamentals
• FPV community relay operation reports
• Multi-drone operational planning best practices

Supply Chain Substitution Guide

Your preferred receiver is out of stock. Your ESC supplier raised MOQ to 500 units. The FC you spec'd got discontinued. This guide maps drop-in replacements by pinout, protocol, mounting, and firmware compatibility — so you can swap without redesigning your build or reflashing your stack.

Cross-references: Flight Controllers · ESCs · Comms & Datalinks · CRSF & ELRS Protocol · DShot & ESC Protocols · UART Layout · NDAA Compliance Review needed: regulatory / configuration Flag this

How to Use This Guide

1. Find your out-of-stock component's category below
2. Check the compatibility matrix for your specific part
3. Verify the three swap criteria: pinout, protocol, mounting
4. Flash firmware if needed — the guide notes when a reflash is required

"Drop-in" means same pinout, same protocol, same mounting — solder it in place of the old part and it works. "Near-drop-in" means one thing differs (usually a wire swap or a firmware setting change).

Scope boundary (editorial guidance): do not carry these FPV substitution labels over to proprietary aircraft or controller assemblies as blanket compatibility approval. Keep the exact model, module position, connector, board revision, supplied-item condition, and unresolved calibration or pairing requirements in the replacement record. A matching-looking connector or an OEM-pulled label does not resolve those unknowns.

Supplier-published illustration: the source below is a commercial supplier's parts-evidence guide, not a manufacturer approval, field test, endorsement, or verified substitute matrix.

ELRS Receivers (900 MHz)

The most commonly stocked-out component. All ELRS receivers speak CRSF over UART and are cross-compatible on the air side regardless of brand. The differences are physical: pinout, antenna connector, size, and whether they have a PA/LNA.

Nano Form Factor (no PA/LNA)