About acknowledgement and retransmission

RE: About acknowledgement and retransmission

lbehhhh — Wed, 29 Mar 2017 17:09:58 GMT

By using a sniffer you can confirm that regardless of indicate/notify there is a LL ack that happens. For indication there is a higher layer ack as well. This was confirmed using a nRF52840 DK set up as a sniffer.

RE: About acknowledgement and retransmission

Martin — Fri, 04 Apr 2014 14:55:07 GMT

Hm, in the BLE spec. I read that notifications are NOT confirmed by radio from client side so packet can be lost in air or dropped if client is overloaded. Contrary to Indication that should be confirmed by radio via packet back from client to server (but this is slower). So how it's implemented? How can I be sure that client got a notification?

RE: About acknowledgement and retransmission

Ole Morten — Mon, 17 Mar 2014 14:09:33 GMT

All packets transmitted over a BLE link will be retried infinitely or until link loss, and all packets are protected by a CRC on the link layer. There is no way to tweak this, or set a maximum number of retransmits. The only thing you can possibly do is to adjust the supervision timeout, so that less data is tried transmitted before the link is considered lost.

Hence, no matter if it's Reads, Write Commands, Notifications or Write Requests, Indications, you should not normally see any data loss.

I can therefore not quite understand how you manage to get the behavior you see. Could you supply a little more details on the test you're doing, and exactly how you perform it?