Skip to content

Backup Power and Lost-Aircraft Beacon

Interface and protection requirements for the always-on power domain: a backup battery (since 2026-10-06 the lights node’s 2S lighting battery, lights.md), charged from the flight pack, that keeps the GPS and the LoRa radio running when the flight pack is lost, so that a downed aircraft reports its position and sounds an alarm. Ryan’s proposal (2026-10-05); the flight controller side is th-avionics’, the board is th-eda’s and the radio firmware is th-telemetry’s. Nothing here is built. Part numbers are suggestions to check for stock and fit; they are not chosen.

State Main power (flight pack) Always-on domain Flight controller
Normal flight Present Runs from the lighting battery, with main 5 V as the seamless fallback Flies; reads the GPS and the radio through isolators
Pack swap on the ground Absent for seconds Runs from the lighting battery; the GPS keeps its fix and RTK state Off
Lost or crashed Absent Runs from the lighting battery down to its cell cut; the radio sends the GPS position when a ground transmitter links (the dock, or a handheld such as a Heltec V3: an mLRS receiver transmits only when linked, th-telemetry); the buzzer sounds Off

The always-on domain holds the Waveshare Q43 (GPS and its compass), the XIAO ESP32-S3 with its two Wio-SX1262 radios (one ESP32 with two radios, in diversity, Ryan 2026-10-05), and the buzzer. The flight controller, the airspeed sensor and everything else stay on main power.

Block Requirement Candidate (suggestion)
Main 5 V in From the main 5 V supply, not from the flight controller’s GPS-port 5 V pin The existing 5 V supply
Backup battery The lights node’s 2S lighting battery (lights.md; Roaring Top 1300 recommended). The lights stop at its 25 % reserve and the rest is kept for this domain: about 250 mA at 5 V for the Q43 and both radios (an estimate) On the lights node
Charger On the lights node, from the flight pack, only when disarmed LT3652 (th-eda)
Change-over Seamless: an ideal-diode OR of main 5 V and +5V_LIGHT, set above main so the lighting battery carries the rail by day. No dropout, so the Q43 keeps its fix and the radio does not reset LM66100 (th-eda)
Battery to 5 V +5V_LIGHT, 5.2 V from the 2S battery on the lights node, over a GH-4 with the UART between the boards. Alive down to the cell cut, 6.03 V open and 6.28 V reclose (a hardware cut with hysteresis) On the lights node
Always-on 5 V out Feeds the Q43 (3.3 to 16 V, 500 mW typical, Waveshare), the radio board and the buzzer

Cut or leave open the 5 V wire from the flight controller’s GPS port to the Q43. The Q43 takes its power only from the always-on rail. If both supplies connect to the Q43, the backup battery feeds the flight controller’s 5 V rail through that wire.

Signal From To Notes
GPS UART TX Q43 Flight controller RX (SERIAL3, 230,400 baud) through an isolator; ESP32 RX directly One driver, two receivers. The ESP32 reads the GPS position itself in lost mode, because no MAVLink comes from a flight controller that is off
GPS UART RX Flight controller TX (SERIAL3) through an isolator Q43 Carries the GPS configuration and the RTK corrections that the flight controller injects
Compass I2C (SCL, SDA) Q43’s QMC5883P Flight controller I2C through an I2C isolator The airspeed sensor stays on the flight controller side of the isolator
Radio UART ESP32 TX and RX Flight controller SERIAL2 (TELEM2, 115,200 baud) through an isolator One MAVLink link: the diversity is inside the radio
Main power present Main 5 V ESP32 GPIO through an optocoupler Tells the ESP32 that main power is gone, to start the beacon and the alarm
Buzzer ESP32 GPIO A MOSFET and a loud piezo (85 to 100 dB) Sounds a few seconds after main power is lost with no movement

When the flight controller is off, the Q43 keeps its configuration in memory, so it continues to send the UBX messages that ArduPilot set. If the Q43 also loses power and restarts, it returns to its stored default output. The ESP32 firmware must read both.

The trap is back-feeding. When the always-on domain has power and the flight controller does not, every signal line from the always-on domain to the flight controller pushes current into the flight controller’s pins. That current goes through each pin’s protection diode into the flight controller’s 3.3 V rail, which partly powers the flight controller and anything on its I2C bus, such as the airspeed sensor. It drains the backup battery, it can latch up the flight controller, and a flight controller that is half powered can drive its own pins in ways that nobody tested.

Isolation stops this. Each side of an isolator takes power from its own domain only: the flight controller side from the flight controller’s 3.3 V, and the always-on side from the always-on rail. With the flight controller off, its side of the isolator has no power and nothing crosses the barrier. The flight controller and the always-on domain keep a common ground; the isolator is for the back-feed and for noise, not for a ground break.

