I'm building a BLE peripheral device using the ST BlueNRG-MS chip and need to implement a few features where I'm not really sure what's the right way to go. This is my first BLE project so maybe someone with a bit more experience could shed some light on the issue.

1. Let "known" devices connect automatically
While pairing should only be allowed in a specific device mode, an already paired device should be able to automatically reconnect.

My idea was that I have is that the device has to be discoverable all the time, and I store the address of the 10 last paired devices. So when a new device connects I check if its address is stored in this list and if not I refuse the connection. Or if in pairing mode, I add the new device to the list.

Question: At what point of the connection process can I do that? I assume I only get the EVT_LE_CONN_COMPLETE event in the user_notify callback. At what point is the connection to the central device established? If I don't call GAP_ConnectionComplete_CB() if the address is not in the list, would that work? It seems that the central device then still can see all the available service, but is just not able to read them. But after that the BLE connection seems broken and the peripheral is not visible anymore.

2. Read the name of the Central Device
Beside the phone's address I'd also like to store a human readable device name. How can I do that? I assume I have to use some GATT command to read the device name, but how can I now what I have to read? Is the device name always 0x2A00?

3. Automatic update interval for characteristics

Is it possible to use the BlueNRG API to have a automatic characteric broadcasting? Currently I do this manually by calling the function


for the corresponding characteristic but that's kinda cumbersome. Does the stack provide an automatic approach for this problem?

  • \$\begingroup\$ Doesn't seem to be a widely used chip... \$\endgroup\$
    – po.pe
    Jul 14, 2021 at 6:06

1 Answer 1


I'll write here what I've figured out so far, maybe someone can use it one day...

  1. The problem with new mobile phone OS is that they use random resolvable addresses so you cannot simply check the received address. Instead the address has to be resolved using the IRK (identity resolving key) and then add the device to the whitelist.

  2. The answer to the question is "yes", the device name characteristic is always uuid 0x2a00

  3. To use the aci_gatt_update_char_value() is the correct way to change/broadcast a characteristic to the connected central device.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.