Is there a way to know the device information that sent the connection request?

[sdi_kei]

Hello.

I used to ask this question to DevZone. However, I made a new question because it is locked and I cannot ask additional questions.

My purpose is to know the bonded device information that sent the connection request. Does this answer mean that you can get information about bonded devices by using a white list?
Or is it possible to know the device information only after connecting?

I really want information such as the MAC address of the other party before connecting.
Please answer.

Best regards.

[Edvin]

Hello,

Does this answer mean that you can get information about bonded devices by using a white list?

When you use a whitelist, it means that only devices that are already in your whitelist will be able to connect. Any other connection requests will be refused. If the device is already in your whitelist (or if you don't use a whitelist) the peripheral have to connect to all incoming connection requests, no matter what. This is decided in the Bluetooth specification. However, you can choose to disconnect after the connection has been established.

So the only way to refuse connections from devices is to use a whitelist, and not include that specific device in the whitelist. 

Whitelists are typically used when you are bonded with at least one device.

Best regards,

Edvin

[sdi_kei]

Hello.

As a premise, as a flow of connecting BLE, I think that the central device issues a connection request and the peripheral device returns a connection response to connect. Is this recognition correct?

What I want to know is that I want to get the information of the central device by the communication (I think it is a connection request) before the connection is made. This is because you want to see how many central devices around you are trying to connect.

Edvin said:

So the only way to refuse connections from devices is to use a whitelist, and not include that specific device in the whitelist. 

If I use whitelist and refuse to connect from a device, can I get information about that device?

Best regards.

[sdi_kei]

Hello.

I didn't know that the peripheral couldn't reject the connection request.

Edvin said:

The central issues a connection indication (sometimes called connection request), but the peripheral can not deny a connection request.

Is this a Bluetooth specification? Is it an SDK specification?

Excuse me, let me restate what I want to do.

1. I want central device information before connecting.
2. I want to get information from multiple devices and connect to the device I want.
3. I want to make the maximum number of connected devices to one.

Suppose you use a white list to reject a connection request from a central device. Is it possible to return a connection request after that?

In summary, does it mean that you can't get information about your central device without making a connection under any circumstances?

Best regards.

[Edvin]

sdi_kei said:

Is this a Bluetooth specification? Is it an SDK specification?

Bluetooth specification. Not 100% sure of the official name (connection request / indication), but a peripheral is not able to deny a connection request.

sdi_kei said:

In summary, does it mean that you can't get information about your central device without making a connection under any circumstances?

Yes. That is correct. The connection request holds some information about the central address and the connection parameters, but this information will not be available for the peripheral before the connection is made (because it isn't time to do so). 

I believe you got off with the wrong start for this application. Perhaps you can describe what your application is doing, and we can discuss some possible ways to aquire this?

Best regards,

Edvin

[sdi_kei]

Hello.

I had a wrong idea because I had only a rough idea of Bluetooth communication. I found that I couldn't get the information. Thank you very much.

We're discussing some possible ways, but what exactly do we do?

Best regards.

[Edvin]

sdi_kei said:

We're discussing some possible ways, but what exactly do we do?

Depends on what you want to acheive... ?

[sdi_kei]

Hello.

I found out that I couldn't get the device information in the connection request, so I'm thinking of getting the information in the event "BLE_GAP_EVT_CONNECTED" at the time of connection.
You said that you can get device information after connecting, but is it correct for connected of p_ble_evt? You can get the device address here, but how do you get the Tx Power and RSSI information?

Best regards.

[Edvin]

This is the information you have in the BLE_GAP_EVT_CONNECTED event:

/**@brief Event structure for @ref BLE_GAP_EVT_CONNECTED. */
typedef struct
{
  ble_gap_addr_t        peer_addr;              /**< Bluetooth address of the peer device. If the peer_addr resolved: @ref ble_gap_addr_t::addr_id_peer is set to 1
                                                     and the address is the device's identity address. */
  uint8_t               role;                   /**< BLE role for this connection, see @ref BLE_GAP_ROLES */
  ble_gap_conn_params_t conn_params;            /**< GAP Connection Parameters. */
  uint8_t               adv_handle;             /**< Advertising handle in which advertising has ended.
                                                     This variable is only set if role is set to @ref BLE_GAP_ROLE_PERIPH. */
  ble_gap_adv_data_t    adv_data;               /**< Advertising buffers corresponding to the terminated
                                                     advertising set. The advertising buffers provided in
                                                     @ref sd_ble_gap_adv_set_configure are now released.
                                                     This variable is only set if role is set to @ref BLE_GAP_ROLE_PERIPH. */
} ble_gap_evt_connected_t;

(in addition to the conn_handle).

The event doesn't contain any information on RSSI. To get the RSSI, please see this and similar threads on Devzone.

The TX power that the central uses isn't available information on the peripheral. If you need that, you need to set this up in a proprietary way. You need to add a service that the central can write it's TX power into. The central doesn't broadcast this in any way.

Best regards,

Edvin

[sdi_kei]

Hello.

Thank you for the information.
I am going to use it as an example.

Best regards.