ble_app-uart example - ble_nus_data_send() - BLE_NUS_EVT_TX_RDY - connection interval

[AKV]

I am sending 240-byte data from peripheral to central through notification (without response) by using the ble_nus_data_send() function when the BLE_NUS_EVT_TX_RDY event comes. The issue here is the BLE_NUS_EVT_TX_RDY is triggering 2x times of connection interval.
eg: If we put connection interval 7.5 then the event BLE_NUS_EVT_TX_RDY will trigger every 15 ms only.

parameters being used

nRF5 SDK v17.0.2

NRF_SDH_BLE_GAP_DATA_LENGTH 251

NRF_SDH_BLE_GATT_MAX_MTU_SIZE 247

NRF_SDH_BLE_GAP_EVENT_LENGTH 400

and also am using the conn_evt_len_ext_set() function.

why is that event BLE_NUS_EVT_TX_RDY is triggering 2x time of connection interval?

here I attached the sniffer log

[Hung Bui]

Hi AKV, 

We need to look at how your queue the data for sending. 

From the sniffer trace what I can read is that the notification queue was not full, and it seems that you wait until you receive BLE_NUS_EVT_TX_RDY event before you queue the next one. When you queue data, you would need to queue until the buffer is full (until you receive NRF_ERROR_RESOURCES error code). 
If you only queue one packet per BLE_NUS_EVT_TX_RDY event, what showed in the sniffer trace is expected. The chip send one packet, the packet get ACKed (in the next event) then you queue the next packet. This explain the 2x time of connection interval. 

[AKV]

Thanks for the reply..

yes, I am sending data as you said only queue one packet per BLE_NUS_EVT_TX_RDY event,

1. The data is sending from peripheral to central via notification. The notification does not have any response or acknowledgment from central right? Then why it takes the next event to give BLE_NUS_EVT_TX_RDY?

2. Is the NRF_ERROR_RESOURCES mean that the buffer of the softdevice/stack is full right?

[Hung Bui]

Hi AKV, 

1. Even though the notification packet has no acknowledgement the lower layer of BLE implemented acknowledgment. BLE link layer is a reliable protocol and that meant every packet on the link layer need to be ACKed or it will be retransmitted until the connection is timed out.

2. Correct. And that meant the data is not queued and it need to be queued again when you receive the BLE_NUS_EVT_TX_RDY event (and you maybe able to queue more than one packet per each BLE_NUS_EVT_TX_RDY  event, because there could be several packets sent over one connection event)

[AKV]

Thanks

 Is it possible to fill the stack buffer on the central side until we get the NRF_ERROR_RESOURCES?

how can I know whether the data has sent or not? 

what is the event on the central side similar to BLE_NUS_EVT_TX_RDY?

[AKV]

Hung Bui

[Hung Bui]

Hi AKV,

The equivalent to BLE_NUS_EVT_TX_RDY is BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE. In the example we don't handle this event (like BLE_GATTS_EVT_HVN_TX_COMPLETE event in the peripheral code). 

But when you successfully sent a write command you will receive BLE_GATTC_EVT_WRITE_CMD_TX_COMPLETE event. You may want to add that into ble_nus_c_on_ble_evt() function. 

You will receive NRF_ERROR_RESOURCES when you have the buffer full on the central side. If you use the queue library (as in ble_app_uart_c, you will receive NRF_ERROR_NO_MEM if the queue is full)

[AKV]

Thanks.