Starting the 10.x branch from 9.x

.github/workflows/ci.yml

@@ -256,11 +256,15 @@ jobs:
           for f in ./build_SITL/*_SITL.exe; do
             mv $f $(echo $f | sed -e 's/_[0-9]\+\.[0-9]\+\.[0-9]\+//')
           done
+      - name: Copy cygwin1.dll
+        run: cp /bin/cygwin1.dll ./build_SITL/
       - name: Upload artifacts
         uses: actions/upload-artifact@v4
         with:
           name: ${{ env.BUILD_NAME }}_SITL-WIN
-          path: ./build_SITL/*.exe
+          path: |
+            ./build_SITL/*.exe
+            ./build_SITL/cygwin1.dll
 
   test:
     #needs: [build]

.github/workflows/nightly-build.yml

@@ -2,11 +2,12 @@ name: Build pre-release
 # Don't enable CI on push, just on PR. If you
 # are working on the main repo and want to trigger
 # a CI build submit a draft PR.
-on: 
+on:
   push:
     branches:
       - master
       - maintenance-8.x.x
+      - maintenance-9.x
     paths:
       - 'src/**'
       - '.github/**'

.github/workflows/pr-branch-suggestion.yml

@@ -0,0 +1,41 @@
+name: PR Branch Suggestion
+
+on:
+  pull_request_target:
+    types: [opened]
+    branches:
+      - master
+
+jobs:
+  suggest-branch:
+    runs-on: ubuntu-latest
+    permissions:
+      pull-requests: write
+    steps:
+      - name: Suggest maintenance branch
+        uses: actions/github-script@v7
+        with:
+          script: |
+            const comment = `### Branch Targeting Suggestion
+
+            You've targeted the \`master\` branch with this PR. Please consider if a version branch might be more appropriate:
+
+            - **\`maintenance-9.x\`** - If your change is backward-compatible and won't create compatibility issues between INAV firmware and Configurator 9.x versions. This will allow your PR to be included in the next 9.x release.
+
+            - **\`maintenance-10.x\`** - If your change introduces compatibility requirements between firmware and configurator that would break 9.x compatibility. This is for PRs which will be included in INAV 10.x
+
+            If \`master\` is the correct target for this change, no action is needed.
+
+            ---
+            *This is an automated suggestion to help route contributions to the appropriate branch.*`;
+
+            try {
+              await github.rest.issues.createComment({
+                issue_number: context.issue.number,
+                owner: context.repo.owner,
+                repo: context.repo.repo,
+                body: comment
+              });
+            } catch (err) {
+              core.setFailed(`Failed to post suggestion comment: ${err}`);
+            }

docs/Battery.md

@@ -169,6 +169,155 @@ current_meter_scale = (reported_draw_mAh / charging_data_mAh) * old_current_mete
                     = 435
 ```
 
+## Power and Current Limiting
+
+INAV includes an advanced power and current limiting system to protect your battery and ESCs from excessive discharge rates. This feature automatically reduces throttle output when current or power draw exceeds configured limits.
+
+### Why Use Power Limiting?
+
+Power and current limiting helps:
+- **Protect batteries** from exceeding their C-rating and getting damaged
+- **Prevent voltage sag** and brown-outs during high-throttle maneuvers
+- **Extend battery lifespan** by avoiding excessive discharge rates
+- **Improve safety** by preventing ESC or battery overheating
+- **Comply with regulations** that may limit power output
+
+### How It Works
+
+The power limiter uses a PI (Proportional-Integral) controller to smoothly reduce throttle when current or power exceeds limits. It supports two operating modes:
+
+1. **Continuous Limit**: The sustained current/power that can be drawn indefinitely
+2. **Burst Limit**: A higher current/power allowed for a short duration before falling back to the continuous limit
+
+This burst mode allows brief high-power maneuvers (like punch-outs or quick climbs) while protecting the battery during sustained high-throttle flight.
+
+### Configuration
+
+Power limiting requires a current sensor (`CURRENT_METER` feature). Power-based limiting additionally requires voltage measurement (`VBAT` feature).
+
+#### Basic Settings (per battery profile)
+
+| Setting | Description | Unit | Range |
+|---------|-------------|------|-------|
+| `limit_cont_current` | Continuous current limit | dA (deci-amps) | 0-2000 (0-200A) |
+| `limit_burst_current` | Burst current limit | dA | 0-2000 (0-200A) |
+| `limit_burst_current_time` | Duration burst is allowed | ds (deci-seconds) | 0-600 (0-60s) |
+| `limit_burst_current_falldown_time` | Ramp-down duration from burst to continuous | ds | 0-600 (0-60s) |
+| `limit_cont_power` | Continuous power limit | dW (deci-watts) | 0-20000 (0-2000W) |
+| `limit_burst_power` | Burst power limit | dW | 0-20000 (0-2000W) |
+| `limit_burst_power_time` | Duration burst power is allowed | ds | 0-600 (0-60s) |
+| `limit_burst_power_falldown_time` | Ramp-down duration for power | ds | 0-600 (0-60s) |
+
+**Note**: Set any limit to `0` to disable that specific limiter.
+
+#### Advanced Tuning Settings
+
+| Setting | Description | Default | Range |
+|---------|-------------|---------|-------|
+| `limit_pi_p` | Proportional gain for PI controller | 100 | 10-500 |
+| `limit_pi_i` | Integral gain for PI controller | 15 | 10-200 |
+| `limit_attn_filter_cutoff` | Low-pass filter cutoff frequency | 50 Hz | 10-200 |
+
+### Example Configurations
+
+#### Example 1: Simple Current Limiting (50A continuous)
+
+Protect a 1500mAh 4S 50C battery (75A max burst, 50A continuous safe):
+
+```
+battery_profile 1
+
+set limit_cont_current = 500         # 50A continuous
+set limit_burst_current = 750        # 75A burst
+set limit_burst_current_time = 100   # 10 seconds
+set limit_burst_current_falldown_time = 20   # 2 second ramp-down
+```
+
+#### Example 2: Power Limiting for Racing (500W limit)
+
+Limit total system power for racing class restrictions:
+
+```
+battery_profile 1
+
+set limit_cont_power = 4500          # 450W continuous
+set limit_burst_power = 5000         # 500W burst
+set limit_burst_power_time = 50      # 5 seconds
+set limit_burst_power_falldown_time = 10    # 1 second ramp-down
+```
+
+#### Example 3: Combined Current and Power Limiting
+
+Protect both battery (current) and ESCs (power):
+
+```
+battery_profile 1
+
+# Current limits (battery protection)
+set limit_cont_current = 600         # 60A continuous
+set limit_burst_current = 800        # 80A burst
+set limit_burst_current_time = 100   # 10 seconds
+
+# Power limits (ESC protection)
+set limit_cont_power = 8000          # 800W continuous
+set limit_burst_power = 10000        # 1000W burst
+set limit_burst_power_time = 100     # 10 seconds
+```
+
+### Understanding Burst Mode
+
+When you exceed the continuous limit, the system uses "burst reserve" (like a capacitor):
+- **Burst reserve** starts full and depletes when current/power exceeds the continuous limit
+- When reserve is empty, the limit drops to the continuous value
+- The `falldown_time` setting creates a smooth ramp-down instead of an abrupt drop
+- Reserve recharges when current/power drops below the continuous limit
+
+**Example timeline** (60A continuous, 80A burst, 10s burst time, 2s falldown):
+```
+Time    Limit    Reason
+----    -----    ------
+0s      80A      Full burst reserve
+5s      80A      Still have reserve (using 5s of 10s)
+10s     80A      Reserve depleted
+10-12s  80→60A   Ramping down over 2 seconds
+12s+    60A      Continuous limit active
+```
+
+### OSD Elements
+
+Three OSD elements display power limiting status:
+
+- **`OSD_PLIMIT_REMAINING_BURST_TIME`**: Shows remaining burst time in seconds
+- **`OSD_PLIMIT_ACTIVE_CURRENT_LIMIT`**: Shows current limit being enforced (blinks when limiting)
+- **`OSD_PLIMIT_ACTIVE_POWER_LIMIT`**: Shows power limit being enforced (blinks when limiting)
+
+Enable these in the OSD tab to monitor limiting during flight.
+
+### Calibration Tips
+
+1. **Find your battery's limits**: Check manufacturer specifications for continuous and burst C-ratings
+   - Continuous limit = `battery_capacity_mAh × continuous_C_rating / 100` (in dA)
+   - Burst limit = `battery_capacity_mAh × burst_C_rating / 100` (in dA)
+
+2. **Test incrementally**: Start with conservative limits and increase gradually
+
+3. **Monitor in flight**: Use OSD elements to see when limiting activates
+
+4. **Calibrate current sensor**: Accurate current readings are critical - see "Current Monitoring" section above
+
+5. **Tune PI controller**: If limiting feels abrupt or causes oscillation, adjust `limit_pi_p` and `limit_pi_i`:
+   - Increase P for faster response (may cause oscillation)
+   - Increase I for better steady-state accuracy
+   - Decrease if throttle oscillates during limiting
+
+### Notes
+
+- Power limiting is part of the battery profile system - each profile can have different limits
+- Both current and power limiting can be active simultaneously - the most restrictive applies
+- Limiting is applied smoothly via PI controller to avoid abrupt throttle cuts
+- The system uses instantaneous current/power readings for responsive limiting
+- Set limits to `0` to disable a specific limiter while keeping others active
+
 ## Battery capacity monitoring
 
 For the capacity monitoring to work you need a current sensor (`CURRENT_METER` feature). For monitoring energy in milliWatt hour you also need voltage measurement (`VBAT` feature). For best results the current and voltage readings have to be calibrated.

docs/Blackbox.md

@@ -120,6 +120,7 @@ These chips are also supported:
 * Winbond W25Q64 - 64 Mbit / 8 MByte
 * Micron N25Q0128 - 128 Mbit / 16 MByte
 * Winbond W25Q128 - 128 Mbit / 16 MByte
+* Puya PY25Q128HA - 128 Mbit / 16 MByte
 * Winbond W25N01  - 1 Gbit / 128 MByte
 * Winbond W25N02  - 2 Gbit / 256 MByte
 
@@ -165,13 +166,36 @@ The CLI command `blackbox` allows setting which Blackbox fields are recorded to
 * `PEAKS_R` - Roll axis noise peak
 * `PEAKS_P` - Pitch axis noise peak
 * `PEAKS_Y` - Yaw axis noise peak
+* `SERVOS` - Servo outputs (for planes, tris, etc.)
 
 Usage:
 
 * `blackbox` currently enabled Blackbox fields
 * `blackbox list` all available fields
 * `blackbox -MOTORS` disable MOTORS logging
-* `blackbox MOTOR` enable MOTORS logging
+* `blackbox MOTORS` enable MOTORS logging
+
+### Debug Mode Logging
+
+In addition to the standard blackbox fields above, INAV supports logging debug values for troubleshooting and analysis via the `debug_mode` setting. When a debug mode is active, it populates 8 debug values (`debug[0]` through `debug[7]`) with mode-specific data that gets logged to the blackbox.
+
+Available debug modes include:
+- `FLOW_RAW` - Optical flow sensor raw data (useful for sensor alignment)
+- `LANDING` - Landing mode debugging
+- `POS_EST` - Position estimation debugging
+- `GPS` - GPS debugging
+- `ALTITUDE` - Altitude estimation debugging
+- And 20+ other modes for specific subsystems
+
+To use debug mode logging:
+```
+set debug_mode = FLOW_RAW    # Enable a specific debug mode
+set debug_mode = NONE        # Disable debug mode (default)
+```
+
+You can view current debug values in the CLI with the `debug` command, or display them in real-time on your OSD using the `OSD_DEBUG` element.
+
+For technical details on debug logging and blackbox internals, see the [Blackbox Internals](development/Blackbox%20Internals.md) documentation.
 
 ## Usage
 

docs/LedStrip.md

@@ -71,7 +71,7 @@ Enable the Led Strip feature via the GUI under setup.
 Configure the leds from the Led Strip tab in the INAV GUI.
 First setup how the led's are laid out so that you can visualize it later as you configure and so the flight controller knows how many led's there are available.
 
-There is a step by step guide on how to use the GUI to configure the Led Strip feature using the GUI http://blog.oscarliang.net/setup-rgb-led-cleanflight/ which was published early 2015 by Oscar Liang which may or may not be up-to-date by the time you read this.
+There is a step by step guide on how to use the GUI to configure the Led Strip feature using the GUI https://oscarliang.com/setup-led-betaflight/ which was published early 2015 by Oscar Liang which may or may not be up-to-date by the time you read this.
 
 CLI:
 Enable the `LED_STRIP` feature via the cli:
@@ -605,4 +605,4 @@ This also means that you can make sure that each R,G and B LED in each LED modul
 
 After a short delay the LEDs will show the unarmed color sequence and or low-battery warning sequence.
 
-Also check that the feature `LED_STRIP` was correctly enabled and that it does not conflict with other features, as above.
+Also check that the feature `LED_STRIP` was correctly enabled and that it does not conflict with other features, as above.

docs/OSD.md

@@ -200,6 +200,7 @@ Here are the OSD Elements provided by INAV.
 | 165 | OSD_V_DIST_TO_FENCE                              | 8.0.0  |       |
 | 166 | OSD_NAV_FW_ALT_CONTROL_RESPONSE                  | 8.0.0  |       |
 | 167 | OSD_NAV_MIN_GROUND_SPEED                         | 9.0.0  |       |
+| 168 | OSD_THROTTLE_GAUGE                               | 9.0.0  |       |
 
 # Pilot Logos
 

docs/Settings.md

@@ -432,6 +432,16 @@ Max Antigravity gain. `1` means Antigravity is disabled, `2` means Iterm is allo
 
 ---
 
+### apa_pow
+
+Use airspeed instead of throttle position for PID attenuation if airspeed is available on fixedwing. Scales P/D/FF with airspeed (I-term scaled less aggressively). Gains range from 30% (high speed) to 150% (low speed). Set to 0 to disable and use throttle-based attenuation. Recommended: 120 for aircraft with validated pitot sensor.
+
+| Default | Min | Max |
+| --- | --- | --- |
+| 0 | 0 | 200 |
+
+---
+
 ### applied_defaults
 
 Internal (configurator) hint. Should not be changed manually
@@ -1468,7 +1478,7 @@ TPA smoothing and delay time constant to reflect non-instant speed/throttle resp
 
 | Default | Min | Max |
 | --- | --- | --- |
-| 1500 | 0 | 5000 |
+| 2000 | 0 | 5000 |
 
 ---
 
@@ -6442,13 +6452,23 @@ Throttle PID attenuation also reduces influence on YAW for multi-rotor, Should b
 
 ---
 
+### tpa_pitch_compensation
+
+Pitch angle based throttle compensation for fixed wing. Positive values will increase throttle when pitching up, and decrease throttle when pitching down.
+
+| Default | Min | Max |
+| --- | --- | --- |
+| 8 | 0 | 20 |
+
+---
+
 ### tpa_rate
 
-Throttle PID attenuation reduces influence of PDFF on ROLL and PITCH of multi-rotor, PIDFF on ROLL,PITCH,YAW OF fixed_wing as throttle increases. For every 1% throttle after the TPA breakpoint, P is reduced by the TPA rate.
+Throttle based PID attenuation(TPA) reduces influence of PDFF on ROLL and PITCH of multi-rotor, PIDFF on ROLL,PITCH,YAW OF fixed_wing as throttle increases. On multirotor, For every 1% throttle after the TPA breakpoint, P is reduced by the TPA rate. for fixedwing modifies PIDFF. See **PID Attenuation and scaling** Wiki for full details.
 
 | Default | Min | Max |
 | --- | --- | --- |
-| 0 | 0 | 100 |
+| 0 | 0 | 200 |
 
 ---
 

docs/USB Flashing.md

@@ -68,14 +68,26 @@ With the board connected and in bootloader mode (reset it by sending the charact
 
 Put the device into DFU mode by **one** of the following:
 
-* Use the hardware button on the board
-* Send a single 'R' character to the serial device, e.g. on POSIX OS using `/dev/ttyACM0` at 115200 baudrate.
+* **Hardware button:** Press and hold the DFU/BOOT button while plugging in USB
 
+* **Serial CLI sequence:** Send `####\r\n`, wait for CLI prompt, then send `dfu\r\n`
+
+```bash
+# Enter CLI mode
+echo -ne '####\r\n' > /dev/ttyACM0
+
+# Wait for "CLI" prompt (important - don't skip!)
+# Recommended: use a proper script that reads serial response
+
+# Send DFU command
+echo -ne 'dfu\r\n' > /dev/ttyACM0
 ```
-stty 115200 < /dev/ttyACM0
-echo -ne 'R' > /dev/ttyACM0
-```
-* Use the CLI command `dfu`
+
+**Note:** The simple single 'R' character method shown in older documentation is unreliable. The above sequence is required for proper CLI entry.
+
+* **CLI command:** If already connected to CLI via configurator or terminal: type `dfu`
+
+* **MSP command:** Use MSP_REBOOT with DFU parameter (INAV 9.x+) - most reliable programmatic method
 
 It is necessary to convert the `.hex` file into `Intel binary`. This can be done using the GCC `objcopy` command; e.g. for the notional `inav_x.y.z_NNNNNN.hex`.