.pr_agent_accepted_suggestions - iNavFlight/inav GitHub Wiki

Linked worktrees have their own HEAD, but the new commondir handling reads the main checkout’s HEAD and reports its revision.

• cmake/GetGitRevisionDescription.cmake[73-90]
• cmake/GetGitRevisionDescription.cmake.in[18-39]

Preserve the worktree Git directory for reading and tracking HEAD. Resolve shared branch refs and packed refs through commondir separately, without replacing the directory used for HEAD.

The widened stack watermark scan assumes the entire reserved stack range contains 0xa5, but the AT32 reset handler initializes only .data and .bss. Initialize the reservation before normal calls begin so stack usage reflects bytes actually overwritten by stack activity.

• src/main/target/link/at32_flash_f4_split.ld[22-24]
• src/main/startup/startup_at32f435_437.s[53-60]
• src/main/drivers/stack_check.c[48-64]

In Reset_Handler, immediately after setting sp and before calling any functions, fill the memory from _estack - _Min_Stack_Size through _estack with 0xa5. Preserve the hot-reboot area above _estack, and ensure the initialization itself does not push stack frames before painting completes.

mavlinkTunnelMspReplyIsBusy() flushes a pending reply while processing an incoming request, bypassing the half-duplex RX guard applied by the telemetry runtime. A pipelined request received on the pending reply's ingress port can therefore trigger transmission during the protected interval instead of being safely dropped.

• src/main/fc/fc_mavlink.c[92-96]
• src/main/mavlink/mavlink_runtime.c[295-305]
• src/main/mavlink/mavlink_runtime.c[322-337]

Make mavlinkTunnelMspReplyIsBusy() non-transmitting so it only reports whether a reply remains pending, and leave transmission to mavlinkRuntimeHandle(), whose telemetry-cycle flush already enforces half-duplex backoff. The incoming pipelined request should then be dropped as documented. Add a same-port half-duplex test proving that a pipelined request neither writes pending reply chunks nor executes until the backoff expires.

The newly assigned fast divisor map contains DIV32 for the slow speed, causing affected devices requesting the approximately 1 MHz setting to run above 3 MHz.

• src/main/drivers/bus_spi_hal_ll.c[76-82]
• src/main/drivers/bus_spi_hal_ll.c[157-169]
• src/main/drivers/bus_spi_hal_ll.c[248-248]

Change the SPI_CLOCK_SLOW entry in spiDivisorMapFast from LL_SPI_BAUDRATEPRESCALER_DIV32 to LL_SPI_BAUDRATEPRESCALER_DIV128, preserving the intended speed relationship with the half-rate map, and update its frequency comment if necessary.

The version bump changes the generated SITL executable from inav_9.1.1_SITL to inav_10.0.0_SITL, but checked-in MAVLink test launchers still use the old path, so those tests fail after a clean build.

• src/test/mavlink/missions/run_mavlink_mission_tester.sh[10-10]
• src/test/mavlink/ports/test_config_multiport4_sweep_rc460800_tele115200.yaml[2-2]
• src/test/mavlink/sanity/mavlink_sitl_sanity.yaml[2-2]

Replace the hardcoded inav_9.1.1_SITL references with a version-independent path or update them to the generated inav_10.0.0_SITL artifact. Prefer deriving the path from the configured project version so future version bumps do not leave these test entry points stale, then run the affected MAVLink SITL tests.

fwLineIntersect() no longer preserves the old guard's behavior for NaN cross products: fabsf(cross) <= minAbsCross is false for NaN, so the helper calculates and writes NaN outputs and returns true.

• src/main/navigation/navigation_fixedwing_turn_math.c[74-80]

Use the original positive acceptance condition: only calculate and write the intersection when fabsf(cross) > minAbsCross; otherwise return false. This retains the previous fallback behavior for both near-parallel and non-finite geometry.

The privileged workflow_run comment job trusts a pull-request-controlled artifact to identify the issue or pull request receiving a bot comment. A fork author can alter the source workflow to upload a chosen pr_number.txt, redirecting the job's write-capable token to an unrelated repository target.

• .github/workflows/pg-version-check-comment.yml[18-40]
• .github/workflows/pg-version-check-comment.yml[88-117]
• .github/workflows/pg-version-check.yml[57-73]

Derive the target pull request number exclusively from trusted github.event.workflow_run.pull_requests metadata, verify that exactly one associated pull request exists, and fail closed otherwise. Stop uploading, downloading, or reading pr_number.txt; continue treating the downloaded checker output as untrusted text and post it only to the pull request associated with the triggering workflow run. Optionally validate the originating repository and head SHA before processing the artifact.

The project version bump renames the generated simulator executable, but operational test launchers and configurations still point at the previous versioned filename.

• CMakeLists.txt[56-76]
• cmake/sitl.cmake[124-124]
• src/test/mavlink/missions/run_mavlink_mission_tester.sh[10-10]
• src/test/mavlink/missions/run_mavlink_mission_tester.sh[146-162]
• src/test/mavlink/sanity/mavlink_sitl_sanity.yaml[2-2]
• src/test/mavlink/ports/test_config_multiport4_sweep_rc460800_tele115200.yaml[2-2]

Update all operational simulator paths to the 9.1.1 executable and preferably derive or discover the filename from the CMake project version so future version bumps do not break these test runners.

The scheduled cleanup job removes all GITHUB_TOKEN permissions before using actions/checkout, preventing the job from reliably fetching the cleanup script.

• .github/workflows/cleanup-pr-test-builds-scheduled.yml[17-23]

Replace permissions: {} with an explicit permissions block granting contents: read. Keep all other token permissions disabled.

The scheduled sweep deletes by reusable tag after deciding staleness from an earlier snapshot, allowing a concurrent publisher run to replace the release before deletion.

• .github/scripts/cleanup-old-pr-test-builds.py[86-118]
• .github/workflows/pr-test-builds.yml[70-103]

Before an age-based deletion, fetch the current release again and verify that its publication timestamp still matches the listed release and remains beyond the threshold. If it changed or disappeared, skip it so a concurrently refreshed build is preserved.

The burst-DMA implementation uses nemvoid, which is not a valid C return type and causes affected HAL firmware builds to fail.

• src/main/drivers/timer_impl_hal.c[543-543]

Replace nemvoid with void so the implementation matches the declaration in timer_impl.h and compiles for HAL targets using burst DMA.

The fixed-wing TPA filter now processes a zero-centered pitch adjustment, but its lifecycle still initializes it with an absolute idle-throttle value and can preserve stale state while TPA is inactive.

• src/main/flight/pid.c[467-472]
• src/main/flight/pid.c[1300-1331]
• src/main/navigation/navigation_fw_launch.c[318-322]

Reset fixedWingTpaFilter to zero now that its input is an adjustment rather than absolute throttle. Ensure its state is also updated or reset while pitch TPA is inactive so reactivation cannot reuse an adjustment from an earlier attitude.

The protocol documentation retains references to the removed throttle.pa_breakpoint member after the profile field was renamed to throttle.tpa_breakpoint.

• docs/development/msp/msp_messages.json[4022-4027]
• docs/development/msp/msp_messages.json[5127-5132]
• docs/development/msp/msp_messages.json[7447-7452]
• docs/development/msp/msp_messages.json[7541-7546]
• docs/development/msp/README.md[1994-2000]
• docs/development/msp/README.md[2421-2427]
• docs/development/msp/README.md[3315-3321]
• docs/development/msp/README.md[3336-3342]

Replace every protocol-documentation reference to throttle.pa_breakpoint with throttle.tpa_breakpoint, then regenerate the rendered protocol README from the corrected message definitions.

