Add MSP2 link stats message + fix missing msp-set-wp-index-and-altitu…

[xznhj8129]

1. Adds a new message MSP2_INAV_GET_LINK_STATS from feature request Ability for a GCS to get RC Link Info from INAV #10522

MSP2_INAV_GET_LINK_STATS (8451 / 0x2103)

Description: Provides uplink RC link statistics for monitoring on a GCS.

Request Payload: None

Reply Payload:

Field	C Type	Size (Bytes)	Units	Description
uplinkRSSI_dBm	uint8_t	1	-dBm	Uplink RSSI in dBm, sent as a positive magnitude (getRSSI()). For example, 70 means -70dBm.
uplinkLQ	uint8_t	1	%	Uplink Link Quality (rxLinkStatistics.uplinkLQ)
uplinkSNR	int8_t	1	dB	Uplink Signal-to-Noise Ratio (rxLinkStatistics.uplinkSNR)

Notes: Useful for GCS monitoring of the active RC link quality and signal margin.

2. PR Add two new MSP2 commands for GCS-initiated flight control #11462 added two new MSP messages, but they weren't actually defined in the msp_messages.json file; the documentation was manually updated, which nobody noticed. This also adds the messages to the spec and regenerates docs with gen_docs.sh (those enum changes are basically the delta from the last time it was run)

3. fixes a small, dumb bug in gen_docs which was zeroing out rev on checksum change; that whole system will be gone in 10

[qodo-code-review]

Review Summary by Qodo

Walkthroughs

File Changes

[qodo-code-review]

Code Review by Qodo

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

🐞\ ⚙ Maintainability (1)

📘\ ≡ Correctness (1) ☼ Reliability (1)

1. uplinkRSSI_dBm docs cite getRSSI() 📘 ≡

Description

The new MSP2_INAV_GET_LINK_STATS documentation/spec says uplinkRSSI_dBm comes from getRSSI(),
but firmware actually serializes -rxLinkStatistics.uplinkRSSI (dBm). This mismatch can cause GCS
implementations to interpret the field incorrectly and breaks the documented API contract.

Code

docs/development/msp/msp_messages.json[R6963-6966]

+                    "name": "uplinkRSSI_dBm",
+                    "ctype": "uint8_t",
+                    "desc": "Uplink RSSI in dBm, sent as a positive magnitude (`getRSSI()`). For example, 70 means -70dBm.",
+                    "units": "-dBm"

Evidence

The spec text for uplinkRSSI_dBm references getRSSI(), but the implementation writes
-rxLinkStatistics.uplinkRSSI; additionally, getRSSI() is documented as a normalized `[0,
RSSI_MAX_VALUE]` value rather than dBm, confirming the documentation is out of sync with actual
behavior.

docs/development/msp/msp_messages.json[6963-6966]
docs/development/msp/README.md[4372-4372]
src/main/fc/fc_msp.c[745-748]
src/main/rx/rx.h[222-223]
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_GET_LINK_STATS.uplinkRSSI_dBm` is documented as being sourced from `getRSSI()`, but the implementation serializes `-rxLinkStatistics.uplinkRSSI` (dBm). This makes the spec/docs inconsistent with the actual API behavior.

## Issue Context
- `getRSSI()` is documented as a normalized value in `[0, RSSI_MAX_VALUE]`, not dBm.
- The new message name and field name (`uplinkRSSI_dBm`) imply dBm, aligning with `rxLinkStatistics.uplinkRSSI`.

## Fix Focus Areas
- docs/development/msp/msp_messages.json[6963-6966]
- docs/development/msp/README.md[4372-4372]

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

---

2. RSSI negation may wrap 📘 ☼

Description

MSP2_INAV_GET_LINK_STATS serializes RSSI as (uint8_t)-rxLinkStatistics.uplinkRSSI without
clamping or sign normalization. If uplinkRSSI is stored using a different convention (e.g., set
directly from a uint8_t source), this can wrap/overflow and report incorrect RSSI magnitudes to
the GCS.

Code

src/main/fc/fc_msp.c[R745-748]

+    case MSP2_INAV_GET_LINK_STATS:
+        sbufWriteU8(dst, (uint8_t)-rxLinkStatistics.uplinkRSSI);
+        sbufWriteU8(dst, rxLinkStatistics.uplinkLQ);
+        sbufWriteU8(dst, (uint8_t)rxLinkStatistics.uplinkSNR);

Evidence

The new serialization logic assumes rxLinkStatistics.uplinkRSSI is a negative dBm value and
directly negates then casts to uint8_t; elsewhere, uplinkRSSI can be assigned from msg->rssi
without conversion, increasing the risk of inconsistent sign/encoding and wrap when negated/cast.

src/main/fc/fc_msp.c[745-748]
src/main/telemetry/mavlink.c[1255-1273]
src/main/rx/rx.h[183-188]
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_GET_LINK_STATS` converts RSSI with `(uint8_t)-rxLinkStatistics.uplinkRSSI` without guarding against differing internal conventions or out-of-range values, which can wrap and send incorrect bytes on the wire.

