Transmitting multiple Notifications in one Connection Interval

RE: Transmitting multiple Notifications in one Connection Interval

BjoernSchmitz — Wed, 09 Dec 2020 09:02:23 GMT

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.

RE: Transmitting multiple Notifications in one Connection Interval

Kenneth — Mon, 07 Dec 2020 18:18:16 GMT

[quote user="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?[/quote]

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

[quote user="BjoernSchmitz"]

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.

[/quote]

A sniffer log will show what is happening here.

RE: Transmitting multiple Notifications in one Connection Interval

BjoernSchmitz — Mon, 07 Dec 2020 17:53:53 GMT

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.

RE: Transmitting multiple Notifications in one Connection Interval

Kenneth — Mon, 07 Dec 2020 16:08:28 GMT

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

RE: Transmitting multiple Notifications in one Connection Interval

BjoernSchmitz — Mon, 07 Dec 2020 15:50:37 GMT

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?

[quote userid="2111" url="~/f/nordic-q-a/69173/transmitting-multiple-notifications-in-one-connection-interval/283623#283623"]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.[/quote]

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?

RE: Transmitting multiple Notifications in one Connection Interval

Kenneth — Mon, 07 Dec 2020 15:34:57 GMT

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

RE: Transmitting multiple Notifications in one Connection Interval

BjoernSchmitz — Mon, 07 Dec 2020 15:24:00 GMT

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

RE: Transmitting multiple Notifications in one Connection Interval

Kenneth — Mon, 07 Dec 2020 15:06:37 GMT

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