The checker executes untrusted pull-request code and then tries to post its result using the same pull-request workflow token. Fork runs cannot obtain the required write access, so genuine detections fail during comment creation instead of publishing the warning.

• .github/workflows/pg-version-check.yml[37-143]
• .github/workflows/pr-test-builds.yml[1-36]

Keep checking in the unprivileged pull_request workflow, upload the checker result and validated pull-request number as artifacts, and add a privileged workflow_run consumer that downloads those artifacts and posts or updates the comment. Follow the repository's existing pr-test-builds.yml pattern and do not execute pull-request code in the privileged workflow.

The checker loses the base-side definition when a parameter-group struct is modified as part of a detected file rename. Because comparison requires the alias in both structure maps, this allows a persisted layout change to pass without a version increase.

• .github/scripts/check-pg-versions.py[147-163]
• .github/scripts/test-check-pg-versions.py[53-67]

Collect both old and new paths for changed files, such as by disabling rename collapsing with git diff --no-renames --name-only, and load each path from whichever tree contains it. Add a fixture that renames a registered struct header, changes its layout without increasing the version, and expects exit code 1.

The 0.2 Hz telemetry mode schedules its next possible reply no earlier than the link timeout, so the driver disconnects before receiving it.

• src/main/io/motor_srxl2.c[184-188]
• src/main/io/motor_srxl2.c[811-824]
• src/main/io/motor_srxl2.c[1011-1029]

Base the link timeout on the selected request interval with allowance for multiple unanswered requests, or use a separate sufficiently frequent link-health exchange independent of the telemetry delivery rate.

Manual-high calibration can command full throttle while a battery-sensed ESC is already powered.

• src/main/io/motor_srxl2.c[826-876]
• src/main/fc/cli.c[4807-4812]
• src/main/fc/fc_msp.c[3831-3834]

For SRXL2_CAL_HIGH_MANUAL, reject the request with SRXL2_CAL_REJECT_BATTERY_PRESENT whenever battery sensing is configured and the battery state is not BATTERY_NOT_PRESENT; retain the manual fallback only where voltage cannot be sensed.

Firmware built without USE_MOTOR_SRXL2 can retain and select PWM_TYPE_SRXL2 even though no compiled driver case assigns a motor writer and the SRXL2 link-health arming check is absent. Since SRXL2 is classified as a non-timer output, timer allocation is also bypassed, leaving motor writes as no-ops without a visible PWM initialization or insufficient-output error.

• src/main/fc/config.c[267-277]
• src/main/drivers/pwm_output.c[599-634]
• src/main/drivers/pwm_mapping.c[66-94]
• src/main/drivers/pwm_mapping.c[438-455]

Add explicit validation for builds without USE_MOTOR_SRXL2 so PWM_TYPE_SRXL2 is rejected or replaced with a supported protocol such as PWM_TYPE_MULTISHOT, with a visible configuration or output error where rejection is used. Keep the existing DSHOT-specific validation separate, prevent unavailable firmware from advertising SRXL2 as selectable, and ensure an unsupported protocol cannot reach the non-timer initialization path.

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution Issue description SRXL2 discovery polls only device ID 0x40, although the driver recognizes ESC IDs 0x40 through 0x4F and documents that nonzero-unit ESCs require polling because they do not announce. Such an ESC therefore cannot complete the handshake. Fix Focus Areas

• src/main/io/motor_srxl2.c[74-77]
• src/main/io/motor_srxl2.c[980-998] Recommended Fix Track a discovery device ID per ESC instance and rotate through 0x40 to 0x4F while polling, resetting the scan when a valid handshake is received. Preserve the one-ESC-per-port behavior and only finalize negotiation with the ID that replied.

The fixed one-second freshness window is shorter than supported telemetry intervals and invalidation is advanced at busy-loop frequency.

• src/main/io/motor_srxl2.c[187-188]
• src/main/io/motor_srxl2.c[1094-1103]
• src/main/sensors/esc_sensor.c[273-303]

Derive freshness from the configured delivery interval with jitter and missed-response allowance, and update dataAge only when an expected sample opportunity is missed rather than on every realtime callback.

Per-field no-data sentinels are converted into valid zero readings because telemetry has only one aggregate validity flag.

• src/main/io/motor_srxl2.c[462-492]
• src/main/io/motor_srxl2.h[52-69]
• src/main/sensors/esc_sensor.c[282-299]

Add validity flags for each exported measurement and propagate them into consumers, or reject/retain fields explicitly so sentinel values are never presented as fresh numeric zeroes.

The new Thrust Reverse mode is advertised in the active-box list and consumed internally, but omitted from MSP active-mode status serialization, preventing MSP clients from displaying its active state.

• src/main/fc/fc_msp_box.c[399-419]
• src/main/fc/fc_msp_box.c[426-525]
• src/main/fc/fc_tasks.c[335-340]

Add CHECK_ACTIVE_BOX(IS_RC_MODE_ACTIVE(BOXTHRUSTREVERSE), BOXTHRUSTREVERSE) to packBoxModeFlags() alongside the other mode-state serialization entries. Apply the same feature conditions used when advertising the box so the serialized flag corresponds to its active-box-list position.

Configuration accepts unsupported reverse channels and still advertises an operational reverse mode.

• src/main/fc/settings.yaml[884-890]
• src/main/fc/fc_msp_box.c[414-419]
• src/main/io/motor_srxl2.c[761-808]

Validate the value as exactly zero or 5 through 9 during configuration loading, reject invalid CLI/MSP writes, and advertise the mode only when the normalized channel is usable.

The SRXL2 calibration CLI implementation and command registration are accidentally compiled only when unrelated USB mass-storage support is enabled. SRXL2 targets without the optional MSC build feature therefore cannot use the documented CLI calibration flow even though the driver API requires only SRXL2 support.

• src/main/fc/cli.c[4745-4828]
• src/main/fc/cli.c[5107-5115]
• src/main/target/SITL/target.h[57-65]
• cmake/stm32.cmake[327-338]
• src/main/io/motor_srxl2.c[826-876]

Move the SRXL2 calibration helper and command registration outside the USE_USB_MSC blocks while retaining their USE_MOTOR_SRXL2 guards. Leave only the existing msc command under USE_USB_MSC.

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution The issue below was found during a code review. Follow the provided context and guidance below and implement a solution Issue description The SRXL2 receive parser accepts a CRC-valid five-byte frame and dispatches it as a handshake without checking the handshake structure length. The handshake handler then reads fields outside the logical received frame, so stale buffer contents can affect link setup. Fix Focus Areas

• src/main/io/motor_srxl2.c[498-553]
• src/main/io/motor_srxl2.c[567-588]
• src/main/io/motor_srxl2.c[590-618]
• src/main/rx/srxl2_types.h[81-86] Recommended Fix Before calling srxl2HandleHandshake(), require len >= sizeof(Srxl2HandshakeFrame) (or require the protocol-defined exact handshake length). Reject malformed handshake frames without updating state, device ID, handshake counters, or baud capabilities.

The new ESC debug values are updated only along the BL bootloader success path, leaving stale values after failures and omitting successful STK detections.

• src/main/io/serial_4way.c[347-393]

Clear the ESC identifier and family debug slots at the start of every Connect call. Record the signature and appropriate family before returning from either the STK or BL success path, including family 2 for Atmel devices.

Secondary gyro sampling automatically enables gyroRaw2 logging, so the independently configurable blackbox GYRO_2 switch described by the feature is unavailable.

• src/main/blackbox/blackbox.c[864-867]
• src/main/blackbox/blackbox.h[24-39]
• src/main/fc/cli.c[185-204]
• docs/Blackbox.md[171-175]

Add a dual-gyro Blackbox feature-mask bit and matching GYRO_2 CLI name, then require both that include flag and gyro.secondaryInitialized in the secondary field condition. Keep the new flag disabled by default and update the documentation to describe sampling and logging as separate switches.

Secondary gyro selection assumes every dual-sensor target uses tags 0 and 1, but repository targets also use 0 and 2 or duplicate tag 0. This silently prevents detection and Blackbox logging on those boards.

• src/main/sensors/gyro.c[343-358]
• src/main/target/AETH743Basic/target.c[30-36]
• src/main/target/BRAHMA_H7/target.c[29-30]

Replace arithmetic tag inversion with an explicit target-declared physical sensor-slot mapping. Normalize duplicate physical descriptors to unique logical slots where necessary, support the existing 0-and-2 layout, and add coverage for both conventional and nonconventional tag pairs.

The new persist parameter is unused when USE_IMU_FAKE removes its only reference, causing warnings-as-errors SITL builds to fail.

• src/main/sensors/gyro.c[418-442]

Add UNUSED(persist) in the USE_IMU_FAKE branch, or restructure the conditional so persist is evaluated in every build configuration. Verify the SITL target with warnings-as-errors enabled.

Secondary calibration may continue retrying after arming, causing every secondary Blackbox sample to remain zero under sustained vibration.

• src/main/sensors/gyro.c[383-415]
• src/main/sensors/gyro.c[600-610]

Make secondary calibration terminate after one window by allowing failure, then continue producing aligned and scaled samples with a zero offset when calibration fails instead of restarting forever. Add coverage for noisy secondary input during early arming and verify that primary updates remain unaffected.

The consumers require github.event.workflow_run.path, but the repository does not establish that this property is present in workflow_run event payloads. An absent property makes the condition false, so valid pull-request firmware runs do not reach the artifact consumers.

• .github/workflows/pr-test-builds.yml[17-20]
• .github/workflows/ci-size-report.yml[138-142]

Replace the path-based guard with a reliably available identifier for the real firmware workflow, such as its workflow ID or another supported discriminator. Preserve the existing pull-request and successful-conclusion checks, and ensure both consumers reject non-code-change.yaml without excluding valid .github/workflows/ci.yml runs.

The new raw magnetometer logger trusts each driver's success result, but mlx90393Read reports success after a failed bus transaction and supplies three zero values. Those values are consequently recorded as real measurements and can skew external calibration.

• src/main/drivers/compass/compass_mlx90393.c[103-114]
• src/main/sensors/compass.c[417-426]

Check the return value from busReadBuf in mlx90393Read and return false without replacing magADCRaw when the transaction fails. This allows the existing failure branch in compassUpdate to skip publishing the invalid sample.

The remembered acceleration timestamp is never expired, and the signed 32-bit comparison becomes negative after about 35 minutes, causing an old event to satisfy the one-second recency check.

• src/main/navigation/navigation_fw_launch.c[426-435]
• src/main/common/time.h[27-30]
• src/main/common/time.h[63-64]

Explicitly clear the remembered timestamp once its one-second window expires and require the computed delta to be nonnegative before accepting it as recent. Keep expiry evaluation running on every detection cycle so the timestamp cannot survive until signed-delta overflow.

A throttle-low transition aborts detection and returns the controller to WAIT_THROTTLE, but the newly added acceleration timestamp survives that transition and remains usable by the next attempt.

• src/main/navigation/navigation_fw_launch.c[416-431]

Clear forwardAccelHighTimeUs when low throttle exits WAIT_DETECTION, ensuring every newly armed detection attempt requires its own acceleration event.

Rejecting an invalid JUMP at waypoint 1 returns before the existing mission is reset, so stale valid mission state remains available to execute.

• src/main/navigation/navigation.c[5471-5483]
• src/main/fc/fc_msp.c[3323-3354]

Reorder first-waypoint handling so resetWaypointList() runs before JUMP validation when wpNumber == 1, while still validating before copying or converting the new waypoint. Ensure a rejected first waypoint leaves the count zero and waypointListValid false.

Rejecting a short MSPv1 start frame leaves the previous partial request active, allowing later continuation chunks to complete and execute that stale command.

• src/main/telemetry/msp_shared.c[116-206]

Set mspStarted to zero before returning for a short MSPv1 start frame, ensuring the next frame cannot continue the previous request. Apply the same reset consistently to malformed start-frame rejection paths.

The board documentation labels both supported flash variants as 16 MB, but the firmware geometry defines one as 2 MB and the other as 16 MB.

• docs/boards/ALEXF722V3.md[13-13]

List the capacity separately for each flash variant, describing the smaller variant as 2 MB and the larger variant as 16 MB.

Tagged typedef enums are emitted twice by the collector—once by the typedef enum pass and again by the plain enum Tag pass—and the broadened parser renders both copies. This creates duplicate Markdown sections, table-of-contents entries, and HTML anchors, while duplicate JSON keys silently overwrite the first definition.

• src/utils/gen_enum_md.py[74-81]
• src/utils/get_all_inav_enums_h.py[34-86]
• docs/development/msp/inav_enums_ref.md[498-510]

Ensure each tagged typedef is collected or parsed exactly once. Prefer changing the collector’s plain tagged-enum extraction so it skips matches whose enum token is preceded by typedef, while preserving extraction of standalone enum Tag { ... }; declarations; also add a duplicate-name guard before rendering to prevent future duplicate anchors and JSON overwrites. Regenerate both enum output files and verify that every enum has exactly one table-of-contents entry, Markdown section, HTML anchor, and JSON definition.

The --inav-root option accepts external source trees, but source attribution forces every discovered file to be relative to the current repository root, causing valid external paths to raise ValueError.

• src/utils/get_all_inav_enums_h.py[97-123]

Preserve stable repository-relative attribution for files under REPO_ROOT, but when a discovered file is outside it, fall back to a stable path relative to the supplied base_dir or retain the resolved absolute source path. Ensure valid external --inav-root invocations cannot raise from Path.relative_to(REPO_ROOT), and add coverage that invokes the script with an external temporary source tree.

The regional size calculator discards all sections at address zero, including allocated .tcm_code sections placed in zero-origin ITCM. Distinguish non-allocated metadata from allocated ELF sections using section allocation flags or equivalent map information rather than the address alone.

STM32F7 and STM32H7 linker scripts define writable ITCM at 0x00000000, and repository code populates .tcm_code through FAST_CODE. Keep excluding debug and symbol sections at address zero while counting allocated sections there, and add regression coverage for both cases.

• .github/scripts/compute-region-sizes.py[89-103]

A CMS exit can skip releasing a newly selected display because cmsYieldUntil records that an earlier display was yielded rather than whether the current display is actually grabbed. Track current display ownership explicitly and use that state consistently across yielding, display switching, reacquisition, and exit.

cmsYieldDisplay() releases the original display and records a deadline. During that deadline, the HoTT display path can call cmsMenuOpen() while a menu is active, causing CMS to cycle displays, release the prior display, and grab a newly selected display without clearing the yield deadline. Because display ownership is reference-counted, exit must release the current display according to its actual ownership instead of clearing the timer and inferring that no release is needed.

• src/main/cms/cms.c[854-926]
• src/main/cms/cms.c[996-1003]
• src/main/cms/cms.c[1038-1047]
• src/main/io/displayport_hott.c[146-168]

Forced in-flight CMS closure can leave the active battery profile changed while its calculated cell count and voltage warning thresholds still belong to the previous profile.

Entering the battery SETTINGS submenu immediately activates the selected profile. Its onExit is the only armed-path operation that updates calculated thresholds, but the new CMS_EXIT behavior deliberately skips all onExit callbacks.

• src/main/cms/cms.c[979-984]
• src/main/cms/cms_menu_battery.c[99-116]
• src/main/cms/cms_menu_battery.c[173-190]

