ESP32-S3 FTM fails with external station when c > 8 (IDFGH-7396)

[NaivelyWritten]

Environment

• Development Kit: [ESP32-S3-USG-OTG]
• Module or chip used: [ESP32-S3]
• IDF version (run git describe --tags to find it):
  // v4.4.1
• Build System: [idf.py]
• Compiler version (run xtensa-esp32-elf-gcc --version to find it):
  // xtensa-esp32s3-elf-gcc (crosstool-NG esp-2021r2-patch3) 8.4.0
• Operating System: [macOS]
• (Windows only) environment type: [MSYS2 mingw32|ESP Command Prompt|Plain Command Prompt|PowerShell].
• Using an IDE?: VSCode
• Power Supply: [USB]

Problem Description

ESP32-S3 cannot measure distance to external Google Nest Router (router works with WifiRttScan).

Expected Behavior

It should work

Actual Behavior

ftm> ftm -I -s testap -c 16 -p 100
I (415570) ftm_station: Requesting FTM session with Frm Count - 16, Burst Period - 10000mSec (0: No Preference)
W (415580) wifi:Starting FTM session with xx:xx:xx:xx:xx in 0.200 Sec
W (415580) wifi:Mode: non-ASAP, Bursts: 2, FTM's per burst: 8, Burst Period: 9900mSec, Burst Duration: 32000uSec
E (415780) wifi:No valid FTM Measurements found!
I (415780) ftm_station: FTM procedure with Peer(xx:xx:xx:xx:xx) failed! (Status - 4)

Steps to reproduce

1. use latest ftm demo from esp-idf
2. patch the console to use USB-JTAG console
3. compile flash and monitor
4. type above command
5. fail

// If possible, attach a picture of your setup/wiring here.

Code to reproduce this issue

need to patch the console according to 3390d2a

Debug Logs

ftm> ftm -I -s testHotspotname
I (76377) ftm_station: Requesting FTM session with Frm Count - 32, Burst Period - 200mSec (0: No Preference)
V (76377) esp_adapter: thread sem get: sem=0x3fcecc4c
W (76387) wifi:Starting FTM session with xxxxxxxx in 0.200 Sec
W (76387) wifi:Mode: non-ASAP, Bursts: 8, FTM's per burst: 4, Burst Period: 900mSec, Burst Duration: 32000uSec
E (76587) wifi:No valid FTM Measurements found!
D (76587) event: running post WIFI_EVENT:17 with handler 0x420063f0 and context 0x3fcea76c on loop 0x3fce1fc0

Other items if possible

• sdkconfig file (attach the sdkconfig file from your project folder) sdkconfig.gz
• elf file in the build folder (note this may contain all the code details and symbols of your project.) ftm.elf.gz
• coredump (This provides stacks of tasks.)

[NaivelyWritten]

Tested again with same (Pixel phone), FTM Responder mode works fine with the ESP32-S3. FTM Initiator against the Nest wifi does not work.

[NaivelyWritten]

Error is within libnet80211.a, so it is internal to Espressif.

[NaivelyWritten]

Also, unlike #6243 this is the case even after association with AP

[NaivelyWritten]

Tested again today with burst size = 8, the ranging works under this condition. Anything larger than 8 fails. Tested larger burst sizes with Pixel, and Pixel works without an issue.

[NaivelyWritten]

Also, the FTM routine has some kind of heap corruption issue. In the official FTM demo, first associate of an AP, type query:

ftm> sta STAT PASSWORD
I (4309) ftm_station: sta connecting to 'XXX'
I (6439) ftm_station: Connected to XXX (BSSID: XXXX, Channel: 11)
ftm> query
I (12339) ftm_station: sta mode, connected XXX

Then do one round of FTM:

ftm> ftm -I -c 8 -s ANOTHER_AP
I (49989) ftm_station: Estimated RTT - 550 nSec, Estimated Distance - 82.50 meters
ftm> query
I (16949) ftm_station: sta mode, connected setu�r�?�

Note query now outputs garbage

[NaivelyWritten]

@nachiketkukade @sagb2015 @suda-morris Pinging because this is some kind of memory corruption that seems more serious than just FTM failure.

[chegewara]

Hi,
i believe this is still a problem.
"wifi->ftm" example on 2x esp32 S3 most the time is returning status == 4 (FAIL)

ftm> ftm -I
I (379281) ftm_station: Requesting FTM session with Frm Count - 32, Burst Period - 200mSec (0: No Preference)
I (379781) ftm_station: FTM procedure with Peer(1e:cf:24:b2:82:e0) failed! (Status - 2)
ftm> ftm -I -s espTest
I (392991) ftm_station: Requesting FTM session with Frm Count - 32, Burst Period - 200mSec (0: No Preference)
W (392991) wifi:Starting FTM session with 7c:df:a1:e8:05:ed in 0.084 Sec
W (393011) wifi:Mode: non-ASAP, Bursts: 8, FTM's per burst: 4, Burst Period: 200mSec, Burst Duration: 32000uSec
E (394521) wifi:No valid FTM Measurements found!
I (394521) ftm_station: FTM procedure with Peer(7c:df:a1:e8:05:ed) failed! (Status - 4)
ftm> ftm -I -s espTest
I (425721) ftm_station: Requesting FTM session with Frm Count - 32, Burst Period - 200mSec (0: No Preference)
W (425721) wifi:Starting FTM session with 7c:df:a1:e8:05:ed in 0.020 Sec
W (425731) wifi:Mode: non-ASAP, Bursts: 8, FTM's per burst: 4, Burst Period: 200mSec, Burst Duration: 32000uSec
W (427181) wifi:FTM session ends with 1 valid readings out of 31, Avg raw RTT: 481.250 nSec, Avg RSSI: -21
I (427181) ftm_station: FTM Report:
I (427181) ftm_station: | Diag |   RTT   |       T1       |       T2       |       T3       |       T4       |  RSSI  |
I (427191) ftm_station: |    26| 481250  | 5280411673437  | 3957497960937  | 3957615545312  | 5280529739062  |   -21  |
I (427201) ftm_station: Estimated RTT - 348 nSec, Estimated Distance - 52.30 meters
ftm> ftm -I -s espTest
I (450861) ftm_station: Requesting FTM session with Frm Count - 32, Burst Period - 200mSec (0: No Preference)
W (450871) wifi:Starting FTM session with 7c:df:a1:e8:05:ed in 0.069 Sec
W (450881) wifi:Mode: non-ASAP, Bursts: 8, FTM's per burst: 4, Burst Period: 200mSec, Burst Duration: 32000uSec
E (452371) wifi:No valid FTM Measurements found!
I (452371) ftm_station: FTM procedure with Peer(7c:df:a1:e8:05:ed) failed! (Status - 4)
ftm> ftm -I -s espTest
I (461831) ftm_station: Requesting FTM session with Frm Count - 32, Burst Period - 200mSec (0: No Preference)
W (461831) wifi:Starting FTM session with 7c:df:a1:e8:05:ed in 0.058 Sec
W (461851) wifi:Mode: non-ASAP, Bursts: 8, FTM's per burst: 4, Burst Period: 200mSec, Burst Duration: 32000uSec
E (463331) wifi:No valid FTM Measurements found!
I (463331) ftm_station: FTM procedure with Peer(7c:df:a1:e8:05:ed) failed! (Status - 4)

and with -c 8 it return success all the time.

I dont want to open new issue, yet, but the result is offset by around 50+ meters. Devices about 10-20cm from each other:

ftm_station: Estimated RTT - 348 nSec, Estimated Distance - 52.30 meters

the same test with +/-14 meters away (multiple tests, the same distance):

ftm_station: Estimated RTT - 506 nSec, Estimated Distance - 75.90 meters
...
ftm_station: Estimated RTT - 402 nSec, Estimated Distance - 60.40 meters

I tested with this commit, but i can try to update if needed:
commit a634aa5

Thanks

[chegewara]

Some RTT observation:

• in my tests, using ftm example, there is about +52m offset
• when initiator connects to responder, then offset is +40m
• when initiator disconnect from responder, then offset is around 64.5m until AP is reinitiated on responder, then offset get back to previous values (worth to see whats going on when responder lose connection)

board: esp32 S3 - wroom -1U devkit (Chip is ESP32-S3 (revision v0.1))
esp-idf: d29e53d

When responder is esp32S2 then offset is much lower (few cm away):

I (250995) ftm_station: Estimated RTT - 236 nSec, Estimated Distance - 35.40 meters - disconnected mode
ftm> sta esp
I (288199) ftm_station: Estimated RTT - 149 nSec, Estimated Distance - 22.40 meters - connected to responder mode

When initiator and responder, both are esp32 S2 then i see no distance offset.

@igrr @suda-morris

Thanks

[rgrunbla]

I have the same issue.

[NaivelyWritten]

Gently pinging after 1 year :) @sagb2015 Could we just open source the FTM part of the blobs and we can try fix these ourselves?

[sarveshb14]

Hi @NaivelyWritten, we are working on multiple issues related to FTM including this one.
This will get fixed soon.

[sarveshb14]

Hi @NaivelyWritten, @chegewara, @rgrunbla , Can you please try with following IDF patch: FTM_patch_v4.4.1.txt and WiFI libraries: ftm_esp32s3_libraries.zip
(Replace WiFi binaries in components/esp_wifi/lib/esp32s3 with provided binaries) and provide the logs here.
We recommend setting bandwidth to 20MHz before starting connection. (esp_wifi_set_bandwidth(WIFI_IF_STA, WIFI_BW_HT20))

We have added improvements along with modified logs to indicate if no FTM responses were received from the Responder.

[NaivelyWritten]

Hi @sarveshb14 we have moved from 4.4.1 and is now operating with v5.1-rc1 now

[sarveshb14]

Hi @NaivelyWritten , here are libraries (ftm_esp32s3_libraries_v5.1-rc1) and IDF patch (FTM_patch_v5.1-rc1.txt) for v5.1-rc1.

[sarveshb14]

Hi @NaivelyWritten ,
Any update on this ?

[ProfFan]

Hi @sarveshb14 I am currently not actively working on FTM anymore but I can test when I have time

[nachiketkukade]

@NaivelyWritten / @ProfFan , we needed help on one more thing. Can you please confirm if the Google Nest Router is able to successfully perform FTM in 2.4GHz? You can check the channel/frequency in WifiRttScan App or share a sniffer capture of a Beacon of the AP in 2.4GHz. We have both Google Wi-Fi and Nest Wifi Pro AP's with us, but we found that both support FTM only in 5GHz.

[nachiketkukade]

Closing due to no activity. The original issue was likely due to calibration issues similar to #6810 which was closed recently