berkus
/
wifi-densepose
mirror of https://github.com/ruvnet/wifi-densepose.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
wifi-densepose/docs/adr/ADR-270-vendor-rf-sensing-i...

5.8 KiB
Raw Blame History

ADR-270: Vendor RF Sensing Integration Program

  • Status: accepted
  • Date: 2026-07-18
  • Deciders: RuView maintainers
  • Tags: vendors, csi, telemetry, simulator, rust, hardware-validation

Context

RuView is evaluating Qualcomm, RF Solutions, Origin AI, Plume, Linksys, Electric Imp, Mist/Juniper, Luma, Google Nest, NETGEAR and Wifigarden. These names do not represent equivalent integration surfaces: some expose raw CSI, some expose derived sensing events or network telemetry, and some expose no supported developer interface. A repeated implementation process must not turn brand compatibility, Linux connectivity or synthetic fixtures into a false CSI claim.

Decision

Adopt a Rust-first provider portfolio with explicit capability negotiation:

  • ComplexCsi: calibrated per-packet complex channel matrices.
  • DerivedSensing: vendor-produced motion, occupancy or location events.
  • RfTelemetry: RSSI, radio, client and topology observations.
  • NetworkOnly: useful as excitation/AP infrastructure but not a sensor.
  • Unsupported: no stable, lawful or supportable integration surface.

Every provider follows the same gated loop:

  1. Verify an authoritative API/SDK, exact model/chipset and licensing boundary.
  2. Write provider and wire/contract ADRs before coupling core code to a vendor.
  3. Implement bounded Rust types, explicit capabilities and synthetic provenance.
  4. Test deterministic replay, corruption, loss, reconnect, backpressure, schema evolution and secrets handling.
  5. Promote to hardware support only after lawful physical capture on an exact model/firmware, calibration and repeatability tests, and fixture publication rights. Simulator success never satisfies this gate.
  6. Publish code/release and an upstream or vendor collaboration announcement that states the measured-versus-simulated boundary.

Portfolio decisions

Provider Classification Decision
Qualcomm QCA9300 ComplexCsi candidate Implement first physical baseline via established ath9k research tooling; QCS1 adapter ships simulator-first.
Qualcomm QCN9074/QCN9274 experimental ComplexCsi Simulator and protocol now; require confirmed ath11k/ath12k firmware export before hardware claim.
Origin AI commercial DerivedSensing, possible CSI Pursue NDA sandbox/API and raw-data rights; isolate proprietary engine behind provider trait/service boundary.
Plume/OpenSync RfTelemetry; Plume Sense is gated DerivedSensing Build optional OVSDB/control-plane adapter; negotiate Sense separately and do not infer raw CSI.
Mist/Juniper RfTelemetry + location Conditional read-only REST/webhook adapter for occupancy, RSSI and coordinates; no CSI claim.
NETGEAR partner-gated RfTelemetry Insight adapter only after API access; exact legacy OpenWrt models remain community experiments.
Luma discontinued OpenWrt salvage target Generic OpenWrt telemetry/pcap fixture only when already owned; no procurement or Luma CSI source.
Google Nest Wifi NetworkOnly Use as traffic/AP infrastructure; Device Access does not expose router CSI or radio telemetry.
Linksys Unsupported for sensing Linksys Aware reached end of support in 2024; record capability probe only, if needed.
Electric Imp scalar IoT/RSSI telemetry Optional agent/impCentral bridge for existing fleets; reject as CSI acquisition hardware.
RF Solutions non-Wi-Fi RF/IoT telemetry Exclude from sensing backend; optional RIoT environmental fusion is a separate future concern.
Wifigarden commercial OEM, capability unknown Hold implementation pending chipset, schema, offline, calibration and data-rights disclosure.

Provider boundary

Core code consumes a vendor-neutral RfSource-style contract whose capability set prevents RSSI, location or derived occupancy from being represented as CSI. Cloud adapters use bounded async queues, regional endpoints, secret-provider credentials and explicit data provenance. Proprietary device SDKs live behind a feature-gated FFI or sidecar boundary and are never redistributed without rights.

Consequences

Positive

  • The integration loop can be repeated without duplicating unsafe parsers.
  • Product integrations remain useful even when only telemetry is available.
  • Public releases make hardware confidence and simulator confidence distinct.

Negative

  • Several named vendors cannot produce a legitimate CSI implementation today.
  • Commercial providers require contracts, subscriptions, test vectors or NDAs.
  • Exact hardware revisions and firmware provenance increase validation effort.

Neutral

  • A no-go or telemetry-only ADR is a completed research outcome, not a failed port.
  • Vendor status and APIs must be rechecked before each implementation begins.

Evidence and Links