Connect to device in 2 different ways to distinguish between masters

RE: Connect to device in 2 different ways to distinguish between masters

ovrebekk — Mon, 26 Jul 2021 07:34:35 GMT

When you configure the advertising payload you can set the handle, and you just need to make sure that you use two unique handle numbers that you can refer to later.

Below is an excerpt from the ble_app_uart example, showing how the handle is set:

In most examples the handle is just set to 1, since there is only one type of advertise packet defined.

In your case you can just use 1 and 2.

Best regards
Torbjørn

RE: Connect to device in 2 different ways to distinguish between masters

DS4 — Sat, 24 Jul 2021 22:04:46 GMT

Thanks, seems like a good solution, and I would like to try it.

Can you tell me how can I read the handle number from my advertisement packets?

Its location, or an API I can use to get/set it.

RE: Connect to device in 2 different ways to distinguish between masters

ovrebekk — Fri, 23 Jul 2021 06:32:26 GMT

You make a fair point, there is a risk if the master connects to you just as you are changing advertise type.

I took a closer look at the ble_gap_evt_connected_t struct:

/**@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;

It seems that when the master connects to you you will get the advertising handle and data corresponding to the advertising packet that the master connected to.

This means that if your two types of advertising use two unique advertising handles, you should be able to safely determine which advertising packet the master responded to by looking at this field in the connected event.

Please note I haven't tested this myself, since your use case is not a very common one.

Best regards
Torbjørn

RE: Connect to device in 2 different ways to distinguish between masters

DS4 — Thu, 22 Jul 2021 06:22:31 GMT

This solution sounds great, but I feel it might not be prefect.

"On the slave side you will need to reconfigure the BLE device address periodically. Whenever the connected event occurs you know that the master that connected to you did it over the currently configured BLE device address (which you can map to MAC1 and MAC2)."

My concern about this solution is of a race.

By the time the connection ISR occurs, I may already change the system MAC.

Is there a way to get this 100% accurate?

Maybe a different ISR? Or a way to read the destination MAC address from the masters packets? Or any other way..

Thanks

RE: Connect to device in 2 different ways to distinguish between masters

ovrebekk — Mon, 19 Jul 2021 11:41:54 GMT

The most reliable way to do this is to change the BLE device address on the advertising side, instead of just changing a value in the advertising payload.

When the application on the master side tells the stack to establish a connection you use the BLE device address to decide which advertiser to connect to, so this is the most reliable way to ensure that the master connects to the right advertiser.

On the slave side you will need to reconfigure the BLE device address periodically. Whenever the connected event occurs you know that the master that connected to you did it over the currently configured BLE device address (which you can map to MAC1 and MAC2).

Best regards
Torbjørn

RE: Connect to device in 2 different ways to distinguish between masters

DS4 — Sun, 18 Jul 2021 06:27:55 GMT

Hi thanks again,

The peer address is how the master saved my address?

What I meant is supposedly I am advertising alternating "MAC1" and "MAC2".

Started advertising.

Salve gets an ISR connection.

How can the slave know (100%), if this ISR master connected through MAC1 or MAC2?

Thanks.

RE: Connect to device in 2 different ways to distinguish between masters

ovrebekk — Fri, 16 Jul 2021 08:23:44 GMT

When you establish a connection the BLE_GAP_EVT_CONNECTED event will occur, and in this event you can read out the BLE address of the peer device that you just connected to.

Assuming the ble_event_handler is implemented as in the standard examples you can get access to the peer address like this:

p_ble_evt->evt.gap_evt.params.connected.peer_addr

Best regards
Torbjørn

RE: Connect to device in 2 different ways to distinguish between masters

DS4 — Thu, 15 Jul 2021 14:12:07 GMT

Thanks!

Propriety characteristic can definitely work.

But our goal is to keep it simple on the master side, and do the work on the slave.

(We considered scanning and reading the masters ID characteristics)

But before that would like to test the alternation method.

For that it is important for me to know through which MAC the master's were initially connected.

Can I get that info? if yes, how?

RE: Connect to device in 2 different ways to distinguish between masters

ovrebekk — Thu, 15 Jul 2021 12:07:54 GMT

Can't you just have MASTER1 and MASTER2 send a data packet once the connection have been established, to identify themselves to the slave as either MASTER1 or MASTER2?

To do this you can set up a proprietary characteristic for this specific purpose, and the master can send a data update on this characteristic.

It should also be possible to do as you say and have the slave alternate between two advertise packets, but this would make the code on the slave side a bit more complex.

Best regards
Torbjørn