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. Confirmed on KakuteH7-Wing with the matching full-v1.1 build: 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_CUSTOM.md (light variant)
🔀 Other track — full-v1.1 release →
🐞 Issues or questions — open an issue