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

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

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

Children
No Data
Related