Skip to content

Fix false Ground Station activation during Blackbox download - #2689

Closed
mart1npetroff wants to merge 4 commits into
iNavFlight:masterfrom
mart1npetroff:fix/ltm-blackbox-routing
Closed

Fix false Ground Station activation during Blackbox download#2689
mart1npetroff wants to merge 4 commits into
iNavFlight:masterfrom
mart1npetroff:fix/ltm-blackbox-routing

Conversation

@mart1npetroff

Copy link
Copy Markdown

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.

sensei-hacker and others added 4 commits July 19, 2026 20:25
cliTab.initialize() flushed the MSP queue synchronously but only set
CONFIGURATOR.cliActive true inside the async cli.html import callback,
leaving a window where periodicStatusUpdater's 300ms poll still saw
cliActive as false and queued status requests that never got flushed
again. Those requests went out over the wire and corrupted the FC's
CLI output (visible as leaked MSP2 frame bytes). Move the flag to the
first line of initialize() so no interval tick can land in the gap.

Also guard the tab-click handler's cliTab.exit() call with cliValid in
addition to cliActive, since cliActive can now be true before the FC
has confirmed CLI mode was actually entered.
MSP.send_message()'s queue-put can be rejected as a duplicate when the
same MSP code is still awaiting a response (routine on a slow/loaded
serial link where round-trip exceeds the poll interval). The rejected
message retried every 150ms for up to 25 attempts without ever
re-checking CONFIGURATOR.cliActive, so a status poll deferred right
before switching to the CLI tab could still land several seconds
later, once the FC was already echoing raw bytes in CLI mode. Found by
reproducing the original bug's exact symptom live after the first fix
landed. Check cliActive before every attempt, not just the one made at
send_message() time.
…-polling-leak

Fix MSP status polls leaking into CLI session on tab entry
@qodo-code-review

Copy link
Copy Markdown
Contributor

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

Copy link
Copy Markdown

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 because it should never be included in any release, no action is needed.


This is an automated suggestion to help route contributions to the appropriate branch.

@sonarqubecloud

Copy link
Copy Markdown

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants