Is it possible to make the connection processes that an nrf52 central follows more like the connection process that a phone follows?


The company that I work for has built a gateway that uses the nrf52832 as a ble central device (nrf5 SDK and the s132 softdevice). Customers frequently ask us to add support for various Bluetooth peripherals. In this process, we have come across two different peripherals that do not connect properly.

When I say that they do not connect properly, I mean that when we send a connection request, the peripherals become unresponsive. The details were slightly different for the two devices. For one, it became unresponsive as soon as we send the connection request and disconnected with the message BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED. For the other, it would send a few responses but would become unresponsive after that and the connection would time out. Both peripherals work as expected when I connect to them with a phone (using either the nrf connect app or the vendor app).

I have attached wireshark sniffer logs to demonstrate the problem. I have one trace that is between the peripheral and our gateway and a second one (for contrast) that is between the peripheral and a phone.


I am almost certain that this is because of an error in the Bluetooth stack running on the peripherals, but when we ask the vendors about the problem, they rightly point out that their hardware works with phone apps. When we should them sniffer logs, they (reasonably) point to the differences in the sniffer logs and tell us that we need to make our connection process look more like the connection process that phones use.

In order to debug these problems and to more clearly explain to the peripheral developers where the problem is we need a way to make our connection process as similar to the process used by the phone apps.

Is there a way to do this?

Specifically, immediately after a connection, the phone apps send a sequence of control opcodes to read the supported features, version information, etc (LL_FEATURE_REQ, LL_VERSION_IND, LL_CONNECTION_UPDATE_REQ). Is there a way to make the s132 softdevice do something similar?

The phone apps also send a "read by group type" request to get a list of the services supported by the peripheral. We already know the services supported by the peripheral, but maybe the peripherals need to process the request before the other discovery requests will work. is there a way to make a central device using the s132 softdevice send a read by group type request?

The phone apps use a different window size and offset in their connection requests. I can change all the other important values in the connection request, but I have not figured out how to change those values. Is there something in the sdk_config file that will allow us to use a different window size and offset? In case it isn't clear what I mean, see the connection packet from the sniffer trace below.

Frame 7: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface wireshark_extcap2076, id 0
Nordic BLE Sniffer
Bluetooth Low Energy Link Layer
Access Address: 0x8e89bed6
Packet Header: 0x22e5 (PDU Type: CONNECT_REQ, ChSel: #2, TxAdd: Random, RxAdd: Random)
.... 0101 = PDU Type: CONNECT_REQ (0x5)
...0 .... = RFU: 0
..1. .... = Channel Selection Algorithm: #2
.1.. .... = Tx Address: Random
1... .... = Rx Address: Random
Length: 34
Initator Address: d5:d6:38:ac:56:b4 (d5:d6:38:ac:56:b4)
Advertising Address: ef:d8:e4:6d:c9:4e (ef:d8:e4:6d:c9:4e)
Link Layer Data
Access Address: 0xb862cb17
CRC Init: 0x3762fa
Window Size: 5 (6.25 msec)
Window Offset: 0 (0 msec)
Interval: 36 (45 msec)
Latency: 0
Timeout: 500 (5000 msec)
Channel Map: ffffffff1f
...0 1111 = Hop: 15
111. .... = Sleep Clock Accuracy: 0 ppm to 20 ppm (7)
CRC: 0x711421

Thanks in advance

  • Hi,

    In this process, we have come across two different peripherals that do not connect properly.

    It could also be a HW issue with these devices, e.g. inaccurate low/high frequency crystal(s).

    As a test, I suggest setting NRF_SDH_CLOCK_LF_ACCURACY in sdk_config.h to 500 ppm, and see if the behavior changes.

  • Hi Sigurd,

    Thanks for the input! That actually fixed the problem for one of the devices!

    I had tried it already on the first device that was giving us trouble. It didn't work for that one, but I had not thought to try it again for the second one.

    Can you help me to understand the consequences of changing the NRF_SDH_CLOCK_LF_ACCURACY? My understanding is that this parameter sets the tolerance on the timing windows that bluetooth uses for communication, so a higher value would mean that the device might be on for a longer period of time during each connection event, correct?

    If, so, it sounds like the main drawbacks of using a higher tolerance value would be 1) higher power consumption, 2) more processor time used by the radio, and 3) longer softdevice interrupts. would that correct?

    thanks again!