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?

[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?

[Kenneth]

It is not weird that the connection fails with 0x3E if the connection request is not received by the peer, that is the way BLE have specified handling of that case. It is however weird that the connection request packet is consistently not received for a long period of time.

Is it possible that the module is also handling other non-BLE operations at the time that it is scanning and trying to connect? For instance is is possible that the module is running any serial interfaces, blinking LEDs (PWM) and/or any other activity here? Depending on the layout such activity may interfere with the radio.

[PatrickHennig]

I agree if it is not received correctly, but even at the sniffer I can only see 1-2 out of 20 failing connection requests attempts and the successfull one. 

We used it together with an skywalk amplifier now, this seems to work very good.

[Kenneth]

I think I would recommend to run some DTM tests to check if everything is as it is suppose, also if possible share schematic and layout (in a private case) so we may review if you haven't already done so.

Best regards,
Kenneth