When the central device connects to the peripheral device, the connection is lost. The reason is BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED.

[Chaoyue Ying]

I attempted to connect the central device to the peripheral device.

Both sides are custom boards of nrf52832 and both are based on nrfSDK v17.

The log output on central is as follows：

00> <debug> ble_scan: Scanning
00> 
00> <debug> ble_scan: Connecting
00> 
00> <debug> ble_scan: Connection status: 0
00> 
00> <debug> ble_scan: Conn params:min:6,max:24,sl:0,cst:400
00> 
00> <info> app: Scan FILTER MATCH.
00> 
00> <info> app: name:
00> 
00>  41 6E 6E 79 5F 45 54 43|Anny_ETC
00> 
00>  5F 31 39 36 31         |_1961   
00> 
00> <debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
00> 
00> <debug> nrf_ble_gatt: Updating data length to 251 on connection 0x0.
00> 
00> <info> app: Connected.
00> 
00> <info> app: 19:61:78:87:1E:DE
00> 
00> <info> app: Connection 0x0 has been disconnected. Reason: 0x3E

Peripheral uses UART to output logs.When the central unit outputs the above log, the peripheral does not make any output.

I looked for the information related to "BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED" in the devzone.

It seems to be because  the peripheral does not respond to the first 6 connection events.

What can I do to make it easier and even faster for them to connect?

[Kenneth]

Hello,

If you experience repeated BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED disconnect reasons, it may be that the peripheral device have whitelist enabled while advertising, whitelist on the peripheral device only allow previously bonded central devices to connect with the peripheral. You may need to enable pairing on the peripheral device to allow a new central device to connect and bond in this case.

What may cause intermittent BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED disconnect reason:

In a realistic end-user environment there are a lot of 2.4GHz traffic, it can be traffic from other Bluetooth devices communicating, it can be Bluetooth devices that are trying to scan or connect to the same peripheral device, it can be Wifi devices that typically have higher output power and use much higher bandwidth, other proprietary 2.4GHz equipment (even microwave ovens or USB3.0 noise). All this 2.4GHz traffic will interfere, and sometimes this interference will cause packets to not be received by the peer device. This is very normal in a wireless application. It's very difficult to estimate the amount of packet that can be lost, since it depends so much on the environment, but typically you will expect about 1-5% of the packets to be lost. This will mean that about 1-5% of the times you try to establish a connection you will experience a BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED on the central. How should you handle this? My suggestion is simply to try to connect again.

Kenneth

[Chaoyue Ying]

Hi,

I'm certain that my peripheral has not enabled the whitelist, and it allows new central devices to connect and be bound.

Perhaps it was because the peripheral was being connected during the test (my peripheral allows multiple central devices to be connected simultaneously).

However, during my testing process, the central device developed with nrf52832 failed to connect successfully once. This seems to be inconsistent with the 1-5% data packet loss you mentioned.

Another point is regarding reconnection. On my central device, I am using a filter and automatic connection initiation. If I want the central to handle this connection process automatically, what actions should I take within which callback?

[Kenneth]

Chaoyue Ying said:

However, during my testing process, the central device developed with nrf52832 failed to connect successfully once. This seems to be inconsistent with the 1-5% data packet loss you mentioned.

So what rate do you see?

Kenneth

[Chaoyue Ying]

Almost every time, it returns BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED.Just a few successful connections.

I now suspect that it might be related to the parameters of the scanner and broadcasting, but I'm not very sure.