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

How to receive BLE_EVT_TX_COMPLETE faster?

Greatings!

I am sending a packet with data in it from my custom board with nrf51822 to my android phone using cahnged ble_app_uart. The packet is being sent 8 times before I receive event BLE_EVT_TX_COMPLETE. Is it possibile to reduce time for receiving BLE_EVT_TX_COMPLETE or could you suggest how to wait for this event so I would not be sending 8 packets? This is where I set event flag:

case BLE_EVT_TX_COMPLETE:
        ble_tx_complete = 1;					
	    break;

Is device is connected I am sending a string while I will get an event flag:

if( m_conn_handle != BLE_CONN_HANDLE_INVALID ) // BLE is connected. Do service routine.
	 {					
	  if(ble_tx_complete == 0) 
	    {
	      sprintf((char*)siusti_plnasete0,"H:%.2f T:%.2f",BME280_humidity,BME280_temperature);
	      ble_nus_send_string(&m_nus,siusti_plnasete0,20);
            }
	 }

This is how it looks in nrf_uart app:

image description

I have tried this way but then phone do not receive that packet at all:

 if( m_conn_handle != BLE_CONN_HANDLE_INVALID ) // BLE is connected. Do service routine.
    	 {					
    	
    	      sprintf((char*)siusti_plnasete0,"H:%.2f T:%.2f",BME280_humidity,BME280_temperature);
    	      ble_nus_send_string(&m_nus,siusti_plnasete0,20);
                 while(ble_tx_complete == 0) 
    	       {
                   }
    	 }

Any suggestions?

-----------------------EDIT----------------------------------------------- This is real time trace from wireshark:

image description

I use s110 (7.0.0), I can not find which SDK example I took. Is there a way to find from which sdk it was taken somewhere in a project? But I believe its one of 5,6 or 7.

Parents
  • Not sure I understand the problem here. But why would you use the tx_complete event to determine when to send another packet? I.e. If you only want to send the packet once, you should only call the sd_ble_gatts_hvx one time. The packet is buffered in the SD until it's received by the peer or the connection is disconnected.

    If you want to send one packet per connection event you could use radio notifications to let your application know when to prepare the next packet.

    If you want to send data as fast as possible, just loop through your date until the Softdevice buffers are full (7 or 6 if you sent packets in the previous connection event.)

  • So back to drawing board. In principle you have 3 independent mechanisms inside BLE stack which can serve as acknowledgement that peer device received the packet over radio:

    1. Each LL PDU is acknowledged by sequence number of next incoming PDU from the other side. That's what will cause TX_COMPLETE event callback from Nordic Soft Device. This is reason why so many people love BLE (because it's simple and reliable) and that's why almost nobody really cares about any true "ack" on higher layers = because it's very unlikely and rare that BLE stack on any device would lose the packet before handing it over to higher layers.
    2. Anyway if you don't trust (for whatever reason) ability of stack on the other side to deliver the packets you can use "ack" mechanism on (G)ATT layer by using Indications and Write with Response (instead of Notifications and Write without Response).

    (1/2)

Reply
  • So back to drawing board. In principle you have 3 independent mechanisms inside BLE stack which can serve as acknowledgement that peer device received the packet over radio:

    1. Each LL PDU is acknowledged by sequence number of next incoming PDU from the other side. That's what will cause TX_COMPLETE event callback from Nordic Soft Device. This is reason why so many people love BLE (because it's simple and reliable) and that's why almost nobody really cares about any true "ack" on higher layers = because it's very unlikely and rare that BLE stack on any device would lose the packet before handing it over to higher layers.
    2. Anyway if you don't trust (for whatever reason) ability of stack on the other side to deliver the packets you can use "ack" mechanism on (G)ATT layer by using Indications and Write with Response (instead of Notifications and Write without Response).

    (1/2)

Children
No Data
Related