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

BLE_HCI_INSTANT_PASSED Disconnection Reason

Hi Team,

We are seeing an intermittent issue where BLE connection disconnects abruptly due to reason BLE_HCI_INSTANT_PASSED (0x28). We are using nRF SDK version 15.2.0. The mobile device is Moto G7 Power which runs on Android OS. We have seen this issue 8 times in past month with the same device. Please help us with the following queries:

1. When can this happen? I have seen a stack overflow post explaining the possible reasons. Is that an exhaustive explanation?

2. How can we prevent it? Our customers can have multiple types of devices hence we are looking at a firmware level solution. We came across this link to extend connection event length. Can that help?

Thanks in advance

Parents
  • I would say the answer in stackoverflow is to the point, but to elaborate a bit on what may trigger it in specific:

    problem1. If either peer are using an LFCLK source that is out of spec, this may contribute to the packet loss overall. 

    problem2. If either peer is operating at the maximum range (or much 2.4GHz interference from other devices), this will cause high packet loss, and only intermittent communication. 

    problem3. If the peripheral is executing any "operation" that have higher priority than the BLE link, see scheduling priorities, then this may also affect packet loss overall at the time it is executing the "operation" with higher priority than the BLE link.

    How to reduce the risk of this to occur?

    Assuming problem1 is a problem, then setting higher tolerance of the LFCLK source when init the softdevice may help, since that indirectly will handle a peer or if local clock is out of tolerance.

    Assuming problem2/3 is the problem, then enabling (or increasing) slave latency on the link will help, since that will indirectly increase the time from when the LL request is sent first time until the instance where the change will take place.

    Assuming problem 3 is the problem, then looking into reducing "operation" on the peripheral with higher priority may also help if that is the problem.

    Other than I can't really think of anything but to handle it gracefully, e.g. start advertising again. 

    We came across this link to extend connection event length. Can that help?

     Sorry no.

Reply
  • I would say the answer in stackoverflow is to the point, but to elaborate a bit on what may trigger it in specific:

    problem1. If either peer are using an LFCLK source that is out of spec, this may contribute to the packet loss overall. 

    problem2. If either peer is operating at the maximum range (or much 2.4GHz interference from other devices), this will cause high packet loss, and only intermittent communication. 

    problem3. If the peripheral is executing any "operation" that have higher priority than the BLE link, see scheduling priorities, then this may also affect packet loss overall at the time it is executing the "operation" with higher priority than the BLE link.

    How to reduce the risk of this to occur?

    Assuming problem1 is a problem, then setting higher tolerance of the LFCLK source when init the softdevice may help, since that indirectly will handle a peer or if local clock is out of tolerance.

    Assuming problem2/3 is the problem, then enabling (or increasing) slave latency on the link will help, since that will indirectly increase the time from when the LL request is sent first time until the instance where the change will take place.

    Assuming problem 3 is the problem, then looking into reducing "operation" on the peripheral with higher priority may also help if that is the problem.

    Other than I can't really think of anything but to handle it gracefully, e.g. start advertising again. 

    We came across this link to extend connection event length. Can that help?

     Sorry no.

Children
No Data
Related