## Issue Context
`rxLinkStatistics.uplinkRSSI` is an `int16_t` described as dBm, but there are code paths that may populate it from unsigned/raw values. The wire format for `uplinkRSSI_dBm` is a `uint8_t` magnitude (e.g., 70 means -70 dBm), so serialization should be robust (e.g., `abs()` + clamp/saturate to `[0,255]`, plus a defined behavior for invalid/unknown).

## Fix Focus Areas
- src/main/fc/fc_msp.c[745-748]

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

---

3. Broken rev markdown bold 🐞 ⚙

Description

docs/development/msp/README.md has the JSON revision rendered as '**JSON file rev: 5' followed by a
newline and then '**', breaking markdown formatting. This happens because the doc generator inserts
the raw contents of the rev file (including trailing newline) into a bold template without
stripping.

Code

docs/development/msp/README.md[R12-13]

+**JSON file rev: 5
+**

Evidence

The generated README shows the broken bold formatting. The generator reads rev via f.read() and
substitutes it into **JSON file rev: <file_rev>**, so a trailing newline in the rev file splits
the closing bold marker onto the next line.

docs/development/msp/README.md[12-15]
docs/development/msp/gen_msp_md.py[411-424]
docs/development/msp/docs_v2_header.md[12-13]

Agent prompt

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

### Issue description
Generated `docs/development/msp/README.md` has malformed markdown for the revision line because `<file_rev>` replacement includes a newline.

### Issue Context
`gen_msp_md.py` uses `rev = f.read()` and inserts it into a bold markdown line from `docs_v2_header.md`. If `rev` contains a trailing newline, the resulting markdown splits `**` across lines.

### Fix Focus Areas
- docs/development/msp/gen_msp_md.py[417-424]

### Implementation notes
- Change to `rev = f.read().strip()` (and optionally also `chksum = f.read().strip().split(' ')[0]`) so replacements never include newlines.
- Regenerate docs so README.md is updated accordingly.

ⓘ 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

[qodo-code-review]

1. uplinkrssi_dbm docs cite getrssi() 📘 Rule violation ≡ Correctness

The new MSP2_INAV_GET_LINK_STATS documentation/spec says uplinkRSSI_dBm comes from getRSSI(),
but firmware actually serializes -rxLinkStatistics.uplinkRSSI (dBm). This mismatch can cause GCS
implementations to interpret the field incorrectly and breaks the documented API contract.

Agent Prompt

## Issue description
`MSP2_INAV_GET_LINK_STATS.uplinkRSSI_dBm` is documented as being sourced from `getRSSI()`, but the implementation serializes `-rxLinkStatistics.uplinkRSSI` (dBm). This makes the spec/docs inconsistent with the actual API behavior.

## Issue Context
- `getRSSI()` is documented as a normalized value in `[0, RSSI_MAX_VALUE]`, not dBm.
- The new message name and field name (`uplinkRSSI_dBm`) imply dBm, aligning with `rxLinkStatistics.uplinkRSSI`.

## Fix Focus Areas
- docs/development/msp/msp_messages.json[6963-6966]
- docs/development/msp/README.md[4372-4372]

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

[github-actions]

Test firmware build ready — commit 69db786

Download firmware for PR #11496

232 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.

[b14ckyy]

That will go nicely with https://codeberg.org/stronnag/mwptools/issues/184
Already informed Stronnag over there.