ArduPlane Custom Build — Light Variant — v1.1

🪶 Light variant — the 1 MB F4 track. A backend-stripped build that fits 1 MB F4 boards with room to spare. Built on ArduPlane 4.6.3; everything stock 4.6.3 does still applies underneath the ArduCustom additions.

📖 Full feature & parameter reference: README_CUSTOM.md (light variant)
🔧 Full variant (F7 / H7 / 2 MB, every backend compiled in): full-v1.1 release →

Firmware version string: ArduPlane V4.6.3 ArduCustom v1.1 Light (89032c1) — 89032c1 is the git short-hash the binaries were built from.

---

⚠️ Release tracks now split by MCU class

As of v1.1 the two tracks no longer overlap. A given board appears on exactly one of them:

Track	Boards	MCU
light (this release)	9 boards	1 MB F4 only
full	3 boards	F7 / H7 / 2 MB

Previously the F7/H7 boards were built for both tracks. They're now full-only — a 2 MB board has no reason to run a backend-stripped build. If you were flashing MatekF765-Wing, MatekH743-bdshot or KakuteH7-Wing from the light release, switch to full-v1.1.

New in v1.1

🚀 Move sticks to cancel auto launch

Nudge pitch or roll during an automatic takeoff and the plane drops to FBWA, so you can save a bad launch without reaching for the mode switch. Modelled on iNav's "move sticks to cancel auto launch". Works in TAKEOFF mode and in AUTO while a NAV_TAKEOFF item is running.

Phase	Cancel available?
Armed, waiting for the throw	✅ immediately
Launch → TKOFF_CNCL_DLY (default 1 s)	❌ locked — the throw can't abort its own launch
After the grace period → target altitude	✅
Target altitude onward	❌ never

Two GCS announcements make it visible: Move sticks to cancel auto launch when the pre-launch window opens, and Launch cancel armed once the grace period elapses. Cancelling reports Auto launch cancelled. The takeover is sticky — you stay in FBWA until you flip the mode switch.

New parameter — TKOFF_CNCL_DLY (default 1.0 s, range 0-10): how long stick input is ignored after launch. This is the equivalent of iNav's nav_fw_launch_min_time, and exists because you throw one-handed while holding the transmitter. Set 0 to allow cancelling from the instant of launch.

⚠️ RC_OPTIONS bit 20 has been removed. Earlier builds had bit 20 (AUTO_SWITCH_TO_FBWA_WITH_STICKS), which fired any time you were in AUTO, at any altitude, mid-mission — a 10 % stick bump silently ended missions, and stock ArduPlane has no equivalent. That option no longer exists; the behaviour is takeoff-only and always available, with nothing to configure. If your saved RC_OPTIONS still has bit 20 set it is simply ignored. New RC_OPTIONS default is 544 (was 1049120).

🎚️ STICK_MIXING back to upstream's default

STICK_MIXING now defaults to 1 (FBW-style pilot override in auto/RTL/guided), matching stock ArduPlane. This fork previously shipped 0, which made sense only while the old always-on takeover existed — running both gave an invisible threshold where a small nudge biased the mission and a slightly larger one ended it. With the takeover confined to the takeoff, mixing is the right tool for mid-mission pilot input. Set 0 if you want pilot input ignored in nav modes.

🔄 Pilot loiter radius and direction in TAKEOFF mode

TAKEOFF mode stays in TAKEOFF mode after the climb and circles at TKOFF_DIST/TKOFF_ALT — it does not switch to LOITER. Previously that circle used WP_LOITER_RAD with no pilot control. Now all three sticks work there, as they already did in LOITER and RTL:

Stick	Effect in the TAKEOFF loiter
Pitch	loiter altitude (FBWB_CLIMB_RATE, release to lock)
Roll	loiter radius, clamped 20-1000 m
Rudder	loiter direction, beyond 50 % deflection

Stick mixing is suppressed in that phase so the same input isn't applied twice — matching the existing guards for RTL and LOITER. During the climb, mixing behaves exactly as before. 📖 Full details in README_CUSTOM.md →

🔊 Other additions

• Takeoff cues on plain GPIO buzzers. Pre-launch audio cues previously only worked on boards with a PWM/ALARM ToneAlarm output. Boards that only have a simple on/off GPIO buzzer (e.g. AtomRCF405NAVI) now get the same cues, with three cadences chosen to stay distinguishable by ear: slow lone beeps = raise throttle, medium double-beeps = spooling to idle, fast continuous = ready to launch (repeats until you throw).
• Gimbal support restored on AtomRCF405NAVI. Upstream's minimize_common.inc disables HAL_MOUNT_ENABLED on flash-constrained 1 MB F4 boards, which left this board with no gimbal support at all. Re-enabled with the servo (PWM) and CADDX backends only — enough for CADDX GM3-type serial gimbals and PWM mounts, without spending flash on backends nobody uses on this board.

🐞 Fixes

• Takeoff cues could arrive up to 3.3 s late. The pre-launch cues were queued behind the notify layer's minimum-separation guard, which enforces a gap of 32 bits × 100 ms + 100 = 3300 ms between patterns. A cue announcing "ready to launch" could therefore sound well after a hand launch had already happened — worse than useless, since it invites a throw at the wrong moment. State-change cues now bypass the guard and fire immediately. The repeating launch-ready cue deliberately stays behind it: update() runs at 50 Hz, so preempting there would reset the pattern every 20 ms and the buzzer would sit on one solid tone.

• TAKEOFF mode latched a stale climb target — airframes with an airspeed sensor only. ModeTakeoff::navigate() wrote the pilot-adjustable target altitude back into the loiter waypoint unconditionally, from the moment the mode started, before that value had been seeded off the loiter waypoint. Entering TAKEOFF from FBWB could therefore latch the climb target at ground level, so the plane levelled off almost immediately instead of climbing to TKOFF_ALT. Airframes without an airspeed sensor were unaffected, because their climb is pitch-driven (TKOFF_LVL_PITCH) rather than TECS-driven. The write-back is now gated on the altitude having been seeded.

Docs

