Further details of buffering notifications and indications

RE: Further details of buffering notifications and indications

Carl — Tue, 01 Mar 2016 12:46:14 GMT

Thanks, that's a great, thorough answer.

RE: Further details of buffering notifications and indications

run_ar — Mon, 22 Feb 2016 14:31:37 GMT

If you successfully queue a notification or indication it is sent as soon as possible. This normally means the next connection interval if there are no restrictions on the peer (also for indications if there are no outstanding unacknowledged indications), however if you are transmitting multiple packets the amount of notifications that can be sent in one event depends on the peer as well. This means that if you queue 6 packets and the peer can only receive one, it will take 6 connection events to empty the buffer.

Buffers are served first in first out. so if you queue a notification immediately followed by an indication, the notification will be transmitted first, and the indication as soon as the notification has been received by the peer. The notification will be transmitted until it's acked by the peer (NESN and SN is incremented) or the connection times out.

If the connection is lost you will not get a TX_COMPLETE event. Instead you will get a disconnected event and can considered the buffers purged for the given connection upon receiving this event.

RE: Further details of buffering notifications and indications

Carl — Thu, 18 Feb 2016 17:21:52 GMT

Further on the last bullet point about TX_COMPLETE. The documentation for "sd_ble_tx_buffer_count_get" suggests that buffers should be tracked from "boot time". I think they should probably be tracked on a per-connection basis instead (i.e. the counter should be reset on every new connection). This is supported by the answer for one of the other questions linked to in the question, which says that for the s120 and s130 buffers are per-link rather than global.