CSI acquisition on FTM packets (AEGHB-472)

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.

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?

Thank you for your support.

Thank you for your feedback. Recently, we have also been researching the application of combining FTM and CSI data. We will try to reproduce your issue and respond to you as soon as possible.

Hello, is there any update on this? I built custom PCBs with multiple ESP chipsets per board. But we need to capture CSI for FTM packets in order to capture the information about CSI quickly enough for our application. Without CSI from FTM, we have no path to implementing our design. Please let us know if this will be possible, if not we will need to abandon our design.
Thank you!

I'm sorry that we were unable to successfully reproduce the issue you reported. Could you please provide the key code snippets for both the initiator and responder? This would greatly assist us in reproducing the issue.

Thank you for checking it out on your end. I have attached the scripts for the initiator and responder. Please change them to *.c files on your end, github does not allow uploading .c files.

init.txt
resp.txt

We have received the code you provided and are about to reproduce the issue. We will keep you informed of any progress.

@a-arun1

Hello @a-arun1, in my perspective, addressing your requirements can be achieved by incorporating our CSI repository and the ftm example project (idf/example/wifi/ftm). No modifications are necessary for the codes within these two repositories.

Moreover, considering that your initiator can fulfill your needs, specifically in sending ftm and acquiring csi data from ftm packets, why not utilize your initiator code on the responder device?

Hello, thank you for the response.

-- "in my perspective, addressing your requirements can be achieved by incorporating our CSI repository and the ftm example project (idf/example/wifi/ftm). No modifications are necessary for the codes within these two repositories."

I have done exactly this in the attached code, and it did not work. Please let me know if you observed different results on your end. I am unsure how to debug this problem.

-- "Moreover, considering that your initiator can fulfill your needs, specifically in sending ftm and acquiring csi data from ftm packets, why not utilize your initiator code on the responder device?"

I am using the same CSI-acquisition code on the initiator and responder.

@a-arun1

@a-arun1 I am curious to know what was the result of your experiments, did FUSIC work for you on ESP32 chip?

I was facing the same problem (it seems) like you have described, the following helped in my case:

    wifi_csi_config_t csi_cfg = {
        .enable = 1,
        .acquire_csi_legacy = 1,
        .acquire_csi_ht20 = 1,
        .acquire_csi_ht40 = 1,
        .acquire_csi_su = 1,
        .acquire_csi_mu = 1,
        .acquire_csi_dcm = 1,
        .acquire_csi_beamformed = 1,
        .dump_ack_en = 1,
    };

I am on C6.

@abbbe

@abbbe Were you able to get CSI at the responder as well as the initiator? I am only able to get it at initiator on ESP32-S3.

Responder is messy. From what I understood it used much shorter packets with smaller preamble.

我这边也遇到了同样的问题，responder收到的CSI更短（128字节），并且在一组burst里面只会接收到一帧。从FTM原理来说，这里识别到的一帧应该是FTM request帧，category和ACTION在IEEE标准中定义和FTM measurement帧是不一样的，并且在esp-32平台上强制是使用LLTF的前导码。然后在接下来的测量中，responder发给initiator的都是FTM measurement，但是initiator发给responder的都是ack，不知道是设备本身的问题还是其他，总是ack帧是无法通过过滤得到的（查阅了IEEE标准并进行了正确的过滤，但是ack帧无法得到，就算能够得到，应该也是64个子载波，如果需要用40MHZ或者80MHZ的话，双边的CSI是始终不可能的）。

Navigation Menu

Repository navigation

CSI acquisition on FTM packets (AEGHB-472) #148

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

CSI acquisition on FTM packets (AEGHB-472) #148

Description

Activity

lisir233 commented on Nov 29, 2023

julianstj1 commented on Dec 12, 2023

MacChu0315-Espressif commented on Dec 12, 2023

a-arun1 commented on Dec 13, 2023

MacChu0315-Espressif commented on Dec 14, 2023

MacChu0315-Espressif commented on Dec 19, 2023

a-arun1 commented on Jan 3, 2024

abbbe commented on Feb 19, 2026

wshunter commented on Apr 21, 2026

abbbe commented on Apr 21, 2026

fangyiye-wxx commented on Jul 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions