# TerraHawk flight parameters: the airframe. Load last. Values measured on the aircraft: calibrations and the
# elevon linkage. One airframe (Ryan, 2026-10-04; airframe-A.parm and airframe-B.parm were one file each for two
# airframes). Every value below is a placeholder until measured; the procedure for each is on the right.

# Measured CG (267 to 270 mm aft of the nose datum on Fuselage C, aim 268; params/README.md):
#   with the Tattu 4500: ___ mm   with the P50B 6S2P: ___ mm   date: ____

# Board level in the aircraft's FC cradle: accelerometer level calibration with the airframe level.
AHRS_TRIM_X       0
AHRS_TRIM_Y       0
# Airspeed ratio on Fuselage C v2.4B (th-aeronautics, 2026-10-18; coarse CFD, ESTIMATE; the tables are in
# aero/airspeed/static-cp-c-v24b.json, 6bbf590f). The flush side static ports
# (Y 40, Z -10, both sides, teed to the MS4525's static nipple) sit in a compression zone whose Cp climbs steeply
# with alpha: +0.08 at alpha 0, +0.22 at 3, +0.34 at 6.7, +0.39 at 9.5, +0.40 at 12.5, +0.39 at 14. So no single ratio
# reads true at both ends, and the low-alpha end is the dangerous one: a forward transition flies the wing at alpha 0.5
# to 1.5 deg until "Transition airspeed reached" (SITL 20261012T044346Z), and ArduPlane ends the airspeed wait when
# EAS passes AIRSPEED_MIN (quadplane.cpp:1522). Indicated 18 there is about true at 2.3, 16.7 to 17.1 m/s true at 2.6,
# and 15.8 to 16.2 at 2.9, the trimmed stall. Keep 2.3: about true at the transition end and low (slow-reading)
# everywhere else (13 % low at cruise, 17 % low near the stall), so the aircraft flies faster than it shows.
# SITL with a sensor that reads through this Cp(alpha) table (th-simulator SIM_ARSPD_CP, th-testpilot 5a04a88a, 47
# flights): at 2.3 the transition ends at 18.2 to 20.2 m/s true (2.9: 16.3 to 17.4). The table stops at alpha 0, and if
# Cp falls further below it the real end is a little earlier: at 2.3 by under 1 % of speed (alpha was -0.3 deg or more
# where indicated passed 18), more at 2.9. The wing stalls at the same true
# speed in every case, so the ratio moves the display, not the stall; 2.3 costs about 7.5 % more energy in the survey.
# AIRSPEED_MIN is 20 since 2026-10-18 (terrahawk-common.parm, th-simulator 7a2d664c): on the C model no transition then
# ends under 18 m/s true (th-testpilot 1d51b2d9); at 18, 19 % did.
# The total source since W104 (th-blender 888383ba, 2026-10-19): our own brass tube beside the camera, total only, an
# open bevelled mouth with a 30 deg internal chamber, 7 deg tip down; the static stays on the Y 40 ports. At its mouth
# the flow is within about +-17 deg of the tube axis through alpha 14 (-16.4 to +16.3 in pitch, about 16.7 with the yaw) and Cpt is 0.988 to 0.990 (th-aeronautics e68dc651),
# inside the mouth's +-23 deg acceptance, so total reads about 0.5 % low in airspeed; with the lift rotors on, the
# transition end moves about 0.5 % (9789b957). So 2.3 stands. (W93.2's kit tube, 60f05e70, is retired.)
# Recompute this row whenever the nose or the ports change.
ARSPD_RATIO       2.3
# Do NOT run the in-flight airspeed calibration on these ports: in cruise circles at 21 m/s (alpha about 6.5) it
# converges near 3.0, which ends the transition below the stall (above). A filed row, so the checklist code catches
# a 1 left on.
ARSPD_AUTOCAL     0
# Elevons: reversal from the bench check (guide step 4), endpoints for 25 degrees of travel
# (docs/cg.md). Trim: before the first transition, set the predicted cruise trim from docs/cg.md's
# 'up elevon to trim' at the aircraft's measured CG and 22 m/s, at 16 us per degree (400 us is 25
# degrees), toward up. A transition that starts out of trim sags much deeper (th-simulator,
# 2026-09-28). SERVO_AUTO_TRIM then refines it in flight; copy the learned values back here.
# On Fuselage C with our own wing the predicted level trim at 22 m/s indicated (24.3 true, ARSPD_RATIO 2.3) is about
# 4.8 deg trailing edge up at alpha 4.65, 3.034 kg and CG 268 (th-aeronautics 086d1330, aero/wing-own/c24b-level.json,
# ESTIMATE), so about 77 us toward up: cg.md's first-build table, the 22 m/s indicated row (4aeeb934), not the earlier
# wing's table under it (about 7.7 deg). Which
# way "up" moves the pulse is known only after the bench reversal check, so the rows stay 1500 until then.
# The output numbers belong to the board: 5 and 6 on the NxtPX4v2 (board-nxtpx4v2.parm, the first-flight board).
# On a board with the elevons on 7 and 8 (the 6C, our own FC), rename these rows; on the NxtPX4v2, 7 is the pusher
# and 8 the camera trigger. check_params.py refuses an elevon row on an output that is not an elevon.
SERVO5_REVERSED   0
SERVO5_MIN        1100
SERVO5_MAX        1900
SERVO5_TRIM       1500
SERVO6_REVERSED   0
SERVO6_MIN        1100
SERVO6_MAX        1900
SERVO6_TRIM       1500
# The flight compass is the QMC5883L in the SEQURE M10-25Q (GPS2, board file), the ONLY compass since 2026-10-15: the
# SEN0697 cannot be bought (Ryan, via th-blender). The Q43's QMC5883P stays off, because on v2.4B the PM02 sits on the
# beacon carrier about 32 mm from the Q43 (CLAUDE.md Fuselage row, th-telemetry's condition): DISBLMSK bit 20
# (QMC5883P) turns its driver off, so it can never be probed into compass 1. Bit 12 (QMC5883, the M10's chip) stays
# clear. The LUX F765 has no compass of its own. ArduPilot's QMC5883L driver already applies ROLL_180 for an external
# chip (AP_Compass_QMC5883L.h), the usual GPS-module build, so COMPASS_ORIENT starts at 0 for the module upright with
# its arrow forward, as th-blender's W52 hanger mounts it (6ac8c58e: upright, patch up, arrow forward; an arrow aft would be 4). The calibration may change it
# (COMPASS_AUTO_ROT 2, also the LUX's hwdef default); once first-flight step 11 confirms the signs by hand, the
# confirmed value replaces the 0 here.
COMPASS_DISBLMSK  1048576
COMPASS_ORIENT    0
# With one compass there is nothing to compare it against, so the EKF's GSF yaw estimator (yaw from GPS velocity and
# the IMU) stays on and may reset a bad magnetic yaw: run and use it on cores 1 and 2 (the defaults; filed because the
# sole-compass gate depends on them, th-telemetry M8, 20cf07d2). The one core of EK3_IMU_MASK 1 is core 1.
EK3_GSF_RUN_MASK  3
EK3_GSF_USE_MASK  3
COMPASS_AUTO_ROT  2
# Compass offsets: a full calibration on the aircraft once; after work near the compass, the fixed-yaw
# calibration as a check. The calibration writes COMPASS_OFS*, COMPASS_DIA*, COMPASS_ODI*.
# Current-based compensation for the battery feed, phase leads and the pusher's feed (the M10 at Y 390 to 420; th-telemetry's
# clearances: pusher motor and Aria 100 mm, pusher feed 60 mm, 20cf07d2; interference under 30 % is their M3). PLACEHOLDERS (0 = no compensation) until the tied-down bench
# run: after the compass calibration, props on and tied down, step the lift motors through hover current with
# LOG_DISARMED 1, then tools/fit_compass_mot.py on the log writes these rows. Over 30 % interference: re-route
# the leads instead (th-telemetry). ArduPlane has no compassmot command.
COMPASS_MOTCT     2
COMPASS_MOT_X     0
COMPASS_MOT_Y     0
COMPASS_MOT_Z     0
# th_prearm.lua adds TH_AIRFRAME (load the flight scripts and reboot before this file); set it to 1 here. It refuses
# to arm while it is 0, so a board that has not had this file loaded cannot fly on its placeholder calibrations.
TH_AIRFRAME       1
# th_prearm.lua v0.4: arming needs the mLRS telemetry radio seen on TELEM2 (RADIO_STATUS from 51/68 and its RSSI_A,
# RSSI_B and LQ values for 12 s, docs/failsafes.md). 0 only on a bench without the radio; SITL sets 0 in its harness.
TH_RAD_REQ        1
# lift_check.lua (load the flight scripts and reboot before this file): arming waits for a landing lane in the mission,
# a JUMP_TAG LCK_LANE_TAG then the approach and a fixed-wing NAV_LAND on the keels, into the usual wind, on ground fit
# for a belly landing. After a lift-motor loss it is the planned way down on the wing (th-avionics, 2026-10-12: kept at
# the script's default for every flight, the first hovers included; only the wingless testbed quad uses 0).
LCK_LANE_REQ      1
# FPV camera: the Walksnail lens points 15 deg below the airframe's axis (th-blender W104, 888383ba). ArduPilot's OSD
# artificial horizon has no camera-tilt offset (AP_OSD_Screen::draw_horizon; in fixed-wing flight it also subtracts
# PTCH_TRIM_DEG, Plane.cpp:1053), so with the trim at 5 its level line would sit about 10 deg off the real horizon in
# cruise and 15 in hover. So it is off (Ryan, 2026-10-20). Only OSD screen 1 is enabled by default; any other screen
# turned on later needs its HORIZON_EN at 0 too. The goggles draw no horizon of their own that we use, so nothing live
# depends on the tilt; the 15 deg goes into Gyroflow for the recordings (th-telemetry 086393e3).
OSD1_HORIZON_EN   0