[MT7916 CSI] HE160 event 0xc2 segment 0/1 pairing for 512-sample reconstruction

[young3016]

Summary

I am investigating Wi-Fi CSI collection on an OpenWrt-based MT7916/Filogic device.

In HE160 operation, CSI event ID 0xc2 appears to be exported as two adjacent 256-sample segment events rather than one 512-sample event.

This is not a bug report about normal Wi-Fi connectivity. I am trying to confirm the expected interpretation of the MT7916 CSI event format and whether this should be handled in userspace CSI parser logic.

Device / environment

• Device: ipTIME AX7800M-6E
• Chipset: MediaTek MT7916 / Filogic class device
• OS: OpenWrt
• Driver: mt76 / mt7915e
• Mode: AP
• Channel: 36
• Width: contiguous HE160
• CSI firmware event ID: 0xc2

iw dev confirms that the AP is running as contiguous 160 MHz, not 80+80.

Per-event observation

Each firmware CSI event contains:

• data_count = 256
• I payload = 512 bytes
• Q payload = 512 bytes
• raw TLV payload length = 1260 bytes

So a single firmware event appears to remain fixed at 256 I/Q samples.

Segment observation in raw PCAP

From csi_raw_160_test.pcap, using only this one PCAP file:

• total CSI events: 191,713
• segment 0 events: 95,950
• segment 1 events: 95,763
• metadata-matched segment 0/1 pairs: 54,741
• packet index delta: 1 for all 54,741 pairs
• wrapper sequence delta: 1 for all 54,741 pairs
• same_iq_pairs: 0
• different_iq_pairs: 54,741
• reconstructed I shape: (54,741, 512)
• reconstructed Q shape: (54,741, 512)

For random spot-checked raw packet pairs:

Segment 0 event:

• TLV 0x05 = 256
• TLV 0x06 length = 512 bytes
• TLV 0x07 length = 512 bytes
• TLV 0x15 = 0
• TLV 0x16 = 1

Segment 1 event:

• TLV 0x05 = 256
• TLV 0x06 length = 512 bytes
• TLV 0x07 length = 512 bytes
• TLV 0x15 = 1
• TLV 0x16 = 0

The two events share the same conservative metadata key, excluding only segment index, segment flag, I/Q bytes, packet index, and timestamp.

Interpretation

My current interpretation is:

• HE160 CSI is not exported as one 512-sample firmware event.
• Instead, the firmware exports:
  • segment 0 event: 256 I/Q samples
  • segment 1 event: 256 I/Q samples

The two adjacent events can be paired offline to reconstruct a 512-sample CSI candidate.

This interpretation preserves the conclusion that the single firmware event is fixed at 256 I/Q samples, while allowing 512-sample reconstruction from segment 0/1 pairs.

Questions

1. Is this segment 0/1 interpretation expected for MT7916 HE160 CSI event 0xc2?
2. Is TLV 0x15 intended to be the CSI segment index?
3. Is TLV 0x16 a segment or continuation flag?
4. Is the correct reconstruction order segment 0 + segment 1?
5. Is this segmentation design related to wide-bandwidth handling for contiguous 160 MHz and/or 80+80 MHz?
6. Should userspace CSI parsers treat HE160 CSI as paired segment events rather than expecting one 512-sample event?

Note

I am not requesting firmware source code or any proprietary implementation details. I only want to confirm the expected event interpretation and reconstruction method from the raw CSI event format.

[BigNerd95]

Hi @young3016,

I've been investigating MT76 CSI too, coming at it from the opposite side: my hardware doesn't emit 0xc2 events at all, while yours clearly does. I spent some time digging into the MediaTek firmware and I think I can answer most of your TLV questions. I also have one thing I'm still stuck on, in case you've already worked it out.

My setup

Hardware	2x GL.iNet GL-MT6000 (MT7986 SoC + MT7976 radio)
OS	OpenWrt 25.12.2, mt76 master (39c960c3)
Firmware	mt7986_wm.bin, build 20240823
FW md5	ee47aedd03db7624fed3977305cd5fc6, identical to the one shipped in linux-firmware and in MediaTek's public mtk-openwrt-feeds SDK

Your TLV questions (from firmware static analysis)

I disassembled the firmware with radare2 + the nds32 plugin and traced the function that builds the CSI events before they're sent to the host. Here's what the logic does, in plain terms.

The builder reads a bandwidth/width configuration byte and decides how many segments to emit:

• Narrow bandwidth: it calls the event-sender once, so you get a single 0xc2 event per capture.
• Wide bandwidth (HE160): it enters a loop and calls the event-sender multiple times, roughly scaling as 2^(width-2). For HE160 the loop runs twice, so you get two segments per capture.

Inside that loop, right before each event is sent, the firmware writes two small fields:

1. A loop counter that increments 0, 1, 2, ... across the segments of one capture.
2. A flag set to one value for the non-final segment and a different value for the final one.

This lines up cleanly with what you observed:

Your question	What the firmware logic suggests
Is segment 0/1 pairing expected?	Yes. For HE160 the builder loop runs twice by design.
Is TLV 0x15 the segment index?	Matches the loop counter field.
Is TLV 0x16 a continuation flag?	Matches the last/non-last flag field.
Is reconstruction segment 0 + segment 1?	Yes for HE160. Concatenating the two in counter order is correct.
Is this wide-bandwidth-specific?	Yes. The segment count is strictly a function of the channel width.

One caveat: this is from static disassembly only. I can't capture live 0xc2 events on my hardware (see below), so I couldn't verify the final on-the-wire TLV header packing. But the segment-counting and the index/flag logic in the firmware match your empirical findings exactly.

What I'm stuck on

On MT7986 the whole CSI emission path is present in the firmware. The strings, the builder, the event-sender are all there. The catch is that it's effectively dead code: the functions at the top of the CSI chain have no callers anywhere in the firmware image, so nothing ever triggers them.

I also ported MediaTek's official CSI driver patch (the one that defines MCU_EXT_CMD_CSI_CTRL) and confirmed the command is dispatched correctly, the firmware returns success. But when I turn on verbose firmware logging, that opcode actually lands on a TWT / power-management diagnostic handler, not the CSI subsystem. Sampling the MCU's program counter, it never executes the CSI code path.

So on the public MT7986 firmware, CSI looks like it's shipped but not wired up. Your MT7916 device is clearly producing CSI events, so something on your side is different. If you have a moment, two things would help me a lot:

1. The md5 and build date of your firmware:

   md5sum /lib/firmware/mediatek/mt7916_wm.bin
   hexdump -C /lib/firmware/mediatek/mt7916_wm.bin | tail -3

2. Whether you're running stock ipTIME firmware, a MediaTek SDK build, or a custom build, and which mt76 commit or patches you applied to get CSI flowing.

That would tell me whether MT7916 has the CSI path wired natively (a chip-level difference from MT7986), or whether your firmware is a non-public MediaTek build that enables it.

Either way, I'm happy to share the full reverse-engineering notes: the disassembled emit chain, the segment-counting logic, and where the index/flag fields get written, in case any of it is useful for your reconstruction work.

Thanks, and nice work on the pairing analysis.

Lorenzo