WIFI/BLE Simultaneously

[Ritesh]

Hi Loboris or Kolban or Espressif Developer,

Could you guys please provide some more useful and fruitful informations regarding how WiFi and BLE are working together from Architecture Point of View?

So that ESP32 Users might have better idea and will have clear understanding regarding that.

[ESP_Tianhao]

Hi Loboris or Kolban or Espressif Developer,

Could you guys please provide some more useful and fruitful informations regarding how WiFi and BLE are working together from Architecture Point of View?

So that ESP32 Users might have better idea and will have clear understanding regarding that.

I can describe something about the WIFI and BLE/BR/EDR coexistence.
As everyone know, ESP32 only have one RF, so WIFI and Bluetooth share the RF. Thus, low layer have two method to control the RF sharing: hardware control automatically and software control.

1. Hardware control:
If you disable CONFIG_SW_COEXIST_ENABLE, it will use hardware control. In this mode, Bluetooth has higher priority then WiFi. It will keep the bluetooth performance, but WiFi may be effected depend on bluetooth traffic. It means while WIFI is RX a packet, if bluetooth want to TX or RX a packet, it will stop WiFi. For example, BLE is scanning and WiFi is just in connection to hear beacon. If you set BLE scan interval equal to scan window, it means BLE scan will occupy RF all the time, so WiFi connection may be lost. So to keep WiFi connection, you should set BLE scan window little than scan interval and should not set scan window too large (such scan window=0x10, scan_interval=0x80 seems good), It will give WiFI a lot chances to use RF. Although, there 's still some conflicts may happen that WiFI is TX/RX while bluetooth is TX/RX, but the ratio is decreased. It may cause WiFi TX/RX performance decrease but don't cause WiFi connection lost. In fact, the performance is not too bad. For most IoT applications, it can be adopted.
Most of BLE have enough time gap(except BLE scan parameter or connection interval is too bad), there's a lot chance for WiFI. So BLE and WiFi can be work in hardware control mode.
But for BR/EDR(classic BT), due to the restriction of BR/EDR, BR/EDR has no enough time gap. Each Master-To-Slave frame, there's only a little time (much little than 625us) time gap. So BR/EDR cannot work better with WiFi simultaneously in hardware control mode.

2. Software control:
For resolve the restrictions of hardware control mode, we develop software control mode. This control mode works in low layer to arbit the RF occupy right for WiFI or bluetooth.
It depends on WiFi power-save and Bluetooth retransmission mechanism. So this mode is only for WiFi station mode (AP mode could not support power-save). In this mode, most applications (A2DP/SPP/GATT-based Profiles) need not to care about the coexistence implementation, not afraid WiFi connection lost and other things, just use WiFi and Bluetooth as your expect. Except some special applications, such like BLE mesh(use scan/adv) and WiFi TCP connection, to keep BLE scan performance, it may need to modify the software control parameters to make the coexistence more fit to this application scenario.
In software control mode, there's 3 option to modify the coexist preference（Balance, prefer to WiFi and prefer to Bluetooth). Normally, Balance is a good choice. For example, in balance preference, Bluetooth A2DP can play music fluently while WiFi is running throughput test (In sheildbox, the TCP RX can reach 8Mbps).

Above all:
1. BLE can works under both hardware control mode and software control mode. But in hardware control mode, you should care about the BLE scan parameter is bad or BLE connection interval is too small.
2. BR/EDR can only works in software control mode.

[Ritesh]

Hi Loboris or Kolban or Espressif Developer,

Could you guys please provide some more useful and fruitful informations regarding how WiFi and BLE are working together from Architecture Point of View?

So that ESP32 Users might have better idea and will have clear understanding regarding that.

I can describe something about the WIFI and BLE/BR/EDR coexistence.
As everyone know, ESP32 only have one RF, so WIFI and Bluetooth share the RF. Thus, low layer have two method to control the RF sharing: hardware control automatically and software control.

