• State Not Answered
  • Replies 15 replies
  • Subscribers 24 subscribers
  • Views 291 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 285081
Options

Pairing specific pairs among many

user112049

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?

Parents
  • 0

    Hi Joon,

    None of the pm_* APIs are relevant if you don't use bonding. I referred to pm_whitelist_get() just to see where it gets the whitelist (which is simply a list of addresses) from the peer manager and how to use it.

    You can see a very simple way to do whitelisting manually here:

    (this is not very elegant as I just did minimal changes needed for the HRS example without caring about code duplication. As you can see if you compare with the HID mouse example it is basically the same thing, just that you provide the list of addresses (or just one address in this case) yourself instead of getting it from the peer manager.

Reply
  • 0

    Hi Joon,

    None of the pm_* APIs are relevant if you don't use bonding. I referred to pm_whitelist_get() just to see where it gets the whitelist (which is simply a list of addresses) from the peer manager and how to use it.

    You can see a very simple way to do whitelisting manually here:

    (this is not very elegant as I just did minimal changes needed for the HRS example without caring about code duplication. As you can see if you compare with the HID mouse example it is basically the same thing, just that you provide the list of addresses (or just one address in this case) yourself instead of getting it from the peer manager.

Children
No Data
Related
Terms of service