WIFI/BLE Simultaneously

[redradist]

In esp-idf v4.2beta1 Bluetooth and WiFi works simultaneously, but by some reason discovery services does not work from phone ... it is strange

[bloobird0]

In software control mode, there's 3 option to modify the coexist preference（Balance, prefer to WiFi and prefer to Bluetooth).

Hello @ESP_Tianhao this post was the most usefull I found until now. Thanks for it. Could you please tell me how to choose Balance, prefer WiFi or prefer Bluetooth? In Menuconfig I found where to activate the SW control coexistence but I'm unable to find how to select the SW control option to any of the 3 possibilities you mentionned. I use the current master branch of IDF.

[Wernfried]

I have read a lot here regarding the parallel usage of WiFi and BLE.

Since some got it working I decided to give it also a try.
My application has two tasks, one for WiFi and other stuff and one for BLE. I could get both working together. BLE scans every 5s for advertisenets and detects the ones I'm sending from my phone. WiFi does scan the SSIDs and connects to AP. Next step was to send MQTT messages via WiFI, when some advertisements are detected. This also worked.

But then I decided to add a WebServer to allow some configurations via WiFi. And here startet the problems. When I comment the code for BLE the WebServer works well. As soon I only do BLEDevice::Init(""), the request from a browser to the WebServer hangs. using the browser debugger I see the request is not fully answered. The response is a somehow long one, it has HTML, CSS ans JS all inline, but zipped. I've played a bit and if I shorten the response (only a simple "Hello Page" or even a bit more) it works. Everytime I make the reponse a bit larger, it hangs.

It seems for MQTT the packages sent are short enough to work.

Since I only have the BLEDevice::Init() statement running (the scanning is commented out temporary) I do not see a possibility to init BLE without turning on the radio. I could live with a solution to disable BLE scanning while the WebServer is responding.

Does someone have an idea how to acheave this?

One more, for my WebServer I'm using "ESPAsyncWebServer". Would it be better to use the synchronous WebServer, since in that case I have to call to handle request by my own in the loop?

[redradist]

In last release v4.2 Ble/WiFi coexistence is working, but it depends on order of starting ...

If I first start Ble and then WiFi then only WiFi works, but if first I start WiFi and then Ble - both Ble and WiFI works, it is strange issue

[millim]

I am sharing also my experience with this feature:

I am working on a web radio commercial application. Basically, the device connects to a web radio server (ICY/Shoutcast) and streams the decoded data to a BT speaker/headphones (as A2DP source). I think this is a key feature the ESP32 has to deal with properly as IOT device!!! I am using IDF v. 4.2.2.

It works well for some headphones/speakers, but produces audio fall outs for some other devices frequently. I think it may depend on the memory on the BT receiving device (amount of jitter buffer), and the Wifi communication with the server.

It is not helpful that the coexist algorithm is not documented. This is pure frustration!

With some debugging, I assume that the WIFI/BT switching period is 100ms (identified with coex_schm_curr_phase_idx_get()). It is not synchronized with the A2DP media timer, so I think in case the phases are out of sync, audio fallout happens.

How can the WIFI/BT switching period be changed? Please tell me what to do!

millim

[666hjk]

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 sharing.

[severaldecor]

I found this ESP32 Bluetooth Architecture word hurdle document describing in details the Bluetooth system on Esp32.
They mention limits of using only one interface by HCI. I couldn't find more technical info on WiFi and it is interesting how both stacks are 'switched' to operate. In theory two cores should do the job just fine. What exactly means 'switching between WF and BT' ?
You mean switching context? They use same host controller or something? This could be solved with different stack architecture.

Although the ESP32 has two cores in this instance, the radio is shared by WiFi and BLE. Therefore, that may be the reason why BLE and Bluetooth cannot be used simultaneously but can be used as a switching mechanism.

[Ritesh]

What exactly means 'switching between WF and BT' ?
You mean switching context? They use same host controller or something? This could be solved with different stack architecture.

Again, this is not a software issue. The ESP32 only has one radio and only one antenna. This radio and antenna, if viewed in a somewhat simplified fashion, can be used for one of six things: send a WiFi packet, send a BT packet, listen for a WiFi packet, listen for a BT packet, receive a WiFi packet, receive a BT packet. I think we actually do some magic that allows us to listen for BT and WiFi packets at the same time in some circumstances, but in general, we're limited to doing only one of these things. To get around this, we would need a separate radio and antenna, something which is not in the current ESP32. No software hacks can change this, because it's a hardware limitation, not a software one.

Hello ESP_Sprite,

Nice Explanation from your end.

Yes. Absolutely correct as it is due to Hardware Limitations. We can use either Wi-Fi or Bluetooth at a time or can be switched between if continuous data transmission or receptions is not required.