MSP2_INAV_SET_AUX_RC (0x2230) — Bandwidth-efficient auxiliary RC channel updates by b14ckyy · Pull Request #11482 · iNavFlight/inav

b14ckyy · 2026-04-06T13:56:48Z

Summary

Adds a new MSPv2 command MSP2_INAV_SET_AUX_RC (0x2230) that allows lightweight updates to auxiliary RC channels (CH13–CH32) with configurable resolution. Designed for extending channel count beyond native RC link capacity via MSP passthrough (SmartPort, CRSF, FPort) without the overhead of MSP_SET_RAW_RC.

Motivation

Most common RC links are limited to 12–16 channels but offer native MSP passthrough. MSP_SET_RAW_RC is impractical over these links because it always starts at CH1, sends 2 bytes per channel, and scaling up to higher channels causes payload fragmentation across multiple transport chunks — killing passthrough performance.

MSP2_INAV_SET_AUX_RC solves this with:

Arbitrary start channel — target any channel range CH13+ without preceding channels
Configurable resolution — 2/4/8/16 bits per channel (only as much data as needed)
Non-destructive skip — value 0 = no update, previous value persists

Example savings: 8 channels above CH16 in 8-bit mode = 18 bytes vs 52 bytes with MSP_SET_RAW_RC (65% reduction).

Changes

New feature: `MSP2_INAV_SET_AUX_RC`

src/main/msp/msp_protocol_v2_inav.h

Define MSP2_INAV_SET_AUX_RC 0x2230

src/main/rx/rx.h / src/main/rx/rx.c

Add static uint16_t mspAuxOverlay[] — persistent overlay array for CH13–CH32
Add rxMspAuxOverlaySet(channelIndex, value) — setter with bounds validation (index 12–31)
Apply overlay in calculateRxChannelsAndUpdateFailsafe() — after MSP RC Override, before failsafe evaluation

src/main/rx/msp.c / src/main/rx/msp.h

Track last MSP_SET_RAW_RC channel count via rxMspGetLastChannelCount()
Used to prevent AUX_RC from overlapping with MSP RX provider channels

src/main/fc/fc_msp.c

Add case MSP2_INAV_SET_AUX_RC: handler with:
- Definition byte parsing (start channel + resolution mode)
- CH1–CH12 rejection (safety guard)
- Multi-resolution decoding: 2-bit (3 positions), 4-bit (~71µs steps), 8-bit (~3.9µs steps), 16-bit (raw PWM, clamped to 750–2250µs)
- Sub-byte unpacking (MSB-first for 2-bit/4-bit modes)
- Payload size validation (2–49 bytes, rejects oversized payloads to prevent uint8_t overflow)
- Comprehensive validation (bounds, even byte count for 16-bit, reserved modes)

docs/development/msp/msp_messages.json

Add MSP2_INAV_SET_AUX_RC entry with full field documentation

Included bugfixes (from separate PRs, merged into base branch):

Fix MSP-over-telemetry multi-frame request assembly #11478 — initSharedMsp() response buffer initialization fix
Fix MSP_RESULT_NO_REPLY ignored in MSP-over-telemetry passthrough #11481 — MSP_FLAG_DONT_REPLY handling fix for telemetry passthrough

Safety Design

CH1–CH12 are rejected by design (MSP_RESULT_ERROR). These channels carry:

CH1–CH4: AETR (primary flight controls)
CH5–CH12: Arming, flight modes, and safety-critical switches. All modern RC protocols provide at least 12 channels natively — there is no valid reason to control these via AUX_RC.

This means MSP2_SET_AUX_RC should not arm/disarm, change flight modes, or take over aircraft control. No USE_RX_MSP, no MSP-RC-OVERRIDE flight mode, no additional safety gates required — any MSP source can safely update aux channels at any time.

Overlay priority & safeguards

The overlay applies as the last writer in calculateRxChannelsAndUpdateFailsafe():