The new menu-close cleanup treats every layout override as menu-owned, cancelling timed configurator previews. Restrict forced cleanup to overrides established by the menu layout editor while preserving timeout-based overrides from other callers.

Both the menu editor and the configuration protocol call osdOverrideLayout(). Ownership or lifetime must therefore be represented explicitly rather than inferred solely from cmsInMenu.

• src/main/io/osd.c[6026-6046]
• src/main/io/osd.c[6107-6114]
• src/main/cms/cms_menu_osd.c[379-394]
• src/main/fc/fc_msp.c[3706-3714]

The LAND adjustment reads the immediately preceding stored item, although stored mission actions do not necessarily carry the aircraft's preceding flight altitude.

Commands such as MAV_CMD_DO_JUMP, MAV_CMD_DO_SET_ROI, and MAV_CMD_CONDITION_YAW are staged as waypoints. Search backward for the applicable positional waypoint whose altitude defines the final approach, and add coverage with intervening stored actions.

• src/main/mavlink/mavlink_mission.c[792-796]
• src/main/mavlink/mavlink_mission.c[799-816]
• src/main/mavlink/mavlink_mission.c[900-945]

The LAND workaround overwrites all negative altitudes even though mission validation explicitly accepts them.

Restrict the sentinel handling to the exact frame/value combination intended to represent an unspecified touchdown altitude. Add tests for negative relative altitude and non-positive absolute altitude so valid elevations remain intact.

• src/main/mavlink/mavlink_mission.c[752-796]
• src/main/mavlink/mavlink_mission.c[214-228]

Rotary landing detection omits an alternate helicopter mixer profile even though the repository's shared platform classifier includes helicopters.

Use consistent multirotor-type classification for the configured landing profile, or explicitly include every platform accepted by isMultirotorTypePlatform. Add a test for a fixed-wing current profile with a helicopter-type alternate profile.

• src/main/mavlink/mavlink_mission.c[788-790]
• src/main/flight/mixer.h[36-51]
• src/main/flight/mixer_profile.c[931-947]

The RTH altitude-change calculation combines a negative-sign climb component with a positive-up NEU wind value. Convert the estimated vertical wind to the sign convention used by the calculation before passing it into distance and energy estimation.

getEstimatedWindSpeed(Z) returns positive-up wind, while RTHInitialAltitudeChangePitchAngle() returns a negative angle for climbing and estimateRTHAltitudeChangeTime() adds the resulting negative sine component directly to vertical wind.

• src/main/flight/rth_estimator.c[73-94]
• src/main/flight/rth_estimator.c[147-177]

Preserve voltage-specific warning semantics while avoiding references to checkBatteryVoltageState() on builds without USE_ADC. The aggregate getBatteryState() must not drive the explicitly voltage-based warning because it becomes capacity-derived when capacity thresholds are active.

batteryUpdate() selects checkBatteryCapacityState() when batteryUseCapacityThresholds is true. The following capacity-warning block already reports that aggregate state separately, so using it for the voltage block produces incorrect and duplicate warnings.

• src/main/fc/multifunction.c[268-280]
• src/main/sensors/battery.c[397-435]
• src/main/sensors/battery.c[498-510]

Keep voltage-display blinking based on voltage thresholds while preventing non-ADC builds from referencing an unavailable symbol. Do not substitute the aggregate battery state because it can represent remaining capacity.

checkBatteryVoltageState() evaluates batteryWarningVoltage and batteryCriticalVoltage, but getBatteryState() returns the shared state that batteryUpdate() derives from capacity whenever capacity thresholds are enabled. Use compile-time guarding or an always-defined voltage-state API with an appropriate non-ADC fallback.

• src/main/io/osd.c[1588-1607]
• src/main/sensors/battery.c[397-435]
• src/main/sensors/battery.c[498-510]
• src/main/sensors/battery.h[76-80]

RP2350 supplies no-op implementations of the CMSIS DSP functions used by dynamic gyro notch analysis. Although the target disables the filter only by default, users can re-enable it and receive silently invalid filtering.

Either provide functional ARMv8-M-compatible DSP implementations or compile USE_DYNAMIC_FILTERS out for RP2350 so the unsupported setting and execution path cannot be enabled.

• src/main/drivers/system_rp2350.c[220-287]
• src/main/target/RP2350_PICO/target.h[150-175]
• src/main/target/RP2350_PICO/config.c[24-31]
• src/main/flight/gyroanalyse.c[72-89]

Adding an item changes the stride of each row in persisted item_pos[OSD_LAYOUT_COUNT][OSD_ITEM_COUNT]. Because the registered PG version remains 3, old four-layout payloads are copied as a flat prefix into the new shape and alternate layouts become misaligned.

The generic PG loader only performs a size-limited memcpy when versions match; it does not migrate two-dimensional arrays. Either bump the layout PG version so incompatible data resets safely, or add an explicit migration that copies each old layout row into the matching new row and initializes the Terrain AGL slot.

• src/main/io/osd.h[382-383]
• src/main/io/osd.c[235-236]

The sibling-branch cache survives ordinary enum members, causing a later opposite-polarity conditional to reuse a stale numeric base even though the two blocks are not adjacent alternate branches.

Only an immediately corresponding opposite-polarity sibling should reuse the closed branch base. Parsing any intervening enumerator must invalidate the closed frame at that nesting level; add regression coverage including an intervening explicit assignment.

• docs/development/msp/gen_enum_md.py[107-114]
• docs/development/msp/gen_enum_md.py[262-297]

MSP2_INAV_SET_GEOZONE_VERTEX accepts a circular-zone payload without the required four-byte radius, mutates the center, and reports success.

Polygon updates require a 10-byte prefix, while circular updates require that prefix plus a 4-byte radius. Preserve lenient acceptance of bytes beyond the known complete encoding, but reject circular payloads shorter than 14 bytes before mutating vertex state.

• src/main/fc/fc_msp.c[3922-3936]

The pruning query attempts to match a one-line anchored regex against the complete multi-line release body, causing releases created by this script to be omitted.

Extract and validate the first body line, and ensure malformed notes still emit a record under the fallback branch group rather than disappearing from the stream.

• .github/scripts/publish-size-baseline.sh[74-76]
• .github/scripts/publish-size-baseline.sh[87-92]

The pruning AWK program only considers retained tags when producing deletions and loses every tag outside the per-branch keep set.

Track every input tag, retain only the newest configured count per branch and then the global count, and print every input tag absent from the final keep set.

• .github/scripts/publish-size-baseline.sh[99-120]

The new host line-coding baseline is captured after both transmit-drain waits. If the host changes its COM-port baud or framing while either wait is running, polling sees no difference from the captured baseline and never applies that change to the passthrough UART.

The CLI prints its passthrough handoff message before entering serialPassthrough(), and each drain wait sleeps repeatedly until its port's software TX buffer empties. Capture the VCP baseline at actual function entry, before those waits, while preserving the USE_VCP guards and existing non-VCP behavior.

• src/main/io/serial.c[603-629]

The new derivative-on-measurement path differentiates wrapped COG directly. Crossing 0°/360° therefore creates an artificial full-circle delta and a large D-term roll correction.

navHeadingError is wrapped safely, but actualState.cog is represented as a wrapped angular value. Preserve derivative-on-measurement while making the measurement delta wrap-aware, for example by maintaining a continuous/unwrapped COG value or adding an angular-difference-aware PID input path; reset that state whenever the navigation PID is reset.

• src/main/navigation/navigation_fixedwing.c[555-561]
• src/main/common/fp_pid.c[60-73]
• src/main/navigation/navigation_pos_estimator.c[742-752]

The WS2812 RAM figures assume 2-byte DMA elements even though the supported timer DMA-safe type is 4 bytes.

The full array has 3,115 elements and the proposed 2×4-LED circular buffer has 192 elements. Keep the stated byte counts consistent with the guide's later requirement to use timerDMASafeType_t.

• docs/development/ram-and-flash-optimization.md[52-55]

The settings schema advertises a sweep-rate default of 100, but firmware reset and migration initialize the field to 10. Make both default paths use the intended value from the PR specification.

The runtime reset function is authoritative after factory reset and supplies missing tail fields when loading older PG records, while settings generation exposes the YAML default to API/configurator consumers.

• src/main/fc/settings.yaml[4510-4515]
• src/main/io/ledstrip.c[146-158]

Hue spacing currently advances for every configured LED rather than only for LEDs carrying the rainbow overlay. Track a rainbow-LED ordinal and use that ordinal in the hue calculation.

The loop index includes non-rainbow entries, while the setting explicitly promises an offset between adjacent rainbow-overlay LEDs.

• src/main/io/ledstrip.c[868-877]
• src/main/fc/settings.yaml[4516-4520]

Rainbow is applied after existing effect overlays and overwrites their color or brightness output. Reorder the layer so rainbow supplies the active color before Blink, Strobe, Landing Flash, and Larson modify it.

LED configuration parsing ORs multiple overlay bits together, and every layer runs in table order. Rainbow writes hue, saturation, and value on every update, erasing effects produced by earlier layers.

• src/main/io/ledstrip.c[971-985]
• src/main/io/ledstrip.c[846-879]
• src/main/io/ledstrip.c[822-843]
• src/main/io/ledstrip.c[881-909]

DIRECT (legacy) waypoint turning is not respected: FLY_BY turn anticipation can still arm in DIRECT, and the mission can advance early (waypoint considered reached at turn start).

• calculateAndSetActiveWaypoint() currently populates activeWaypoint.nextTurnAngle for all modes except COORD_FLYOVER.
• calculateVirtualPositionTarget_FW() uses nextTurnAngle to arm wpTurnSmoothingActive without checking that the configured turn mode is COORD_FLYBY (or landing-approach forced FLY_BY).
• isWaypointReached() returns true immediately when wpTurnSmoothingActive is set, which advances the mission early.

• src/main/navigation/navigation.c[4300-4313]
• src/main/navigation/navigation_fixedwing.c[1123-1144]
• src/main/navigation/navigation.c[3103-3115]

• Only compute activeWaypoint.nextTurnAngle for modes that actually need anticipation (COORD_FLYBY, COORD_FLYINTO, and landing approach override).
• Additionally (defense-in-depth), gate the FLY_BY corner-cut arming (wpTurnSmoothingActive) so it only runs when wp_turn_mode == NAV_FW_WP_TURN_COORD_FLY_BY (or landing approach state forces FLY_BY).
• Ensure DIRECT mode never sets wpTurnSmoothingActive and therefore never triggers early isWaypointReached().

DIRECT mode is documented as legacy heading-PID behavior, but the new coordinated-turn feed-forward is applied unconditionally whenever WP tracking is active.

• updatePositionHeadingController_FW() always executes rollAdjustment += getFwTurnFeedForward(navHeadingError); when not in an arc.
• getFwTurnFeedForward() does not check navConfig()->fw.wp_turn_mode; it only checks WP tracking/heading error/speed.

• src/main/navigation/navigation_fixedwing.c[1341-1347]
• src/main/navigation/navigation_fixedwing.c[551-565]

• Gate feed-forward by turn mode, e.g. return 0 (or skip calling) when navConfig()->fw.wp_turn_mode == NAV_FW_WP_TURN_DIRECT.
• If you still want FF in DIRECT for some reason, update docs/setting semantics accordingly; otherwise DIRECT should be a true opt-out.

Docs/settings say the roll easing window is n * 100ms (max 900ms) and the setting max is 9, but code comments/constants claim a 1000ms cap. Today the effective max is still 900ms, but the inconsistency is misleading.

• nav_fw_control_smoothness max is 9.
• Docs describe max 900ms.
• Code defines NAV_FW_SMOOTH_TCONST_MAX_MS 1000.0f and comment says “capped at 1000 ms”.

• src/main/navigation/navigation_fixedwing.c[62-68]
• src/main/fc/settings.yaml[3058-3064]
• docs/Settings.md[3641-3644]

Either:

• Change NAV_FW_SMOOTH_TCONST_MAX_MS and the comment to 900ms, matching the setting range and docs, or
• Keep 1000ms and update docs/setting max accordingly (e.g., allow 10) so behavior matches documentation.

ws2811SetIdleHigh() unconditionally dereferences ws2811TCH via timerCCR(ws2811TCH). If LED-strip initialization never ran or returned early (no suitable timer, DMA config failure, etc.), ws2811TCH can be NULL and this becomes a hard-fault path.

pinioSetDuty() routes index == 0 directly to ws2811SetIdleHigh(), so this can be triggered even when LED strip init did not succeed.

Add a defensive guard at the top of ws2811SetIdleHigh():

• if (!ws2811Initialised || !ws2811TCH) return; Optionally also avoid touching lineIdleLow/lastLowAtUs when not initialized.

• src/main/drivers/light_ws2811strip.c[293-300]
• src/main/drivers/pinio.c[195-201]
• src/main/drivers/light_ws2811strip.c[144-171]

At the end of a circular DMA LED transfer, ws2811DMARefillCallback() calls ws2811StopTransfer(), which unconditionally drives the line low (CCR=0) and marks it idle-low. This can override a PINIO-driven idle-high request made via ws2811SetIdleHigh(true).

• pinioSetDuty(index==0) uses ws2811SetIdleHigh(duty>0).
• When the last LED group completes, the DMA refill callback stops the DMA and forces low.

Track the desired idle level separately (e.g. static volatile bool idleHighRequested; updated by ws2811SetIdleHigh()), and in ws2811StopTransfer() set CCR to either 0 or a constant-high value based on that desired level instead of always forcing low. If latch/reset timing requires a low gap before returning high, enforce that before restoring high.

• src/main/drivers/light_ws2811strip.c[225-233]
• src/main/drivers/light_ws2811strip.c[235-249]
• src/main/drivers/light_ws2811strip.c[293-300]
• src/main/drivers/pinio.c[195-201]

resolutionType_e is a wire-protocol enum (sent as a raw byte via MSP_DP_OPTIONS). This PR updates its explicit values, but the committed enum reference artifacts under docs/development/msp/ still document the old ordinals, causing protocol documentation drift.

The repo contains auto-generated enum reference files (inav_enums.json, inav_enums_ref.md) produced by docs/development/msp/gen_docs.sh / gen_enum_md.py. These should reflect the updated resolutionType_e members and values (including the newly reintroduced HD_3016=2).

• src/main/io/displayport_msp_osd.c[64-73]
• docs/development/msp/inav_enums.json[3300-3306]
• docs/development/msp/inav_enums_ref.md[4824-4834]

• Regenerate/update docs/development/msp/inav_enums.json and docs/development/msp/inav_enums_ref.md so resolutionType_e matches the new wire values:
• SD_3016 = 0
• HD_5018 = 1
• HD_3016 = 2
• HD_6022 = 3
• HD_5320 = 4
• Prefer running the documented generator (docs/development/msp/gen_docs.sh) and committing the updated artifacts, rather than hand-editing.

In-flight auto-close paths call cmsMenuExit(..., CMS_EXIT), but cmsMenuExit() does not dispatch onExit callbacks for CMS_EXIT. Menus that rely on onExit for cleanup (e.g. OSD layout preview override) can leave that transient state active after an emergency/timeout close.

• In-flight main menu includes the OSD submenu (cmsx_menuOsd), which can enter menuOsdElements that sets an OSD override on enter and clears it on exit.
• Safety close / inactivity close uses CMS_EXIT, not cmsMenuBack(), so no stack unwinding happens.

• Ensure auto-close (safety/timeout/switch-off) triggers the same cleanup as backing out of menus:
• Call currentCtx.menu->onExit(...) if present.
• Optionally iterate menuStack[] and call onExit for each stacked menu (similar to the popup-save traversal) to guarantee cleanup.
• Keep the “no EEPROM save/reboot while armed” restriction intact.
• src/main/cms/cms.c[908-944]
• src/main/cms/cms.c[1443-1457]

Calling batteryInit() while armed resets live battery runtime state (batteryState, cell count, and voltage thresholds). This can transiently change behaviors that depend on those values (notably throttle VBAT compensation which uses batteryFullVoltage).

The CMS battery menus already write settings directly; they only need to refresh derived thresholds/state, not reset battery presence.

• Replace batteryInit() (armed path) with a new targeted refresh that:
• recomputes batteryFullVoltage/batteryWarningVoltage/batteryCriticalVoltage based on current batteryCellCount and current battery profile, without forcing batteryState = BATTERY_NOT_PRESENT.
• avoids transiently zeroing values used in the mixer.
• If a new battery API is needed, implement it in sensors/battery.c and expose via sensors/battery.h.
• src/main/cms/cms_menu_battery.c[60-68]
• src/main/cms/cms_menu_battery.c[100-109]

docs/Telemetry.md says MAVLink is transmit-only, but the implementation processes inbound MAVLink messages. This is incorrect documentation and can lead users to wrong configuration/expectations.

The telemetry MAVLink code contains an explicit receive loop and dispatches received message IDs.

• docs/Telemetry.md[205-210]
• src/main/telemetry/mavlink.c[1388-1433]
• src/main/telemetry/mavlink.c[1444-1456]

After this PR, docs/Telemetry.md no longer mentions a 19200 SoftSerial limit for iBus, but docs/Serial.md and docs/Blackbox.md still claim SoftSerial is limited to 19200 baud. This is conflicting documentation.

The PR’s stated goal is to fix misleading SoftSerial-limit docs; this should be applied consistently across the documentation set.

• docs/Telemetry.md[231-237]
• docs/Serial.md[46-48]
• docs/Blackbox.md[68-75]

docs/Telemetry.md no longer states SoftSerial is limited to 19200 baud, but docs/Serial.md and docs/Blackbox.md still state (as a hard limit) that SoftSerial is limited to 19200. This creates contradictory documentation after this PR.

The SoftSerial code path takes a baud parameter and configures timers from it without a clear 19200 cap, so documentation that presents 19200 as a strict limit is inconsistent with the current implementation.

• docs/Telemetry.md[205-236]
• docs/Serial.md[36-49]
• docs/Blackbox.md[68-76]
• src/main/drivers/serial_softserial.c[170-189]
• src/main/drivers/serial_softserial.c[204-345]

Update the other docs to match the new reality (e.g., remove the “limited to 19200” hard-limit phrasing) or rephrase consistently as a practical/recommended limit if that’s the intended guidance (e.g., “SoftSerial may be unreliable at high baud rates; prefer hardware UART for >19200 / high bandwidth”).

The updated MAVLink line uses a comma splice (“transmit-only, is usable”), which is grammatically awkward and can be misread.

This is purely a documentation clarity/readability fix.

• docs/Telemetry.md[205-210]

Reword to something like:

• “MAVLink implementation in INAV is transmit-only and usable at low baud rates. MAVLink V1 and V2 are supported.”

docs/Telemetry.md says MAVLink is transmit-only, but the implementation processes inbound MAVLink messages. This is incorrect documentation and can lead users to wrong configuration/expectations.

The telemetry MAVLink code contains an explicit receive loop and dispatches received message IDs.

• docs/Telemetry.md[205-210]
• src/main/telemetry/mavlink.c[1388-1433]
• src/main/telemetry/mavlink.c[1444-1456]

docs/Telemetry.md no longer states SoftSerial is limited to 19200 baud, but docs/Serial.md and docs/Blackbox.md still state (as a hard limit) that SoftSerial is limited to 19200. This creates contradictory documentation after this PR.

The SoftSerial code path takes a baud parameter and configures timers from it without a clear 19200 cap, so documentation that presents 19200 as a strict limit is inconsistent with the current implementation.

• docs/Telemetry.md[205-236]
• docs/Serial.md[36-49]
• docs/Blackbox.md[68-76]
• src/main/drivers/serial_softserial.c[170-189]
• src/main/drivers/serial_softserial.c[204-345]

Update the other docs to match the new reality (e.g., remove the “limited to 19200” hard-limit phrasing) or rephrase consistently as a practical/recommended limit if that’s the intended guidance (e.g., “SoftSerial may be unreliable at high baud rates; prefer hardware UART for >19200 / high bandwidth”).

After this PR, docs/Telemetry.md no longer mentions a 19200 SoftSerial limit for iBus, but docs/Serial.md and docs/Blackbox.md still claim SoftSerial is limited to 19200 baud. This is conflicting documentation.

The PR’s stated goal is to fix misleading SoftSerial-limit docs; this should be applied consistently across the documentation set.

• docs/Telemetry.md[231-237]
• docs/Serial.md[46-48]
• docs/Blackbox.md[68-75]

docs/Telemetry.md no longer states SoftSerial is limited to 19200 baud, but docs/Serial.md and docs/Blackbox.md still state (as a hard limit) that SoftSerial is limited to 19200. This creates contradictory documentation after this PR.

The SoftSerial code path takes a baud parameter and configures timers from it without a clear 19200 cap, so documentation that presents 19200 as a strict limit is inconsistent with the current implementation.

• docs/Telemetry.md[205-236]
• docs/Serial.md[36-49]
• docs/Blackbox.md[68-76]
• src/main/drivers/serial_softserial.c[170-189]
• src/main/drivers/serial_softserial.c[204-345]

Update the other docs to match the new reality (e.g., remove the “limited to 19200” hard-limit phrasing) or rephrase consistently as a practical/recommended limit if that’s the intended guidance (e.g., “SoftSerial may be unreliable at high baud rates; prefer hardware UART for >19200 / high bandwidth”).

The updated MAVLink line uses a comma splice (“transmit-only, is usable”), which is grammatically awkward and can be misread.

This is purely a documentation clarity/readability fix.

• docs/Telemetry.md[205-210]

Reword to something like:

• “MAVLink implementation in INAV is transmit-only and usable at low baud rates. MAVLink V1 and V2 are supported.”

The updated MAVLink line uses a comma splice (“transmit-only, is usable”), which is grammatically awkward and can be misread.

This is purely a documentation clarity/readability fix.

• docs/Telemetry.md[205-210]

Reword to something like:

• “MAVLink implementation in INAV is transmit-only and usable at low baud rates. MAVLink V1 and V2 are supported.”

mavlinkParseRxStats() in GENERIC mode unconditionally assigns rxLinkStatistics.uplinkRSSI = -msg->rssi;. MAVLink defines rssi == UINT8_MAX (255) as invalid/unknown, so the new code turns this into -255, which downstream code interprets as an extremely poor (but valid) dBm.

• MAVLink RADIO_STATUS.rssi is uint8_t with values [0..254], 255 = invalid/unknown.
• The same function already treats msg->rssi != 255 specially for LQ, indicating the sentinel is expected.
• OSD displays rxLinkStatistics.uplinkRSSI directly and compares it to osdConfig()->rssi_dbm_alarm, so -255 can trigger alarms even though RSSI is unknown.

