BLE connection to iOS device disconnects consistently after 40 seconds

[erik_fw]

We are consistently seeing a BLE disconnection after being connected to an iOS device for 40 seconds. On the iOS side, the log output at the time of disconnection says: "[System]Error disconnect from peripheral <DeviceName> Unknown Error." We are handling the iOS data length updates successfully as well as MTU exchange. We are able to read/write/notify over the connection properly with no failures until we hit the 40-second point, upon which the connection drops immediately.

We have essentially breakpointed each instance of sd_ble_gap_disconnect() in our code, and verified that it is not being called from our code at the time of disconnection. We're not seeing any BLE events immediately before the disconnection that would lead us to believe that a request timeout or transmission failure occurred, and nothing in the iOS logs indicates any related failures either.

When testing this same code against a BLE connection with a PCA dev board thru the OSx NRF Connect app, connection is sustained indefinitely without any issues.

Any ideas as to what might be causing this?

iOS version: 11.3

Device: iPhone 7

SoftDevice: S132 5.1.0

SDK version: 14.2

Connection parameter configuration:

Min connection interval = 15ms

Max connection interval = 650ms

Slave latency = 0

Connection supervisory timeout = 4s

[Martin Lesund]

Hi Erik,

 

Could you try to provide a sniffer log to actually see what is happening over the air?

Could you also provide a snippet of the actual defines for the connection parameters?

Thanks.

 

//Martin L.

[erik_fw]

Having access to a BLE sniffer would be great, but it looks like there's no supported version for OSx as well as no hardware support for nRF52 dev boards (I'm seeing nRF51 but not 52).

Here are our connection parameter definitions:

/**< Minimum acceptable connection interval (0.015 seconds). */
#define MIN_CONN_INTERVAL MSEC_TO_UNITS(15, UNIT_1_25_MS)

/**< Maximum acceptable connection interval (0.65 second). */
#define MAX_CONN_INTERVAL MSEC_TO_UNITS(650, UNIT_1_25_MS)

/**< Slave latency. */
#define SLAVE_LATENCY 0

/**< Connection supervisory timeout (4 seconds). */
#define CONN_SUP_TIMEOUT MSEC_TO_UNITS(4000, UNIT_10_MS)

These parameters are being initialized with a call to sd_ble_gap_ppcp_set() with a pointer to a ble_gap_conn_params_t structure whose respective members are assigned to the constants defined above.

EDIT for additional info: the BLE_GAP_EVT_DISCONNECTED event gives a reason of 0x08 (BLE_HCI_CONNECTION_TIMEOUT)

[Martin Lesund]

Hi Erik,

Please check the "download" tab to see the Sniffer user guide as well as the software. (v2)

(it has support for OSx  and nRF52 DK)

I would like you to take a look at this thread regarding your error message. What is you chosen accuracy in your system?

 

 

[erik_fw]

nrf_ble_packets.pcap

I've attached the ble trace, we can see the connection occurring at t=0, then regular correspondence between peripheral(nRF) and central(iPhone) up until t=39.5, at which point the central does not respond to the final packet from the peripheral. 

I had previously looked through the thread you linked and tried the suggestions. Our xtal clock accuracy is set to 20ppm, but changing this value did not eliminate the issue.

It may be important to note that I've tried this same connection on iPad with iOS 11 and an iPhone on iOS 9 and both of those held a consistent connection without seeing this issue occur. I've also gotten the Heart Rate Service nrf example running on my board with a consistent connection to the iPhone as well, so somehow this issue is only occurring on the iOS11 iPhone7 with our specific program. Currently trying to see where our program and the HRS demo differ, since it does not exhibit this failure.

[Martin Lesund]

Hi Erik,

  I would recommend you to try to use the GATT module, to ensure that the parameter exchanges is handled correctly.

(Since it looks like there are some things in your application that doesn't get handled correctly)

Do you use peer manager?

 

I can investigate further, but then I would need you to send me your code. (we can make this case private if this is sensitive information)

 

//Martin L.