how to hold and transmitt(when BLE_ERROR_NO_TX_BUFFERS occurs) the packets while using more no of characreristics to transmitt ?

[balaji]

Hi,

I am using nrf51822 evaluation kit, and the sample program i am working on is ble_app_hrs.

I have created 4 characteristics with notify property and also created 4 buffers each of 20 byte packets when an write event with particular data occurs, i need to transmit all the 4 packets continuously using the 4 characteristics (each one will notify one packet) i have created.

Without putting any delay i can send only 7 packets, i think that is because of the transmission buffer size (7), when i put delay (0xffff) after transmitting 4 packets i can receive the packet continuously until i disable the service. but the packets sent in one connection interval is less than 2, which should be greater than 4 as i studied in ble document. Because of that delay i am not achieving 4 packets in a connection interval. I know how to use the BLE_EVT_TX_COMPLETE when transmitting large no of packets using single characteristics but when using more no of characteristics i dont have any idea on how check the BLE_EVT_TX_COMPLETE and hold the transmission until the buffer is free. please suggest me an idea to overcome this.

Regards, Balaji

[Carles]

Hi there,

The amount of buffers that you get back with:

sd_ble_tx_buffer_count_get()

is shared among all characteristics. That means that if you want to send data simultaneously on multiple characteristics you will have to schedule your traffic among them. Packets are sent and received in order, sequentially. That means that when you receive a BLE_EVT_TX_COMPLETE, the packets that have been transmitted are the first ones that you sent earlier. Say you send 3 notifications:

sd_ble_gatts_hvx( attr_handle1, data ); [packet 1 queued] sd_ble_gatts_hvx( attr_handle2, data ); [packet 2 queued] sd_ble_gatts_hvx( attr_handle3, data ); [packet 3 queued]

And then you get a BLE_EVT_TX_COMPLETE with tx_complete.count = 2. That means that the first 3 packets have been transmitted, and therefore it means that packet 1 and packet 2 have been successfully transmitted. Later on you will get a second BLE_EVT_TX_COMPLETE with tx_complete.count = 1, and that will mean that packet 3 has been successfully sent to the peer.

EDIT: To further clarify, the transmit queue behaves like a FIFO (First In, First Out) and therefore the packets will be transmitted and acknowledged (with BLE_EVT_TX_COMPLETE) in the exact order that you sent them.

Carles

[balaji]

Thank you for the reply, as i posted above i have 4 characteristics each of 20 byte size which will continuously send the data until the packet count reaches 200. Please tell me the exact condition i need to check and where to check before transmitting the each packet, to achieve no packet loss and also the efficient packet transmission in a single connection interval ( >4). Does the condition tx_complete.count = 1 enough to send the next packet to avoid loss? Simple example will help me a lot.

[Ole Morten]

I'd strongly recommend you to just use one characteristic, then queue data until you get the BUFFERS_FULL error, and then again queue data the next time you get the TX_COMPLETE event. By doing this, it should be easy to transmit all the data needed as fast as possible.

[Christopher]

The answer given by Carles is also described in the following sequence diagram: infocenter.nordicsemi.com/index.jsp