[Announcement / RFC] RuView MediaTek Filogic CSI simulator and MTC1 userspace boundary

Announcement

RuView and Cognitum.one have published a Rust-centric MediaTek Filogic CSI beta so integration work can proceed against a deterministic simulator while we wait for physical hardware and vendor SDK access.

Release: https://github.com/ruvnet/RuView/releases/tag/v0.9.1-mediatek-beta.1
Merged implementation: https://github.com/ruvnet/RuView/pull/1358

This is an early collaboration announcement/RFC, not a claim that current public mt76 firmware exposes CSI on every listed chipset.

What is available now

• Deterministic simulator profiles for MT7981+MT7976, MT7986+MT7975, and MT7988+MT7996
• A versioned MTC1 envelope carrying complex I/Q, per-chain RSSI, MIMO dimensions, bandwidth, PPDU type, provenance flags, sequence/timestamp, and CRC32
• Rust codec and strict validation (bounds, dimensions, finite values, CRC, truncation, and UDP size)
• UDP ingestion in the RuView sensing server, REST latest-frame summary, and bounded WebSocket summaries
• Reproducible replay files for all three profiles, Windows beta binaries, and SHA-256 manifests
• Explicit mediatek:simulated provenance so synthetic data cannot be confused with physical captures

Architecture decisions:

• Platform boundary: https://github.com/ruvnet/RuView/blob/main/docs/adr/ADR-266-mediatek-filogic-csi-platform.md
• Wire protocol: https://github.com/ruvnet/RuView/blob/main/docs/adr/ADR-267-mediatek-mimo-csi-wire-protocol.md

Why announce here

Issue #1087 documents real MT7916 0xc2 CSI events and HE160 segment pairing, while its discussion also highlights that public MT7986 firmware may contain CSI-related code without a reachable emission path. We want the hardware adapter to align with mt76 and known firmware behavior instead of inventing a kernel ABI.

We would appreciate maintainer/community guidance on:

1. Which currently obtainable MediaTek/Filogic combinations can emit raw complex per-packet CSI with public firmware?
2. For supported hardware, is the stable source the 0xc2 MCU event/TLV stream, RX descriptors, or another path?
3. Would a small mt76 Generic Netlink or relayfs interface be acceptable for exporting validated CSI metadata and I/Q to userspace, or should this remain entirely debugfs/vendor tooling?
4. Which metadata is trustworthy across MT7915/MT7916, MT7975/MT7976, and MT7996 generations?
5. Are there public SDK patches or firmware builds we should test when hardware arrives?

The MTC1 protocol is deliberately an application-side boundary: any future mt76 adapter can translate the actual kernel/firmware event format without coupling RuView to unstable private structs. We are happy to revise the ADRs and simulator fixtures based on upstream feedback, and to contribute a narrowly scoped adapter once a supported capture path is confirmed.

Thanks to the mt76 community and the investigators in #1087 for making the current constraints visible.

Start with docs/adr/ADR-266-mediatek-filogic-csi-platform.md and docs/adr/ADR-267-mediatek-mimo-csi-wire-protocol.md, then read issue #1087 for the reported event format and hardware constraints. The next step depends on maintainer guidance about supported hardware and the kernel/firmware capture path; done means an agreed, narrowly scoped adapter plan rather than a simulator change.