espressif / esp-idf

Espressif IoT Development Framework. Official development framework for Espressif SoCs.
Apache License 2.0
13.51k stars 7.26k forks source link

BLE Disconnections (IDFGH-1627) #3877

Closed elad30300 closed 5 years ago

elad30300 commented 5 years ago

Hi, I use esp32-wroom-32 chip with esp-idf v3.0 . My system has a: 1) board containing the esp32 microcontorller 2) android app with galaxy a7 3) sensor

The components talk in the following way: 1) the board sends info to the app using ble (board: gatt server, app: gatt client) 2) the sensor sends info to the board using ble (board: gatt client, sensor: gatt server) (as mentioned in 1 - the board sends this info also to the app)

I have a lot of ble disconnections in outside area (I almost don't have disconnections in a room). Usually I get connection reasons 0x28 (HCI_INSTANT_PASSED) and 0x1F (UNSPECIFIED_ERROR), I also get 0x08 code but I believe from the docs and experiments it is caused due to distance between the board and the smatphone.

Here are some links contain some info about code 0x28: https://devzone.nordicsemi.com/f/nordic-q-a/29002/disconnection-code-0x28/114693#114693 https://stackoverflow.com/questions/48447645/android-ble-peripheral-disconnects-with-status-code-ble-hci-instant-passed0x28

I would like to know if there is anyone who came across these disconnection codes and maybe know why it might happen, and maybe if I upgrade the esp-idf version may solve this issue.

Thanks a lot.

gengyuchao commented 5 years ago

The Instant Passed error code indicates that an LMP PDU or LL PDU that includes an instant cannot be performed because the instant when this would have occurred has passed. So, for example when the master sends this PDU (LMP PDU or LL PDU), it will sends an instant value as a part of this PDU. The Instant field of this PDU shall be used to indicate the connection Event Count when the updated parameters shall be applied; this is known as the instant. The master should allow a minimum of 6 connection events that the slave will be listening for before the instant occurs.

Now try resolve this issue --

Because you use the board sends info to the app using ble (board: gatt server, app: gatt client), the board might be a salve device. Its connection parameters (as slaves) will be set by the app. The outdoor wireless environment is worse than the indoor environment, app may retry many times to update the connection parameters. If you changing the connection parameters after the BLE connection has established, this problem may be appeare, check what the Slave latency number you have used. Try with a lesser number for slave latency (eg. 0).

Hope it can help you.

elad30300 commented 5 years ago

Actually I don't change the connection parameters after connect event, but the android app use some modes and the final connection parameters I see are: min_int = 0, max_int = 0,conn_int = 36,latency = 0, timeout = 2000

Any idea if it is related to the disconnections?

gengyuchao commented 5 years ago

Maybe you will see the connection parameters change many times, although you did not change it by youself. GATTC will automatically initiate a discovery service after connection. Some device services will cause a longer discovery service. To save time, GATTC will update the connection parameters to 7.5 ms before the discovery service. The discovery service will restore the previous connection parameters when it is completed.

So, if you find HCI_INSTANT_PASSED in esp32, Because esp32 is slave device, and it received an connection parameters which would have occurred passed.

As the answer in Stack Overflow says

At the Link Layer, BLE is reliable. This means each Link Layer packet must be ack'd by the other side. In a noisy RF environment, it's possible a link layer packet may require a couple retries to actually send. This means the packet could arrive many "connection events" after originally intended.

elad30300 commented 5 years ago

The disconnections occur mostly with the app and many times even without be connected to sensors, which means the GATTC discovery service doesn't occur.

elad30300 commented 5 years ago

I also think I didn't explain my problems until the end: 1) the esp as a server can be connected to 3 clients (android apps) 2) there is only one profile for GATTC 3) the android app can connect to multiple esp boards 4) sometimes the system has a "central" smartphone connected to multiple esp GATT Servers, and at the same time those esp boards can also be connected to other phones and to sensors

The disconnections mostly occur with the "central" smartphone, but it also occurs when the esp boards are connected to other devices. So the make it more clear, the disconnection mosltly occur: 1) outside 2) esp to phone relations are many-to-many 3) most disconnections occur in the "central" phone which is connected to multiple GATT Servers

gengyuchao commented 5 years ago

When you are outdoors, the possibility of sharing the same RF channel is greatly increased, and it is easy to cause data communication to be unobstructed for a period of time. This problem is exacerbated when multiple devices are connected. You can try to increase the connection interval.

elad30300 commented 5 years ago

Hi, I tried it, from my experiments the system is more stable than before, there are still some disconnection so I'll keep trying another connection intervals until I'll find it satisfying, but I wonder why it is the solution for the disconnections? Why it helps?

elad30300 commented 5 years ago

I also get recently (after some changes) code 0x3d, does anyone know why it might happen?

gengyuchao commented 5 years ago

Oh, I am sorry for the late reply. I want to know the distance you want to use the device. Because your problem is related to the quality of the connection signal. And BLE is used for short distances. If you want to use it over a long distance it is very difficult. For the last problem, increasing the interval can reduce the conflict of device communication, so it can help keep the connection stable.

elad30300 commented 5 years ago

Alright, got it, there are still improvements to make but the system is much more stable, thank you very much!

Alvin1Zhang commented 5 years ago

@elad30300 Thanks for the updates, feel free to reopen if the issue still exists. Thanks.