Pairing specific pairs among many

[June20]

Hello, we're trying to make products using BLE with nRF52840(central) and nRF52833(peripheral).

We did make custom boards and also made a program that once paired(bonded), it won't connect with others.

(eg, once nRF52840 and nRF52833 is paired, it will not connect with others)

We were wondering is there a way to make specific central connect with specific peripheral?

Is there a way to make each central/peripheral unique so that pairing process can be done without interference?

We got concerned that wrongly paired(or bonded) devices might ship out.

At our current stage, pairing wrong central/peripheral is possible.

Other infos.

nRF52840-central has 2 buttons, while nRF52833-peripheral has none

We're using SDK 17.1.0 S140 Segger Studio

has NUS(communication) and BAS(battery check) BLE services

thanks

edit:

extra question: is there a way to write certain unique number/MAC address on flash during flash write and then read it during application?

How do I know which address of flash is used or not?(want to avoid  collision with bonded info)

Is there a download tool beside nRF Connect Programmer?

[Einar Thorsrud]

Hi,

June20 said:

Edit: Central looks very tricky. hrs_c has whitelist-ing stuffs but it's related to peers

pm_peer_id_t says it is uint16_t, how does it carry whitelist data??

does central has something like ble_advertising_whitelist_reply()?

my central's NRF_BLE_SCAN_EVT_CONNECTED display totally different ble address compare to my peripheral's device address(NRF_FICR->DEVICEADDR[0,1]), is it possible?

Just as with peripherals, you don't need the peer manager to whitelist addresses. You can do it manually. But for a central this is related to scanning, and not advertising. Also as with the peripheral examples, you can see how it is done with the peer manager, but just replace the peer manager calls to get the whitelist from the peer manager with a whitelist you make yourself (which is just a list of addresses). I understand you already have referred to examples\ble_central\ble_app_hrs_c\main.c, and that is a good reference. Here you have the whitelist being handled mostly in the whitelist_load() and on_whitelist_req() functions. Remove the pm_* calls, and add code handling the whitelis manually, just like in the peripheral example I showed yesterday.

Another point though is that whitelisting might not be relevant on the central. It is mostly useful when using IRKs as then the stack will handle address resolution etc. for you. If you just have a specific static address you want to connect to, then you can simply select to connect to that address. If you look at the scan_init() implementation in the same example you can see it filters on different things. You can simply filter on the address, and that is that.

June20 said:

Peripheral's side doesn't respond much but central's side constantly find connection and get disconnected for reason 2 and 3e

what does it mean unknown connection identifier?

I believe BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHEDd is due to constantly trying to connect?

I guess this is with the whitelisting code? That has whitelisted a device I used to test, so you need to change the hard coded address to use another device. BLE_HCI_CONN_FAILED_TO_BE_ESTABLISHED (0x3e) is the expected disconnect reason when trying to connect with a device that use whitelist and you are not in it. That is because the peripheral will simply ignore connections from a central that is not in the whitelist. I am not sure why/where you would see BLE_HCI_STATUS_CODE_UNKNOWN_CONNECTION_IDENTIFIER (2), though..