ESP32 Forum

Dear Espressif,

I have a question considering the CSI Data Reception functionality. Please kindly be patient with me as I am new to WiFi modulation specific topics.

The documentation specifically denotes that the registered CSI callback function is called after CSI data has been received. Here are a couple of assertions I have about workings of CSI; Please kindly correct me if I understood something wrong.

• As I am aware, CSI data is generated for every single received packet in a manner specified by the `wifi_csi_config_t` provided in the respective configuration API, the specifics of CSI data (HT / non-HT, HT20/HT40, LLTF, LTF etc.) solely depends on received packet (e.g. for figuring out the contents of the passed CSI data buffer, the user must evaluate for secondary channel location and received packet modulation characteristics like HT/non-HT etc.)
• ESP32 supports a single packet demodulation path (SISO), but additionally, multiple antennae can be configured to be switched between automatically based on an algorithm which selects the best antenna.
• CSI data is generated for every OFDM transmission burst (e.g. for each single PSDU)
• CSI data callback is only generated in promiscuous mode
• We can enable promiscuous mode in AP mode while maintaining a maximum of 4 STA connections simultaneously

I have certain questions on the documentation for CSI receive callback mechanism; Specifically, I need more information on the following:

• Each transmitted packet results in a single, contiguous PSDU which is transmitted in a single OFDM burst?
• The documentation says that the CSI data callback is called whenever CSI data becomes available;
  https://docs.espressif.com/projects/esp ... csi_cb_tPv

  Register the RX callback function of CSI data.
  Each time a CSI data is received, the callback function will be called.

  How does the procedure look like in detail? This is my understanding:

  Code: Select all

  Timestamp - Step
  1 - OFDM burst start detection at demodulator
  2 - OFDM burst LTF transmission end
  3 - PSDU transmission end
  4 - WiFi interrupt
  4.1 - In WiFi thread:
  5 - Copy from WiFi static buffer to dynamic buffer
  6 - User CSI callback
  7 - User procmiscuous mode callback
  

• Is there any condition in which CSI callback may not get called?
• Is the order of CSI callback and user promiscuous callback always the same?
• Does CSI callback get called for each packet?
• Does CSI callback get called as often as promiscuous mode callback?
• Does WiFi thread copy CSI information, or is WiFi Demodulator packet reception blocked by CSI data callback processing?

Thank you very much in advance! Please have a nice day (:

Ok, I have now read a little more about this topic and I have found following insights:

• LTF only exists in Souding Frame, there may exist OFDM bursts which do not contain Training Sequence.
• For each OFDM burst to contain a single packet, we must disable AMPDU / AMSDU

Now here are my remaining questions:

• Are there further informations on WiFi PHY beyond CSI which can be extracted (e.g. HT Control field with information regarding RIFS Mode, HT Protection mode, CSI Steering and generally information considering the Training Procedure with TRQ, NDP mechanism and initiatiation parameters for Sounding Frame)?
• Specifically, how can we force ESP32 to transmit a sounding frame, is there a possibility for the user to generate a sounding frame request using TRQ mechanism or force the transmitter to send an NDP containing the LTF beyond what is defined in 802.11 standard being the inverval of 100 ms (e.g. user-triggered, or reduction of interval to some arbitrary unit so that the radio sends NDP every 10 ms or less)?
• What information, beyond what is given in the CSI data callback can we get? I have seen that in Promiscuous Mode callback, the interesting parameter (sounding frame bit) is present, but I would like to arbitrarily generate sounding frame / TRQ.
• If not possible, can we reset this 100 ms timer somehow to trick WiFi into sending an NDP?

I'd be happy to have a little, very tiny bit more control over PHY considering the CSI mechanism as it is currently an exceedingly interesting research topic!

Good evening (:

I wanted to ask if there is any information I can provide so that someone can answer my questions, I would be very grateful for that.

Even if there is no information you can provide, I would be exceedingly happy to know about it or maybe why.

Thank you very much in advance.

Have a nice day

Dear Espressif,

It seems that anybody that is trying to work with this API in a meaningful way has some difficulty or another considering that there are some GitHub issues that have yet to be handled; The user must have very certain controls of the PHY layer (the most important one being fixed data rate packet transmission to have any OFDM burst for LTF) to make this API usable; It's like Espressif fully expects the user to reverse-engineer their chipset to make this API work.

Maybe the problem is that CSI data generation is not deemed relevant for you. Do you see; Research is all over this chipset right now because it offers exactly this feature that nobody else seems to serve in this beautiful package. There are so many interesting IoT use-cases that use WiFi sensing that can generate a giant lot of money for your company.

I'd like to understand why Espressif has opted to not communicate with people trying to make the CSI feature work, otherwise I'm happy if Espressif can offer better support for this functionality..

Thank you in advance.

Hello prismatics,

Could you get some info about the CSI performings. I would like to get the AGC for every frame
I would be happy to collaborate

Thanks