esp-csi
esp-csi copied to clipboard
espressif
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.
We have received the code you provided and are about to reproduce the issue. We will keep you informed of any progress.
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.