• State Verified Answer
  • Replies 8 replies
  • Subscribers 87 subscribers
  • Views 457 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 356909
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

BLE connect state to adv state

Liny

I use the nRF5 SDK for BLE peripheral development based on a keyboard example. After the peripheral connects and bonds with a central device, I can detect button presses. I want pressing a button to switch the peripheral back to advertising mode. How should I do this? Should I first call sd_ble_gap_disconnectto disconnect, and then directly call advertising_init()and advertising_start()?
I am encountering an issue: as a peripheral, after bonding with a central device, I unilaterally cleared the whitelist. However, when the peripheral re-enters pairing mode, the central device keeps attempting to connect and bond, causing the peripheral to repeatedly connect and then disconnect. How can I avoid this problem? The desired outcome is to prevent connection attempts from this specific central device while still allowing other central devices to scan and connect to the device.

  • 0

    I am encountering an issue: as a peripheral, after bonding with a central device, I unilaterally cleared the whitelist. However, when the peripheral re-enters pairing mode, the central device keeps attempting to connect and bond, causing the peripheral to repeatedly connect and then disconnect. How can I avoid this problem? The desired outcome is to prevent connection attempts from this specific central device while still allowing other central devices to scan and connect to the device.

  • 0 in reply to Liny

    Bad design. A device that exposes HID service will always see aggressive connection attempts from host OS that has a pairing/bonding active. For good reason: Disconnected mouse/keyboard is VERY annoying.

    The only good solution is to change the device MAC address dynamically. This is how my BTLE mouse here can support up to 3 different hosts. It has a extra button and status LEDs for this function.

    No idea how to do this in either NCS or the old NRF5 SDK though.

  • 0

    Hi,

    1) I can suggest a few steps. In order to make the device advertise again when button is pressed, ask the SoftDevice first to disconnect. This you can do by using sd_ble_gap_disconnect(...). Then, when you get the disconnected event in the BLE handler, start advertising.

    advertising_init() is called once at the start. After that, you can use advertising_start() again after disconnect. 

    2) The reason why the central keeps reconnecting is because it remembers the bonding info between your peripheral and central. The peripheral still advertises in a mode that accepts it. Then you advertised normally, so the central tried using the old bond to connect. When the connection fails, it tries again which causes a loop where it connects and disconnects. 

    3) If you want to only block that central, you can try to use PeerManager and build a whitelist of peers which you want to allow. When advertising module asks for a whitelist, to get the addresses for those peerIDs, you can call pm_whitelist_get(...). These can then be passed to ble_advertising_whitelist_reply(...). So, don't include the central's peer ID in the list passed to pm_whitelist_set().

    Let me know if you have any further questions.

    Best Regards,

    Samruddhi

  • 0 in reply to Samruddhi Jadhav
    According to your method, the first one has been achieved. Thank you!
    As for the third question, I’d like to ask: Do you mean using a whitelist for broadcasting and limiting the scope of the whitelist? Is that correct?
    What I want to know is, if I want to pair with most mainstream Windows, iOS, Android, and Mac devices on the market, how should I configure the scope of the whitelist? In other words, if the whitelist for the new host devices I want to pair with isn’t specific, is your method still effective? And if it is effective, could you provide more detailed guidance? Thank you!
  • 0 in reply to Liny
    If the above method doesn't work, is there any alternative approach? For example, when the peripheral receives a connection request from the host or detects an error like err4102, it could reply by rejecting the connection or something similar, so that the host won't keep attempting to reconnect repeatedly.
    Alternatively, if I set the peripheral to broadcast in non-whitelist mode, will the host still be able to discover my device and try to reconnect?
Related
Terms of service