Are notifications always sent before disconnecting?

[Thiemo van Engelen]

Hi,

In our code we would like to respond to a write with a notification and then disconnect. So we first we call sd_ble_gatts_rw_authorize_reply to reply to the write, then sd_ble_gatts_hvx for the notification and then sd_ble_gap_disconnect. Now I was wondering if the write response and the notification are always sent before the disconnection occurs, or do I have to wait for BLE_EVT_TX_COMPLETE (for 2 packets) to know for sure that they are sent?

Regards,

Thiemo van Engelen

[FormerMember]

No, there is no guarantee that the sd_ble_gatts_rw_authorize_reply() and the notifications will be sent before the disconnect command.

So yes, to be sure that sd_ble_gatts_rw_authorize_reply() and the notifications are transmitted before the disconnect command, you should wait for BLE_EVT_TX_COMPLETE/BLE_GATTS_EVT_HVN_TX_COMPLETE (S132 v. 4.x.x)

[Arepa]

Hi Kristin, I have a similar issue do I have to wait for BLE_EVT_TX_COMPLETE/BLE_GATTS_EVT_HVN_TX_COMPLETE to be sure the central received the notification before disconnecting? I am disconnecting after the BLE_EVT_TX_COMPLETE and some times I lost the notification packet, the central does not receive it when it is far away

[FormerMember]

When receiving BLE_EVT_TX_COMPLETE, the notification should have been successfully transmitted over the air. Could you use the sniffer to check which packets that are being transmitted over the air?

[Fanis]

I have a similar problem. Between connection/disconnection cycles it seems i lost one packet. I schedule one transfer and wait for BLE_EVT_TX_COMPLETE, then increment TX_buffer index. It works seamless when i manually enable and disable notifications. But if i disconnect while was subscribed, on next connection stream continues loosing several packages. Can anybody tell me if it is possible that i got BLE_EVT_TX_COMPLETE when disconnection occurs suddenly? Maybe there is some delay that my nrf peripheral reveals that connection lost and in this case automatically all scheduled tranfers are closed with TX_COMPLETE?

[endnode]

Ell everything is possible, Soft Device is just piece of SW written by human so it can have bugs. However could you link your suspicion to some BLE logs which would show that some packets didn't get through and that it's not aligned with TX_COMPLETE events? If you say "on next connection stream continues loosing several packages" it can as well mean "my state machine is not able to recognize which packets were already sent reliably over the link and hence I restart the stream on wrong index (and to the app it looks like some packets were lost)".

[Fanis]

There is a very simple case. I just try to send in timer timeout handle every 2 sec: if(is_connected) send_new_val(&buf[to_send_index]); and then on ble evt i check:

... case BLE_EVT_TX_COMPLETE:

   to_send_index++;
enter code here
send_new_val(&buf[to_send_index]);
enter code here
...

Now i look at nrf_connect logs on android app (swipe to right). For debug purposes i filled the buffer and sending packet values with incrementing values. What i see is if i connect, subscribe to the characteristic, get stream of packets. Now if i unsubscribe and after subscribe again, android input logs continues from the right buf element. But if i just press disconnect while subscribed, and then connect. What i see i lose 3-20 input packets in between (depends on how long i disconnected). Conn. interval is 10-70 ms, s132 of SDK v12.3..