CC2640R2F: Compatibility problems with some mobile phones when running BLE5.0 stack

Pls kindly refer to the following picture for the mobile phone version

Hi Sunny, 

Assigning an expert to comment. 

Thanks, 
Elin 

Sunny,

The TI devices and SDKs are tested thoroughly every release for compatibility with a large list of phones. However, it is impossible to cover all phone combinations (hw/sw).

I recommend to use a BLE sniffer to capture the traffic in the air and study where the error comes from. TI has a packet sniffer, or you can also use a commercial sniffer. Please let me know if it would be possible for you to provide us a log.

In any case, I will suggest to the team to add this device to our list.

-Luis

Hi Luis，

I used a third-party sniffer tool to capture the traffic packet in the air. There are two attachments, one is normal disconnect, the other is timeout disconnect.

Test conditions:
Hardware: TI Launchpad ("LAUNCHXL-CC2640R2F Rev:1.0)
Firmware: cc2640r2lp_simple_peripheral.hex (C:/ti/simplelink_cc2640r2_sdk_4_20_00_04/examples/rtos/CC2640R2_LAUNCHXL/ble5stack/hexfiles/cc2640r2lp_simple_peripheral.hex)
Mobile phone: Redmi Note 7 Pro (MIUI 11.0.8) (The phenomenon was found more frequently in this phone).
APP: nRF Connect v4.19.0
Sniffer analyzer：Wireshark v3.0.6

normal disconnect:

normal disconnect.zip

timeout disconnect:

timeout disconnect.zip

Hope we can get the feedback ASAP.

Best regards.

Steven

Steven,

I've involved the team. We're looking at this issue. 

Is this blocking you from going to production? Can you give me an idea of your project's timeline and the severity of the issue?

Thanks,

luis

Steven,

As I've said, I'm in the process of obtaining feedback from our team of experts.

However, on a quick look, it seems that the phone is sending connection events at intervals much more smaller than the permitted. The minimum interval between connection events is 7.5 ms, and as I'm showing in the attached image, the phone jams the TI chip with too-frequent connection events, as close as even less than 1 millisecond! (see for example message #1638 in the image below)

Please see the image below: (I'm displaying time between packets)

So, I believe that the cause is that, at least in part, the phone is out of spec.

Thanks,

Luis

Hi Luis,

Steven and I are in the same team. 

This is really blocking our production. And it is urgent, our customer and our team are dying to solve this problem ASAP. The end product will mostly use in APAC market, and the phone we listed is very popular in this area.

This problem has prolonged the project for a month, can you help us to solve this? And we would like to move to the production in the late of this August.

Thanks a lot.

Sunny

Hi Luis,

The following picture shows that the mobile phone communicates with the CC2640R2F chip normally, but the timeout disconnection still occurs.

Looking forward to your reply.

Sunny

Sunny,

What are your thoughts in the likely root cause that I mentioned? It seems to me that the messages from the phone are coming at a much higher rate than permitted by the Bluetooth specification.

Also, could you please share some logs of a "good" phone? (maybe another model that works reliably). I'm trying to analyze the communication and compare "pass" vs "fail".

In any case, I'm involving more members on my team as you have shared the severity of this issue for your product.

I'm hoping I can give you an update tomorrow, 8/13 by the end of the day, USA Central time.

-Luis

Hi Luis,

Pls kindly refer to our more detailed information:

The following screenshot is of TI official firmware (SimplePeripheral of blestack, not ble5stack) interacting data with Xiaomi phones.

Xiaomi phones also send data frequently, but there has never been a timeout disconnection. Our team think it is not entirely due to the frequent data sent by mobile phones. Xiaomi mobile phones are connected with other chips, and data is also sent frequently but this phenomenon does not occur.

Firmware: cc2640r2lp_simple_peripheral.hex (C:\ti\simplelink_cc2640r2_sdk_4_20_00_04\examples\rtos\CC2640R2_LAUNCHXL\blestack\hexfiles)

Sunny,

Our dev team is involved and now investigating the issue. Unfortunately, I can't guarantee a timeline for a possible solution.

I have some questions for you:

1) Could you please share some logs of a "good" phone? (maybe another model that works reliably). I'm trying to analyze the communication and compare "pass" vs "fail".

2) Are there other phones that show the same behavior? Maybe other Xiaomi? If you give us more options, we might be able to get one here in the USA. As you probably know, the most important thing right now is being able to reproduce the issue.

Thanks,

Luis

Hi Luis,

Good day.

Currently, the phones which occurs the problem are the following: HUAWEI Mate30Pro(5G), HUAWEI Mate20, REDMI Note7Pro, Xiaomi 6, VIVO Iqoo Neo.

The compressed package contains the interactive data between two mobile phones and TI CC2640R2F Launchpad (simple_peripheral) separately.

sniffer_data.zip

All three mobile phones tested on hand have this phenomenon, and mobile phones were  normal when interactive data.

Looking forward to your reply.

Sunny

Sunny,

Our team is investigating the issue. I will update you periodically in this thread.

Thanks,

Luis