This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

About acknowledgement and retransmission

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

  • 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?

  • 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?

  • 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.

Related