Eliminate BLE_HCI_INSTANT_PASSED 0x28 BLE disconnection

[Rafig]

Hello Nordic Team, 

We are developing a wearable device. We noticed spontaneous BLE disconnections every 1-2 hours. The error code is BLE_HCI_INSTANT_PASSED. I have checked all related questions in devzone, this one was especially useful. According to it, there are 3 root causes: LFCK inaccuracy, Radio Interference, and software that blocks BLE operations. 

The problem appears mostly when the device is worn, i.e. the interference is increased from human body, clothing, and other obstacles (e.g. chair). Otherwise when the device is on the table, the issue is very hard to reproduce. That's why, I believe that the root cause is radio interference and probably signal weakness because of distance. 

In any case, regarding LFCK, we chose external capacitors according to guidelines provided by Nordic. We also tried to use capacitors calculated with another formula given by the crystal manufacturer (it slightly differs from Nordic formula, and results in ~5pF difference). Also, we tried to increase LFCK accuracy from 20 to 250, and it didn't help. 

Regarding software, we have priority 2 for TWI and PWM. PWM calls have been specifically disabled throughout the tests, so it shouldn't have any effect. TWI is used, but in blocking mode. If I am not mistaken, it should not interfere with Softdevice. Please correct me if I am wrong. 

My understanding of this error is following: For example, Master is at 10th connection event. When it sends commands to update communication channels or to update connection parameters (the "special requests"), Slave has to respond within 6 next connection events. So, if we increase the connection interval, the overall time-window covering these 6 connection events will increase, thus if there was a noisy/blocking environment, by prolonging the time, we have higher chances that the problem will disappear before the connection is lost. Furthermore, when we increase the slave latency from 0 to lets say 5, then the wait window is increased to 11 instead of 6 connection events. Can you confirm that my understanding is correct? 

Hoping that it will help, I did following modifications:

Old configuration:

• Min. Interval: 20 ms
• Max. Interval: 75 ms
• Latency: 0
• Timeout: 15 sec

New configuration:

• Min. Interval: 30 ms
• Max. Interval: 90 ms
• Latency: 5
• Timeout: 15 sec

But it didn't help. 

I want to ask following:

1. If my understanding about help of latency to this issue is correct, can I increase the latency to much higher value such as 30, 40? This would mean that if packets are lost 40 times in a row, the connection would be still alive, right? 
2. Instant Passed occurs after 6th connection event. Can we increase this "6" somewhere? Can central modify it? Our central is a smartphone.  
3. What would you recommend for starters to use for connection interval min/max values? 

Please let me know if there are any other ideas that come to your mind. 

I would greatly appreciate your assistance. 

[Jared]

Hi,

The antenna size will affect the antenna performance, but I'm not sure if that is the culprit in your case. Do you have a nRF52832 DK available? Could you try flashing your project to our development kit and compare its performance with your custom board? Any significant difference? The result should indicate whether this is a HW or SW problem. 

regards

Jared  

[Rafig]

Hello Jared.

Sorry for the small delay, we were conducting various tests. 

Unfortunately testing our code with DK is complicated because of many peripherals that need to be connected.

We tried the opposite, we used an example from SDK (ble_app_template) and flashed it on our hardware. We made some minor changes to the example to indicate the disconnection status, and used following connection parameters:

• min/max interval: 15ms
• latency: 15
• timeout: 30s
• lfck accuracy: 20ppm
• tx power: 0dBm (default)

Result is following:

When device was tested in standard conditions (worn by the user), we saw instant passed errors. 

Then we tested the same device, but this time device was not worn by the person, instead phone and device were both on the table without any obstacles between them. This time we didn't see any disconnection for ~9 hours. 

In the datasheet of module that we use, I came across following text:

"Care should be taken when designing and placing the BMD-350 into an enclosure. Metal should be kept clear from the antenna area, both above and below. Any metal around the module can negatively impact RF performance.

The module is designed and tuned for the antenna and RF components to be in free air. Any potting, epoxy fill, plastic over-molding, or conformal coating can negatively impact RF performance and must be evaluated by the customer."

I am not sure how to interpret this information. As most of electronic devices, our PCB is enclosed inside plastic case, in which the antenna is in free air. It is not clear for me if they mean that antenna should should not be covered directly by other material, or they mean that antenna should be outside of plastic case. 

Waiting for your feedback. 

[Jared]

Hi,

Rafig said:

I am not sure how to interpret this information. As most of electronic devices, our PCB is enclosed inside plastic case, in which the antenna is in free air. It is not clear for me if they mean that antenna should should not be covered directly by other material, or they mean that antenna should be outside of plastic case. 

I think this question should be directed to the module makers. But in general, when you tune an antenna you'll have to do it on a physical body if that's the use case for the device. If the module makers didn't take this into consideration( they probably didn't) when they tuned the antenna then it's very likely that you'll get a worse result when you put your device next to a body. The thought behind testing with the DK was to see if this issue was HW dependent or not. 

Adjusting the connection parameters might mitigate the issue:

Could you try increasing either the interval or the latency so that: 

interval *(latency +6) > 1sec? 

Also, my colleague Kenneth has some useful suggestions in this case.

regards

Jared 

[Rafig]

Hi Jared, 

Thank you for the suggestions. By the way I have already read the post by Kenneth, that's why I started using higher latency values for the tests. 

Regarding the modules' antenna tuning, if possible we will try to make some tests with custom nrf antenna or with alternative modules. 

Meanwhile, I will conduct tests with following parameters and let you know the result within couple of days.

• Interval: 45ms
• Latency: 17
• Timeout: 30 seconds
• Clock accuracy: 250ppm

[Rafig]

Hello Jared,

We tested the device with above mentioned parameters and now connection seems pretty reliable. We haven't noticed random disconnects. I believe ticket can be closed. Thanks a lot for your assistance.