76 lines
3.5 KiB
Markdown
76 lines
3.5 KiB
Markdown
# 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
|
|
|
|
- [ADR-123: BFLD capture path](ADR-123-bfld-capture-path-nexmon-and-esp32.md)
|
|
- [ADR-264: RTL8720F radar wire protocol](ADR-264-rtl8720f-radar-wire-protocol.md)
|
|
- [upstream mt76](https://github.com/openwrt/mt76)
|
|
- [OpenWrt One](https://openwrt.org/toh/openwrt/one)
|
|
- [MediaTek OpenWrt feed](https://git01.mediatek.com/openwrt/feeds/mtk-openwrt-feeds/)
|