CC2642R-Q1: few Android phone Connection Establishment fails

Hi Chad,

0x3E is Connection Failed to be Established per ll.h and the behavior for the central to attempt the first connection event six times and then leave is defined in the specification. 

It is possible, and not always a guarantee that the advertiser will see the centrals connection indication. There is only one opportunity for the peripheral to see the connection indication and if there is a significantly noisy environment or the central device is far away from the peripheral, it can increase the chance that the connection indication is not seen. 

What is the environment you're testing in?

Also, please share the full Ellisys log. 

In the desktop test in the office, the distance between the test phone and the CC2642 board is only about 10cm, and there is no obstruction;

Ellisys logs will be sent to you tomorrow。

Sounds good - thanks. Please also let me know how common it is that you see this. Is it every attempt, 50% of the time, more rare?

It is easier to reproduce on a few mobile phones, such as this xiaomi14 mobile phone, but it is not easy to reproduce on most mobile phones;
I have compared that the SCA in the CONNECT_IND data packet of most mobile phones is: 1 (151~250ppm), but the SCA of the xiaomi14 mobile phone is: 5 (31~50ppm);
I just found a similar ellisys log. The test environment is the same, but the test time is different.xiaomi14_connectError0x3E.zip

Hi，Evan，The btt file of ellisys corresponding to the screenshot was not saved yesterday, but the problem is that the compressed file behind is the same。

HI，Evan，Is there any doubt about the documents I provided here?

Chad,

In the log, I can see the connection failed to be established, but it doesn't look like there is anything wrong with the connection indication from the phone or the TI device other than it likely has not seen the connection indication. One thing you can do is enable the RF debug pins and connect them to the Ellisys logic capture functionality and log that within the Ellisys as well when the issue occurs and that will let us know if the radio is attempting to meet at the connection interval or not. If it is not, then it's safe to assume the indication was not seen, likely due to interference. 

Info on how to enable the RF debug output:

https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_7_10_01_24/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/debugging-index.html#debugging-rf-output

Okay, I'll do it this way

Hi，Evan，

 Sorry, our ellisys device needs a license to capture Logic signals, so it cannot be captured，Is there any other way？

test_data_0313.zip

Hi，Evan，

1. By using the logic analyzer of DSlogic to grasp manually, we can see the approximate corresponding situation, but we are not sure whether it is normal;
2. Try to test in the shielded room and office environment. Indeed, the problem did not recur in the shielded room, and it is easy to recur in the office environment.
3. By comparing multiple mobile phones and observing Bluetooth air signals, it is tested that the channel map of the mobile phone with abnormal conditions has fewer available channels and the SCA accuracy is high. Do these circumstances indicate that this situation is an expected behavior and cannot be avoided?

Hi Evan，Is there any strategy to optimize and improve the success of the connection in cc2642

Chad,

At this point, it would be more related to ensuring your hardware is good first. Making sure you have a good RF/antenna match, good return loss, crystals (both LF and HF crystals) are tuned appropriately and operating effectively. Have you done this with your hardware? All of this combines to make sure you are sensitive and able to receive packets, even in noisy environments, but the reality is in some environments you may have constructive and destrucrtive interference that can affect packets and may cause the CONN_IND to be received incorrectly. How often are you seeing this behavior?

Thank you very much for your advice. I'll collect it tomorrow