Strange Connection Issue with iOS and Android

[PatrickHennig]

We are trying to connect to discovered smartphones with a Nordic 52840 chip, with S140 softdevice, discover the gatt table, read and write attributes. Most of the time it works great.
It is a custom chip, but we have the same issue with the LAIRD 654 Devboard and different antennas.

But sometimes we do fail with 0x3E for 20 times or up to 60 times, even if the phone is in close proximity. After 20 to 60times everything is fine and we can discover the GATT table, read and write successfully.
We have played around with the Connection parameters and the MTU sizes and looked into different ways.

Our connection parameter and MTU settings are as follows:

#define NRF_SDH_BLE_GATT_MAX_MTU_SIZE 184
#define NRF_SDH_BLE_GAP_DATA_LENGTH 181

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(15, UNIT_1_25_MS)   
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(45, UNIT_1_25_MS)   
#define SLAVE_LATENCY                   0                                 
#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(2000, UNIT_10_MS)   

Sometime (very often) we get in the following situation. We do get a successful connection handle and at the same time we receive a disconnect with 0x3E. In a lucky case this goes for 2-3 times until we get a succesful connection for data retrieval. But sometimes we see this for up to 60 times when we want to connect to a smartphone.

<info> app: CENTRAL: Disconnected, handle: 0, reason: 0x3E
<info> app: GRPC call to ConnectTo
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 184 bytes on connection 0x0.
<debug> nrf_ble_gatt: Updating data length to 181 on connection 0x0.
<info> app: CENTRAL: Connected, handle: 0.
<info> app: CENTRAL: Disconnected, handle: 0, reason: 0x3E
<info> app: GRPC call to ConnectTo
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 184 bytes on connection 0x0.
<debug> nrf_ble_gatt: Updating data length to 181 on connection 0x0.
<info> app: CENTRAL: Connected, handle: 0.
<info> app: CENTRAL: Disconnected, handle: 0, reason: 0x3E
<info> app: GRPC call to ConnectTo
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 184 bytes on connection 0x0.
<debug> nrf_ble_gatt: Updating data length to 181 on connection 0x0.
<info> app: CENTRAL: Connected, handle: 0.
<info> app: CENTRAL: Disconnected, handle: 0, reason: 0x3E
<info> app: GRPC call to ConnectTo
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 184 bytes on connection 0x0.
<debug> nrf_ble_gatt: Updating data length to 181 on connection 0x0.
<info> app: CENTRAL: Connected, handle: 0.
<info> app: CENTRAL: Disconnected, handle: 0, reason: 0x3E
<info> app: GRPC call to ConnectTo
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 184 bytes on connection 0x0.
<debug> nrf_ble_gatt: Updating data length to 181 on connection 0x0.
<info> app: CENTRAL: Connected, handle: 0.
<debug> nrf_ble_gatt: ATT MTU updated to 184 bytes on connection 0x0 (response).
<debug> nrf_ble_gatt: Data length updated to 181 on connection 0x0.
<debug> nrf_ble_gatt: max_rx_octets: 181
<debug> nrf_ble_gatt: max_tx_octets: 181
<debug> nrf_ble_gatt: max_rx_time: 2120
<debug> nrf_ble_gatt: max_tx_time: 2120

Any ideas what we should change?

Best Regards, 

Patrick

[Kenneth]

Seems to be consistent for quite some time, this leads me to believe that the peripheral may be advertising with whitelist enabled, and that the specific phone is not in the whitelist. Typically after a while the peripheral will disable whitelist by default. As a quick test to confirm you may try to call ble_advertising_restart_without_whitelist() instead of ble_advertising_start() on the peripheral.

[PatrickHennig]

Thanks, but the nrf chip is in the central role and we want to connect to the phones from the nrf chip. The android and iphones are in peripheral role and on the phone we don't have the option to disable a whitelist, right?

[Kenneth]

Not that familiar with how to setup a phone in peripheral mode and if there are any "gotchas", but if you have an on-air sniffer log maybe we can take a look at the advertisement and connection request packet for anything in specific:
https://www.nordicsemi.com/Software-and-tools/Development-Tools/nRF-Sniffer-for-Bluetooth-LE

[PatrickHennig]

We did a capture of the sequence. But we were not able to capture all connection attempts. 
Please find the capture here: https://shared-link.bdrive.cloud/shared/9b9930cd-d627-4c8d-aa86-5a759475bbd3#ca16bd6661b5ea70ad29ea41093927a44f89dd7fa7b0ca0fc37cf68cfe01983c

