BLE_HCI_INSTANT_PASSED Disconnection Reason

[pranesa]

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

[Kenneth]

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.

[pranesa]

Hi Kenneth,

Thanks for prompt response. I have few follow-ups questions:

>> setting higher tolerance of the LFCLK source when init the softdevice may help

1. How can we set that? Is this a config in sdk_config.h?

2. What is the value that we can set? Is there some guidance around it?

>> enabling (or increasing) slave latency on the link will help

3. I think this can be done only by peer device. Is it possible for the peripheral to set slave latency?

>> peer is operating at the maximum range (or much 2.4GHz interference from other devices),

4. Will it help to mitigate this issue if we introduce a guidance to our customers to not use other BLE devices when operating our product?

[Kenneth]

pranesa said:

1. How can we set that? Is this a config in sdk_config.h?

2. What is the value that we can set? Is there some guidance around it?

You can find in the sdk_config the following defines:

NRF_SDH_CLOCK_LF_SRC
NRF_SDH_CLOCK_LF_RC_CTIV
NRF_SDH_CLOCK_LF_RC_TEMP_CTIV
NRF_SDH_CLOCK_LF_ACCURACY

It is the NRF_SDH_CLOCK_LF_ACCURACY that set the accuracy used in the LL to compute timing. If either peer have a LFCLK that is out of spec, then increasing this value may help, however it will also increase current consumption, since the peripheral now will increase the receive window on each connection event. You can in the online power profile for instance see how increasing clock accuracy impact the average current consumption in a connection:
https://devzone.nordicsemi.com/nordic/power/w/opp/2/online-power-profiler-for-ble

It is very difficult to comment by how much this value should be increased if the LFCLK is out of spec, but increase it so that average current consumption still meet your battery lifetime can be considered.

pranesa said:

>> enabling (or increasing) slave latency on the link will help

3. I think this can be done only by peer device. Is it possible for the peripheral to set slave latency?

It is the central device that control this yes, however the peripheral device can request the peer to update the connection parameters, and in most cases it seems that the central device will go ahead and accept and initiate connection parameter updates based on these parameters.

In your project these are typically set in gap_params_init()->sd_ble_gap_ppcp_set() and conn_params_init()->sd_ble_gap_conn_param_update(). The ble_conn_params module can be configured to send a connection parameter update request if the parameters are outside the preferred ones. Typically you can find that the preferred SLAVE_LATENCY is set in main.c, however in sdk_config.h you can find that there is a define that control by how much slave latency can differ without sending a connection parameter update request. This define is called NRF_BLE_CONN_PARAMS_MAX_SLAVE_LATENCY_DEVIATION. So in other words you should check both these parameters and if you have ble_conn_params module enabled in your application. 

pranesa said:

>> peer is operating at the maximum range (or much 2.4GHz interference from other devices),

4. Will it help to mitigate this issue if we introduce a guidance to our customers to not use other BLE devices when operating our product?

I don't believe that this help, I don't think interference is a big problem overall. Instead you can possible add some description that if you experience frequent disconnect change location/move it closer if possible, since that will also influence the signal to noise ratio and improve link budget overall.

[karnram]

Hi Kenneth,

>> I don't believe that this help, I don't think interference is a big problem overall.

In our case, the master is a mobile device connecting to our peripheral. Can a mobile device concurrently connected to multiple other BLE devices like smart watch, headset etc. have budget issue for BLE link with our peripheral? 

Thanks

[Kenneth]

That may have some impact yes, it could then depend on the scheduling and priority on the mobile phone when the various connections overlap, ideally those links that are doing LL procedures that contain operations from a specific instance should have priority. I do not know how this is handled today in the various mobile operating systems and stacks, it may even vary between chipsets in the mobile phone.

Best regards,
Kenneth