• MNT1_TYPE=7 documented for non-stabilised head-track servos.
• FrSky Ethos sound path added to the Yaapu Course Hold install table.
• F4 EKF3/RAM section rewritten around allocation order (logger → terrain → EKF3), which explains why lowering TERRAIN_CACHE_SZ alone can backfire; plus LOG_FILE_BUFSIZE as a RAM-headroom lever.
• 23:ShortenPluscode restored to the OSD_OPTIONS documentation on the light branch.

---

📡 Yaapu telemetry — Course Hold name + audio cue

Stock Yaapu doesn't know Plane mode 26, so Course Hold shows as a blank chip with no audio cue. The two non-firmware files attached below fix that — no need to clone the repo:

• plane.lua — replace Yaapu's copy under WIDGETS/yaapu/ (EdgeTX widget install), then delete the plane.luac sitting next to it (compiled cache, regenerates itself).
• coursehold.wav — copy into WIDGETS/yaapu/sounds/en/ (use your language folder if not English).

⚠️ Right name but no sound? The WAV is in a folder Yaapu isn't reading — the mode name and the sound file are looked up separately, so the HUD text can work while the cue silently doesn't. The folder depends on your Yaapu build:

Build	coursehold.wav goes in
EdgeTX widget (TX16S)	WIDGETS/yaapu/sounds/en/
OpenTX / Horus script	SOUNDS/yaapu0/en/
FrSky Ethos	scripts/yaaputelemetry/audio/en/

None of these is EdgeTX's own SOUNDS/en/ folder, which is for Special Functions and unrelated to Yaapu.

📖 Full install notes, including the Yaapu GCS desktop tool and recording your own cue: Tools/yaapu-coursehold/README.md →

---

Fleet (9 boards, all 1 MB F4)

Free flash after the fork feature set:

Board	Free flash	Notes
KakuteF4-Wing-Buzz	79.6 KB	Kakute F4 Wing + tone buzzer
speedybeef4v3	50.4 KB	most F4 headroom
MatekF405-STD	44.9 KB
omnibusf4pro	39.8 KB	Omnibus F4 Pro FPV FC
MatekF405-TE-bdshot	39.8 KB
AtomRCF405NAVI	30.9 KB	AtomRC F405 Navi — mount re-enabled this release
SpeedyBeeF405WING	27.1 KB
SpeedyBeeF405WING-Buzz	26.8 KB	SpeedyBee F405 WING + tone buzzer
MatekF405-Wing-bdshot	24.7 KB	tightest of the fleet — the canary board

Which file do I flash?

Each <board>_plane_bin_light-v1.1_.zip contains four build products. Two of them are flashable:

File	Use it when
arduplane.apj	Normal upgrade. Load it from MissionPlanner / QGC → "Load custom firmware" onto a board that already has a working ArduPilot bootloader. This is the usual path.
arduplane_with_bl.hex	The .apj won't take. Flash over DFU (board in bootloader mode — STM32CubeProgrammer, dfu-util, or MissionPlanner's DFU option). This writes the bootloader and the firmware, so it recovers a board whose bootloader is missing, stale, or the wrong family.
arduplane / arduplane.bin	ELF and raw binary, for debugging and toolchain use. Not for GCS flashing.

💡 If the .apj is rejected or the flash fails, go straight to arduplane_with_bl.hex over DFU. Conf...

ArduCustom Full v1.1

🔧 Full variant — the F7 / H7 / 2 MB track. Every upstream backend compiled in, plus the fork additions. Built on ArduPlane 4.6.3; everything stock 4.6.3 does still applies underneath the ArduCustom additions.

📖 Full feature & parameter reference: README_CUSTOM.md (full variant)
🪶 Light variant (1 MB F4, backend-stripped to fit): light-v1.1 release →

Firmware version string: ArduPlane V4.6.3 ArduCustom v1.1 (4e6897a) — 4e6897a is the git short-hash the binaries were built from. No Light suffix on this track.

---

⚠️ Release tracks now split by MCU class

As of v1.1 the two tracks no longer overlap. A given board appears on exactly one of them:

Track	Boards	MCU
full (this release)	3 boards	F7 / H7 / 2 MB
light	9 boards	1 MB F4 only

MatekF765-Wing, MatekH743-bdshot and KakuteH7-Wing were previously built for both tracks. They're now full-only — a 2 MB board has no reason to run a backend-stripped build.

1 MB F4 boards are not on this release. The accumulated fork feature set no longer fits in ~1 MB alongside every upstream backend. Flash those from light-v1.1 instead — the board-specific fixes are shared, the light variant uses the same hwdefs.

New in v1.1

🚀 Move sticks to cancel auto launch

Nudge pitch or roll during an automatic takeoff and the plane drops to FBWA, so you can save a bad launch without reaching for the mode switch. Modelled on iNav's "move sticks to cancel auto launch". Works in TAKEOFF mode and in AUTO while a NAV_TAKEOFF item is running.

Phase	Cancel available?
Armed, waiting for the throw	✅ immediately
Launch → TKOFF_CNCL_DLY (default 1 s)	❌ locked — the throw can't abort its own launch
After the grace period → target altitude	✅
Target altitude onward	❌ never

Two GCS announcements make it visible: Move sticks to cancel auto launch when the pre-launch window opens, and Launch cancel armed once the grace period elapses. Cancelling reports Auto launch cancelled. The takeover is sticky — you stay in FBWA until you flip the mode switch.

New parameter — TKOFF_CNCL_DLY (default 1.0 s, range 0-10): how long stick input is ignored after launch. This is the equivalent of iNav's nav_fw_launch_min_time, and exists because you throw one-handed while holding the transmitter. Set 0 to allow cancelling from the instant of launch.

⚠️ RC_OPTIONS bit 20 has been removed. Earlier builds had bit 20 (AUTO_SWITCH_TO_FBWA_WITH_STICKS), which fired any time you were in AUTO, at any altitude, mid-mission — a 10 % stick bump silently ended missions, and stock ArduPlane has no equivalent. That option no longer exists; the behaviour is takeoff-only and always available, with nothing to configure. If your saved RC_OPTIONS still has bit 20 set it is simply ignored. New RC_OPTIONS default is 544 (was 1049120).

🎚️ STICK_MIXING back to upstream's default

STICK_MIXING now defaults to 1 (FBW-style pilot override in auto/RTL/guided), matching stock ArduPlane. This fork previously shipped 0, which made sense only while the old always-on takeover existed — running both gave an invisible threshold where a small nudge biased the mission and a slightly larger one ended it. With the takeover confined to the takeoff, mixing is the right tool for mid-mission pilot input. Set 0 if you want pilot input ignored in nav modes.

