-
Notifications
You must be signed in to change notification settings - Fork 7.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BLE suddenly disconnected, Wi-Fi and BLE coexist case. (IDFGH-13900) #14742
Comments
Hi @Sky-Soo-Ap , thanks for reporting the issue and the logs. I would like to collect following information for further analysis.
|
Hi Wmy,
|
Hi @Sky-Soo-Ap thanks for the information. For Question 5 on estimation of wireless interference, it is enough to roughly tell me how many wireless devices(BLE devices, WLAN APs, etc) that uses 2.4GHz band are there in your test environment, and what are the distances from the device under test nearby. Here is my initial analysis for this issue: LOG1:
LOG2:
In case of wireless coexistence of BLE connection + WiFi STA mode, part of BLE connection events(15ms interval) will be pre-empted by Wi-Fi activities, however, the SupervisionTimeout is as long as 6s, which allows at most 400 chances for two devices to communicate and restore synchronization. In this case, occasional interference(not severe) is not likely to break the connection, I think. However, we don't know yet whether the BLE supervision timeout is caused by the DUT(central) or the remote BLE device. So I would suggest to
This may make peripheral to use larger Rx window and improve the robustness of BLE link. Besides, suggest to modify the following configuration options, which may improve the wireless coexistence performance:
|
Hi Wmy, Thank you for your detailed reply.
|
Hi Wmy, About the estimation of wireless interference, there are another 2 devices that use the 2.4 GHz band at about 5 meters. BTW, do you know how the ESP32 client (master) role in BLE listens and responds to peripheral (slave) update connection interval parameters requests? |
HI @Sky-Soo-Ap
I am afraid we don't have such lower-level statistics. If you have a sniffer you can check the air packets.
Usually ESP32 as BLE central will accept the connection update request from peripheral. I have check the log file "2024-10-21.log", there is a new phenomenon that did not occur in "2024-10-17_debug.log":
This indicates connection parameter is updated, connection interval is increased to 50ms(40 * 1.25ms), and slave latency is set to 10. This parameter set will behave quite differently from the original log that uses 15ms connection interval and 0 slave latency. Current parameter is more risky in case of BLE connection robustness in wireless coexistence mode. My questions:
|
Hi Wmy,
Also, how do I set the BLE connection timeout? |
Hi @Sky-Soo-Ap ,
The default BLE supervision timeout is 6s when acting as central. There is an inner macro |
Hi Wmy, |
I am afraid there is no argument to set connection timeout provided in the API An option is to use |
Hi Wmy, |
Hi @Sky-Soo-Ap the macro BTM_BLE_CONN_TIMEOUT_DEF is defined in |
Hi Wmy, |
Hi @Sky-Soo-Ap . I guess this is what you need: there is a sdkconfig parameter: |
Hi wmy-espressif, |
Hi @Sky-Soo-Ap , I am sorry for the late response. |
Answers checklist.
IDF version.
v5.3.1
Espressif SoC revision.
ESP32-D0WDR2-V3-V3 (revision v3.1)
Operating System used.
Windows
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
None
Development Kit.
Custom Board
Power Supply used.
USB
What is the expected behavior?
I expected BLE to keep connected.
What is the actual behavior?
BLE will be randomly disconnected.
Steps to reproduce.
...
Debug Logs.
More Information.
Attached BLE & log level set to verbose.
2024-10-17_debug.log
The text was updated successfully, but these errors were encountered: