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

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.

Start by tracing the mt7915e CSI event handling and the TLV 0x15/0x16 fields described in the issue, then compare that behavior with the supplied raw PCAP observations. The work is complete only when the segment interpretation and reconstruction order are confirmed well enough to define any required userspace parser behavior.