🔄 Pilot loiter radius and direction in TAKEOFF mode

TAKEOFF mode stays in TAKEOFF mode after the climb and circles at TKOFF_DIST/TKOFF_ALT — it does not switch to LOITER. Previously that circle used WP_LOITER_RAD with no pilot control. Now all three sticks work there, as they already did in LOITER and RTL:

Stick	Effect in the TAKEOFF loiter
Pitch	loiter altitude (FBWB_CLIMB_RATE, release to lock)
Roll	loiter radius, clamped 20-1000 m
Rudder	loiter direction, beyond 50 % deflection

Stick mixing is suppressed in that phase so the same input isn't applied twice — matching the existing guards for RTL and LOITER. During the climb, mixing behaves exactly as before. 📖 Full details in README_CUSTOM.md →

🔊 Other additions

• Takeoff cues on plain GPIO buzzers. Pre-launch audio cues previously only worked on boards with a PWM/ALARM ToneAlarm output. Boards that only have a simple on/off GPIO buzzer now get the same cues, with three cadences chosen to stay distinguishable by ear: slow lone beeps = raise throttle, medium double-beeps = spooling to idle, fast continuous = ready to launch (repeats until you throw).

The other v1.1 board change — re-enabling AP_Mount on AtomRCF405NAVI — applies only to that 1 MB F4 board and ships in light-v1.1. The full variant already has every mount backend compiled in.

🐞 Fixes

• Takeoff cues could arrive up to 3.3 s late. The pre-launch cues were queued behind the notify layer's minimum-separation guard, which enforces a gap of 32 bits × 100 ms + 100 = 3300 ms between patterns. A cue announcing "ready to launch" could therefore sound well after a hand launch had already happened — worse than useless, since it invites a throw at the wrong moment. State-change cues now bypass the guard and fire immediately. The repeating launch-ready cue deliberately stays behind it: update() runs at 50 Hz, so preempting there would reset the pattern every 20 ms and the buzzer would sit on one solid tone.

• TAKEOFF mode latched a stale climb target — airframes with an airspeed sensor only. ModeTakeoff::navigate() wrote the pilot-adjustable target altitude back into the loiter waypoint unconditionally, from the moment the mode started, before that value had been seeded off the loiter waypoint. Entering TAKEOFF from FBWB could therefore latch the climb target at ground level, so the plane levelled off almost immediately instead of climbing to TKOFF_ALT. Airframes without an airspeed sensor were unaffected, because their climb is pitch-driven (TKOFF_LVL_PITCH) rather than TECS-driven. The write-back is now gated on the altitude having been seeded.

Docs

• MNT1_TYPE=7 documented for non-stabilised head-track servos.
• FrSky Ethos sound path added to the Yaapu Course Hold install table.
• F4 EKF3/RAM section rewritten around allocation order (logger → terrain → EKF3), plus LOG_FILE_BUFSIZE as a RAM-headroom lever. (Applies to the F4 fleet on the light track; kept in the shared README.)

---

📡 Yaapu telemetry — Course Hold name + audio cue

Stock Yaapu doesn't know Plane mode 26, so Course Hold shows as a blank chip with no audio cue. The two non-firmware files attached below fix that — no need to clone the repo:

• plane.lua — replace Yaapu's copy under WIDGETS/yaapu/ (EdgeTX widget install), then delete the plane.luac sitting next to it (compiled cache, regenerates itself).
• coursehold.wav — copy into WIDGETS/yaapu/sounds/en/ (use your language folder if not English).

⚠️ Right name but no sound? The WAV is in a folder Yaapu isn't reading — the mode name and the sound file are looked up separately, so the HUD text can work while the cue silently doesn't. The folder depends on your Yaapu build:

Build	coursehold.wav goes in
EdgeTX widget (TX16S)	WIDGETS/yaapu/sounds/en/
OpenTX / Horus script	SOUNDS/yaapu0/en/
FrSky Ethos	scripts/yaaputelemetry/audio/en/

None of these is EdgeTX's own SOUNDS/en/ folder, which is for Special Functions and unrelated to Yaapu.

📖 Full install notes, including the Yaapu GCS desktop tool and recording your own cue: Tools/yaapu-coursehold/README.md →

---

Fleet (3 boards)

Board	MCU / Flash	Free flash	Notes
MatekF765-Wing	F7 / 2 MB	519.4 KB	Matek F765-WING — most headroom in the fleet
MatekH743-bdshot	H7 / 2 MB	99.0 KB	Matek H743-WING, bidirectional DShot
KakuteH7-Wing	H7 / 2 MB	103.5 KB	Holybro Kakute H743 Wing

Which file do I flash?

Each <board>_plane_bin_full-v1.1_.zip contains four build products. Two of them are flashable:

File	Use it when
arduplane.apj	Normal upgrade. Load it from MissionPlanner / QGC → "Load custom firmware" onto a board that already has a working ArduPilot bootloader. This is the usual path.
arduplane_with_bl.hex	The .apj won't take. Flash over DFU (board in bootloader mode — STM32CubeProgrammer, dfu-util, or MissionPlanner's DFU option). This writes the bootloader and the firmware, so it recovers a board whose bootloader is missing, stale, or the wrong family.
arduplane / arduplane.bin	ELF and raw binary, for debugging and toolchain use. Not for GCS flashing.

💡 If the .apj is rejected or the flash fails, go straight to arduplane_with_bl.hex over DFU. Confirmed on KakuteH7-Wing with this release: the .apj would not flash, the _with_bl.hex worked first try. Boards that shipped with Betaflight, or that have been moved between firmware families, are the usual candidates — their on-board bootloader isn't the one the .apj path expects.

---

📖 **Full feature & parameter reference — [README_CUS...

ArduPlane Custom Build — Light Variant — v1.0

🪶 Light variant — a stripped-down build that fits 1 MB F4 boards. First non-beta release, built on ArduPlane 4.6.3; everything stock 4.6.3 does still applies underneath the ArduCustom additions.

📖 Full feature & parameter reference: README_CUSTOM.md (light variant)
🔧 Full variant (H7 / 2 MB, every backend compiled in): full-v1.0 release →

Firmware version string: ArduPlane V4.6.3 ArduCustom v1.0 Light (67c82ad) — 67c82ad is the git short-hash the binaries were built from (the source tag carries a few later docs-only commits).

New in v1.0

• RTL Autoland Commit (RCx_OPTION 251) — hold over home until you flip a switch, then commit to the landing sequence; RTL_AUTOLAND_DLY adds a failsafe grace timer.
• Walksnail Headtracking via MSP and Serial Gimbal — point a camera gimbal with your head. Head-tracker angles arrive over the MSP DisplayPort link and drive the mount. Works with CADDXFPV GM-series serial gimbals (GM1/GM2/GM3) or a PWM servo. RC switches for head-tracking enable + centre/FPV-lock, plus the Walksnail Goggles X Gimbal Lock button. Implements MSP2_SENSOR_HEADTRACKER similar to how iNav implements it — credit and thanks to mmosca and the iNav project.
• Plus code (OLC) OSD element now ships on every board.

📡 Yaapu telemetry — Course Hold name + audio cue

Stock Yaapu doesn't know Plane mode 26, so Course Hold shows as a blank chip with no audio cue. The two non-firmware files attached below fix that — no need to clone the repo:

• plane.lua — replace Yaapu's copy under WIDGETS/yaapu/ (EdgeTX widget install), then delete the plane.luac sitting next to it (compiled cache, regenerates itself).
• coursehold.wav — copy into WIDGETS/yaapu/sounds/en/ (use your language folder if not English).

⚠️ Right name but no sound? The WAV is in a folder Yaapu isn't reading — the mode name and the sound file are looked up separately, so the HUD text can work while the cue silently doesn't. The folder depends on your Yaapu build:

Build	coursehold.wav goes in
EdgeTX widget (TX16S)	WIDGETS/yaapu/sounds/en/
OpenTX / Horus script	SOUNDS/yaapu0/en/
FrSky Ethos	scripts/yaaputelemetry/audio/en/

None of these is EdgeTX's own SOUNDS/en/ folder, which is for Special Functions and unrelated to Yaapu.

📖 Full install notes, including the Yaapu GCS desktop tool and recording your own cue: Tools/yaapu-coursehold/README.md →

Fleet (11 boards)

MatekF765-Wing · KakuteH7-Wing · KakuteF4-Wing-Buzz · MatekF405-STD · AtomRCF405NAVI · MatekF405-TE-bdshot · MatekF405-Wing-bdshot · omnibusf4pro · SpeedyBeeF405WING · SpeedyBeeF405WING-Buzz · speedybeef4v3

Each <board>_plane_bin_light-v1.0_.zip contains: arduplane, arduplane.apj, arduplane.bin, arduplane_with_bl.hex.

ArduCustom Full v1.0

Full variant — compiles every hardware backend; runs on H7 / 2 MB boards. First non-beta release, built on ArduPlane 4.6.3; everything stock 4.6.3 does still applies underneath the ArduCustom additions.

📖 Full feature & parameter reference: README_CUSTOM.md (full variant)
🪶 Light variant (fits 1 MB F4 boards): light-v1.0 release → — 1 MB F4 boards overflow the full build, so flash those from light.

Firmware version string: ArduPlane V4.6.3 ArduCustom v1.0 (327ab6c) — 327ab6c is the git short-hash the binaries were built from (the source tag carries a few later docs-only commits).

New in v1.0

• RTL Autoland Commit (RCx_OPTION 251) — hold over home until you flip a switch, then commit to the landing sequence; RTL_AUTOLAND_DLY adds a failsafe grace timer.
• Walksnail Headtracking via MSP and Serial Gimbal — point a camera gimbal with your head; angles arrive over the MSP DisplayPort link and drive the mount. On the full build it drives any ArduPilot gimbal backend (Siyi, SToRM32-serial, Topotek, Viewpro, CADDX, servo, …). Implements MSP2_SENSOR_HEADTRACKER similar to how iNav implements it — credit and thanks to mmosca and the iNav project.
• Plus code (OLC) OSD element.

📡 Yaapu telemetry — Course Hold name + audio cue

Stock Yaapu doesn't know Plane mode 26, so Course Hold shows as a blank chip with no audio cue. The two non-firmware files attached below fix that — no need to clone the repo:

• plane.lua — replace Yaapu's copy under WIDGETS/yaapu/ (EdgeTX widget install), then delete the plane.luac sitting next to it (compiled cache, regenerates itself).
• coursehold.wav — copy into WIDGETS/yaapu/sounds/en/ (use your language folder if not English).

⚠️ Right name but no sound? The WAV is in a folder Yaapu isn't reading — the mode name and the sound file are looked up separately, so the HUD text can work while the cue silently doesn't. The folder depends on your Yaapu build:

Build	coursehold.wav goes in
EdgeTX widget (TX16S)	WIDGETS/yaapu/sounds/en/
OpenTX / Horus script	SOUNDS/yaapu0/en/
FrSky Ethos	scripts/yaaputelemetry/audio/en/

None of these is EdgeTX's own SOUNDS/en/ folder, which is for Special Functions and unrelated to Yaapu.

📖 Full install notes, including the Yaapu GCS desktop tool and recording your own cue: Tools/yaapu-coursehold/README.md →

Fleet (3 boards)

MatekF765-Wing · MatekH743-bdshot · KakuteH7-Wing

Each <board>_plane_bin_full-v1.0_.zip contains: arduplane, arduplane.apj, arduplane.bin, arduplane_with_bl.hex.

ArduPlane Custom Build — Light Variant — v0.3-beta

🪶 ArduCustom Light v0.3-beta

Lightweight ArduPlane 4.6.3 build for flash-constrained F4 flight controllers. Feature-identical to light-v0.2-beta — the single change in this release is serial port numbering matched to chip UART numbers.

🛠️ Which variant do I want? This is the Light build — rarely-used backends are stripped so it fits 1 MB F4 flight controllers (the full build overflows their flash). Running an H7 / 2 MB board, or want every hardware backend compiled in? Use the Full variant — full-v0.3-beta instead.

🔄 Built 2026-07-11 from f345f9a on master_custom_4.6.3_light. Onboard version string reports ArduCustom v0.3-beta Light.

What's new in v0.3-beta

Serial port numbering matched to chip UART numbers

On boards whose stock ArduPilot SERIAL_ORDER was scrambled, SERIALn now equals the silkscreen UARTn pad again — restoring the mapping that shipped in ArduCustom custom-v11.3 and earlier. The pad marked TX2/RX2 is SERIAL2 (not SERIAL6), TX3/RX3 is SERIAL3, and so on. This removes the long-standing mismatch (e.g. wiring an ELRS receiver to the RX2/TX2 pads and finding it on SERIAL6).

Light-fleet boards affected:

Board	New SERIAL_ORDER
MatekF405-TE-bdshot	OTG1 USART1 USART2 USART3 UART4 UART5 USART6
MatekF405-STD	OTG1 USART1 USART2 USART3 UART4 UART5
omnibusf4pro	OTG1 USART1 EMPTY USART3 UART4 EMPTY USART6

omnibusf4pro has no USART2 / UART5, so SERIAL2 / SERIAL5 are EMPTY placeholders that keep USART3=SERIAL3 and USART6=SERIAL6 aligned. The other five light boards already numbered cleanly and are unchanged (version bump only).

Like v11.3, this is a SERIAL_ORDER-only change — no serial protocol defaults were added — so ports fall on the stock per-index defaults (S1/S2 MAVLink, S3/S4 GPS, rest off). Set SERIALx_PROTOCOL to match your wiring.

⚠️ Upgrade warning. If you are moving from light-v0.2-beta on MatekF405-TE-bdshot, MatekF405-STD, or omnibusf4pro, your saved SERIALx_PROTOCOL / _BAUD / _OPTIONS values now point at different physical UARTs. Re-check your serial config after flashing — GPS, telemetry and RC (CRSF/ELRS) may need reassigning to the new SERIALn.

Example — ELRS on the MatekF405-TE-bdshot RX2/TX2 pads is now SERIAL2 (SERIAL2_PROTOCOL 23, BRD_ALT_CONFIG 1 for CRSF), no longer SERIAL6.

Everything else carries forward unchanged from light-v0.2-beta — see those notes or README_CUSTOM.md for the full feature set.

Fleet (9 boards)

Remapped: MatekF405-TE-bdshot, MatekF405-STD, omnibusf4pro.
Unchanged numbering (version bump only): speedybeef4v3, SpeedyBeeF405WING, SpeedyBeeF405WING-Buzz, MatekF405-Wing-bdshot, KakuteF4-Wing-Buzz, KakuteH7-Wing.

ℹ️ KakuteH7-Wing is an H7 / 2 MB board (also carried on the full-v0.3-beta release) — included in the light fleet here for convenience; it has ample flash for either variant.

Flashing

Each <board>_plane_bin_light-v0.3-beta_.zip contains arduplane.apj (flash via MP/QGC), arduplane.bin (DFU), arduplane_with_bl.hex (first-time DFU), and arduplane (ELF, debug only). The coursehold.wav + plane.lua assets are the Yaapu Telemetry Course-Hold files (unchanged); see Tools/yaapu-coursehold/README.md.

ArduCustom Full v0.3-beta

🛠️ ArduCustom Full v0.3-beta

ArduPlane 4.6.3 full-backend build for H7 / 2 MB targets. Feature-identical to full-v0.2-beta — the single change in this release is serial port numbering matched to chip UART numbers.

🪶 Which variant do I want? This is the Full build — every upstream hardware backend compiled in, for boards with the flash headroom (H7 / 2 MB). Flashing a 1 MB F4 board, or don't need every backend? Use the Light variant — light-v0.3-beta instead; it strips rarely-used backends to fit flash-constrained F4 FCs (the full build overflows 1 MB flash on those boards).

🔄 Built 2026-07-11 from 5d0669a on master_custom_4.6.3. Onboard version string reports ArduCustom v0.3-beta.

What's new in v0.3-beta

Serial port numbering matched to chip UART numbers

On boards whose stock ArduPilot SERIAL_ORDER was scrambled, SERIALn now equals the silkscreen UARTn pad again — restoring the mapping that shipped in ArduCustom custom-v11.3 and earlier. The pad marked TX2/RX2 is SERIAL2 (not SERIAL6), TX3/RX3 is SERIAL3, and so on.

Full-fleet board affected — MatekH743-bdshot:
SERIAL_ORDER → OTG1 USART1 USART2 USART3 UART4 EMPTY USART6 UART7 UART8 OTG2

KakuteH7-Wing is intentionally left on upstream numbering (it was never remapped in v11.3, and its connectors are labelled functionally rather than by chip UART number).

Like v11.3, this is a SERIAL_ORDER-only change — no serial protocol defaults were added — so ports fall on the stock per-index defaults (S1/S2 MAVLink, S3/S4 GPS, rest off). Set SERIALx_PROTOCOL to match your wiring.

⚠️ Upgrade warning. If you are moving from full-v0.2-beta on MatekH743-bdshot, your saved SERIALx_PROTOCOL / _BAUD / _OPTIONS values now point at different physical UARTs. Re-check your serial config after flashing — GPS, telemetry and RC may need reassigning to the new SERIALn.

Everything else carries forward unchanged from full-v0.2-beta.

Boards

Board	Notes
MatekH743-bdshot	Matek H743-WING (bidirectional DShot) — serial numbering remapped
KakuteH7-Wing	Holybro Kakute H743 Wing — numbering unchanged

Flashing

Each <board>_plane_bin_full-v0.3-beta_.zip contains:

• arduplane.apj — upload via Mission Planner / QGC / MAVProxy (the usual path)
• arduplane.bin — raw image for DFU / bootloader tools
• arduplane_with_bl.hex — image with bootloader, for first-time DFU flashing
• arduplane — ELF with debug symbols (crash analysis only, not for flashing)

ArduCustom Full v0.2-beta

🛠️ ArduCustom Full v0.2-beta

The full variant of the ArduPlane 4.6.3 fork — every upstream hardware
backend compiled in, plus the complete ArduCustom + fork feature set.
This is the counterpart to the flash-stripped light release:
identical fork features, but nothing removed to save flash, so it targets
H7 / 2 MB boards with room to spare.

ℹ️ Full vs light — how to tell them apart. The onboard version string
is the tell: the full build reports ArduPlane V4.6.3 ArduCustom v0.2-beta (<hash>);
the light build appends Light. Both carry the same parameters and
features — they differ only in which hardware backends (GPS / RC / battery
/ rangefinder / airspeed / CAN …) are compiled in. If your board has
≤ 1 MB flash, use the light release instead — the full build overflows 1 MB F4.

Boards in this release

Built from 7aad7f5,
the full-variant mainline (master_custom_4.6.3):

Board	MCU / Flash	Free flash (full)	Notes
MatekH743-bdshot	H7 / 2 MB	~101 KB	Matek H743-WING, bidirectional DShot
KakuteH7-Wing	H7 / 2 MB	105.3 KB	Holybro Kakute H743 Wing

Each asset is <board>_plane_bin_full-v0.2-beta_.zip containing the four
build products: arduplane, arduplane.apj, arduplane.bin,
arduplane_with_bl.hex. Flash the .apj via Mission Planner / QGC as a
normal firmware update.

Features

Same fork feature set as the light release — wind-aware landing selection
(LAND_WIND_BIAS / LAND_WIND_DIST / LAND_WIND_STRICT), the failsafe
emergency-landing state machine (FS_ELAND_*), Course Hold, auto-trim, the
OSD element suite, takeoff idle throttle, and the rest. See
README_CUSTOM.md
on the full branch for the complete list.

The full variant additionally keeps every upstream hardware backend that
the light variant strips: all GPS / RC / battery / rangefinder / airspeed
drivers, CAN / DroneCAN, ADSB, EFI, and the rest. If you need a backend that
isn't in the light build and your board has the flash for it, this is the
release to use.

Notes

• KakuteH7-Wing was intentionally left out of the light fleet (it's a
  2 MB H7, outside light's "tight 1 MB F4" focus) — it belongs here, where
  the extra flash is an asset rather than overkill.
• Both boards link with ~100 KB free, so there's comfortable headroom for
  future feature growth on the full track.
• This is the first full-variant release; the light track is at
  light-v0.2-beta.

ArduPlane Custom Build — Light Variant — v0.2-beta

🪶 ArduCustom Light v0.2-beta

A lightweight ArduPlane 4.6.3 build for flash-constrained F4 flight controllers. Carries forward the ArduCustom v11.3e feature set plus the fork-specific additions from v0.1-beta.

This release is a feature-additive update to v0.1-beta — same base capabilities, plus wind-aware landing-selection controls and a validated radar stack. If you were running v0.1-beta, the parameter set is a strict superset (nothing removed or renamed), so you can flash and keep flying with your existing tuning.

🔄 Assets rebuilt 2026-07-03 — all five firmware zips rebuilt from eb1873b61c. This is a build-hygiene rebuild only — no flight-behavior change vs the 2026-07-02 assets. It folds in two CI-caught fixes: an AP_GPS single-instance compile guard (the 1-GPS light config tripped clang's array-bounds check on an unreachable code path), and AP_Radar switched to NEW_NOTHROW so the throwing operator new is dropped from the binary. Every feature below is unchanged, so if you already flashed a 2026-07-02 zip you do not need to re-flash for any functional reason. The onboard version string reports v0.2-beta.

_{Earlier rebuild — 2026-07-02, from 1b129e4313: added pilot control of loiter radius/direction (ArduCustom PR #180), the Course Hold throttle-to-pitch compensation restore, two FS_ELAND emergency-landing glide fixes, and the LAND_WIND_STRICT parameter-registration fix — all present in the current build.}

➕ Added 2026-07-04 — SpeedyBeeF405WING-Buzz — a hardware-tone-buzzer variant of SpeedyBeeF405WING (S11/PB15 remapped to TIM12_CH2 + ALARM, so ArduPilot tunes play on a passive buzzer instead of the DShot ESCs; costs servo output 11). Built from 55f575e074 rather than the eb1873b61c of the other five zips, but the commits between those two are CI/autotest/SITL/docs only plus the new board's hwdef — no flight-behavior change vs the rest of the fleet. Its version string reports ... Light (55f575e). Flashes over the stock SpeedyBee bootloader (board ID 1106) as a normal update.

➕ Added 2026-07-05 — two more light boards, plus code (OLC) removed — (1) MatekH743-bdshot, the Matek H743-WING (bidirectional DShot); ~305 KB free flash. (2) KakuteF4-Wing-Buzz, a hardware-tone-buzzer variant of the Kakute F4 Wing — which ships no buzzer — with a passive buzzer on the WS2812 LED pad (PA1 remapped TIM5_CH2 → TIM2_CH2 + ALARM; costs the LED-strip output, no servo/motor output). Both built from ebe3833df4 and report ... Light (ebe3833). This commit also drops the plus code (OLC) OSD element fork-wide — low demand per a user survey: the OSDx_PLUSCODE_* panel is compiled out on all boards and OSD_OPTIONS bit 23 (ShortenPluscode) is removed from the bitmask. No change to the existing five F4 assets (plus code was already off on 1 MB F4) — you do not need to re-flash them.

➕ Added 2026-07-10 — omnibusf4pro — the Omnibus F4 Pro, a stock upstream 1 MB F405 FPV flight controller (MPU6000/BMI270 IMU, BMP280 baro, onboard 7456-series OSD). No fork hwdef work was needed — it already pulls in minimize_fpv_osd.inc. ~41.6 KB free flash on light (940,436 B of 1 MB used), mid-pack in the F4 fleet. Built from 0db8004 and reports ... Light (0db8004). No change to any existing asset.

⚠️ Known gotcha — EK3 sources require VisualOdom prearm. VisualOdom / external-nav is compiled out on 1 MB F4 boards by upstream's BOARD_FLASH_SIZE > 1024 gate — not a light strip (it's absent on stock ArduPlane and the full variant too on the same board). If a saved parameter has EK3_SRCx_* = ExternalNav, you'll hit this prearm. Fix: set those sources off ExternalNav — use RangeFinder (value 2, e.g. EK3_SRC1_POSZ = 2) for a downward-lidar height source, or the GPS/Baro/Compass defaults. A Benewake TFmini is a rangefinder (fully supported on light), not external nav — only the ExternalNav source value needs the absent VisualOdom backend.

---

What's new since v0.1-beta

Wind-aware DO_LAND_START selection — LAND_WIND_DIST and LAND_WIND_STRICT

LAND_WIND_BIAS (v0.1-beta) let the autopilot prefer landings whose approach faces into wind, but on missions with DO_LAND_START items spread over a wide area a strong bias could pull the plane toward a much farther landing purely for wind alignment. On battery-marginal RTL, that extra travel can cost you the airframe. This release adds two companion params:

• LAND_WIND_DIST (metres, default 0 = no cap) — hard distance ceiling. Any DO_LAND_START whose start-of-approach sits farther than this many metres from the plane's decision-time position is excluded from selection. The wind bias then picks only from within-cap survivors.

  • Under RTL_AUTOLAND=1, the cap is effectively measured from HOME (plane loiters there before the pick).
  • Under RTL_AUTOLAND=2 / battery FS / GCS DO_LAND_START, the cap is measured from wherever the plane is when the trigger fires.

• LAND_WIND_STRICT (0/1, default 0) — chooses what happens when LAND_WIND_DIST eliminates every candidate:

  • 0 (soft fallback) — fall through to upstream nearest-across-all so the plane still attempts a landing. Preserves the failsafe safety net at the cost of occasionally flying outside the cap.
  • 1 (hard fence) — refuse the autoland; RTL/failsafe stays in RTL and the plane loiters at HOME/rally requiring pilot intervention. ⚠️ Under strict mode, a battery failsafe with no in-cap landing will not attempt to land — the plane loiters until the battery dies. Only enable if you can take manual control on failsafe.

Both params ship as Standard-user parameters and are visible in the GCS parameter tree. Default values preserve pre-existing v0.1-beta behaviour bit-for-bit — nothing changes until you set them.

See README_CUSTOM.md sections LAND_WIND_DIST and LAND_WIND_STRICT for the full behaviour table, worked examples, and the safety trade-off.

Pilot control of loiter radius and direction — LOITER & RTL (added in the 2026-07-02 rebuild)

Port of ArduCustom PR #180 (shellixyz). In LOITER and RTL, once the plane is established in the loiter circle:

• Rudder stick past half deflection left/right — snap loiter direction counter-clockwise / clockwise.
• Roll stick grows or shrinks the loiter radius at 20 m/s (direction-aware, so pushing "outward" always grows the radius), clamped to 20–1000 m.

On mode entry the radius/direction seed from WP_LOITER_RAD (LOITER) or RTL_RADIUS with WP_LOITER_RAD fallback (RTL). The helper is disabled during RC failsafe so the emergency-landing state machine (FS_ELAND_LOTRAD, wings-level glide) keeps exclusive ownership of the loiter geometry. No parameter to enable — it's always on in LOITER/RTL outside RC failsafe. See README_CUSTOM.md § Pilot control of loiter radius and direction for the full input map.

Bug fixes in the 2026-07-02 rebuild

• LAND_WIND_STRICT parameter registration — the parameter used an out-of-range index (64) which could panic at parameter-table setup. Fixed index; the param now registers cleanly.
• Course Hold — restored the mf0o/shellixyz throttle-to-pitch compensation (pitch-up compensation fades to zero as throttle approaches TRIM_THROTTLE).
• FS_ELAND glide engagement (two fixes) — update_control_mode() no longer stomps the TECS gliding-requested flag every fast-loop tick during RC failsafe (it pinned the plane at FS_ELAND_GLDALT with ~48 % throttle instead of gliding), and the flag is now cleared once on failsafe entry so a stale pilot-throttle-zero latch can't start the glide prematurely from RTL cruise. Net behaviour: TECS sinks to FS_ELAND_GLDALT at normal throttle, holds altitude through the upwind alignment, then wings-level glides to touchdown — and this now works regardless of FLIGHT_OPTIONS bit 23.

Peer-aircraft radar — bench-verified end-to-end

v0.1-beta shipped the radar stack (AP_Radar library, MSP backend, OSD widget) with a "radar under test" caveat. v0.2-beta promotes it to verified: peer detection was tested on real hardware (SpeedyBee F405 WING + a FormationFlight ESP32 module), the OSD element draws correctly once both planes have GPS lock, and formation-side ESP32s see us in the FormationFlight web UI without any fork-specific firmware on their side. Same code, same parameters — just now with a bench-test data point behind it.

Fleet change

v0.2-beta launched with 5 boards (down from 6 in v0.1-beta) and has since grown to 9 via post-launch additions — see the dated ➕ notes at the top of these release notes:

Board	Free flash	Status
MatekH743-bdshot	305 KB	➕ Added 2026-07-05 — Matek H743-WING (H7, not F4)
KakuteF4-Wing-Buzz	81.3 KB	➕ Added 2026-07-05 — HW-buzzer variant of Kakute F4 Wing
speedybeef4v3	53.4 KB	Ships — most F4 headroom
MatekF405-STD	47.0 KB	⭐ New in v0.2-beta
MatekF405-TE-bdshot	42.5 KB	Ships
omnibusf4pro	41.6 KB	➕ Added 2026-07-10 — Omnibus F4 Pro (stock upstream FPV FC)
SpeedyBeeF405WING	29.7 KB	Ships
SpeedyBeeF405WING-Buzz	29.2 KB	➕ Added 2026-07-04 — HW-buzzer variant of SpeedyBeeF405WING
MatekF405-Wing-bdshot	27.6 KB	Ships — canary (tightest F4)

• Added at launch: MatekF405-STD as a standard (non-bdshot) alternative in the F4 lineup with ~47 KB free.
• Added post-launch: SpeedyBeeF405WING-Buzz (0...

ArduPlane Custom Build — Light Variant — v0.1-beta

🪶 ArduCustom Light v0.1-beta

A lightweight ArduPlane 4.6.3 build carrying forward the ArduCustom v11.3e feature set while introducing several new capabilities not available in either ArduCustom v11.3e or official ArduPlane.

This release is optimized for flash-constrained F4 flight controllers using the strict "Light" build philosophy, removing seldom-used hardware backends and protocols while preserving the features most commonly used by FPV and long-range fixed-wing pilots.

---

Carried Forward from ArduCustom v11.3e

This release includes many of the features that made ArduCustom popular among FPV and long-range fixed-wing pilots:

• Course Hold flight mode (ground-track hold)
• Auto Trim flight mode
• FLTMODE_EXT 12-position flight mode selection
• Emergency landing failsafe state machine
• AUTO → FBWA stick takeover
• Manual airspeed control in navigation modes
• RTL manual altitude control
• Arm-switch throttle-cut safety behavior
• Servo auto-trim enhancements
• Advanced OSD functionality and flight statistics grid
• Watt-hour battery monitoring and energy-based failsafes
• Multi-parameter RC tuning workflow
• Enhanced telemetry features (CRSF, MSP, FrSky)
• TECS tuning and throttle-control enhancements

Yaapu Telemetry Script Course Hold support

To enable the coursehold call out and flight mode ID, follow the instructions here:
https://github.com/erwinquilloy/ardupilot/blob/master_custom_4.6.3_light/Tools/yaapu-coursehold/README.md

Auto Trim Flight Mode (Mode 27)

Auto Trim combines Course Hold's locked ground-track behavior with the servo auto-trim system.

While flying, the pilot can make small pitch and roll corrections using the sticks while the firmware gradually accumulates trim adjustments into the saved servo trims. This eliminates the need to land between trim iterations.

Key features:

• Locked ground-track navigation similar to Course Hold
• Background servo auto-trim while flying
• Trim results are written directly into saved servo trims
• Exiting the mode immediately stops auto-trim accumulation
• Uses the existing SERVO_AUTO_TRIM and SAT_FINISHTHRESH parameters
• Shares Course Hold's CRUISE_YAW_RATE behavior
• Supports yaw-stick steering of the locked course through FLIGHT_OPTIONS bit 20

Enable:

FLTMODE_n = 27

or assign it to any of the additional FLTMODE_EXT slots (7–12).

RC Aux Switch Support

The firmware adds dedicated RC auxiliary functions for AutoTrim and AutoTune so pilots don't have to consume a flight-mode slot.

RCx_OPTION = 17 — AUTOTUNE Mode

Entering the switch HIGH position automatically places the aircraft into Plane AUTOTUNE flight mode.

Unlike RCx_OPTION = 107 (FW_AUTOTUNE), this changes the aircraft's flight mode rather than simply enabling the autotune logic.

RCx_OPTION = 200 — Servos Auto Trim

Allows servo auto-trim to be started and stopped from a momentary or latching switch.

When switched HIGH:

• Starts a fresh auto-trim session
• Resets previous auto-trim accumulation
• Continues operating in the current flight mode (FBWA, CRUISE, RTL, etc.)
• Does not switch into Auto Trim mode

When switched LOW:

• Stops auto-trim accumulation

Ground control stations display status messages such as:

Servos auto trim started
Servos auto trim stopped

RCx_OPTION = 200 matches the mf0o implementation, allowing parameter compatibility with existing mf0o-based builds.

---

New Features Not Available in ArduCustom v11.3e or Official ArduPlane

⭐ LAND_WIND_BIAS

Wind-aware landing-sequence selection for missions containing multiple DO_LAND_START options.

Instead of always choosing the nearest landing sequence, the aircraft can bias selection toward the most favorable headwind approach, improving autonomous landing decisions in windy conditions.

⭐ FormationFlight / ESP32-INAV-Radar Support

Integrated peer-aircraft radar support compatible with:

• FormationFlight
• ESP32-INAV-Radar

Displays nearby aircraft directly on the OSD using MSP radar messages, enabling formation flying and aircraft awareness without MAVLink-based tracking systems.

⭐ PTCH_TRIM_DEG RC Knob Tuning

PTCH_TRIM_DEG can now be assigned directly to the RC tuning knob via:

TUNE_PARAM = 59

This enables in-flight pitch-trim adjustment without opening a GCS and was not available in ArduCustom v11.3e or upstream ArduPlane.

---

What You Gain Over Official ArduPlane 4.6.3

Compared to stock ArduPlane 4.6.3, this firmware provides:

• Course Hold flight mode
• Auto Trim flight mode
• FLTMODE_EXT 12-position mode selection
• AUTO → FBWA stick takeover
• Emergency landing failsafe system
• Manual RTL altitude control
• Manual airspeed control in navigation modes
• RC-switch AutoTrim and AutoTune support
• Wind-aware landing selection
• Advanced battery-energy monitoring
• Expanded flight statistics system
• Enhanced OSD functionality
• FormationFlight / ESP32-INAV-Radar support
• PTCH_TRIM_DEG RC knob tuning

---

Light Variant

The Light build follows the strict 2022 lightweight philosophy and maximizes flash headroom on F4 targets by removing less commonly used hardware backends and protocols.

Included

• UBLOX GPS
• SBUS
• CRSF / ELRS
• IBUS
• FPORT / FPORT2
• Analog airspeed sensors
• MS4525 airspeed sensors
• Benewake rangefinders
• EKF3

Removed

• DroneCAN / CAN support
• Multiple GPS support
• Multiple compass support
• DSM
• SRXL / SRXL2
• SUMD
• ST24
• GHST
• MAVRadio
• Most GPS backends
• Most battery-monitor backends
• Most rangefinder backends
• Most airspeed backends
• ICE engine support
• PiccoloCAN ESC support

Important:

• DroneCAN peripherals are not supported in the Light build.
• DLVR/MS5525 digital I²C airspeed sensors require the full build.

---

Validated Boards

This release has been actively tested and validated on:

• MatekF405-Wing
• MatekF405-TE-bdshot
• SpeedyBeeF405Wing
• SpeedyBeeF405V3
• LongBowF405Wing
• Holybro KakuteH7-Wing

---

Documentation

Full documentation is available in:

📖 https://github.com/erwinquilloy/ardupilot/blob/master_custom_4.6.3_light/README_CUSTOM.md

Including:

• Full feature documentation
• Parameter reference links
• OSD setup guides
• Emergency landing configuration
• Flight-mode descriptions
• FormationFlight / ESP32-INAV-Radar setup
• Battery-management extensions
• Migration notes from upstream ArduPlane

---

Version

ArduPlane V4.6.3 ArduCustom v0.1-beta Light

Built on ArduPlane 4.6.3 with the ArduCustom v11.3e feature set, plus additional functionality developed specifically for this fork.