• src/main/telemetry/mavlink.c[1318-1328]

• Only negate when msg->rssi != UINT8_MAX; otherwise set uplinkRSSI to a defined “unknown” representation that won’t be misinterpreted as a real low dBm (e.g. 0, or a dedicated sentinel plus consumer handling).
• Make the cast explicit to avoid any ambiguity: -(int16_t)msg->rssi.

mavlinkParseRxStats() in GENERIC mode unconditionally assigns rxLinkStatistics.uplinkRSSI = -msg->rssi;. MAVLink defines rssi == UINT8_MAX (255) as invalid/unknown, so the new code turns this into -255, which downstream code interprets as an extremely poor (but valid) dBm.

• MAVLink RADIO_STATUS.rssi is uint8_t with values [0..254], 255 = invalid/unknown.
• The same function already treats msg->rssi != 255 specially for LQ, indicating the sentinel is expected.
• OSD displays rxLinkStatistics.uplinkRSSI directly and compares it to osdConfig()->rssi_dbm_alarm, so -255 can trigger alarms even though RSSI is unknown.

• src/main/telemetry/mavlink.c[1318-1328]

• Only negate when msg->rssi != UINT8_MAX; otherwise set uplinkRSSI to a defined “unknown” representation that won’t be misinterpreted as a real low dBm (e.g. 0, or a dedicated sentinel plus consumer handling).
• Make the cast explicit to avoid any ambiguity: -(int16_t)msg->rssi.

mavlinkParseRxStats() in GENERIC mode unconditionally assigns rxLinkStatistics.uplinkRSSI = -msg->rssi;. MAVLink defines rssi == UINT8_MAX (255) as invalid/unknown, so the new code turns this into -255, which downstream code interprets as an extremely poor (but valid) dBm.

• MAVLink RADIO_STATUS.rssi is uint8_t with values [0..254], 255 = invalid/unknown.
• The same function already treats msg->rssi != 255 specially for LQ, indicating the sentinel is expected.
• OSD displays rxLinkStatistics.uplinkRSSI directly and compares it to osdConfig()->rssi_dbm_alarm, so -255 can trigger alarms even though RSSI is unknown.

• src/main/telemetry/mavlink.c[1318-1328]

• Only negate when msg->rssi != UINT8_MAX; otherwise set uplinkRSSI to a defined “unknown” representation that won’t be misinterpreted as a real low dBm (e.g. 0, or a dedicated sentinel plus consumer handling).
• Make the cast explicit to avoid any ambiguity: -(int16_t)msg->rssi.

hrstSent is a function-static counter used to rate-limit the "HRST" indication when BOXHOMERESET is active, but it is never reset when the mode becomes inactive. This permanently disables the HRST indication after the first limited run.

A similar flight-mode text implementation resets hrstSent when BOXHOMERESET is not active, allowing each new activation to show the indication again.

• src/main/telemetry/hott.c[229-382]

• After the flight-mode selection logic, add something like:
• if (!IS_RC_MODE_ACTIVE(BOXHOMERESET) && hrstSent > 0) hrstSent = 0;
• Optionally also reset hrstSent when disarmed to avoid carrying state across arm cycles.

The function returns early on !STATE(GPS_FIX) (or !STATE(GPS_FIX) && !STATE(GPS_ESTIMATED_FIX)), skipping the newly added free_char status updates. Because the message struct is reused across calls (not memset each time), the free_char bytes can retain stale values after GPS fix loss.

initialiseGPSMessage() zeros the struct once at init; hottPrepareGPSResponse() mutates fields in-place and has an early return on no-fix.

• src/main/telemetry/hott.c[180-187]
• src/main/telemetry/hott.c[229-381]

Choose one of:

1. Set a safe default for free_char1..3 (e.g. blanks or "---" / "NOF") before the GPS-fix early return and also set them in the no-fix branch.
2. Move the free_char flight-mode/status computation above the GPS-fix early return so it always runs. Also consider clearing home_direction/flight_direction in the no-fix path to avoid other stale fields.

hrstSent is a function-static counter used to rate-limit the "HRST" indication when BOXHOMERESET is active, but it is never reset when the mode becomes inactive. This permanently disables the HRST indication after the first limited run.

A similar flight-mode text implementation resets hrstSent when BOXHOMERESET is not active, allowing each new activation to show the indication again.

• src/main/telemetry/hott.c[229-382]

• After the flight-mode selection logic, add something like:
• if (!IS_RC_MODE_ACTIVE(BOXHOMERESET) && hrstSent > 0) hrstSent = 0;
• Optionally also reset hrstSent when disarmed to avoid carrying state across arm cycles.

The function returns early on !STATE(GPS_FIX) (or !STATE(GPS_FIX) && !STATE(GPS_ESTIMATED_FIX)), skipping the newly added free_char status updates. Because the message struct is reused across calls (not memset each time), the free_char bytes can retain stale values after GPS fix loss.

initialiseGPSMessage() zeros the struct once at init; hottPrepareGPSResponse() mutates fields in-place and has an early return on no-fix.

• src/main/telemetry/hott.c[180-187]
• src/main/telemetry/hott.c[229-381]

Choose one of:

1. Set a safe default for free_char1..3 (e.g. blanks or "---" / "NOF") before the GPS-fix early return and also set them in the no-fix branch.
2. Move the free_char flight-mode/status computation above the GPS-fix early return so it always runs. Also consider clearing home_direction/flight_direction in the no-fix path to avoid other stale fields.

hrstSent is a function-static counter used to rate-limit the "HRST" indication when BOXHOMERESET is active, but it is never reset when the mode becomes inactive. This permanently disables the HRST indication after the first limited run.

A similar flight-mode text implementation resets hrstSent when BOXHOMERESET is not active, allowing each new activation to show the indication again.

• src/main/telemetry/hott.c[229-382]

• After the flight-mode selection logic, add something like:
• if (!IS_RC_MODE_ACTIVE(BOXHOMERESET) && hrstSent > 0) hrstSent = 0;
• Optionally also reset hrstSent when disarmed to avoid carrying state across arm cycles.

The function returns early on !STATE(GPS_FIX) (or !STATE(GPS_FIX) && !STATE(GPS_ESTIMATED_FIX)), skipping the newly added free_char status updates. Because the message struct is reused across calls (not memset each time), the free_char bytes can retain stale values after GPS fix loss.

initialiseGPSMessage() zeros the struct once at init; hottPrepareGPSResponse() mutates fields in-place and has an early return on no-fix.

• src/main/telemetry/hott.c[180-187]
• src/main/telemetry/hott.c[229-381]

Choose one of:

1. Set a safe default for free_char1..3 (e.g. blanks or "---" / "NOF") before the GPS-fix early return and also set them in the no-fix branch.
2. Move the free_char flight-mode/status computation above the GPS-fix early return so it always runs. Also consider clearing home_direction/flight_direction in the no-fix path to avoid other stale fields.

The retry loop in icm40609dDeviceDetect() runs one extra time due to do { ... } while (attemptsRemaining--); with an unsigned counter. This adds an extra delay on failed detection and obscures intent.

This does not cause an infinite loop, but it does perform 6 attempts when initialized to 5.

• src/main/drivers/accgyro/accgyro_icm40609d.c[174-198]

Replace with an explicit bounded loop, e.g.:

The retry loop in icm40609dDeviceDetect() runs one extra time due to do { ... } while (attemptsRemaining--); with an unsigned counter. This adds an extra delay on failed detection and obscures intent.

This does not cause an infinite loop, but it does perform 6 attempts when initialized to 5.

• src/main/drivers/accgyro/accgyro_icm40609d.c[174-198]

