🤦 LFMM: Using BLE and WiFi Together

This is technically not a mistake I made but it’s one I would have made and hopefully will save you the trouble as well. I have not had a scenario where this bit me but a big shout-out to Manaam Rehan for pointing it out to me this week. Had he not, it surely would have eventually.

One Radio to Rule Them All

Several of the ESP32 modules have WiFi and BLE support which is amazing. You can communicate with BLE devices and send data to the cloud all in one powerful, compact, device. Most projects I have seen use one or the other, or both sparingly or in different scenarios. For example, you may use BLE for WiFi provisioning but after that don’t use it again. But what if you need to transfer a lot of data over BLE and WiFi at the same time.

The key piece of information to understand is this: the ESP32 only has a single hardware radio and antenna.

That means it can only “speak” one wireless language (WiFi/BLE) at a time. After investigating this more I found there is some confusion in the community about this topic. After all, the ESP32 has two cores. Why can’t one core do WiFi and the other core do BLE? Well, it can and it does if you configure it properly. However, that only means the software layer can do both at the same time. A single radio and single antenna means that, at the physical transport layer, the ESP32 can only modulate/demodulate one wireless protocol at a time over the airwaves.

Can They Co-Exist?

The simple answer is yes! The more nuanced, production answer is…kind of. As long as you understand the limitations and how to work around them you can do both BLE and WiFi at the “same” time. Meaning, they can share the single hardware radio and antenna in such a way that both will work simultaneously. This all boils down to how much you need to use each, how often, and in what configuration.

The IDF provides two mechanisms to support simultaneous WiFi and BLE: Hardware control and software control. This is configured in menuconfig. There is a fantasic breakdown of this in the docs and also some good info, although a little dated, in this forum topic.

Hardware Control Mode

• Bluetooth has higher priority than WiFi
• Fine for BLE, not great for BR/EDR (classic BT)
• Need to set BLE scan window smaller than scan interval. If they are the same, WiFi processing will be starved.
• Supports STA and AP WiFi modes.
• Reduces binary size

Software Control Mode

• Only for when WiFi is in station mode. Does not work in AP mode (may work but considered unstable and unstable == not production ready).
• Significant performance increase with PSRAM
• In most cases you can use BLE and WiFi without special considerations in your application code
• Increases binary size

The coexistence mode is configured in menuconfig by the CONFIG_ESP_COEX_SW_COEXIST_ENABLE option and it defaults to software mode.

Production Takeaways

Here are the key takeaways to apply to your production setup:

• Select the right mode. By default the software mode is recommended but if you need to conserve flash space or use AP mode for WiFi then you’ll need hardware mode. If you are in hardware mode make sure to pay close attention to the Bluetooth settings, specifically scan window and scan interval.
• Assign different cores to each. In menuconfig you can control which core WiFi and BLE run on. For best performance assign them to different cores.
• Test, Test, Test. Regardless of mode you need to test coexistence thoroughly to ensure the configuration meets your application needs.

Have you encountered issues trying to run WiFi and BLE at the same time on the ESP32. Please share your story in the comments below.

Join the community and get the weekly Production ESP32 newsletter. Concise, actionable content right in your inbox.