• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 52 subscribers
  • Views 295 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC1352R: BLE Connection Drops and won't reconnect unless device is power cycled

Calex36
Intellectual 2225 points
Part Number: CC1352R

Hi, 

We have 4 BLE Remotes bonded to our Device using CC1352R for BLE, 

What we have found is when walk far enough away with 1 remote that has an active connection, the connection will be dropped. If from this moment, say 1 minute waiting, the persons walks back to the Device it seems that the BLE connection is not reconnected. And the remote is not able to reconnect to the Device, as if it seems that the Device is refusing every connection request. We've experience this behaviour every time after a signal loss. But if the Device gets power-cycled, the remote can connect again. However during a reconnect we are not performing repairing/bonding; just a connect attempt.

Do you have an idea what might cause their remotes to not be able to connect to our Device, unless after a power-cycle? What can be the reasons a connection gets refused (supposedly), although a bonding with that device exists?

Recommendations we have had so far is to use a Ellisys BLE Sniffer Tool to capture an over the air BLE sniffer log of the scenario. To potentially help determine which device is at fault, and provide some clues on what might be going wrong, however these seem expensive and we can't physical replicate the same exact remotes that were used in the field, as these are custom to the user so over the air capture may not be the best way to debug this? 

Any other Recommendations here would be much appreciated

Many Thanks 

Calex  

 

  • 0
    TI__Guru* 85731 points

    I will assign someone to this case. In the meantime, please provide information regarding what SDK version you are running, and which examples from the SDK your application is based on.

    BR

    Siri

  • 0
    TI__Guru* 81111 points

    Hi Calum,

    As Siri says, please provide the SDK version you are using.

    There is a timeout mechanism in the peripheral device that will cause it to wait a certain amount of time before regarding the connection as broken. However this is usually not very long. You can look up the SUPERVISION TIMEOUT variable in your setup and check that this time has elapsed before trying to reconnect.

    A sniffer log sounds like a good idea. You can use a LaunchPad and the Packet Sniffer 2 tool.

    https://www.ti.com/tool/PACKET-SNIFFER

    Cheers,

    Marie

  • 0 in reply to Marie H
    TI__Intellectual 2225 points

    Hi, 

    We are using simplelink_cc13x2_26x2_sdk_4_30_00_54. Beginning next week we will be at onsite and we will try to sniff BLE. For this we have a NRF RSSI monitor and the launchpad packet sniffer 2 tool. With this we supposedly can see how much ‘traffic’ there is on each individual BLE channel and what the payloads are. The supervision timeout (Requested Conn. Timeout (ms)) is set to 1000ms. Sync Whitelist With Bonded Devices is also set.

    We also added some internal logging that shows continuously the amount of bonded BLE devices and the amount of active BLE connections. Using that and the sniffer tooling we will try to find what the cause is

    Many Thanks 

    Calex