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

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

[endnode]

Well it's completely unclear how you handle disconnection here and it's also unclear what happens with packets which were prepared to be sent over GATT in Soft Device. There were indications by Nordic team on similar questions here on the forum that buffers should get flushed and that sounds logical. So once you get event DISCONNECTED how you treat the restart of procedure? How you make sure in your logs about what went from APP layer FW to BLE stack GATT layer through SD API and what really went through? It's even possible that packets went over the link on LL and L2CAP layers but then didn't make it through Android stack and APIs to your Android app before it got disconnect event. Etc. without logs about what is happening on the radio link you can hardly claim anything.

[Fanis]

Thanks for your suggestions. BLE_GAP_EVT_DISCONNECTED i just pull down is_connected flag. So what i expect is during connection i continue sending new values consequtively inside BLE_EVT_TX_COMPLETE "loop", and when suddenly disconnect takes place i just have to not get BLE_EVT_TX_COMPLETE any more, so to_send_index shouldn't increment during disconnected. On next connect just my timer handler triggers new transfer and i get to this event again. So TX_COMPLETE is the only place where my buffer index increases, and it seems to continue doing that short time after disconnection or at connection establishment before subscription to the characteristic. I tried organize my stream with indications instead of notification with the same timing intervals and obtain similare results with losing packets.

[Fanis]

I've just noticed under debug that nrf-connect app for android at the beginning of connection somehow skips first several packets (but it confirms all the indications) and continues with printing to log packets that come after those. This is in case i initialized disconnection from app without unsibscribing from indication(in this case next connection begin with subscription automatically, but unfortunately with lost packets).