ADV_IND
CONNECT_REQ
Sent Exchange MTU Request, Client Rx MTU: 184
Sent Exchange MTU Request, Client Rx MTU: 184
Sent Exchange MTU Request, Client Rx MTU: 184
Sent Exchange MTU Request, Client Rx MTU: 184
Sent Exchange MTU Request, Client Rx MTU: 184
Sent Exchange MTU Request, Client Rx MTU: 184
ADV_IND
ADV_IND
ADV_IND
ADV_IND
ADV_IND
SCAN_REQ
SCAN_RSP
ADV_IND
SCAN_REQ
ADV_IND
ADV_IND
ADV_IND
ADV_IND
SCAN_REQ
ADV_IND
CONNECT_REQ
Sent Exchange MTU Request, Client Rx MTU: 184
Sent Exchange MTU Request, Client Rx MTU: 184
Empty PDU
Control Opcode: LL_LENGTH_REQ
Empty PDU
Empty PDU
Control Opcode: LL_LENGTH_RSP
Empty PDU
Rcvd Exchange MTU Response, Server Rx MTU: 184
Sent Find By Type Value Request, GATT Primary Service Declaration, Handles: 0x0001..0xffff
Control Opcode: LL_VERSION_IND
Control Opcode: LL_VERSION_IND
Rcvd Find By Type Value Response
Sent Read By Type Request, GATT Characteristic Declaration, Handles: 0x0039..0x0050
Control Opcode: LL_SLAVE_FEATURE_REQ
Control Opcode: LL_UNKNOWN_RSP
Rcvd Read By Type Response, Attribute List Length: 8, Unknown, Unknown, Unknown, Unknown, Unknown, Unknown, Unknown, Unknown
Sent Read By Type Request, GATT Characteristic Declaration, Handles: 0x0050..0x0050
Rcvd Read By Type Request, GATT Characteristic Declaration, Handles: 0x000a..0xffff
Sent Error Response - Attribute Not Found, Handle: 0x000a (Unknown)
Rcvd Error Response - Attribute Not Found, Handle: 0x0050 (Unknown)
Sent Find Information Request, Handles: 0x003c..0x003c
Empty PDU
Empty PDU
Rcvd Find Information Response, Handle: 0x003c (Unknown: Unknown: Characteristic Extended Properties)
Sent Find Information Request, Handles: 0x003f..0x003f
Empty PDU
Empty PDU
Rcvd Find Information Response, Handle: 0x003f (Unknown: Unknown: Client Characteristic Configuration)
Sent Find Information Request, Handles: 0x0042..0x0042
Empty PDU
Empty PDU
Rcvd Find Information Response, Handle: 0x0042 (Unknown: Unknown: Client Characteristic Configuration)
Sent Find Information Request, Handles: 0x0045..0x0045
Empty PDU
Empty PDU
Rcvd Find Information Response, Handle: 0x0045 (Unknown: Unknown: Characteristic Extended Properties)
Sent Find Information Request, Handles: 0x0048..0x0048
Empty PDU
Empty PDU
Rcvd Find Information Response, Handle: 0x0048 (Unknown: Unknown: Client Characteristic Configuration)
Sent Find Information Request, Handles: 0x004d..0x004d
Empty PDU
Empty PDU
Rcvd Find Information Response, Handle: 0x004d (Unknown: Unknown: Characteristic Extended Properties)
Sent Find Information Request, Handles: 0x0050..0x0050
Empty PDU
Empty PDU
Rcvd Find Information Response, Handle: 0x0050 (Unknown: Unknown: Characteristic Extended Properties)
Sent Find By Type Value Request, GATT Primary Service Declaration, Handles: 0x0001..0xffff
Empty PDU
Empty PDU
Rcvd Error Response - Attribute Not Found, Handle: 0x0001 (Unknown)
Empty PDU
Empty PDU
Sent Write Request, Handle: 0x003b (Unknown: Unknown)
Empty PDU
Empty PDU
Rcvd Write Response, Handle: 0x003b (Unknown: Unknown)
Sent Write Request, Handle: 0x0048 (Unknown: Unknown: Client Characteristic Configuration)
Empty PDU
Empty PDU
Rcvd Write Response, Handle: 0x0048 (Unknown: Unknown: Client Characteristic Configuration)
Sent Read Request, Handle: 0x004a (Unknown: Unknown)
Empty PDU
Empty PDU
Rcvd Read Response, Handle: 0x004a (Unknown: Unknown)
Sent Write Request, Handle: 0x004c (Unknown: Unknown)
Empty PDU
Control Opcode: LL_TERMINATE_IND
Rcvd Write Response, Handle: 0x004c (Unknown: Unknown)

We are using a u-blox module right now. Can it be due to a miss-configured clock setting?
In the u-blox description we found that the crystal has a tolerance of 500ppm. Nevertheless in our config we used 20ppm from one of the dev boards. 

From our feeling it looks much better now. Is this a suitable reason? And do you think it will be much better if we use a more accurate crystal for the radio?

[Kenneth]

PatrickHennig said:

In the u-blox description we found that the crystal has a tolerance of 500ppm. Nevertheless in our config we used 20ppm from one of the dev boards. 

That will for sure have an impact on the stability of the link yes, the tolerance is sent in the connection request packet and used by the peer to calculate connection periods. If the configured tolerance exceed the actual tolerance this will have an impact. 

Does your testing show that using 500pm solves the issue? 

It is possible to add an external 32kHz crystal to the nRF52-series, this will typically reduce current consumption overall (you can trade-off current consumption vs. cost).

[PatrickHennig]

Unfortunately, the correct clock settings did not help a lot. For the environment we are looking at there seems to be a lot of noise.

If we checked it with the nRF Sniffer, we haven't even seen all of the Connect Requests, we only see the successful ones. The others directly fail in nrf with 0xe3. Could the noise be the reason that the chip is not able to sent out the connect requests?

We now use it together with a skywalk amplifier. This seems to help a lot as almost all connection attempts are successful and we can see them in the sniffer.

[Kenneth]

Any 2.4GHz interference (wifi, bt or other) at the time the connection request packet is sent can prevent the packet to be received correctly, this can cause the same symptoms yes (fail with 0xe3). However I would expect this noise to also affect the link when successfully established, in other words I would expect some packet loss and re-transmissions on the link layer. I can't really from the trace you sent see that happens. Have you tried to enable flight mode on the phone and only enable bt to see if that have an effect?

[PatrickHennig]

Yes, we have tried that already. Strange is that the connection immediately fails with 0x3E. If we put the sniffer antenna directly next to the ble module we even cannot see the connect request in the sniffer. We only see the successful one and maybe one failing before. But not the 20 requests that directly fail with 0x3e.

It looks like if the module is not able to sent the connection request. Can that be the case?