How to receive BLE_EVT_TX_COMPLETE faster?

RE: How to receive BLE_EVT_TX_COMPLETE faster?

Chocol8 — Wed, 20 Dec 2017 14:00:48 GMT

@endnode used indication and waiting for case BLE_GATTS_EVT_HVC: event. After rereading I luckily made it. Thank you for your help.

RE: How to receive BLE_EVT_TX_COMPLETE faster?

Chocol8 — Wed, 20 Dec 2017 13:57:29 GMT

@run_ar @endnode I just solved the problem. By using indications instead of notifications. Thank you, guys, for suggesting all the possibilities. I was not able to understand how indications can be implemented. Fortunately after long rereading I figured what you meant all that time.

RE: How to receive BLE_EVT_TX_COMPLETE faster?

endnode — Tue, 12 Dec 2017 18:50:28 GMT

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.

RE: How to receive BLE_EVT_TX_COMPLETE faster?

endnode — Tue, 12 Dec 2017 13:29:00 GMT

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

RE: How to receive BLE_EVT_TX_COMPLETE faster?

endnode — Tue, 12 Dec 2017 13:26:56 GMT

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:

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

RE: How to receive BLE_EVT_TX_COMPLETE faster?

Chocol8 — Tue, 12 Dec 2017 12:56:57 GMT

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

RE: How to receive BLE_EVT_TX_COMPLETE faster?

run_ar — Mon, 11 Dec 2017 14:23:54 GMT

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.

RE: How to receive BLE_EVT_TX_COMPLETE faster?

Chocol8 — Mon, 11 Dec 2017 12:37:14 GMT

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

RE: How to receive BLE_EVT_TX_COMPLETE faster?

run_ar — Mon, 11 Dec 2017 12:17:15 GMT

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

RE: How to receive BLE_EVT_TX_COMPLETE faster?

endnode — Sun, 10 Dec 2017 22:25:09 GMT

(2/2)

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:

Debug the thing on finer time scale to see exactly TX PDUs inside the connection interval and TX_COMPLETE events.
Wait if someone else (e.g. Nordic support team) will invest their time into doing this for you.

RE: How to receive BLE_EVT_TX_COMPLETE faster?

endnode — Sun, 10 Dec 2017 22:22:53 GMT

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.

(1/2)

RE: How to receive BLE_EVT_TX_COMPLETE faster?

Chocol8 — Sun, 10 Dec 2017 16:21:34 GMT

@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?

RE: How to receive BLE_EVT_TX_COMPLETE faster?

endnode — Fri, 08 Dec 2017 13:18:30 GMT

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

RE: How to receive BLE_EVT_TX_COMPLETE faster?

run_ar — Fri, 08 Dec 2017 12:37:46 GMT

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

RE: How to receive BLE_EVT_TX_COMPLETE faster?

Chocol8 — Fri, 08 Dec 2017 11:28:06 GMT

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] ? (devzone.nordicsemi.com/.../) 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 ?

RE: How to receive BLE_EVT_TX_COMPLETE faster?

run_ar — Fri, 08 Dec 2017 09:37:46 GMT

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

RE: How to receive BLE_EVT_TX_COMPLETE faster?

Petter Myhre — Thu, 07 Dec 2017 12:31:06 GMT

Which SoftDevice and SDK version are you using?

RE: How to receive BLE_EVT_TX_COMPLETE faster?

endnode — Thu, 07 Dec 2017 09:48:51 GMT

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