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/api-docs/adr/ADR-266-mediatek-filogic-cs...

3.5 KiB
Raw Blame History

ADR-266: MediaTek Filogic CSI Platform

  • Status: accepted
  • Date: 2026-07-18
  • Deciders: RuView maintainers
  • Tags: mediatek, filogic, mt76, csi, openwrt, rust

Context

RuView needs a high-antenna-count, router-class Wi-Fi sensing path beyond ESP32. MediaTek Filogic platforms are attractive because the upstream BSD-3-Clause mt76 driver supports MT7915/MT792x/MT7996 families and OpenWrt supports MT7981/MT7986/MT7988 systems. The OpenWrt One (MT7981B + MT7976C) additionally publishes schematics, platform datasheets, register documentation, serial, and JTAG access. The BPI-R3 (MT7986 + MT7975N/P) offers dual-band 4x4 radios.

The current upstream mt76 tree has testmode, debugfs, RX descriptors, and MCU event plumbing, but no supported public interface for exporting per-packet complex channel estimates. Public MediaTek SDK material likewise does not expose an equivalent to Espressif's CSI callback. PHY computation of channel estimates does not imply that firmware transfers those estimates to host memory.

Existing RuView documents that describe MT7661 CSI-over-UDP or released MediaTek CSI tools are unverified architectural hypotheses, not supported hardware claims.

Decision

  1. Use the OpenWrt One as the primary future hardware/upstreaming target and the BPI-R3 as the secondary 4x4 validation target.
  2. Build a Rust-first simulator and host transport before hardware arrives.
  3. Keep the transport independent of private firmware structures. A future mt76 adapter must translate a documented kernel/firmware report into it.
  4. Prefer Generic Netlink for capability/control messages and relayfs or a bounded character-device stream if sustained CSI volume exceeds Netlink's practical throughput.
  5. Do not redistribute vendor firmware, private headers, or SDK components.
  6. Label simulator frames end-to-end and never present them as physical capture.
  7. Do not claim MediaTek hardware CSI support until complex CSI from a physical device passes calibration, sequence, timestamp, and repeatability tests.

Consequences

Positive

  • Development and integration testing can start without fabricating a vendor ABI.
  • OpenWrt One provides a repairable, upstream-friendly hardware target.
  • The same RuView ingestion path can accept simulator, replay, and future driver data.
  • Rust bounds checking isolates untrusted kernel/network input from inference code.

Negative

  • The simulator cannot prove firmware export availability or sensing accuracy.
  • A firmware change or MediaTek cooperation may be required before physical CSI exists.
  • Router-class builds and driver iteration are slower than MCU firmware development.

Neutral

  • NeuroPilot may later accelerate inference but is unrelated to CSI capture.
  • Wi-Fi 7/MLO support remains a later phase after a single-link contract is stable.

Hardware gates

  • Identify a firmware/host report containing complex channel estimates.
  • Document dimensions, quantization, chain ordering, subcarrier indexing, lifetime, timestamps, sequence behavior, calibration, maximum size, and report rate.
  • Validate OpenWrt One first, then BPI-R3 4x4, before considering MT7996/MLO.

Links