CSI acquisition on FTM packets (IDFGH-11565)

[a-arun1]

Answers checklist.

• [X] I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• [X] I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• [X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.0-dev-4723-g30e8f19f5a-dirty

Espressif SoC revision.

ESP32-S3 (revision v0.1)

Operating System used.

Linux

How did you build your project?

Command line with idf.py

If you are using Windows, please specify command line type.

CMD

Development Kit.

ESP32 S3 WROOM 1

Power Supply used.

USB

What is the expected behavior?

CSI should be reliably extracted both on the responder and initiator.

What is the actual behavior?

However, I find that the CSI is not acquired on the packets sent by the "Initiator" consistently by the "Responder". The CSI on the packets sent by the "Responder" is consistently acquired by the "Initiator".

Simply put,

(CSI acquired consistently) Initiator <-------- Responder Initiator --------> Responder (CSI acquired inconsistently)

What does "consistent" mean? Here is the log of the data acquired at the initiator: initiator_logs.txt

I can measure the CSI on all the packets received by the initiator during the FTM session, 7 in total, which is expected. It is also clear that these packets are from the FTM session: time differences between the packet arrivals time for the CSI measurement match closely with the times reported by FTM.

However, this is the log acquired by the responder: responder_logs.txt

Firstly, I don't receive enough packets from the initiator, and secondly, the packet arrival times do not correspond to the times reported by the FTM session in the "initiator_logs.txt" file.

Finally, I also tested this system by setting up a third ESP32-S3 in monitor mode, filtered the packets from the initiator and responder, and observed the same behavior. This tells me that the issue is not the responder's inability to acquire CSI, but the initiator's packet transmission.

How can I reliably acquire CSI on the reponder for the CSI packets transmitted from the initiator?

Steps to reproduce.

Code on initiator: ftm_main_init_csi.txt

Code on responder: ftm_main_resp_csi.txt

Code on monitor: app_main.txt

Debug Logs.

No response

More Information.

I am interested in implementing the enhanced FTM techniques mentioned in the Ubilocate and FUSIC papers. So, I am trying to extract CSI on the FTM packets exchanged between two ESP32-S3 modules.

[MaxwellAlan]

Hi @a-arun1

I am interested in implementing the enhanced FTM techniques mentioned in the Ubilocate and FUSIC papers. So, I am trying to extract CSI on the FTM packets exchanged between two ESP32-S3 modules.

Interesting ideas 👍

Well, if you want to get CSI from FTM, two things you need to check: 1.menuconfig should enable CSI feat. 2.the FTM action frame's data rate(you can check from sniffer logs) should be OFDM(11g or 11n, not 11b rate).

Thanks.

[Sherry616]

Hi @a-arun1, could you please share your latest updates on this issue? Thanks.

[a-arun1]

Thank you for following up. I tried these suggestion however, it did not help. We have already enabled CSI collection with menuconfig and we have confirmed it is 11g rate.

[zhangyanjiaoesp]

@a-arun1 Thanks for update, we will check this issue with your test code ASAP.

[zhangyanjiaoesp]

@a-arun1 Could you please test again with the latest master branch? We have recently addressed some FTM-related issues.

[zhangyanjiaoesp]

@a-arun1 Do you still have this issue? If not, can we close it ?

[Alvin1Zhang]

Thanks for reporting, will close for now, feel free to reopen if the issue still happens.