How to receive BLE_EVT_TX_COMPLETE faster?

chocol8 gravatar image

asked 2017-12-07 10:43:43 +0100

updated 2017-12-08 12:28:36 +0100


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:

        ble_tx_complete = 1;                    

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);

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);
                 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.

edit retag flag offensive close delete report spam


Do you have any real-time trace where you would correlate on-air packets and SoftDevice BLE events? Because you will typically get the event after connection interval is over and if your stack transports more then on PDU in the interval there is now way to have this event in between (but also that's not an issue for you because there is no time to do anything with it anyway, timing during the ongoing connection event is too strict and fast for application processing between packets). But 8 PDUs look suspicious because that should need more then one connection interval even if your stack sends multiple packets (because typical limit is 6 not 8).

endnode ( 2017-12-07 10:48:51 +0100 )editconvert to answer

Which SoftDevice and SDK version are you using?

Petter Myhre ( 2017-12-07 13:31:06 +0100 )editconvert to answer

2 answers

Sort by ยป oldest newest most voted
run_ar gravatar image

answered 2017-12-08 10:37:46 +0100

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.)

edit flag offensive delete publish link more


It is my bad to not making it clear that I want it to send one time and then wait till I know that master have received it. After that while being in the same connection I would like to send more data. Would it be possibile using sd_ble_gatts_hvx? Should I use it as in [this example] ? (https://devzone.nordicsemi.com/questi...) or I should send it using ble_nus_send_string and wait for indication in sd_ble_gatts_hvx? Could make explain more details how should I use sd_ble_gatts_hvx ?

chocol8 ( 2017-12-08 12:28:06 +0100 )editconvert to answer

Have you considered using indications for this instead? I.e. application layer acknowledgement. The drawback is that it is slower than notification.

run_ar ( 2017-12-08 13:37:46 +0100 )editconvert to answer

Btw. any reason why using so old stack? It looks like first 6 PDU/GATT packets are going inside first connection interval while remaining 2 in next. I would expect getting TX_COMPLETE right after first 6 packets but maybe S110 waits further (e.g. because it thinks there is no time for reasonable APP processing or simply bug/limitation of the old stack). Maybe someone can test this and then compare with S130 V2? Anyway it's kind of evident that in this case you cannot expect TX_COMPLETE after each packet but only after first connection interval...

endnode ( 2017-12-08 14:18:30 +0100 )editconvert to answer

@run_ar Thank you for helping me out. yes, I thought of this. But the thing is that later on I am planning to send comands from master device. This way peer must receive and decode them.

@endnode thank you for your contribution and explaining this in detail. No, I do not have any reason for using old stack. I will try s130 on my spare and compare. Right now I understand that I can not receive TX_complete event. I used this because I was not aware of other ways to notify cpu when a data packet was received.

Could you, guys, explain me how to use sd_ble_gatts_hvx to notify cpu that a packet was received, so it proceed further?

chocol8 ( 2017-12-10 17:21:34 +0100 )editconvert to answer

No, I haven't said and I don't think you will never get TX_COMPLETE event. There is actually no other way to know that something happened on GATT layer in outbound direction so you should keep using it (the only other way would be to "shoot into the dark" by simply trying to put more outgoing notifications any time your BLE event handler is triggered by any event or based on some timer). The only thing I said is that you shouldn't expect as many TX_COMPLETE events as many packets you pushed because some of them may go through within one connection interval where there is no time for application processing between PDUs processed by Soft Device. I would simply expect that stack will trigger you as soon as at least one TX slot emptied and there is any time for APP layer processing.


endnode ( 2017-12-10 23:22:53 +0100 )editconvert to answer


Indeed I don't have time to gather any evidence that this is exactly what happens in your special case with S110 V7 or S130 V1/2 but I judge that based on my experience. You have simple options:

  1. Debug the thing on finer time scale to see exactly TX PDUs inside the connection interval and TX_COMPLETE events.
  2. Wait if someone else (e.g. Nordic support team) will invest their time into doing this for you.
endnode ( 2017-12-10 23:25:09 +0100 )editconvert to answer

@chocol8 Later on when you are receiving commands from the master, you will get an event from the softdevice, no need to use tx_complete_event for this. The tx_complete event will just tell you that the tx buffer (s) has been freed...

run_ar ( 2017-12-11 13:17:15 +0100 )editconvert to answer

@run_ar so, in this case I should rather use advertising packets to send information to master?

chocol8 ( 2017-12-11 13:37:14 +0100 )editconvert to answer

No, you should connect. Not sure what you are trying to achive. I would also recommend that you take a look at our tutorials if you have not done so already.

run_ar ( 2017-12-11 15:23:54 +0100 )editconvert to answer

@run_ar to be honest, I am confused at this point... I have check the tutorials. But it is still unclear for me how to send a data packet and receive acknowledgment from master about receid packet. In other words I would like to receive one packet by master.

chocol8 ( 2017-12-12 13:56:57 +0100 )editconvert to answer

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 ...
endnode ( 2017-12-12 14:26:56 +0100 )editconvert to answer

(2/2) 3. Finally if this is still not enough for you then simply build your own "ack" mechanism on APP layer meaning that your application protocol commands will define flow where both sides will let the other side know that previous packet arrived and was processed.

As you see you have plenty of options and each of them is really easy to achieve with nRF5 SDK and Nordic Soft Device API.

endnode ( 2017-12-12 14:29:00 +0100 )editconvert to answer
endnode gravatar image

answered 2017-12-12 19:50:28 +0100

Btw. BLE_GATTS_EVT_HVN_TX_COMPLETE makes ble_gatts_evt_hvn_tx_complete_t structure available which says how many Tx packets went out in last connection interval.

edit flag offensive delete publish link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer. Do not ask a new question or reply to an answer here.

[hide preview]

Question Tools



Asked: 2017-12-07 10:43:43 +0100

Seen: 68 times

Last updated: 14 hours ago