Prevent automatic re-connection with a bonded device

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

I am using a CYBLE-022001-00 chip, and I have made use of the bonding feature of the BLE so that I will only pair with a device once. I am well aware that enabling bonding means that automatic reconnection is inevitable.

Is there a way to bond with a SELECTED bonded device and prevent re-connection with a "not-selected" bonded device? thanks.

0 Likes
1 Solution

Also, you can filter the bonded devices based on connection handle. The first bonded device will be assigned a connection handle of 4 ,second 3 and so on... Now when the device connects , in the event CYBLE_EVT_GAP_DEVICE_CONNECTED you can check the connection handle ( the bonded device  will be assigned the same connection handle on re-connection )  and if the currently connected device is not the device you want to connect , you can immediately disconnect.

-Gyan

View solution in original post

0 Likes
9 Replies
GyanC_36
Employee
Employee
250 replies posted 100 replies posted 50 replies posted

Hello,

    Enabling bonding means storing the security keys of peer device , so next time when the device connects they wouldn't exchange the security keys and the pairing process will be faster. Enabling bonding does not mean that the devices will auto connect. Your application can always choose to which device you want to connect.

Please refer the example project from the  link --PSoC-4-BLE/100_Projects_in_100_Days/Day015_Bonding at master · cypresssemiconductorco/PSoC-4-BLE · G...      for more details

-Gyan

Anonymous
Not applicable

Hi gyan​,

So, here's my application. I have configured the BLE as a peripheral and chose Bonding in the "bonding requirement" in its security config settings. I also called the Cyble_StoreBondingData(0) API in my code. As a peripheral, I have paired the BLE with 4 devices such as a laptop, mobile phone etc. With this, they are assigned a bdHandle of 1-4.

Upon startup, the BLE "automatically connects" to one of the 4 devices. Then, say that I turned off the bluetooth of that device, the BLE again "automatically connects" to another bonded device available. Is it possible to choose which among those devices the BLE connects?

Thanks for the project you referred to. I'll take a look into it.

0 Likes

Hello,

     The security levels are just for different different pairing procedures and nothing to do with Automatic Connection.

To connect to a particular device , you can add the central device address in the whitelist of your Peripheral device and then start advertisement with the connection request from the 'Whitelist' device only.

Please refer the example project on whitelist implementation from here -https://github.com/cypresssemiconductorco/PSoC-4-BLE/tree/master/100_Projects_in_100_Days/Day014_Whi...

PSoC-4-BLE/100_Projects_in_100_Days/Day014_Whitelist at master · cypresssemiconductorco/PSoC-4-BLE ·...

-Gyan

Also, you can filter the bonded devices based on connection handle. The first bonded device will be assigned a connection handle of 4 ,second 3 and so on... Now when the device connects , in the event CYBLE_EVT_GAP_DEVICE_CONNECTED you can check the connection handle ( the bonded device  will be assigned the same connection handle on re-connection )  and if the currently connected device is not the device you want to connect , you can immediately disconnect.

-Gyan

0 Likes
Anonymous
Not applicable

Hi gyan​,

My current implementation does this. In my main loop, I have a function that constantly checks the current cyBle_connHandle.bdHandle with a 'selected device's bdHandle' IF there is ANY. If it does not match, I issue a CyBle_GapDisconnect(bdHandle) command. This continues until the desired device/correct bdhandle is the one connected. So, for 4 bonded devices, it is a sequence of 'a device is connected' - 'check bdHandle' - disconnect if wrong device - then back again.

To make the process faster, I'll take a look into that Whitelist project. I'll try to make the Peripheral advertise to only the desired Central device by putting it in the Whitelist. I think this will prevent connecting to the wrong/not-selected device. Thanks a lot for this idea!

0 Likes
Anonymous
Not applicable

I looked into the Whitelist project and also to APIs relating to it. Unfortunately, I think it is not the way to go since the CyBle_GapRemoveDeviceFromWhiteList() API would remove the bonding information of the other devices I do not wish to connect to YET.

I believe a better option is "direct advertising" to the selected/target Central device. Configuring BLE Peripheral to Perform Directed Advertisement - KBA218959

0 Likes
Anonymous
Not applicable

You also have the option of storing the addresses you wish to manipulate in your application RAM space, and then connecting/direct-advertising to them using the APIs with the RAM address passed in. I used this approach in the project I did, as I had to support storing the addresses in FLASH for permanent use, as well as keeping track of connection-related data when a list of devices would connect. This allowed easy array-access of the data, and the addresses of the devices.

Anonymous
Not applicable

Just to share the final outcome of what I was working on. Given that I have 4 peer devices that I have bonded with the BLE, this means that they are assigned connection handles (bdHandle) of 4 to 1 and will remain with that assignment even upon power reset because of the stored bonding data. The simplest way to handle connecting to a SELECTED peer device is to check in the stack event CYBLE_GATT_CONNECT_IND if the cyBle_connHandle.bdHandle is the "selected" device's connection handle; otherwise, issue a CyBle_GapDisconnect command. In this way, I am not concerned with the peer device address may it be static or a random resolvable private address.

I believe this is all working now. Thanks for all the help, e.pratt_1639216​ and gyan​!

Anonymous
Not applicable

Here's what I noticed so far. In my application, the BLE is configured with a Security Mode 1 with "unathenticated pairing with encryption" in contrary to the BLE_Bonding project (that you referred to) with security level of "authenticated pairing with encryption". Do these have something to do with the "automatic reconnection" without having the Central device "choosing" to connect? Thanks, gyan​.

0 Likes