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.

[Chaoyue Ying]

Hi Kenneth，

I have some additional materials here that I hope will be helpful for your analysis of this issue.

The following is the data obtained from the packet sniffer.

7266.pcapng

From this, I can only infer that my central once attempted to connect and modify the MTU value of the connection.

The address of the central is D9:C6:14:6C:FA:8E.

The address of the peripheral is DE:1E:87:78:61:19

[Kenneth]

Hi,

Both sides are custom boards of nrf52832

Have you done any verification of the hardware?

If not, you can setup the radio test example:
https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.0.2/page/nrf_radio_test_example.html 

Then use the start_channel and start_tx_carrier commands.

You should then for instance see a unmdulated carrier exactly on the frequency of 2400MHz + channel, e.g. 2402MHz if channel = 2.

You then need access to a spectrum analyzer, set it up to sweep around 2.402MHz and check how much off the center frequency the carrier is. If it's within specification it should be maximum +-96kHz off center frequency.

Also, for the low frequency 32.768kHz clock, are you using internal or external, and what it the configured tolerance in ppm for the clock? Possible try with 500ppm if you haven't tried it already.

Kenneth

[Chaoyue Ying]

Hi,

Do you think there is a problem with the customized board's advertising?

I currently don't have a spectrum analyzer at hand. According to the documentation, do I need to use the second method and employ two boards for both transmission and reception?

32.768kHz clock uses an external clock. The ppm currently used is 20ppm. I will try 500ppm.

[Kenneth]

Chaoyue Ying said:

Do you think there is a problem with the customized board's advertising?

If increasing the tolerance of the 32.768kHz doesn't help, then it's likely related to the 32MHz clock, and it can only be measured indirectly by using a spectrum analyzer.

Kenneth