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_CUSTOM.md (full variant)
🔀 Other track — light-v1.1 release →
🐞 Issues or questions — open an issue