Skip to content

Adaptive channel migration 5/5: optional drone-side target validation #280

Description

@josephnef

Summary

Add optional drone-side validation of a ground-proposed destination before the drone commits an automatic migration. Ground evidence remains authoritative for downlink video quality; drone evidence is a conservative veto/diagnostic for locally busy, unsupported, or unsafe destinations, never an independent channel-selection state machine.

Experiment 5 of 5; depends on #279. This stage must quantify whether validation benefit justifies its airborne airtime, latency, power, USB, and hardware cost.

Why this is optional

The ground receiver is the endpoint whose video delivery matters, and interference is asymmetric. A channel clean at the drone can be bad at ground and vice versa. Drone sensing therefore must not override good ground delivery evidence merely because its local energy differs.

Useful drone checks are narrower:

  • target is legal/supported by its actual radio configuration;
  • target has extreme local occupancy or a local transmitter likely to cause TX deferral/desense;
  • RF/thermal/power state permits the retune;
  • optional second airborne scout has recent trustworthy evidence.

Sensing variants to compare

A. No sensing, validation-only baseline

Validate regulatory/channel/BW/calibration support and commit using ground evidence. This may remain the recommended product result.

B. Single-radio pre-commit probe

At a scheduled quiet opportunity, pause/drain video, retune to target, settle, sample GetRxEnergy/NHM, return to source, restore state, and resume. Measure the resulting video outage and whether the ground primary loses synchronization.

C. Single-radio post-switch probation

Commit based on ground evidence, then use destination delivery/confirmation plus local energy during the normal probation window. Avoids a double retune but detects problems only after moving.

D. Dedicated airborne scout

Continuously or selectively survey with a second adapter. Quantify mass, power, USB/controller contention, RF self-interference, antenna placement, and thermal cost; do not assume the ground-side dual-radio result transfers to an aircraft.

Step-by-step

  • Define a versioned TargetValidation result: proposal generation, channel definition, method, observation interval/age, legal/support checks, energy evidence with validity flags, cost estimate, result (accept, veto, unknown), and exact reason.
  • Extend Adaptive channel migration 3/5: authenticated manual proposal, commit, verify, and rollback #278 so only the drone's commit authority consumes this result. Ground never applies a separate mask/target, and unknown follows an explicit configurable policy rather than silently accepting/rejecting.
  • Implement the validation-only baseline and measure commit success without RF sensing.
  • Implement a research-only single-radio probe with deterministic TX drain/drop, retune, settle, counter reset, bounded sample, return, channel-state restoration, and source-channel reacquisition marker. Abort safely on every failed step.
  • Measure source→target→source RF timing, video/FEC loss, queued/stale frames, first-decode delay, power/thermal cost, and whether a degraded source link can still carry the final commit after probing.
  • Implement post-switch local evidence during the existing probation/rollback state without adding a second rollback authority.
  • If hardware is available, run the dedicated-airborne-scout variant with deterministic adapter identity and isolate its RF/USB/power effects from sensing benefit.
  • Add endpoint-evidence disagreement events: ground-bad/drone-clean, ground-clean/drone-bad, both bad, stale/unknown, and method/cost.
  • Choose and document the production policy from measurements; it is acceptable—and preferable if evidence says so—to ship no airborne sensing.

Fusion policy

Initial conservative behavior:

  • Ground never proposes without Adaptive channel migration 4/5: conservative autonomous migration policy #279 evidence.
  • Drone always vetoes illegal/unsupported targets.
  • Strong, sufficiently observed extreme local interference may veto or delay a commit.
  • Ordinary local occupancy does not override a ground receiver that needs to escape its current channel.
  • unknown does not manufacture confidence; policy may proceed with ground authority or require operator approval depending on mode.
  • A veto expires with its evidence and is reported to ground; it cannot permanently blacklist a channel.

Validation scenarios

  • Interferer visible only at ground: drone must not prevent a beneficial move.
  • Interferer visible only at drone: record whether migration actually harms TX/control behavior.
  • Hidden terminal at destination that starts after video TX begins.
  • Source channel so impaired that probe/return control messages are lost.
  • Probe target illegal/no-IR/DFS-unavailable or unsupported width.
  • Airborne scout self-interference from the video transmitter.
  • Probe retune/return failure and adapter/USB reset.
  • Follower/reactive interferer: compare pre-commit probe with post-switch probation.

Decision metrics

  • failed migrations prevented and good migrations incorrectly vetoed;
  • additional video outage and FEC loss per probe;
  • proposal-to-commit latency;
  • probe completion/recovery failure rate;
  • airborne power/thermal/USB/RF cost;
  • disagreement frequency and predictive value;
  • performance versus baseline and post-switch-only validation.

Acceptance criteria

  • No variant creates independent ground/drone channel decisions or split-brain generations.
  • Illegal/unsupported targets are always rejected before commit.
  • Single-radio probe failure returns to a known source/rescue state and is tested with fault injection.
  • Controlled asymmetric tests quantify false vetoes and prevented failures for every variant.
  • The selected policy demonstrably improves migration reliability enough to justify measured cost; otherwise document a no-go and retain ground-authoritative validation/probation.
  • Existing automatic migration remains unchanged when drone-side validation is disabled.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions