This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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

Parents
  • 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

Reply
  • 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

Children
No Data
Related