This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Connect a peripheral always with the same central when an event is produced

Hi,

I am developing an application that needs to activate a relay on a central device when an event occurs on the peripheral device.
The peripheral will always connect to the same
central device.
I need direct communication because there will be more central-peripheral modules with the same functions in the vicinity.
I have studied the example "ble_app_hids_keyboard" and I see that it uses whitelist.
After reading several articles on DevZone, I can't quite understand how data is entered into lists (whitelist_set ()).
Is it possible to use direct communication with the same central device without using whitelist?
How do I enter the ID of the central device in the peripheral the first time? I can use a switch the first time to syncronice peripheral/central if it is necessary.
Both the peripheral and the central are powered by batteries.
Once the ID of the central device has been entered in the peripheral, when changing the batteries, will the ID of the central device disappear on the peripheral?
In this case, is it necessary to use an external E2PROM to save the ID or is it saved directly to the internal flash?

Thanks in advance and Merry Christmas
Parents
  • Hi,

    Whitelisting is not required, but it does enable filtering of connection requests at the HW level, which means that connection requests coming from "unknown" devices will get ignored automatically. The other alternative is to implement a custom filtering mechanism at the application-level from the BLE_GAP_EVT_CONNECTED event to see if a known device has connected, and if not, immediately terminate the connection.

    The address information needed to populate the whitelist is exchanged during the bonding procedure, and this information is stored persistently in internal flash by the Peer manager module.

    It sounds like you can re-use most of the existing whitelist handling in the keyboard example for this. In this example you press button 2 to start advertising without whitelist (when you want to allow a new device to connect).

    In this case, is it necessary to use an external E2PROM to save the ID or is it saved directly to the internal flash?

     The information is stored in internal flash, and preserved across reboots. The Peer manager module manages the flash storage for you.

    Best regards,

    Vidar

Reply
  • Hi,

    Whitelisting is not required, but it does enable filtering of connection requests at the HW level, which means that connection requests coming from "unknown" devices will get ignored automatically. The other alternative is to implement a custom filtering mechanism at the application-level from the BLE_GAP_EVT_CONNECTED event to see if a known device has connected, and if not, immediately terminate the connection.

    The address information needed to populate the whitelist is exchanged during the bonding procedure, and this information is stored persistently in internal flash by the Peer manager module.

    It sounds like you can re-use most of the existing whitelist handling in the keyboard example for this. In this example you press button 2 to start advertising without whitelist (when you want to allow a new device to connect).

    In this case, is it necessary to use an external E2PROM to save the ID or is it saved directly to the internal flash?

     The information is stored in internal flash, and preserved across reboots. The Peer manager module manages the flash storage for you.

    Best regards,

    Vidar

Children
No Data
Related