payload in senddata.c

[Alpha2Cool]

Is it necessary to set payload as 0xaa in senddata.c to acquire csi? Is csi the result of the impulse response? I want to know how csi be calculated. I found the dirver of ath9k (/drivers/net/wireless/ath/ath9k/ar9003_mac.c) has been changed, and the data(in ar9003_mac.c) come from "data_addr = buf_addr + 48;", so what's "buf_addr"? I'm so confused....

[Geosearchef]

The payload isn't important as far as I know. I'm using plain old ICMP echo and it works just fine (as long as the fields mentioned below are set correctly and crc_error ist set, which I think is wrong and only works on older atheros chips).

The data is coming from the wireless chip. The buf_addr points to the data received from the firmware of the chip following this specification (page 101, RX descriptor): https://datasheetspdf.com/pdf-file/825113/Atheros/AR9344/1

When not_sounding is not set, hw_upload is set, hw_upload_data_valid is set and hw_upload_data_type is set to CSI (not e.g. beamforming matrix, see RX descriptor specification as well as the 802.11n standard, page 173 about possible types), the firmware will upload CSI information to the kernel (those flags can be seen being checked in the CSI tool code you referenced). This information happens to be present in the data received beginning at byte 48.

(actually, some newer QCA chips do not follow this/their specification especially when it comes to beamforming, about what devices support the tool, see this discussion: https://github.com/xieyaxiongfly/Atheros_CSI_tool_OpenWRT_src/issues/35)

Sry for the complicated, chaotic answer, but I was trying to point you to the relevant documentation to find the answers you need, what's your actual issue that you're trying to solve?

[Alpha2Cool]

That is to say, CSI is directly generated by the chip, buf_addr just read the data? I have no special issue to solve, just interested in this project.

[Geosearchef]

I recommend taking a look at the 802.11n standard, TxBF (transmit beamforming, around section 19). I was writing sth up, but realized it was too much, so the following is just copied from my bachelor's thesis.

Transmit beamforming

The 802.11n amendment to the WiFi standard [1] defines procedures for transmit beamforming (TxBF) to increase the range and signal strength of WiFi networks. The goal is to calculate a steering matrix based on the received Channel State Information at the client which can then be used by the AP to steer the transmitted signal in the direction of the client. There are two types of beamforming defined in 802.11n, explicit and implicit feedback. In implicit mode the channel is estimated by the beamformer (AP) over a longer time, in explicit mode the beamformer sends an explicit request (a training sequence) to the beamformee which then calculates the Channel State Information or steering matrix and transmits it back to the beamformer [1, 9.19.1]. Both tools listed in sections 4.4 and 4.5 use explicit beamforming. To obtain CSI, the beamformee needs to receive either a sounding PLCP Protocol Data Unit (PPDU) or Null Data Packet (NDP), which means the sounding parameter has to be set by the transmitter [1, 9.17] which restricts the usage of CSI based applications with non-modified WiFi devices. Implementations of TxBF in 802.11n chips are mostly not present or not fully complete as the standard is not very specific and offers too many options (implicit and explicit beamforming) which prompted many manufacturers to implement this feature only in part. This leads to some problems when operating different devices from different manufacturers. In case of the Atheros ath9k driver e.g., CSI reporting is not even implemented. While the chip does upload the calculated CSI matrix to software, it will not be reported back to the beamformer [13].

---

So yes, the CSI is generated by the chip. Sadly the n standard wasn't very precise on beamforming (implicit, explicit,...) so a lot of manufacturers didn't implement it (unlike thr newer 802.11ac). In case of atheros devices, they didn't implement transmitting beamforming information like steering matricies (calculated from CSI) or CSI itself back to the receiver either afaik. But, the chips can calculate CSI information when the not_sounding flag of an arriving PPDU is not set and certain other criteria are fullfilled. Then the chip will upload the calculated CSI to the software (driver) where it can be used. As this feature is not fully implemented there seems to be no documentation about how that works and I have no idea how @ xieyaxiongfly figured out the location inside the data buffer.

[Alpha2Cool]

Thank you for such a detailed description, which inspired me a lot, and now I probably know how it works.