Line Isolator type Candidate (suggestion) Requirement
UART lines (GPS 230,400 baud, radio 115,200 baud) High-speed logic optocoupler, or a digital isolator Optocoupler: Toshiba TLP2361 (3.3 V, logic output, 15 Mbd). Digital isolator: ADuM1201 or ISO7721 (two channels, one each way) At least 1 Mbd. Do not use slow transistor optocouplers such as the PC817: their edges are too slow for 230,400 baud
Compass I2C Bidirectional I2C isolator ADuM1250 or ISO1541 Optocouplers cannot pass bidirectional open-drain I2C without latch-up, so use an isolator made for I2C, 400 kHz or more
Main power present Optocoupler Any LED optocoupler (speed does not matter) LED on the main 5 V side, transistor on the ESP32 side

Fail-safe output state. On every UART channel from the flight controller to the always-on domain (GPS RX, radio RX), the isolator output must stay high when the flight controller side has no power. A UART line held low is a continuous break, which the Q43 and the ESP32 read as noise. Choose the default-high variant (the ISO7721, not the ISO7721F; check the ADuM1201’s default) or add a pull-up on the output.

Optocoupler LED current. An optocoupler’s LED takes several milliamperes. The Q43’s and the ESP32’s TX pins must not drive it directly beyond their rating; use a small buffer from the same domain, or a digital isolator, which needs no LED current.

  1. Disconnect the flight pack. Power the always-on domain from the lighting battery. Measure the flight controller’s 3.3 V and 5 V rails: both must stay at 0 V. Measure the current from the lighting battery with the flight controller connected and disconnected: it must not change.
  2. With main power on, make sure that the GPS reaches RTK fixed through the isolators (the corrections go from the flight controller to the Q43 through the isolator), and that the compass and the airspeed sensor read correctly.
  3. Pull the flight pack with the GPS at RTK fixed. Make sure that the GPS keeps its fix, the radio keeps its link, and the ESP32 starts its beacon and, after the set time with no movement, the buzzer.
  4. Reconnect the flight pack. Make sure that the flight controller starts normally with the always-on domain already powered.

Two radios, the GPS tap, the main-power input, the buzzer and a Q43 load switch need 18 to 19 GPIO, more than the XIAO’s 11, and two Wio carriers cannot stack on one XIAO. So the board carries an ESP32-S3-WROOM-1U module (the U.FL variant since 2026-10-07, Ryan, so the S3’s own 2.4 GHz radio has an antenna for WiFi or BLE at the recovery site; the WROOM-1’s PCB antenna had sat over ground with WiFi never started) and two SX1262 modules, each with 100 µF: Seeed Wio-SX1262 since 2026-10-07 (Ryan; the Heltec HT-RA62 held the slot from the evening of 2026-10-06 and the Ai-Thinker Ra-01SH for a few hours before it; the Wio has its own land, so neither drops in), with the antenna on each module’s own IPEX and the module’s TCXO at 1.8 V. The Wio is the module the XIAO Wio-SX1262 carries, so the bench hal and soak already apply to it. mLRS does not run on the ESP32-P4 (th-mlrs-xiao: a port, not a hal), so the beacon keeps the ESP32-S3. The XIAO and Wio stay a bench rig for the firmware. Isolators: two ISO7721 (default high) for the UARTs and an ISO1541 for the compass, which the Q43’s and the ESP32’s TX pins drive directly with no LED current. The flight controller side of each isolator takes 3.3 V from a regulator fed by the flight controller port’s 5 V, because the LUX brings out 5 V, not 3.3 V. The board takes main 5 V from its own BEC on the flight pack, not from the LUX’s 5 V supply.

Later the same day (Ryan, lights.md “Shared with the beacon”): the backup cell, its charger and its boost leave this board. The lights node’s 2S lighting battery feeds it +5V_LIGHT (5.2 V, alive down to that battery’s cell cut) over a GH-4 that also carries a UART between the two boards (“lost mode” to the lights, the battery state back). The ideal-diode OR stays, with the lighting rail set above main so it carries the Q43, radios and buzzer by day and main takes over with no dropout. The requirements above still describe the behaviour; the cell they name now lives on the lights node (terrahawk-eda/boards/lights, docs/lights-node-brief.md).

  • th-eda: the schematic (done, boards/beacon), the lights node’s +5V_LIGHT setpoint above main (so the lighting battery carries the rail by day and main takes over when main droops), and stock.
  • th-telemetry: the lost-mode firmware (read the GPS, send the position, drive the buzzer) and how the GCS shows a lost aircraft.
  • th-avionics, done: the pre-arm check on the lighting battery’s charge is BATT3_ARM_VOLT 7.8 by day in params/payload-lights.parm (3.9 V a cell, about 75 %), raised by lights.lua to 8.2 V (about 95 %) at night, so a full night survey ends above the night return. In flight at night, lights.lua returns the aircraft under 40 % (the 25 % reserve for lost mode, the return and a margin; lights.md).

Source: docs/backup-power.md in the repo. Edit it there; this page is generated.

Comments on

    Comments are reviewed before they appear. Please leave out places, addresses and other personal details.

    A Supported Systems Flight

    This build log is written and kept by Supported Systems, a small studio that makes thoughtful, user-first technology. The airframe, the hangar and the simulation are ours.

    Visit supported.systems