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

[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

[BjoernSchmitz]

Ok but i only transmit data via notifications from the peripheral to the central. Thus the central should generate the event imidiately when the packet is received, correct? Or do you expect the peripheral to wait, until one packet was answered, until it sends the next one?

However, this still does not explain why notifications with more than 19 bytes are seperated into two connection intervals.

[Kenneth]

BjoernSchmitz said:

Ok but i only transmit data via notifications from the peripheral to the central. Thus the central should generate the event imidiately when the packet is received, correct?

I expect it will be raised during post processing of the connection event.  

BjoernSchmitz said:

Or do you expect the peripheral to wait, until one packet was answered, until it sends the next one?

However, this still does not explain why notifications with more than 19 bytes are seperated into two connection intervals.

A sniffer log will show what is happening here.

[BjoernSchmitz]

Ok, I have found the Issue(s). There were two things that prevented me from sending the notifications as expected:

1. The tx notification queue size on the peripheral was set to the default value of 1. To send multiple notifications in one connection interval, i had to increase the queue size.

    // Configure the BLE stack using the default settings.
    // Fetch the start address of the application RAM.
    uint32_t ram_start = 0;
    err_code = nrf_sdh_ble_default_cfg_set(APP_BLE_CONN_CFG_TAG, &ram_start);
    APP_ERROR_CHECK(err_code);

    //sd_ble_cfg_set( , ,&ram_start)
    ble_cfg_t ble_cfg;
    memset(&ble_cfg, 0, sizeof(ble_cfg));

    ble_cfg.conn_cfg.conn_cfg_tag = APP_BLE_CONN_CFG_TAG;
    ble_cfg.conn_cfg.params.gatts_conn_cfg.hvn_tx_queue_size = 2;
    err_code = sd_ble_cfg_set(BLE_CONN_CFG_GATTS, &ble_cfg, ram_start);
    APP_ERROR_CHECK(err_code);
    // Enable BLE stack.
    err_code = nrf_sdh_ble_enable(&ram_start);
    APP_ERROR_CHECK(err_code);

2. The other Problem was the setting of NRF_SDH_BLE_GAP_DATA_LENGTH. I used 78, the maximum that the stack would allow me to use when NRF_SDH_BLE_GAP_EVENT_LENGTH is set to 2. Instead of using the maximum value, used a smaller value of 30.

These two settings in combination allowed me to sent multiple notifications in one connection interval.