CC2541: Delay while running HID mouse o CC2541 connected to Smartphone

Hi,

It is possible to get a sniffer capture of the BLE connection? I think this will help determine if the latency is on the BLE Stack side of the CC2541, or the smartphone.

Also, which BLE Stack version are you using in your application? If you are not using the latest version, is it possible to migrate and see if you still encounter the same issue?

Regards,
Michael

Hi! I am doing this test to determine where the latency occurs using a LED to blink when the mouse left button should click , but I didn't finished the code yet. We are using BLE-CC254x-1.5.0.16. I saw that there is one new version , but I want to see if there is any release note of this one (I think it is v1.5.1), do you where can I find it? It would save us some time if there were no signicant changes , once it will be very laborious to do it. Thanks!

Regards,

Bruno.

Hi, I've done some tests and I found out that decreasing the max and min BLE connection intervals made it work fine ,but not 100%. When I connect it to the Android for the first time it runs without noticeable latency, the problem is when I disconnect it and connect it again the latency starts to occurs the same way it was happening before my changes. Even if I reset the device , it always runs with this delay. It seems that there are some buffers overloading or something like that.

The previous max and min connetion intervals was 110ms and 90ms , respectively. Now , I've changed them to 40ms and 20ms. Do you have any ideas of how can I solve this problem?

Regards,

Bruno.

Hi Bruno,

Apologize for the delayed response, as availability has been limited the past few weeks for me to investigate this.

As for the release notes, they are not available online for SDK v1.5.1, but it is available in the readme file. SDK v1.5.1 is a minor update from SDK v1.5.0 that contains the following fixes:

• Fixed an issue where the AES-CTR counter value was reset after every 64 byte block in the BEM and EBL projects (BLESTACK-5116).
• Update the MAC verification to use a constant time function in the BEM project (BLESTACK-5117).
• Updated simple peripheral application to re-initiate advertising upon a connection fail event caused by invalid connection PDU parameters (BLESTACK-5258).

Regarding your tests, it would be hard to comment more without sniffer verifying the connection interval. However, I would check the following to verify if the connection interval is getting set as expected:

1. Are connection parameter update requests enabled? (by default, I believe they are for HIDemukbd, but you may want to verify)
2. Is the central accepting the connection parameter update request from the peripheral? Note that the central is not required to accept the desired connection parameters from the peripheral device. Perhaps the central device established the connection with a connection interval that to large for your application requirements, and is also rejecting connection parameter updates from the peripheral with the shorted desired connection interval.

Regards,
Michael

Hi, Michael Hollister!

Thanks for your help, I'm going to check the things you said, and about the sniffer capture , do I need that USB dongle to do it? I was trying to use that app "Sensor tag". I'm also starting to use CC2640.

Regards,

Bruno.

Hi, Michael Hollister!

I've found the root of the problem. It is actually related to GAP bonding procedure. When I use the device with android smartphones (OS  versions 7.0 or upper) it starts working badly in a specific situation that compromises the usability of the product we are making. The thing is that after some search and tests I noticed that after the first pairing when I click on "remove device" on Android's bluetooth settings it seems that the smartphone erase all information related to GAP Bonding of my device, but my device don't do the same, it stays with it's gap bonding keys to make future reconnections faster. The problem occurs when I try to reconnect the device with the smartphone and it seems to get confused because it assumes that the smartphone has it's own GAP bonding key, so it takes a lot of time to pair and when the pairing is done the functionality is terrible. 

So, what I did was to erase all bonding keys using function  GAPBondMgr_SetParameter() with GAPBOND_ERASE_ALLBONDS as parameter after every connection termination, but doing this I lose this faster reconnetion feature that the bonding process gives to me. Given that, I'm trying to "correct" this problem by erasing a single bond when the reconnetion takes more time than it should take. The thing is that I don't know how the device can intercept what bonding it is using in the reconnection event.