BLE Disconnect packet loss

[hmolesworth]

Nordic NUS - uart service; both SDK 15.3 and 17.0.2. Packet loss on repeated BLE disconnect - connect cycles; seeking clarification of my understanding.

"If there are untransmitted packets in the TX buffer where there is a disconnect, those packets will be lost. So, those packets will not be transmitted automatically upon a re-connect. Upon a re-connect, if needed, the packets will have to be put manually into the TX buffer."

How is this best handled, ie how do we know which packets are in the Tx buffer and which have been sent over BLE and removed. TX_COMPLETE is clearly not a good indication; does this require a specific BLE_GATTC_EVT_WRITE_RSP check for every packet, followed by a retransmit if none received but a BLE disconnect takes place?

// BLE_GAP_EVTS - GAP Event IDs - uniquely identify an event coming from the stack to the application

// BLE_GATTC_EVTS - GATT Client Event IDs
/* BLE_GATTC_EVT_WRITE_RSP:  */ "56 Write Response event",

Packets are (say) 160 bytes; loss is typically one or two packets per BLE connect/disconnect cycle, assuming BLE connect/disconnect cycle is the cause; typically 1GByte total transmission.

The question is probably best posed as is the BLE TX buffer discarded regardless of contents on a BLE disconnect event? If so that is not what I expected .. anyone tried working around this?

[JONATHAN LL]

Hi,

The question is probably best posed as is the BLE TX buffer discarded regardless of contents on a BLE disconnect event?

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

[hmolesworth]

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?

[JONATHAN LL]

This might clear things up:

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

• sd_ble_gatts_hvx
• sd_ble_gattc_write

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


Regards,
Jonathan