Advertising with new address in SDK v6.1

[XMLSDK]

I am developing a HID keyboard with SDK v6.1, SD v7.3, IC revision 2.

The keyboard is already able to advertise (non-whitelist) and bond with iPhone, and connect/reconnect to iOS 9.1 (by whitelist and IRK match).

The problem is I want to start new pairing. I have to disconnect this iPhone, start advertising without whitelist to welcome everyone (including the original bonded iPhone), AND don't want to get immediately reconnect back to this iPhone.

Since there is no blacklist mechanism, I have to vary my Bluetooth static random address, e.g. increment 1, and using "sd_ble_gap_address_set(BLE_GAP_ADDR_CYCLE_MODE_NONE, &gap_addr)". Now the original iPhone and everyone else could see my new advertising device.

Then I use this new address to bond with the original iPhone. It can connect at the first time. But after that it can no longer reconnect again. It repeatedly connect and then disconnect immediately, with disconnect reason=0x3D, which is HCI error "Connection Terminated Due to MIC Failure". Could you please help with this problem? Thank you!

[Hung Bui]

Hi XMLSDK,

I understand that it could be a hassle with a bonded iPhone when we don't want it to connect. Usually we simply turn off Bluetooth on the bonded iPhone to let other to connect.

What else you can do is to advertise with very low TX Power, so that the advertising packet is only captured by the new phone which is in proximity to the device.

Your solution of changing the address may work. But I don't understand whether bond the old phone again with the device advertising with new address ? If you did then you may come to the issue that the new bond will replace the old bond on the device. And the phone when reconnect to your device ( when advertise with older address) will try to use the old bond keys, which already replaced on the device.

And also switching the address may create a mess when you don't know which address should be used with which central.

[Hung Bui]

Yes, the IRK will be the same.

Could you check which disconnect reason returned ?

I would need a sniffer trace to really tell what happened.