BLE Disconnect packet loss

RE: BLE Disconnect packet loss

JONATHAN LL — Mon, 12 Apr 2021 08:49:23 GMT

This might clear things up:

For WRITE there is both with and without response, and for HVX there is both with and without confirmation.

So since you want to know what been received then RSP is the a way to check.

Regards,
Jonathan

RE: BLE Disconnect packet loss

hmolesworth — Sat, 27 Mar 2021 22:44:09 GMT

Thanks, although the answer you refer to says the buffer is emptied - ie all queued data sent over BLE - before transmission is cleanly ended, not what happens if the BLE connection drops unexpectedly and not by request or negotiation. I suspect you are correct, however, but don't find any reference to this in the documentation.

As I mention in my question, _TX_COMPLETE does not help as it only indicates data was transmitted, not that it was received; the act of transmission may well be the event that causes BLE connection loss to be recognised by the Peripheral, since if so the L2 layer does not respond even though _TX_COMPLETE is set. It seems _WRITE_RSP is the only safe way to ensure every packet was delivered, and increasing the buffer makes tings worse since if emptied on disconnect than all the pending packets have to be re-queued. I expected that to be handled in the Softdevice, not the application.

Maybe Zephyr stack works differently, any experience with that?

RE: BLE Disconnect packet loss

JONATHAN LL — Fri, 26 Mar 2021 14:15:11 GMT

Hi,

[quote user=""]The question is probably best posed as is the BLE TX buffer discarded regardless of contents on a BLE disconnect event?[/quote]

The buffer is emptied on disconnect: Is the TX buffer flushed/cleared on a disconnect? - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com)

You do get an event when transmitted : BLE_GATTS_EVT_HVN_TX_COMPLETE then the application has to take care of handling what data it has given to the SD with sd_ble_gatts_hvx(), vs ble_gatts_evt_hvn_tx_complete_t::count events

Regards,
Jonathan