Fix false Ground Station activation during Blackbox download

[mart1npetroff]

What changed

• Route LTM decoding only until a valid MSP stream is detected.
• Prevent Ground Station auto-activation when MSP is active.
• Reset MSP and LTM decoder state between connection sessions.
• Handle incomplete LTM telemetry values safely in the Ground Station UI.
• Add regression coverage for a checksum-valid LTM frame embedded in arbitrary data.

Root cause

The serial connection fed every received byte to both MSP and LTM decoders. Raw MSP_DATAFLASH_READ payloads contain arbitrary Blackbox bytes, so they could accidentally form a valid LTM frame and switch the UI into Ground Station mode.

Validation

• yarn test — passed.
• Windows x64 ZIP build completed and archive integrity was verified.

[qodo-code-review]

Qodo reviews are paused for this user.

Troubleshooting steps vary by plan Learn more →

On a Teams plan?
Reviews resume once this user has a paid seat and their Git account is linked in Qodo.
Link Git account →

Using GitHub Enterprise Server, GitLab Self-Managed, or Bitbucket Data Center?
These require an Enterprise plan - Contact us
Contact us →

[github-actions]

Configurator test build ready — commit 1cfc1f2

Download build artifacts for PR #2690

Available platforms (scroll to the Artifacts section at the bottom of the run page):

• Windows x64 (ZIP, MSI) and x32 (ZIP, MSI)
• macOS arm64 (ZIP, DMG) and x64 (ZIP, DMG)
• Linux x64 (DEB, RPM, ZIP) and aarch64 (DEB, RPM, ZIP)

A GitHub login is required to download artifacts. Build is for testing only.

[sensei-hacker]

Thanks for the fix — this is a clean solve for a tricky bug (Blackbox bytes coincidentally checksumming as valid LTM). A couple of small things I noticed while reading through:

It looks like ltmDecoder.reset() in read_ltm fires on every subsequent receive event once MSP.wasEverReceiving() becomes true, rather than just once at the point MSP is first detected. Since that branch runs on the exact hot path this PR is targeting (Blackbox download can mean many receive events per second), could it be adjusted to only reset once at the transition, rather than on every chunk afterward?

Also, for the second test in ltm-decoder.test.mjs — it reads serial_backend.js and regex-matches the source text rather than exercising the gating logic directly. Would it be possible to test this behaviorally instead, e.g. by feeding a valid MSP frame followed by bytes that happen to checksum as a valid LTM frame, and asserting groundstation.activate never fires? That would catch a logic regression even if the surrounding code shape changed.

One more minor thought: the !CONFIGURATOR.connectionValid check alongside !MSP.wasEverReceiving() in both read_ltm and the ltm-connection-check interval — from tracing the paths that set connectionValid, it looks like wasEverReceiving() always becomes true first, so the extra check may never do anything. Could be wrong about this (maybe there's a BLE-specific path I'm missing) — just flagging in case it's worth a second look.

[mart1npetroff]

Thanks — addressed all three points.

• LTM routing now uses a session-level MSP detection gate. The decoder is reset once when the first valid MSP frame is observed, then subsequent receive chunks are ignored by the LTM route for the rest of the connection.
• Replaced the source-regex test with a behavioural test that feeds a valid MSP frame followed by checksum-valid LTM-shaped bytes and verifies that LTM is not read and Ground Station is never activated.
• Removed the redundant connectionValid checks from the LTM gate. In the current connection flow, MSP is observed before connectionValid is set, so the explicit per-session MSP state is the relevant condition.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sensei-hacker]

Just an FYI for contributors: The tentative schedule for INAV 10 is to have a full release in mid December. That means RC2 needs to be in early to mid November, which places INAV 10.0RC1 at September 1. Please plan to have any new features for INAV 10.0 ready for RC1 no later than September 1. After that, 10.1 will follow about six to seven months later.