Notification buffer size and 2M PHY

[TylerD]

Based on several posts I've found on the forum, the notification queue size is automatically set by the stack based on the connection event length (NRF_SDH_BLE_GAP_EVENT_LENGTH ) and data size (NRF_SDH_BLE_GAP_DATA_LENGTH). The max MTU (NRF_SDH_BLE_GATT_MAX_MTU_SIZE) is probably affecting the queue size, too.

I have experimentally found out that the max number of notifications I can queue is 4. This makes sense, because I have set the GAP event length as 7.5ms and max MTU to 247, meaning that the notification max length is 244 bytes. Transmitting 244 bytes at 1M PHY takes about 1.95 ms and 4 x 1.95 ms = 7.8ms. All good, a transmit queue with depth of 4 notifications seems reasonable.

Now the question is: how is the PHY selection taken into account? My test was done using default 1M PHY, but in the end product I am planning to use 2M PHY for max throughput. With 2M PHY, I should be able to fit about 2x notifications in the same connection event. In that sense, the optimal queue depth would be about 7-8 notifications, right?

Am I missing something here?

Another question: is the notification queue allocated as a fixed number of bytes or fixed number of notifications? For example, in my test I was able to fit 4 maximum length notifications in the queue. If I used shorter packets (say 20 bytes per notif) then should I be able to buffer more than 4 notifications? 

[Vidar Berg]

Hello,

The notification queue size is allocated statically when you initialize the Softdevice, and the size of the allocated buffers are only based on the NRF_SDH_BLE_GATT_MAX_MTU_SIZE setting as far as I know.  But you can specify the number of packets the Softdevice should be able to keep its output notification queue as the code snippet below shows.

/**@brief Function for initializing the BLE stack.
 *
 * @details Initializes the SoftDevice and the BLE event interrupt.
 */
static void ble_stack_init(void)
{
    ret_code_t err_code;

    err_code = nrf_sdh_enable_request();
    APP_ERROR_CHECK(err_code);

    // 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);

    /* Mod: increase hxv queue size */
    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 = 10;
    err_code = sd_ble_cfg_set(BLE_CONN_CFG_GATTS, &ble_cfg, ram_start);
    APP_ERROR_CHECK(err_code);
    
    
    ...

Also, the number of packets you can send per connection interval is not neccessarly limited by the queue size - it's usually the connection event length that does. If the app is not too busy with other tasks it can keep queuing up more packets as they are being transmitted by the stack.

Another question: is the notification queue allocated as a fixed number of bytes or fixed number of notifications?

 It's a fixed number of notifications. It stays the same regardless of the connection parameters for a particular link.

Best regards,

Vidar