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).