Transmitting multiple Notifications in one Connection Interval

[BjoernSchmitz]

Hi, we are developing an Application with one nrf52840 acting as central, that is connected to up to three nrf52840 acting as peripheral. For our Project, latency for transmissions from peripheral to central is essential. Thus, we have set the connection interval for all 3 Peripherals to the minimum of 7,5 ms. For data transfer we use the Nordic UART Service (NUS).

We are currently facing a problem: If we call ble_nus_data_send (which then calls sd_ble_gatts_hvx) on peripheral side, while there is already one notification queued to be sent, it will take 2 connection intervals to transmit both notifications. I would expect both notifications to be sent in one connection interval, as long as the total amount of bytes to be transferred, fit according to NRF_SDH_BLE_GAP_EVENT_LENGTH and  NRF_SDH_BLE_GAP_DATA_LENGTH. Is there a way to achieve that both notifications are sent in one connection interval?

Our Connection Parameters:

NRF_SDH_BLE_GAP_EVENT_LENGTH = 2 (this is needed so that 3 connections fit in one connection interval)

NRF_SDH_BLE_GAP_DATA_LENGTH = 78

NRF_SDH_BLE_GATT_MAX_MTU_SIZE = 140

NRF_BLE_SCAN_MIN_CONNECTION_INTERVAL = 6

We transmit 14 bytes per notification. So I would expect at least two notifications to fit in one connection interval. In addition, when we pass more than 19 bytes to ble_nus_data_send, it takes 2 connection intervals to transmit the notification. I would expect it to be transmitted in one connection interval, as long as the payload size does not exceed NRF_SDH_BLE_GAP_DATA_LENGTH.

Thank you and best regards.

Björn

[Kenneth]

Hi,

Do you have any on-air sniffer log that we can take a look at?

https://www.nordicsemi.com/Software-and-tools/Development-Tools/nRF-Sniffer-for-Bluetooth-LE

https://infocenter.nordicsemi.com/topic/ug_sniffer_ble/UG/sniffer_ble/intro.html

Kenneth

[BjoernSchmitz]

Hi,

thanks for the quick reply. Unfortunaltely we don't have a sniffer yet. But we will get the correct Developement Kit and install the sniffer software as soon as possible. In the meantime, do you have any idea why we can not send more than 19 bytes per connection interval, using NUS? If NRF_SDH_BLE_GAP_EVENT_LENGTH is set to 78, we should be able to sent multiple notifications per connection interval. Is that correct?

Best regards

Björn

[Kenneth]

In general you will need DLE enabled to send notifications larger than 20bytes effectively, else they will be split into several packets on the link layer. If you include gatt_init() in your application this typically will ensure that the DLE is updated (you can check the callback handler if you have enabled it).

I would like to see the sniffer log, because it may be that there are 2 packets sent in the connection interval, however the link layer acknowledge that they are actually received may be on the next connection interval. This will seemingly look like it takes two intervals to wait for the HVX event.

Best regards,
Kenneth

[BjoernSchmitz]

I allready use gatt_init() and i also check the event handler that tells me that the data length is updated to 78, like i specified with NRF_SDH_BLE_GAP_DATA_LENGTH. 

/**@brief GATT module event handler.
 */
static void gatt_evt_handler(nrf_ble_gatt_t * p_gatt, nrf_ble_gatt_evt_t const * p_evt)
{
    switch (p_evt->evt_id)
    {
        case NRF_BLE_GATT_EVT_ATT_MTU_UPDATED:
        {
            NRF_LOG_INFO("GATT ATT MTU on connection 0x%x changed to %d.",
                         p_evt->conn_handle,
                         p_evt->params.att_mtu_effective);
        } break;

        case NRF_BLE_GATT_EVT_DATA_LENGTH_UPDATED:
        {
            NRF_LOG_INFO("Data length for connection 0x%x updated to %d.",
                         p_evt->conn_handle,
                         p_evt->params.data_length);
        } break;

        default:
            break;
    }
}

This outputs me "Data length for connection 0 updated to 78." after the connection is established. Does that mean DLE is enabled?

Kenneth said:

I would like to see the sniffer log, because it may be that there are 2 packets sent in the connection interval, however the link layer acknowledge that they are actually received may be on the next connection interval. This will seemingly look like it takes two intervals to wait for the HVX event.

When I send two notifications at the same time, both notifications are received in 7.5 ms delay at the central. So one notification is answered direclty and the other is answered in the next connection interval? Does the softdevice generate the event on the central only after the answer to the peripheral was sent?

[Kenneth]

It may be noise in the system that cause packet(s) not be received, in BLE each packet contain a sequence number and a next expected sequence number. It is only after receiving the next expected sequence number that a device will know that the previous packet have been successfully received. So typically a receiving device can raise the event immediately, while a transmitting device may need to wait until next connection event before it will know that the packet was successfully received. It is this way by design to ensure that all packets are reliably sent and received.

Kenneth