1. Hardware control:
If you disable CONFIG_SW_COEXIST_ENABLE, it will use hardware control. In this mode, Bluetooth has higher priority then WiFi. It will keep the bluetooth performance, but WiFi may be effected depend on bluetooth traffic. It means while WIFI is RX a packet, if bluetooth want to TX or RX a packet, it will stop WiFi. For example, BLE is scanning and WiFi is just in connection to hear beacon. If you set BLE scan interval equal to scan window, it means BLE scan will occupy RF all the time, so WiFi connection may be lost. So to keep WiFi connection, you should set BLE scan window little than scan interval and should not set scan window too large (such scan window=0x10, scan_interval=0x80 seems good), It will give WiFI a lot chances to use RF. Although, there 's still some conflicts may happen that WiFI is TX/RX while bluetooth is TX/RX, but the ratio is decreased. It may cause WiFi TX/RX performance decrease but don't cause WiFi connection lost. In fact, the performance is not too bad. For most IoT applications, it can be adopted.
Most of BLE have enough time gap(except BLE scan parameter or connection interval is too bad), there's a lot chance for WiFI. So BLE and WiFi can be work in hardware control mode.
But for BR/EDR(classic BT), due to the restriction of BR/EDR, BR/EDR has no enough time gap. Each Master-To-Slave frame, there's only a little time (much little than 625us) time gap. So BR/EDR cannot work better with WiFi simultaneously in hardware control mode.

2. Software control:
For resolve the restrictions of hardware control mode, we develop software control mode. This control mode works in low layer to arbit the RF occupy right for WiFI or bluetooth.
It depends on WiFi power-save and Bluetooth retransmission mechanism. So this mode is only for WiFi station mode (AP mode could not support power-save). In this mode, most applications (A2DP/SPP/GATT-based Profiles) need not to care about the coexistence implementation, not afraid WiFi connection lost and other things, just use WiFi and Bluetooth as your expect. Except some special applications, such like BLE mesh(use scan/adv) and WiFi TCP connection, to keep BLE scan performance, it may need to modify the software control parameters to make the coexistence more fit to this application scenario.
In software control mode, there's 3 option to modify the coexist preference（Balance, prefer to WiFi and prefer to Bluetooth). Normally, Balance is a good choice. For example, in balance preference, Bluetooth A2DP can play music fluently while WiFi is running throughput test (In sheildbox, the TCP RX can reach 8Mbps).

Above all:
1. BLE can works under both hardware control mode and software control mode. But in hardware control mode, you should care about the BLE scan parameter is bad or BLE connection interval is too small.
2. BR/EDR can only works in software control mode.

Thanks for useful information regarding that.

It will be good if you provide few more details with examples like where we can use hardware flow control and where we can use software flow control with it's advantage and disadvantages as well.

[mpbejo]

Dear Mr. Tian Hao,
your post it is very interesting, and it is nice to read:-" For example, in balance preference, Bluetooth A2DP can play music fluently while WiFi is running throughput test (In sheildbox, the TCP RX can reach 8Mbps). "
But as Mr. Ritesh Prajapati said We need samples and documentation to implement the Software control.
At this moment i can run my sketch with wifi and ble at the same time but with very poor performance.
I hope that You provide this informations
Thank You
Best Regards
Marco

[ESP_Tianhao]

Dear Mr. Tian Hao,
your post it is very interesting, and it is nice to read:-" For example, in balance preference, Bluetooth A2DP can play music fluently while WiFi is running throughput test (In sheildbox, the TCP RX can reach 8Mbps). "
But as Mr. Ritesh Prajapati said We need samples and documentation to implement the Software control.
At this moment i can run my sketch with wifi and ble at the same time but with very poor performance.
I hope that You provide this informations
Thank You
Best Regards
Marco

Hi, MR mpbejo,
Which does "very poor performance" indicate? wifi performance or ble performance?
For wifi performance, such as TCP, it also depends on LWIP and Wifi settings in menuconfig. Besides, 8Mbps is testing in sheildbox.
Could you check your sdkconfig and environment?

[ESP_Tianhao]

Hi Loboris or Kolban or Espressif Developer,

Could you guys please provide some more useful and fruitful informations regarding how WiFi and BLE are working together from Architecture Point of View?

So that ESP32 Users might have better idea and will have clear understanding regarding that.

I can describe something about the WIFI and BLE/BR/EDR coexistence.
As everyone know, ESP32 only have one RF, so WIFI and Bluetooth share the RF. Thus, low layer have two method to control the RF sharing: hardware control automatically and software control.

1. Hardware control:
If you disable CONFIG_SW_COEXIST_ENABLE, it will use hardware control. In this mode, Bluetooth has higher priority then WiFi. It will keep the bluetooth performance, but WiFi may be effected depend on bluetooth traffic. It means while WIFI is RX a packet, if bluetooth want to TX or RX a packet, it will stop WiFi. For example, BLE is scanning and WiFi is just in connection to hear beacon. If you set BLE scan interval equal to scan window, it means BLE scan will occupy RF all the time, so WiFi connection may be lost. So to keep WiFi connection, you should set BLE scan window little than scan interval and should not set scan window too large (such scan window=0x10, scan_interval=0x80 seems good), It will give WiFI a lot chances to use RF. Although, there 's still some conflicts may happen that WiFI is TX/RX while bluetooth is TX/RX, but the ratio is decreased. It may cause WiFi TX/RX performance decrease but don't cause WiFi connection lost. In fact, the performance is not too bad. For most IoT applications, it can be adopted.
Most of BLE have enough time gap(except BLE scan parameter or connection interval is too bad), there's a lot chance for WiFI. So BLE and WiFi can be work in hardware control mode.
But for BR/EDR(classic BT), due to the restriction of BR/EDR, BR/EDR has no enough time gap. Each Master-To-Slave frame, there's only a little time (much little than 625us) time gap. So BR/EDR cannot work better with WiFi simultaneously in hardware control mode.

2. Software control:
For resolve the restrictions of hardware control mode, we develop software control mode. This control mode works in low layer to arbit the RF occupy right for WiFI or bluetooth.
It depends on WiFi power-save and Bluetooth retransmission mechanism. So this mode is only for WiFi station mode (AP mode could not support power-save). In this mode, most applications (A2DP/SPP/GATT-based Profiles) need not to care about the coexistence implementation, not afraid WiFi connection lost and other things, just use WiFi and Bluetooth as your expect. Except some special applications, such like BLE mesh(use scan/adv) and WiFi TCP connection, to keep BLE scan performance, it may need to modify the software control parameters to make the coexistence more fit to this application scenario.
In software control mode, there's 3 option to modify the coexist preference（Balance, prefer to WiFi and prefer to Bluetooth). Normally, Balance is a good choice. For example, in balance preference, Bluetooth A2DP can play music fluently while WiFi is running throughput test (In sheildbox, the TCP RX can reach 8Mbps).

Above all:
1. BLE can works under both hardware control mode and software control mode. But in hardware control mode, you should care about the BLE scan parameter is bad or BLE connection interval is too small.
2. BR/EDR can only works in software control mode.

Thanks for useful information regarding that.

It will be good if you provide few more details with examples like where we can use hardware flow control and where we can use software flow control with it's advantage and disadvantages as well.

Dear Retish,
Normally, in most scenarios, I suggest enable CONFIG_SW_COEXIST in menuconfig.
I can provide you a A2DP sink and wifi iperf coexist demo. Prior to this, I need to find somewhere to store the code.

[Ritesh]

I can describe something about the WIFI and BLE/BR/EDR coexistence.
As everyone know, ESP32 only have one RF, so WIFI and Bluetooth share the RF. Thus, low layer have two method to control the RF sharing: hardware control automatically and software control.

1. Hardware control:
If you disable CONFIG_SW_COEXIST_ENABLE, it will use hardware control. In this mode, Bluetooth has higher priority then WiFi. It will keep the bluetooth performance, but WiFi may be effected depend on bluetooth traffic. It means while WIFI is RX a packet, if bluetooth want to TX or RX a packet, it will stop WiFi. For example, BLE is scanning and WiFi is just in connection to hear beacon. If you set BLE scan interval equal to scan window, it means BLE scan will occupy RF all the time, so WiFi connection may be lost. So to keep WiFi connection, you should set BLE scan window little than scan interval and should not set scan window too large (such scan window=0x10, scan_interval=0x80 seems good), It will give WiFI a lot chances to use RF. Although, there 's still some conflicts may happen that WiFI is TX/RX while bluetooth is TX/RX, but the ratio is decreased. It may cause WiFi TX/RX performance decrease but don't cause WiFi connection lost. In fact, the performance is not too bad. For most IoT applications, it can be adopted.
Most of BLE have enough time gap(except BLE scan parameter or connection interval is too bad), there's a lot chance for WiFI. So BLE and WiFi can be work in hardware control mode.
But for BR/EDR(classic BT), due to the restriction of BR/EDR, BR/EDR has no enough time gap. Each Master-To-Slave frame, there's only a little time (much little than 625us) time gap. So BR/EDR cannot work better with WiFi simultaneously in hardware control mode.

2. Software control:
For resolve the restrictions of hardware control mode, we develop software control mode. This control mode works in low layer to arbit the RF occupy right for WiFI or bluetooth.
It depends on WiFi power-save and Bluetooth retransmission mechanism. So this mode is only for WiFi station mode (AP mode could not support power-save). In this mode, most applications (A2DP/SPP/GATT-based Profiles) need not to care about the coexistence implementation, not afraid WiFi connection lost and other things, just use WiFi and Bluetooth as your expect. Except some special applications, such like BLE mesh(use scan/adv) and WiFi TCP connection, to keep BLE scan performance, it may need to modify the software control parameters to make the coexistence more fit to this application scenario.
In software control mode, there's 3 option to modify the coexist preference（Balance, prefer to WiFi and prefer to Bluetooth). Normally, Balance is a good choice. For example, in balance preference, Bluetooth A2DP can play music fluently while WiFi is running throughput test (In sheildbox, the TCP RX can reach 8Mbps).

Above all:
1. BLE can works under both hardware control mode and software control mode. But in hardware control mode, you should care about the BLE scan parameter is bad or BLE connection interval is too small.
2. BR/EDR can only works in software control mode.

Thanks for useful information regarding that.

It will be good if you provide few more details with examples like where we can use hardware flow control and where we can use software flow control with it's advantage and disadvantages as well.

Dear Retish,
Normally, in most scenarios, I suggest enable CONFIG_SW_COEXIST in menuconfig.
I can provide you a A2DP sink and wifi iperf coexist demo. Prior to this, I need to find somewhere to store the code.

Thanks for update regarding that.

I will be waiting for some updates regarding same.

[mpbejo]

Dear Mr Tian Hao,
above all thanks for quick reply,
I try to explain what I mean for "poor performance", I have sketch (Arduino 1.8.6) with a BLE Server, and I have an Android app to connect to the server and send some commands. This works well and fast.
Now I added WiFi connection in the sketch, and BLE Server performance went down, I have to try several time to connect and send commands.
About WiFi at this moments I tried only a ping command from my computer and the answer on average is 250ms.
I did not change anything in my sdkconfig and environment or the menuconfig. I don't know how to do but I will check, I hope to find some documentation about it.
Thank You
Best Regards
Marco

[theresavfields]

It is data transfer issue. So you are facing connectivity problem. You have to use standard bluetooth or similar tool that will in fast data transfer.

[ESP_Tianhao]

Dear Mr Tian Hao,
above all thanks for quick reply,
I try to explain what I mean for "poor performance", I have sketch (Arduino 1.8.6) with a BLE Server, and I have an Android app to connect to the server and send some commands. This works well and fast.
Now I added WiFi connection in the sketch, and BLE Server performance went down, I have to try several time to connect and send commands.
About WiFi at this moments I tried only a ping command from my computer and the answer on average is 250ms.
I did not change anything in my sdkconfig and environment or the menuconfig. I don't know how to do but I will check, I hope to find some documentation about it.
Thank You
Best Regards
Marco

Dear mpbejo,
I tested GATT client and Wifi connection coexist previously, It seems OK. So please check your ESP-IDF version, because we fixed some bugs and improve coex performance in July and August.
If your code use an old ESP-IDF version, please try the latest release/v3.1 branch or latest master branch.

BTW, please provide me your sdkconfig and logs (because I want to see some version information in logs). Thanks.
.