Normal RX channels are read (SBUS/CRSF/FPort/etc.)
MSP RC Override is applied (if active)
MSP AUX Overlay is applied (CH13–CH32 only, non-zero values)
Failsafe evaluation runs (incoming AUX_RC channel values do not prevent failsafe trigger)

Three safeguards prevent unintended channel conflicts:

Guard	Scope	Behavior
CH1–CH12 hard block	All configurations	`MSP_RESULT_ERROR` — message rejected if `startChannel < 12`
MSP RX channel count	`RX_TYPE_MSP` only (e.g. mLRS)	Overlay starts at `max(12, mspLastChannelCount)` — channels covered by `MSP_SET_RAW_RC` are skipped silently
MSP_RC_OVERRIDE bitmask	When `BOXMSPRCOVERRIDE` mode is active	Channels in the `mspOverrideChannels` bitmask are skipped silently

Note: For serial RX protocols (SBUS, CRSF, FPort, etc.), the protocol drivers report their maximum capacity (up to 34 channels) rather than actual sender channel count. The firmware cannot reliably detect which channels the sender actively uses. If AUX_RC targets a channel that the RX link also sends, AUX_RC wins (last writer). It is the user's responsibility to configure AUX_RC start channel above their RX link's active channel range.

No failsafe interaction

The overlay does not affect RX signal loss detection or failsafe triggering. If the primary RX link is lost, failsafe triggers normally regardless of overlay state.

Message Format (Quick Reference)

Definition byte [1 byte]:
  Bits 7-3: start channel (12-31 valid, 0-11 rejected)
  Bits 2-0: resolution (0=2-bit, 1=4-bit, 2=8-bit, 3=16-bit, 4-7=reserved/error)

Payload: [defByte] [channel data...]
  Min 2 bytes, max 49 bytes.
  Channel count derived from (payloadSize - 1) and resolution.
  Value 0 = skip (no update). Sub-byte packing: MSB-first.
  16-bit values clamped to 750-2250µs (prevents int16_t overflow in rcChannels).

Recommended:

Send with MSP_FLAG_DONT_REPLY (flags=0x01) on passthrough links for faster update rate for periodic updates
Send MSP2_SET_AUX_RC only when channel values change and not periodically to reduce bandwidth (values are persistent)

Testing

Build verification

MATEKF765 target builds clean (STM32F7, arm-none-eabi-gcc 13.2.1)
No new compiler warnings introduced

Hardware test setup

FC: MATEKF765 (STM32F765, INAV 9.0.1-dev)
RC link: FrSky R9 FPort + SmartPort MSP passthrough / mLRS with CRSF Passthrough custom build
Sender: Custom LUA script on radio sending raw MSPv2 frames via SmartPort/CRSF passthrough

Functional tests performed

Related PRs

Fix MSP-over-telemetry multi-frame request assembly #11478 — initSharedMsp() fix (merged into base branch)
Fix MSP_RESULT_NO_REPLY ignored in MSP-over-telemetry passthrough #11481 — MSP_FLAG_DONT_REPLY handling fix (merged into base branch)

qodo-code-review · 2026-04-06T13:57:40Z

Review Summary by Qodo

Add MSP2_INAV_SET_AUX_RC for auxiliary RC channel updates

Walkthroughs

Description

• Adds MSP2_INAV_SET_AUX_RC (0x2230) for bandwidth-efficient auxiliary RC updates
• Supports configurable resolution (2/4/8/16-bit) for CH9-CH32 channels
• Implements persistent MSP aux overlay applied post-RX, pre-failsafe
• Protects CH1-CH8 from MSP updates for flight safety

Diagram

flowchart LR
  MSP["MSP2_INAV_SET_AUX_RC<br/>0x2230"] -->|"Definition byte<br/>Start channel + resolution"| Parser["Parse channel data<br/>2/4/8/16-bit modes"]
  Parser -->|"Validate<br/>CH9-CH32 only"| Decode["Decode sub-byte<br/>or byte-aligned values"]
  Decode -->|"Skip if 0"| Overlay["Apply to mspAuxOverlay[]<br/>CH9-CH32"]
  Overlay -->|"Post-RX integration"| RxCalc["calculateRxChannelsAndUpdateFailsafe<br/>Override rcChannels after MSP RC Override"]
  RxCalc -->|"Before failsafe"| Failsafe["Failsafe evaluation<br/>unaffected"]

File Changes

1. src/main/msp/msp_protocol_v2_inav.h ⚙️ Configuration changes +2/-0

Define MSP2_INAV_SET_AUX_RC protocol constant
• Defines new MSP2 command MSP2_INAV_SET_AUX_RC with code 0x2230
• Placed in INAV-specific protocol definitions after MSP2_INAV_FULL_LOCAL_POSE
src/main/msp/msp_protocol_v2_inav.h

2. src/main/fc/fc_msp.c New feature +105/-0

Implement MSP2_INAV_SET_AUX_RC command handler

• Implements MSP2_INAV_SET_AUX_RC command handler with full message parsing
• Validates definition byte (start channel 8-31, resolution mode 0-3)
• Decodes multi-resolution channel data (2-bit, 4-bit, 8-bit, 16-bit modes)
• Handles sub-byte unpacking (MSB-first) and byte-aligned modes
• Applies decoded values via rxMspAuxOverlaySet() with skip logic (value 0 = no update)
• Comprehensive bounds checking and error handling

src/main/fc/fc_msp.c

3. src/main/rx/rx.h New feature +4/-0

Declare MSP aux overlay setter function

• Declares new public function rxMspAuxOverlaySet() for setting auxiliary RC overlay
• Adds documentation explaining CH9-CH32 overlay persistence and value=0 behavior

src/main/rx/rx.h

View more (2)

4. src/main/rx/rx.c New feature +17/-0

Add MSP aux overlay storage and integration

• Adds static mspAuxOverlay[] array for persistent CH9-CH32 value storage
• Implements rxMspAuxOverlaySet() function with bounds validation (index 8-31)
• Integrates overlay application in calculateRxChannelsAndUpdateFailsafe() after MSP RC Override
• Overlay values override rcChannels[] data for CH9-CH32 before failsafe evaluation

src/main/rx/rx.c

5. docs/development/msp/msp_messages.json 📝 Documentation +26/-0

Document MSP2_INAV_SET_AUX_RC protocol specification

• Documents MSP2_INAV_SET_AUX_RC message structure with definition byte and channel data fields
• Specifies resolution modes (2/4/8/16-bit) and value encoding for each mode
• Includes safety notes (CH1-CH8 protection, no failsafe interaction, no USE_RX_MSP required)
• Recommends MSP_FLAG_DONT_REPLY for bandwidth optimization on passthrough links

docs/development/msp/msp_messages.json

qodo-code-review · 2026-04-06T13:57:42Z

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (1) 📎 Requirement gaps (0) 🎨 UX Issues (0)

1. 16-bit PWM signed overflow 🐞 Bug ≡ Correctness

Description

In 16-bit mode the command writes an unconstrained uint16_t PWM value into the overlay, which is
later assigned into rcChannels[].data (int16_t), so values >32767 wrap negative and can break
mode/failsafe logic that assumes ~1000–2000us.

Code

src/main/rx/rx.c[R519-522]

