Adhering to Apple Accessory Design Guidelines for BLE Connection Intervals

[CBrown]

Hello,

I am developing a device using nRF52832. This device transmits data every 100ms, but periodically transmits data every 5ms.

The BLE connection is functioning well with a connection interval of 7.5ms to 7.5ms, but to adhere to the Apple Accessory Design Guidelines I see it needs to meet the requirements:

• Interval Min ≥ 15 ms
• Interval Min is a multiple of 15 ms.
• One of the following:
  • Interval Max at least 15 ms greater than Interval Min.
  • Interval Max and Interval Min are both 15 ms.

If we don't meet these requirements the BLE connection drops after 90 seconds. I have tried to use a connection interval of 15ms to 30ms, but this causes some BLE issues when transmitting data quickly (every 5ms).

I am exploring what's causing the BLE issues, and while I think fixing that is the correct solution, I would like to explore other options to see if I am missing anything easier or more obvious. I have tried to use the correct connection interval (15ms to 30ms), but reduce the connection interval (7.5ms to 7.5ms) during fast transmission. This was OK, but it takes a few seconds to update the connection interval, which is too slow.

Any other ideas? How does Apple intend for it to work?

Thanks in advance,

Campbell

[Vidar Berg]

Hello Campbell,

The peripheral may request a connection interval of 7.5 ms, but it will not be accepted by iOS, although some Android phones might. Is the purpose of using such a short connection interval to reduce latency in receiving data, or is it to increase throughput? Please note that a shorter connection interval does not necessarily translate to more throughput, since you can send multiple packets per connection event when using a longer interval, as illustrated by the numbers here: Bluetooth Low Energy data throughput.

If we don't meet these requirements the BLE connection drops after 90 seconds. I have tried to use a connection interval of 15ms to 30ms, but this causes some BLE issues when transmitting data quickly (every 5ms).

I assume the connection is terminated by the peripheral since the requested connection parameters were rejected. Some of the SDK examples using the Connection Parameters Negotiation module will terminate the connection when the connection parameter failed callback is invoked:

/**@brief Function for handling the Connection Parameters Module.
 *
 * @details This function will be called for all events in the Connection Parameters Module which
 *          are passed to the application.
 *          @note All this function does is to disconnect. This could have been done by simply
 *                setting the disconnect_on_fail config parameter, but instead we use the event
 *                handler mechanism to demonstrate its use.
 *
 * @param[in] p_evt  Event received from the Connection Parameters Module.
 */
static void on_conn_params_evt(ble_conn_params_evt_t * p_evt)
{
    ret_code_t err_code;

    if (p_evt->evt_type == BLE_CONN_PARAMS_EVT_FAILED)
    {
        err_code = sd_ble_gap_disconnect(m_conn_handle, BLE_HCI_CONN_INTERVAL_UNACCEPTABLE);
        APP_ERROR_CHECK(err_code);
    }
}

If you have implemented the same callback in your application, do you experience the connection drop if you comment the sd_ble_gap_disconnect() line? 

Best regards,

Vidar

[CBrown]

Our resolution was to adhere to the Apple BLE connection interval requirements (min of 15ms, max of 30ms) and optimize throughput by refactoring how we transmit packets, instead of tuning BLE settings.

[Tai]

Hi CBrown. Could you please share more details about your approach to refactor how packets are transmitted? I'm currently encountering the same issue as setting BLE connection parameters as the Apple design guidelines, data drops would occur. 

Thanks,

Tai

[CBrown]

Hi Tai,

I updated the connection interval to 15ms - 30ms, which causes data drops, and the solution was to reduce the frequency that data was put into the BLE UART TX FIFO (reducing the sampling rate of our sensor) and increasing the capacity of the FIFO. This was suitable for us so we didn't look at adjusting any other BLE settings.