BLE data transfer problem

RE: BLE data transfer problem

Kenneth — Wed, 28 Oct 2020 16:32:34 GMT

Sounds you have been able to get much better throughput now by larger notifications and more packets in each interval.

You can call sd_ble_gatts_hvx() until NRF_ERROR_RESOURCES (error 0x13 = 19). Then you can wait for a BLE_GATTS_EVT_HVN_TX_COMPLETE event (0x57) and retry sd_ble_gatts_hvx().

Alternatively, instead of waiting for BLE_GATTS_EVT_HVN_TX_COMPLETE event you can just retry sd_ble_gatts_hvx() from a timer also.

Best regards,
Kenneth

RE: BLE data transfer problem

romulsre — Wed, 28 Oct 2020 14:33:01 GMT

Thank you for response,

As you suggested, I added (found in some example)

void gatt_evt_handler(nrf_ble_gatt_t * p_gatt, nrf_ble_gatt_evt_t const * p_evt)
{
    if((m_conn_handle == p_evt->conn_handle) &&(p_evt->evt_id == NRF_BLE_GATT_EVT_ATT_MTU_UPDATED))
    {
        m_ble_nus_max_data_len = p_evt->params.att_mtu_effective - OPCODE_LENGTH - HANDLE_LENGTH;
        NRF_LOG_INFO("gatt_event: ATT MTU is set to 0x%X(%d)", data_length, data_length);
    }
    else if((m_conn_handle == p_evt->conn_handle) &&(p_evt->evt_id == NRF_BLE_GATT_EVT_DATA_LENGTH_UPDATED))
    {
        m_ble_nus_max_data_len = p_evt->params.att_mtu_effective - OPCODE_LENGTH - HANDLE_LENGTH - 4;
        NRF_LOG_INFO("gatt_event: Data len is set to 0x%X(%d)", data_length, data_length);
    }
    NRF_LOG_DEBUG("ATT MTU exchange completed. central 0x%x peripheral 0x%x",
                  p_gatt->att_mtu_desired_central,
                  p_gatt->att_mtu_desired_periph);
}

I tryed to increase NRF_SDH_BLE_GAP_EVENT_LENGTH parameter but any value (diffent from the 6) give me "fatal error".
When I changed linker configuration, changing softdevice RAM I was able to change this parameter.
So, now I can receive 4 packets (243 bytes each one) and return ble event with code 0x57. After this I have error 0x13(19). Is it mean that I have softdevice buffer full?
Could you please give me example how to implement for waiting on BLE_GATTS_EVT_HVN_TX_COMPLETE ? Provided by ble_app_att_mtu_throughput example is not fully clear...
As I use 2 boards, should the configuration of both devices be the same ?

RE: BLE data transfer problem

Kenneth — Thu, 22 Oct 2020 13:23:58 GMT

I recommend to check out the ble_app_att_mtu_throughput example, which should negotiate and show the max throughput:
https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.2/ble_sdk_app_att_mtu.html

But here is a tip for you:

If possible try to reduce the number of notifications sent between the peers. For instance instead of sending many small data packets, try to send larger packets combining more data into a single notification packet. To allow this you should exchange max supported MTU and DLE size between the two peers by include nrf_ble_gatt_init() in your application:

void nrf_ble_gatt_evt_handler(nrf_ble_gatt_t * p_gatt, nrf_ble_gatt_evt_t const * p_evt)
{
	if(p_evt->evt_id == NRF_BLE_GATT_EVT_DATA_LENGTH_UPDATED)
	{
		// p_evt->params.data_length is the max length on-air
	}	
	if(p_evt->evt_id == NRF_BLE_GATT_EVT_ATT_MTU_UPDATED)
	{
		// p_evt->params.att_mtu_effective is the max MTU size		
	}	
	
	// Once both are updated, then you can for instance start sending notifications that are longer than 20bytes when calling sd_ble_gatts_hvx()/sd_ble_gatts_value_set().
}


/**@brief Function for initializing the GATT module.
 */
static void gatt_init(void)
{
    ret_code_t err_code = nrf_ble_gatt_init(&m_gatt, nrf_ble_gatt_evt_handler);
    APP_ERROR_CHECK(err_code);
}

If you for instance set NRF_SDH_BLE_GATT_MAX_MTU_SIZE and NRF_SDH_BLE_GAP_DATA_LENGTH to 247, and then wait for nrf_ble_gatt_evt_handler() you can find the most efficient data length for your notification data to be 'p_evt->params.data_length-3'.

Make sure that the characterstic can support this data length by setting add_char_params.max_len = 247 when init the characteristic.

After receiving the nrf_ble_gatt_evt_handler() you can now call sd_ble_gatts_hvx() with larger data than 20bytes (which is default), now you can allow packet of up to (p_evt->params.data_length-3) bytes. This will allow you to send less packets, and should overall make it less likely that you experience NRF_ERROR_RESOURCES and also increase throughput. (FYI: The '-3' is due to header in the packet).

Best regards,
Kenneth