+    for (int i = 8; i < 32; i++) {
+        if (mspAuxOverlay[i] > 0) {
+            rcChannels[i].data = mspAuxOverlay[i];
+        }

Evidence

The MSP handler copies the 16-bit payload directly into pwmValue without clamping, then stores it in
the overlay. The overlay is later applied into rcChannels[i].data, which is defined as int16_t with
an expected [1000;2000] range; assigning large uint16_t values can wrap negative.

src/main/fc/fc_msp.c[2466-2487]
src/main/rx/rx.c[518-523]
src/main/rx/rx.h[168-172]
src/main/rx/rx.h[30-35]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`MSP2_INAV_SET_AUX_RC` allows 16-bit values up to 65535, but RX channel storage uses `int16_t` and expects PWM-like ranges. Writing large values can wrap negative and lead to incorrect mode/failsafe decisions.

### Issue Context
- 16-bit mode currently does `pwmValue = rawValue;`.
- Overlay application assigns `uint16_t` overlay values into `rcChannels[i].data` (`int16_t`).

### Fix Focus Areas
- Clamp 16-bit decoded values to a safe PWM range (e.g. `PWM_PULSE_MIN..PWM_PULSE_MAX` or `PWM_RANGE_MIN..PWM_RANGE_MAX`) before calling `rxMspAuxOverlaySet`.
- Consider changing `rxMspAuxOverlaySet`/`mspAuxOverlay` types to `int16_t` to match `rcChannel_t.data`.
- file/paths and lines:
 - src/main/fc/fc_msp.c[2466-2487]
 - src/main/rx/rx.c[518-523]
 - src/main/rx/rx.h[168-172]
 - src/main/rx/rx.h[30-35]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

2. Aux safety guard bypass 🐞 Bug ⛨ Security

Description

Rejecting only CH1–CH8 does not prevent arming/mode changes because iNav’s mode activation can be
mapped to any AUX channel, including CH9–CH32, so this command can still toggle BOXARM/flight modes
when configured on higher channels.

Code

src/main/fc/fc_msp.c[R2422-2429]

+            const uint8_t defByte = sbufReadU8(src);
+            const uint8_t startChannel = defByte >> 3;          // Bits 7-3: start channel index (0-31)
+            const uint8_t resolutionMode = defByte & 0x07;      // Bits 2-0: resolution
+
+            // Safety: CH1-CH8 (index 0-7) are protected
+            if (startChannel < 8) {
+                return MSP_RESULT_ERROR;
+            }

Evidence
Mode activation reads rxGetChannelValue(auxChannelIndex + NON_AUX_CHANNEL_COUNT), so AUX mappings
can reference channels beyond CH8. Since the overlay forces rcChannels[8..31].data, it will feed
into updateActivatedModes() and can therefore activate BOXARM/other modes when those are mapped to
CH9+.
src/main/fc/fc_msp.c[2422-2429]
src/main/rx/rx.c[518-523]
src/main/fc/rc_modes.c[154-165]
src/main/fc/rc_modes.h[28-49]
src/main/rx/rx.h[87-91]
src/main/fc/fc_core.c[615-654]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The current guard only rejects start channels < 8, but iNav allows arming/flight mode activation to be mapped onto CH9+ via mode activation conditions. As a result, MSP2 aux updates can still arm/disarm or change flight modes, contradicting the claimed safety model.

### Issue Context
- Overlay affects `rcChannels[8..31].data`.
- Mode activation uses `auxChannelIndex + NON_AUX_CHANNEL_COUNT`, enabling BOXARM (and others) to be mapped to CH9+.

### Fix Focus Areas
- Add an explicit safety gate for this MSP command, e.g.:
 - Require an opt-in config/feature flag before accepting this command, and/or
 - Require `IS_RC_MODE_ACTIVE(BOXMSPRCOVERRIDE)` (or a new dedicated box) before applying overlay, and/or
 - Reject updates to any channel currently used by mode activation conditions for critical modes (at minimum BOXARM/BOXPREARM/BOXFAILSAFE).
- Update docs to remove/adjust the “cannot arm/change modes” guarantee if the implementation intentionally allows it.
- file/paths and lines:
 - src/main/fc/fc_msp.c[2416-2517]
 - src/main/rx/rx.c[518-523]
 - src/main/fc/rc_modes.c[154-165]
 - src/main/fc/fc_core.c[615-654]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

3. dataSize truncated to uint8_t 📘 Rule violation ⛨ Security

Description

The new MSP2_INAV_SET_AUX_RC handler narrows dataSize - 1 into uint8_t and then derives
channelCount with uint8_t arithmetic, which can overflow/wrap for MSPv2 payload lengths >255 and
bypass intended length validation. This is incomplete external input size validation and can lead to
incorrect decoding or inconsistent parsing behavior for larger packets.

Code

src/main/fc/fc_msp.c[R2431-2461]

+            const uint8_t dataBytes = dataSize - 1;
+            uint8_t channelCount;
+            uint8_t bitsPerChannel;
+
+            switch (resolutionMode) {
+                case 0: // 2-bit
+                    bitsPerChannel = 2;
+                    channelCount = dataBytes * 4;
+                    break;
+                case 1: // 4-bit
+                    bitsPerChannel = 4;
+                    channelCount = dataBytes * 2;
+                    break;
+                case 2: // 8-bit
+                    bitsPerChannel = 8;
+                    channelCount = dataBytes;
+                    break;
+                case 3: // 16-bit
+                    bitsPerChannel = 16;
+                    if (dataBytes % 2 != 0) {
+                        return MSP_RESULT_ERROR;
+                    }
+                    channelCount = dataBytes / 2;
+                    break;
+                default:
+                    return MSP_RESULT_ERROR;
+            }
+
+            if (channelCount == 0 || startChannel + channelCount > 32) {
+                return MSP_RESULT_ERROR;
+            }

Evidence

The checklist requires validating protocol/payload sizes before reading/decoding. In the new command
handler, dataSize is reduced to uint8_t dataBytes and channelCount is computed using uint8_t
multiplications (dataBytes * 4, dataBytes * 2), which can overflow and undermine the bounds
check startChannel + channelCount > 32.

src/main/fc/fc_msp.c[2431-2461]
Best Practice: Learned patterns
Best Practice: Learned patterns

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`MSP2_INAV_SET_AUX_RC` derives `dataBytes`/`channelCount` using `uint8_t`, which can truncate/overflow for larger MSPv2 payloads and weaken payload-length validation.

## Issue Context
MSPv2 payload length can exceed 255 bytes; narrowing to `uint8_t` makes arithmetic wrap possible in `channelCount = dataBytes * {2,4}` and can allow incorrect decoding decisions.

## Fix Focus Areas
- src/main/fc/fc_msp.c[2431-2461]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

4. Overlay clear semantics inconsistent 🐞 Bug ⚙ Maintainability

Description

The RX API comment states value=0 clears the overlay, but the MSP2 decoder treats 0 as “skip/no
update” and the protocol docs also describe 0 as skip, creating a misleading contract for
callers/readers.

Code

src/main/rx/rx.h[R236-238]

+// MSP aux channel overlay (CH9-CH32). Sets a channel value that persists
+// across RX update cycles. value=0 clears the overlay for that channel.
+void rxMspAuxOverlaySet(uint8_t channelIndex, uint16_t value);

Evidence

rxMspAuxOverlaySet() is documented as allowing value=0 to clear, but MSP2_INAV_SET_AUX_RC
explicitly continues on rawValue==0, meaning this command will never clear an overlay entry. The
MSP message documentation likewise defines 0 as skip/persist, so at least one of the API comment or
the protocol behavior/spec is wrong.

src/main/rx/rx.h[236-238]
src/main/fc/fc_msp.c[2474-2476]
docs/development/msp/msp_messages.json[10958-10964]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The `rxMspAuxOverlaySet()` comment says `value=0` clears the overlay, but the MSP2 command treats `0` as “skip/no update” and therefore cannot clear via the protocol. This inconsistency will cause incorrect integrations.

### Issue Context
- Protocol documentation in `msp_messages.json` states value 0 = skip.
- Implementation in `fc_msp.c` also treats 0 as skip.

### Fix Focus Areas
- Either update the `rx.h` comment to match the protocol semantics (0=skip), OR implement an explicit protocol-level clear mechanism and document it.
- file/paths and lines:
 - src/main/rx/rx.h[236-238]
 - src/main/fc/fc_msp.c[2474-2476]
 - docs/development/msp/msp_messages.json[10958-10964]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

ⓘ The new review experience is currently in Beta. Learn more

src/main/rx/rx.c

src/main/fc/fc_msp.c

github-actions · 2026-04-06T14:12:56Z

Test firmware build ready — commit f025071

Download firmware for PR #11482

228 targets built. Find your board's .hex file by name on that page (e.g. MATEKF405SE.hex). Files are individually downloadable — no GitHub login required.

Development build for testing only. Use Full Chip Erase when flashing.

danarrib · 2026-04-06T17:09:17Z

This is AWESOME, I'll use it for sure on Bullet GCSS. The current RAW_RC implementation always let me unease, with this I think I'll have a more reliable way to set flight modes from outside.

I'll test this and post back the results ASAP.
Thanks.

sensei-hacker · 2026-04-09T04:13:46Z

This is AWESOME, I'll use it for sure on Bullet GCSS. The current RAW_RC implementation always let me unease, with this I think I'll have a more reliable way to set flight modes from outside.

I'll test this and post back the results ASAP. Thanks.

Testing is so VERY much appreciated!
Especially tests that try to find corner cases or potential problems. A lot of times when we code, we are focused on getting it to work. That focus can mean we don't think about in what cases it won't work. Or when it should NOT do the thing. We look at trying to get it to override like it should, and don't even think about when it shouldn't. Third-party testing is awesome for that.

- Clamp 16-bit PWM values to 750-2250 (prevent int16_t overflow) - Reject oversized payloads (dataSize > 49) - Skip channels actively provided by primary RX (SBUS/CRSF/etc.) - When MSP is the RX provider, use actual MSP_SET_RAW_RC channel count - Skip channels controlled by MSP_RC_OVERRIDE bitmask when active

b14ckyy · 2026-04-09T07:49:03Z

Fixed an edge case complaint from qodo with the int_8t overflow possibility.
added 3 priority safeguards:

block AUX overlay for channels within rxChannelCount so no serial RX override and channel jitter possible. No error, inputs just get ignored
if MSP is main serial Rx provider, check what the last (highest) channel was last sent by MSP_SET_RAW_RC and only allow overlay on channels above that.
skip all channels within the mspOverrideChannels bitmask if MSP RC OVERRIDE mode is active to prevent dual-control of channels via MSP as well

This ensures that AUX_RC is really just acting as a low priority auxiliary control for definitely unused channels.

tests pending

- Raise minimum channel from CH9 to CH13 (index 12) All common protocols deliver at least 12 channels on the wire. - Remove rxChannelCount-based guard (protocol drivers report max capacity, not actual sender channel count — unusable as guard) - Remove rxMspGetLastChannelCount (no longer needed) - Keep MSP_RC_OVERRIDE bitmask guard

When MSP is the primary RX provider (e.g. mLRS), skip channels already covered by MSP_SET_RAW_RC to avoid wasting bandwidth on overlapping updates.

b14ckyy · 2026-04-09T16:13:31Z

Slight spec change. I cannot safely determine what channel range the receiver actually sends to add a reliable safeguard and reject all channels that come through sbus or crsf. Alternative solution implemented:

CH1-CH12 are restricted to RC link (instead 1-8) since all modern RC systems have minimum 12 channels already
AUX_RC overlay has priority over existing RC channels since its persistent and checked last in the chain
overlapping AUX and RC channels are the responsibility of the user (will be properly documented)
MSP_SET_RAW_RC and MSP2_SET_AUX_RC still has overlap check and RAW_RC has priority
Same for MSP-Override-Bitmask

- Rx.md: Add 'MSP Auxiliary RC Channel Overlay' section with key properties, use case, priority order, and safeguard descriptions - Rx.md: Fix MSP RX channel count (18 -> 34) - msp_messages.json: Update channel range to CH13-CH32, add clamp range, payload size limits, and guard descriptions

b14ckyy · 2026-04-09T16:57:23Z

Docs updated. Bench tested. All functions as expected. Ready to merge. Wiki Update is prepared as well, when merged.

b14ckyy added this to the 9.1 milestone Apr 6, 2026

b14ckyy added Enhancement Release Notes Add this when a PR needs to be mentioned in the release notes msp non-breaking change Extends or adds an MSP message labels Apr 6, 2026

qodo-code-review bot reviewed Apr 6, 2026

View reviewed changes

src/main/rx/rx.c Outdated Show resolved Hide resolved

src/main/fc/fc_msp.c Show resolved Hide resolved

Add MSP2_INAV_SET_AUX_RC (0x2230)

e93adf3

b14ckyy force-pushed the msp-aux-rc branch from c595afb to e93adf3 Compare April 6, 2026 14:13

sensei-hacker added the Documentation needed label Apr 9, 2026

Merge branch 'maintenance-9.x' into msp-aux-rc

ae33960

b14ckyy added Fix needed - don't merge Not ready for merge because issues remain after testing and removed Enhancement labels Apr 9, 2026

b14ckyy added 2 commits April 9, 2026 17:45

Re-add MSP RX channel count guard for overlay

86615b9

When MSP is the primary RX provider (e.g. mLRS), skip channels already covered by MSP_SET_RAW_RC to avoid wasting bandwidth on overlapping updates.

b14ckyy added Documentation and removed Fix needed - don't merge Not ready for merge because issues remain after testing Documentation needed labels Apr 9, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

MSP2_INAV_SET_AUX_RC (0x2230) — Bandwidth-efficient auxiliary RC channel updates#11482

MSP2_INAV_SET_AUX_RC (0x2230) — Bandwidth-efficient auxiliary RC channel updates#11482
b14ckyy wants to merge 6 commits intoiNavFlight:maintenance-9.xfrom
b14ckyy:msp-aux-rc

b14ckyy commented Apr 6, 2026 •

edited

Loading

Uh oh!

qodo-code-review bot commented Apr 6, 2026

Uh oh!

qodo-code-review bot commented Apr 6, 2026 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

github-actions bot commented Apr 6, 2026 •

edited

Loading

Uh oh!

danarrib commented Apr 6, 2026

Uh oh!

sensei-hacker commented Apr 9, 2026

Uh oh!

b14ckyy commented Apr 9, 2026 •

edited

Loading

Uh oh!

b14ckyy commented Apr 9, 2026

Uh oh!

b14ckyy commented Apr 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

b14ckyy commented Apr 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Motivation

Changes

New feature: MSP2_INAV_SET_AUX_RC

Included bugfixes (from separate PRs, merged into base branch):

Safety Design

Overlay priority & safeguards

No failsafe interaction

Message Format (Quick Reference)

Testing

Build verification

Hardware test setup

Functional tests performed

Related PRs

Uh oh!

qodo-code-review bot commented Apr 6, 2026

Review Summary by Qodo

Walkthroughs

File Changes

Uh oh!

qodo-code-review bot commented Apr 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Code Review by Qodo

Uh oh!

Uh oh!

Uh oh!

github-actions bot commented Apr 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

danarrib commented Apr 6, 2026

Uh oh!

sensei-hacker commented Apr 9, 2026

Uh oh!

b14ckyy commented Apr 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

tests pending

Uh oh!

b14ckyy commented Apr 9, 2026

Uh oh!

b14ckyy commented Apr 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

b14ckyy commented Apr 6, 2026 •

edited

Loading

New feature: `MSP2_INAV_SET_AUX_RC`

qodo-code-review bot commented Apr 6, 2026 •

edited

Loading

github-actions bot commented Apr 6, 2026 •

edited

Loading

b14ckyy commented Apr 9, 2026 •

edited

Loading