The relationship between CSI "sub-carrier index" and "sub-carrier range". (AEGHB-445)

[harlanho4]

This document introduces the sub-carrier index under different channels and packet information. I have some questions about the relationship between sub-carrier index and sub-carrier range.

1. Assuming the secondary channel is set to none, the signal mode is non HT, the channel bandwidth is 20MHz, and STBC is non STBC, according to the table in the document, the sub-carrier index should be "0 ~ 31, -32 ~ 1". My understanding is that this index also represents the storage order of sub-carriers. However, in the 802.11 standard, the range of sub-carriers is -32 to 32 (including null sub-carriers), so do we need to adjust the stored sub-carrier order from "0 ~ 31, -32 ~ -1" to "-32 ~ -1, 0 ~ 31"?
2. How do other sub-carrier indexes, such as "0 ~ 63"(secondary channel : below, HT, 40 MHz, non STBC), correspond to the sub-carrier range of -32 to 32? In the example code provided by you, when removing null subcarriers, it is assumed that sub-carrier index "0 ~ 63" correspond to the sub-carrier range of -32 to 32 (null subcarrier index: -32 to -27, 0, 28 to 32). Can you provide more detailed explanations?

   # Remove invalid subcarriers
   # secondary channel : below, HT, 40 MHz, non STBC, v, HT-LFT: 0~63, -64~-1, 384
   csi_vaid_subcarrier_index = []
   # LLTF: 52
   csi_vaid_subcarrier_index += [i for i in range(6, 32, CSI_VAID_SUBCARRIER_INTERVAL)]
   csi_vaid_subcarrier_index += [i for i in range(33, 59, CSI_VAID_SUBCARRIER_INTERVAL)]

3. If there is no other explanation, we may mistakenly assume that sub-carrier index "-64 ~ -1" corresponds to the sub-carrier range of 32 to -32.

In addition, as stated in the document, if first_word_invalid field of wifi_csi_info_t is true, it means that the first four bytes of CSI data is invalid due to a hardware limitation in ESP32. However, in the console_test code, first_word_invalid is set to 0. Why is this?

len += sprintf(buffer + len, "CSI_DATA,%d,%u,%u,%s," MACSTR ",%d,%d,%d,%d,%d,%d,%d,%d,%d,%d,%d,%d,%d,%d,%d,%u,%d,%d,%d,%d,%d,",
               count++, esp_log_timestamp(), g_console_input_config.collect_number, g_console_input_config.collect_taget,
               MAC2STR(info->mac), rx_ctrl->rssi, rx_ctrl->rate, rx_ctrl->sig_mode,
               rx_ctrl->mcs, rx_ctrl->cwb, rx_ctrl->smoothing, rx_ctrl->not_sounding,
               rx_ctrl->aggregation, rx_ctrl->stbc, rx_ctrl->fec_coding, rx_ctrl->sgi,
               rx_ctrl->noise_floor, rx_ctrl->ampdu_cnt, rx_ctrl->channel, rx_ctrl->secondary_channel,
               rx_ctrl->timestamp, rx_ctrl->ant, rx_ctrl->sig_len, rx_ctrl->rx_state, info->valid_len, 0);

[zhanzhaocheng]

@harlanho4 You can use wifi_csi_filtered_cb obtains CSI data, and the esp radar module filters out invalid subcarriers, making it easier for you to use

1. This is determined by Wi-Fi phy
2. You can refer to this form:
3. Due to the absence of valid CSI data in the first four bytes on certain channels, rst_word_invalid is sometimes set to 0. Among all Espressif chips supporting CSI functionality, the performance of esp32 is comparatively lower. Therefore, it is recommended to utilize the CSI functionality on ESP32-C3 or ESP32-S3.