ESP32 Forum

Hi everyone,
To implement Time-Of-Flight scenarios, I need to know the exact packet arrival time (accurate to ESP32 clock of 240MHz - 4 nanosecond) in the promiscuous mode callback. The current `rx_ctrl->timestamp` field received in the payload is not sufficient as it is precise only to the current microsecond, which makes it moot for calculating ToF.

Since ESP32 supports 802.11mc FTM, the packet arrival time can be read at a higher precision. I'm wondering if:

1. There is an inbuild method I could leverage for it?

2. In case there isn't one, how and where can I modify the code which assigns the fields for rx_ctrl (RSSI, Channel, Timestamp etc.) to instead write the CPU clock register (which can be retreived by `get_ccount_register()` ) in the timestamp field as soon as the packet is received.

3. Where is the internal code implementation for FTM, which I could use as a reference?

4. Is it possible to create a "one-sided" FTM request in the current API? This is now available in Android.

fliptrail wrote: ↑

Fri Sep 15, 2023 9:05 am

where can I modify the code ... to instead write the CPU clock register (which can be retreived by `get_ccount_register()` ) in the timestamp field as soon as the packet is received.

This wouldn't work anyway. When counting CPU clock cycles, the jitter in the timing before any code actually runs in response to a WiFi event/interrupt is huge (can be dozens or even hundreds of CPU cycles).

2. In case there isn't one, how and where can I modify the code which assigns the fields for rx_ctrl (RSSI, Channel, Timestamp etc.) to instead write the CPU clock register (which can be retreived by `get_ccount_register()` ) in the timestamp field as soon as the packet is received.

3. Where is the internal code implementation for FTM, which I could use as a reference?

You can't. That stuff is in Espressif's closed-source WiFi driver.

Thanks for your reply.

This wouldn't work anyway. When counting CPU clock cycles, the jitter in the timing before any code actually runs in response to a WiFi event/interrupt is huge (can be dozens or even hundreds of CPU cycles).

I could live with that jitter, hypothising that since my WiFi task core is idle, the delay would be constant and jitter would be minimal, which might go away after averaging over 100+ ToF measurements.

Also, how instantaneous is the wifi promiscuous callback? Is it attempted to execute as soon as a packet arrives? What happens when a packet arrives before the callback of the previous packet has finished executing? Do such callbacks queue up in a sequence to be executed one after the other?
If I can guarantee that the callback finished before the next packet arrives, then I think getting the ccount register in the first statement of callback function might be a closer indication of the packet arrival time. Since I need to subtract two such values, the possible (constant?) delay from packet arrival to callback execution would get factored out automatically.