ESP32 Forum

Hi guys,

I'm working on a project that uses both Wifi (specifically the http_client component) as well as BLE. They both seem to work great separately.

However, once Wifi establishes a connection and starts working (a small http request every second or so), the BLE feels starved. It takes a very long time to get connected, reads take in the order of seconds, and I often get disconnected.

Any idea what could cause this behavior?

Thanks,
-Nick

Sorry to bump, but either I must be doing something wrong, or there's an issue with the stack.

Is there an example that does WIFI and BLE at the same time? Is it expected to work fine?

BLE + WIFI works fine but its not easy to optimize app to make it work without issues. You have to remember its shared radio and you have to give some time to wifi and ble to operate. My suggestion is to start with very simple app with 2 tasks, 1 for wifi and 1 for ble. In each task setup long delay, then make it shorter and shorter and see how it works for you.

I have one arduino app with wifi + ble, but its commercial app and cant share it.

I don't understand what seems to be the problem with both being used at the same time.
First of all I came across some people complaining about esp and surprisingly discover they use Arduino only for very sophisticated apps normally written in AVR environment. I myself encountered problems with different versions of Arduino so simply stopped using it for more advanced projects. In fact to fully succeed in programming microcontrollers for commercial market you should use machine Assembler only )
For two different network peripherals is best to use different execution contexts (cores?) and separate their memory buffer spaces from conflicts.
Not to mention optimize performance for all kinds of connectivity scenarios

The problem is that they share a radio; in other words, while the ESP32 is sending/receiving a BT packet, it cannot listen or send a WiFi packet. It's like trying to keep up with talkshows on an old FM radio: you're switching back and forth a lot, and you can usually keep up with both because of some redundancy in the sentences used, but if they talk too fast you're going to loose track.

(Also, 'fully succeed in programming microcontrollers for commercial market you should use machine Assembler only' - can you qualify why you think this is the case? I've seen a gazillion of fully succeeded commercial products written in C/C++, and some use eve higher embedded languages like Python and Lua.)

ESP_Sprite wrote:The problem is that they share a radio; in other words, while the ESP32 is sending/receiving a BT packet, it cannot listen or send a WiFi packet. It's like trying to keep up with talkshows on an old FM radio: you're switching back and forth a lot, and you can usually keep up with both because of some redundancy in the sentences used, but if they talk too fast you're going to loose track.

Isn't it how routers work with multiple client packets? They never 'loose track' if clients 'talk to fast'.
There should be very advanced and efficient packet queuing for both protocols and also fast filtering and data distribution as well.
I could suspect this might be done maybe on lover machine code level or very highly optimized with good design.
But considering price of the esp32 chip - having two systems separately for BT and for WF makes better sense in such case.

Sure! The difference is that these routers all work on one channel. Let me strain the analogy a bit: It effectively is as is multiple guests on the talk show are talking at the same time, but still on one radio program: because everyone interacts on the same channel and cooperates to wait for eachother, it all works nicely. Bluetooth and WiFi, however, are two entire separate broadcasting stations that do not work together to coordinate who says what on which time, so you're stuck switching back and forth between them, missing bits and pieces here and there if everything goes too fast. It's not a problem that is solvable by any means of programming - in machine language or in any other language - it's just intrinsic to the problem.

I found this ESP32 Bluetooth Architecture 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.

Deouss wrote:I found this ESP32 Bluetooth Architecture 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.

Here 2 Cores are there into ESP32 but Radio is common for WiFi and BLE. so that might be the reason to not able to operate BLE and Bluetooth together at a time but can be used in switching mechanism.

We are also in queue to use WiFi and BLE or WiFi and Ethernet or WiFi and GSM or Ethernet and GSM like way combinations for some of our products.

Deouss wrote: 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.