About acknowledgement and retransmission

[Paul Yip]

Hi,

We're working on BLE communication between iOS and 51822 and found a data reliability issue. We have a custom characteristics that iOS read 60 bytes data from 51822, e.g. below.

iOS read: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

51822 return: 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 22 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33

We tested in an ordinary office area and found that there is 30% chance that the data return from 51822 is not reliable. In most error cases, it missed the first 20 packets, i.e. the 11 11 11 ..... In some case, it missed the last 20 packets, i.e. 33 33 33 ......

Are there anythings that we could do on 51822 to improve the reliability? Are there any timeout and retransmission mechanism that BLE or nordic could provide? I'm not sure whether it's iOS application's responsibility to trigger the retransmission. If there are any resources that you could provide, that would be a big help. Thanks.

Paul

[Martin]

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?

[lbehhhh]

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.