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.

Reconnection (via ADV_DIRECT_IND) to a paired central device, which has changed its random addr, doesn't work.

Other Parts Discussed in Thread: CC2650, BLE-STACK

My set up:
Central (GATT client):
Android version 6.0
Model number: nexus 6

Peripheral (GATT Server):
TI - CC2650
stack version 2.1.0

Steps I followed:
- Bonding is done between central and peripheral.
- After a while (approx 20 min post bonding), the random bluetooth address of central device has changed.
- On the TI side, I would expect to receive 'GAP_RANDOM_ADDR_CHANGED_EVENT' from the stack but this doesn't happen.

- A new ADV_DIRECT_IND is not replied by the central device and therefore reconnection doesn't work.

Could you please suggest when can I expect the stack to send 'GAP_RANDOM_ADDR_CHANGED_EVENT' to the application;
And what changes do I need to do to my existing set up in order to successfully reconnect to the central device?
Please let me know if you require any further information. Air trace is available on demand.

  • Hello Prem,

    The 'GAP_RANDOM_ADDR_CHANGED_EVENT' is sent to the App when the Peripheral changes its own random address (private resolvable). Support of private resolvable addresses (PRA) is defined in BT4.2 / LE Privacy 1.2. BLE-Stack v2.1 supports BT4.1. In the interim, you'll need to disable use of the whitelist on the Peripheral side and resolve the address in your App.

    Best wishes
  • Hi,

    I am not using whitelist on the peripheral side.
    Please let me know the way App could resolve the address.

    Thank You,
    Prem
  • Hello Prem,

    Using ADV_DIRECT_IND on a phone is a grey area for BT4.0/4.1. You can see some discussions on Stackoverflow.net on how some people have gotten it to work, however, note that it does involve 1) the phone's BT Host supports this, and 2) the App must configure the Scanner Filter correctly.

    Is it not possible to use ADV_IND instead?

    Assuming you know the latest PRA, you can call GAPBondMgr_ResolveAddr to resolve the address.

    Best wishes