Replace with an explicit bounded loop, e.g.:

MSP2_INAV_WIND currently writes wind speed/angle values unconditionally, and only sets a validity flag afterward. Because the wind estimator can become invalid without clearing the last estimated wind vector, the MSP reply can contain non-zero (stale) values while flags.bit0 == 0, contradicting the documented contract (“0 if unavailable”).

• getEstimatedHorizontalWindSpeed() computes magnitude/angle from cached estimatedWind[] regardless of validity.
• The estimator invalidation path clears hasValidWindEstimate but does not reset estimatedWind[].
• The MSP docs for MSP2_INAV_WIND state the fields are zero when unavailable.

• src/main/fc/fc_msp.c[1603-1618]

• Check isEstimatedWindSpeedValid() first.
• If invalid: write windSpeed=0, windAngle=0, flags=0.
• If valid: compute and write speed/angle, set flags=1.
• Optionally clamp the float speed to [0, UINT16_MAX] before casting to avoid wrap/truncation surprises.

getActiveSpeed() assigns navWaypoint_t.p1/p2 (signed int16_t) to a uint16_t temporary and returns it for AIRPLANE without validating it. Negative values (e.g. -1) become large unsigned values (e.g. 65535) and later get clamped to maxSpeed, producing an unintended full-speed demand.

Waypoint params are stored in navWaypoint_t as signed integers. The fixed-wing WP Auto Speed path uses getActiveSpeed() to derive speed demand and constrains it between fw_auto_speed_min_speed and fw_auto_speed_max_speed.

• src/main/navigation/navigation.c[4321-4353]
• src/main/navigation/navigation.h[553-560]
• src/main/navigation/navigation_fixedwing.c[939-948]

• Keep waypoint speed as a signed type (int16_t) when reading p1/p2.
• Treat <= 0 as “no WP speed set” (return 0 or fall back to configured default).
• Optionally clamp to sane bounds before returning (e.g., MIN(wpSpeed, navConfig()->general.max_auto_speed) for MR; for FW, either clamp or rely on the later constrain but only after ensuring non-negative).

autoSpeedIsActive is defined at file scope without static, giving it external linkage even though it is only referenced inside navigation_fixedwing.c.

There is already a public accessor isFixedwingAutoSpeedActive(), so the backing flag does not need external linkage.

• src/main/navigation/navigation_fixedwing.c[74-78]

Change the definition to static bool autoSpeedIsActive = false; (or move it into a private module struct) to keep the symbol local to the translation unit.

SYNERDUINOSTM_F405/target.h defines USE_IMU_BMI088 but does not provide the BMI088-specific configuration macros (BMI088_SPI_BUS + BMI088_GYRO_CS_PIN/BMI088_ACC_CS_PIN, or BMI088_I2C_BUS). Because common_hardware.c only registers BMI088 bus devices when those BMI088_* macros exist, the firmware will have no BMI088 device descriptors and BMI088 detection will fail.

This target currently sets BMI160_CS_PIN / BMI160_SPI_BUS in the BMI088 section, which doesn’t satisfy the BMI088 registration logic.

• src/main/target/SYNERDUINOSTM_F405/target.h[59-67]
• src/main/target/common_hardware.c[68-75]

SYNERDUINOH7/target.h selects SPI1 (USE_SPI_DEVICE_1, BUS_SPI1) but defines SPI2_SCK_PIN/SPI2_MISO_PIN/SPI2_MOSI_PIN. The SPI driver maps SPI1 using the SPI1_* macros, so these SPI2_* definitions are ignored for the active bus and can confuse future maintenance.

Currently the defined values happen to match SPI1 defaults on many boards (PA5/PA6/PA7), but the naming mismatch means any future non-default wiring/pin changes will silently not apply.

• src/main/target/SYNERDUINOH7/target.h[99-116]
• src/main/drivers/bus_spi.c[31-36]
• src/main/drivers/bus_spi.c[83-91]

The target defines PWM-beeper parameters (BEEPER_PWM_FREQUENCY and a TIM_USE_BEEPER timer mapping), but targetConfiguration() does not enable beeperConfig()->pwmMode. As a result, beeperPwmInit() is not called and the timer-based beeper output is never configured.

sound_beeper.c only initializes PWM beeper when beeperConfig()->pwmMode is true; otherwise it uses GPIO toggling.

• src/main/target/HUMMINGBIRD_FC305_H7/config.c[18-29]

1. Include fc/config.h in config.c.
2. Set beeperConfigMutable()->pwmMode = true; in targetConfiguration() (if the hardware is passive / intended to use PWM).
3. If the hardware is actually an active buzzer, remove the PWM-specific configuration (timer mapping / frequency) to avoid confusion.

TARGET_BOARD_IDENTIFIER is duplicated between two different targets (HUMMINGBIRD_FC305 and HUMMINGBIRD_FC305_H7). Since MSP exports this identifier, tools/users relying on boardIdentifier cannot reliably distinguish which firmware/target is running.

The new target defines TARGET_BOARD_IDENTIFIER "HBRD", but the existing HUMMINGBIRD_FC305 target already uses the same identifier.

• src/main/target/HUMMINGBIRD_FC305_H7/target.h[20-22]

Change TARGET_BOARD_IDENTIFIER for HUMMINGBIRD_FC305_H7 to a unique (ideally 4-character, uppercase) identifier, and ensure any documentation/release tooling that references the identifier is updated accordingly.

A rebooting peripheral can be mistaken for a conflicting live node because its previous NodeStatus entry remains cached for 10 seconds. This causes its persisted node ID to be replaced during rapid restart.

The live-node table contains only node IDs and retains them until the stale timeout, so presence in that table does not prove another node is still broadcasting. Preserve the stored mapping unless the occupant is verified as a different currently-live node, or defer allocation until the cached entry expires.

• src/main/drivers/dronecan/dronecan_dna_server.c[177-192]
• src/main/drivers/dronecan/dronecan_node_status.c[150-161]
• src/main/drivers/dronecan/dronecan.h[58-58]

dronecanAsyncCheckTimeout() is executed before processing queued RX frames in dronecanUpdate(). If a response arrives just before the timeout boundary but the next dronecanUpdate() tick occurs at/after the boundary, the slot can be marked ERROR and the queued response will then be ignored by dronecanAsyncHandleServiceResponse() (it only processes when state==PENDING).

The timeout logic uses millis() granularity, so boundary effects are realistic. A correct implementation should always give queued RX frames a chance to resolve the slot before expiring it.

• src/main/drivers/dronecan/dronecan.c[145-168]
• src/main/drivers/dronecan/dronecan_async.c[159-168]

Reorder the NORMAL-state loop so it drains RX (and any resulting TX) first, then calls dronecanAsyncCheckTimeout() after RX handling. Optionally, call the timeout check once per loop iteration after RX+TX drain, so a response in the FIFO always wins over expiring the slot.

getGyroAafConfig() uses int8_t selectedFreq to hold LUT frequencies. For the 42688/42686 path the LUT includes values >127 (e.g. 258, 303), which overflow int8_t and can cause the function to pick the wrong AAF candidate.

This function selects the closest supported AAF cutoff frequency by comparing ABS(desiredFreq - aafConfigs[i].freq) against ABS(desiredFreq - selectedFreq). If selectedFreq wraps, the comparison becomes invalid.

• Change selectedFreq to a wide signed type (e.g. int32_t or uint16_t, but prefer int32_t for safe signed subtraction).
• Ensure the subtraction is performed in a sufficiently wide signed type, e.g.:
  • const int32_t desired = desiredFreq;
  • compare ABS(desired - (int32_t)aafConfigs[i].freq)

• src/main/drivers/accgyro/accgyro_icm42605.c[415-443]