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,

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. 

Correct, time critical events such as keeping the connection alive will not be blocked with applications running at priority 2. 

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

Yes, this should be correct.

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? 

Yes, you can increase it up to 59 with the connection parameters specified under new configuration.

Instant Passed occurs after 6th connection event. Can we increase this "6" somewhere? Can central modify it? Our central is a smartphone.  

No, this is part of the BLE spec.

1. What would you recommend for starters to use for connection interval min/max values? 

Depends on several factors, such as current consumption etc. See this section.

Can you share the datasheet and full part number of both your HFXO and LFXO crystal? Also, what is the size of the parallel load capacitors of both the HFXO and LFXO crystal?

regards

Jared 

[Rafig]

Hi Jared, 

Thanks a lot for you assistance. I will try to play with connection interval values and further increase the latency. 

Regarding LFXO, it is ECS-.327-12.5-12-TR. Links to the datasheet and to the design guide. The latter document has the formula for cap. calculation on the last page. Actually when I googled capacitor calculation formula for crystals, most have been using formula in the crystal document rather than the one used in Nordic documentation. We have been initially using 12pF caps from the reference layout. But later noticed that these values were for 9pF crystal, thus incorrect since we are using 12.5pF crystal. Then we tried capacitors calculated with Nordic formula, the required value was 21pF, we used 22pF that we had available. Then we tried caps calculated from the crystal manufacturer formula, the required value was 15pF, and we used it. None of these solved the problem. 

We are using BMD-350 module, and it has its own 32MHz clock. Text from the module datasheet:

"BMD-350 requires two clocks, a high frequency clock and a low frequency clock. The high frequency clock is provided on-module by a high-accuracy 32 MHz crystal as required by the nRF52832 for radio operation. The low frequency clock can be provided internally by an RC oscillator or synthesized from the fast clock, or externally by a 32.768 kHz crystal. An external crystal provides the lowest power consumption and greatest accuracy. Using the internal RC oscillator with calibration provides acceptable performance for Bluetooth low energy applications at a reduced cost and slight increase in power consumption."

Unfortunately, I was not able to find any other information regarding the HFCK it is using from its datasheet. We tried to open up the module and see the part number, but we weren't able to identify the model. I will keep looking for it, and update you if succeed to find.

Waiting for your feedback.  

[Jared]

Hi,

Yes, about 21 pF would be what we recommend for the crystals. Have you performed an antenna tuning for the device? Was it tuned under similar conditions as when you test it, meaning on a human body and with enclosure?

regards

Jared 

[Rafig]

No we didn't perform antenna tuning. In fact its firs time I hear about it. I only considered increasing peripheral Tx strength from the default 0dBm to 4dBm, but haven't tried it yet. What is the benefit of tuning and how is it done? Should it be done to nRF52 modules as well?

[Jared]

Hi,

I'm sorry, I read your previous reply a bit fast. No, it should not be done if you're using a module. Could you try increasing TX power and see if increasing the latency mitigate the issue?

regards

Jared