BLE_HCI_CONNECTION_TIMEOUT with Linux Central

[federunco]

Hello,

I've flashed to my custom nRF52832 board the ble_app_hrs_pca10040_s132 example, it works fine with iOS and Android hosts but when I try to connect to my development host via bluetooth it disconnects almost instantaneously outputting BLE_HCI_CONNECTION_TIMEOUT. I've read in other threads that the RC low frequency clock could cause this problem, but with other hosts (even a Raspberry PI Zero 2 with linux running) is working fine. How can i address this issue?

SoftDevice version: S132 7.3.0
SoftDevice clock config:

#define NRF_SDH_CLOCK_LF_ACCURACY 1
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
#define NRF_SDH_CLOCK_LF_RC_CTIV 16
#define NRF_SDH_CLOCK_LF_SRC 0

Debug window output:

<debug> nrf_sdh_ble: BLE event: 0x10.
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
<debug> nrf_ble_gatt: Updating data length to 251 on connection 0x0.
<info> peer_manager_handler: Peer data updated in flash: peer_id: 1, data_id: Peer rank, action: Update, no change
<info> app: Connected.
<debug> nrf_sdh_ble: BLE event: 0x11.
<info> app: Fast advertising.
<info> app: Disconnected, reason 8.

bluetoothctl output while pairing:

[bluetooth]# pair FD:81:ED:2A:E3:26 
Attempting to pair with FD:81:ED:2A:E3:26
[CHG] Device FD:81:ED:2A:E3:26 Connected: yes
[DEL] Device 77:CD:7D:D0:7B:85 77-CD-7D-D0-7B-85
Failed to pair: org.bluez.Error.ConnectionAttemptFailed
[CHG] Device FD:81:ED:2A:E3:26 Connected: no
[DEL] Device 4A:81:81:64:3D:7C 4A-81-81-64-3D-7C

[Vidar Berg]

Hello,

Clock drift could be a possible reason for why you are not able to establish the connection, but it's not very common.  I would recommend you start with capturing a sniffer trace of the failed connection attempt (nrf sniffer). That may provide us with some more hints.

Some follow up questions:

1. Is this on a PC, and does it have built-in Bluetooth?

2. What version of Bluez? Older or newer than the one running on the Pi?

3. Is it possible to plug in another BT USB stick on this system to see if the connection problems goes away with another controller?

Best regards,

Vidar

[federunco]

1. Yes, the PC has built-in BLE (Intel 8265 8087:0a2b)

2. Host PC ver: 5.60-0ubuntu2.2, Pi version: 5.55-3.1+rpt1

3. I've tried two different BLE sticks but the board is not even discovered with both external sticks.

I can have the packet capture tomorrow, as I don't have an nRF dongle on hand right now, I've captured with wireshark the bluetooth0 interface, I hope it could be useful

bt1.pcapng

[Vidar Berg]

Hi,

I'm surprised is not working with other BT dongles either. Do you have a 52 DK or similar you can test with to see if it results in the same connection problem?  Also, as a test, you may try with this clock configuration on your board:

NRF_SDH_CLOCK_LF_SRC 2

NRF_SDH_CLOCK_LF_RC_CTIV 0

NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 0

NRF_SDH_CLOCK_LF_ACCURACY 1

This will select the more accurate synthesized clock source, and therefore provide more margin if the issue is indeed related to clock drift.

The HCI dump shows "Connection failed to be established".

[federunco]

I tried using the synth clock it's not working. 

Here's the full capture with nRF sniffer:bt2.pcapng

[Vidar Berg]

You need to select your peripheral device from the Device menu to make the sniffer track the connection (or connection attempt) (Sniffing a connection involving a single Peripheral). The sniffer will only listen on the adv. channels otherwise.

[federunco]

Here you go: bt3.pcapng

[Vidar Berg]

Thanks. The sniffer trace shows that your intel controller is not receiving or acknowledging the packet responses from your board, which is strange. Could you try to disable the MTU request on your peripheral to see if it makes any difference? You can do so by setting NRF_SDH_BLE_GATT_MAX_MTU_SIZE in sdk_config.h to '23'

[federunco]

It was already set to 23, I've tried setting it to another value but it doesn't work either