The nRF52 use the same Mac Address execute ADV mode is interference on some mobile

[CFF.K]

Hi, 

My product continues adv mode after connected with mobile until the amount of connection is full. By the way, there are 4 connect handle in my product.

My client use Samsung Note 5 bonding to my product (nRF52), and then this mobile continues to connect the all connect handle of nRF52 result in the other mobile can't connect with the nRF52.

I figure out the Samsung Note5 will continue to connect with the same mac address of nRF52 after the mobile scan the same mac address of the bond list. No matter the mobile already connect with nRF52.

How could I fix this condition? Because this problem leads to the other mobile can't connect with my product while Samsung Note 5 connects with my product.

[Amanda Hsieh]

Hi, 

I'm not exactly sure I understand the question.

• Is the Android system initiating multiple connections to the bonded nRF device? Or is he using an app to scan? 
• How does Samsung Note 5 connect to the nRF52? Did it use nRF Connect? If not, do you see the same situation if you use the nRF Connect?
• What is the SDK/SD used? 

-Amanda H.

[CFF.K]

Hi,

• Is the Android system initiating multiple connections to the bonded nRF device? Or is he using an app to scan?
  Ans: I'm not sure your question, this problem doesn't focus on the nRF device. I consider the mobile will connect all devices when the BLE device broadcasts the same mac address on ADV mode. And the mobile use system executes to scan, it doesn't use the APP to Scan.

• How does Samsung Note 5 connect to the nRF52? Did it use nRF Connect? If not, do you see the same situation if you use the nRF Connect?
  Ans: I use the Bluetooth of System to choose the device name of ADV to connect nRF52. And then the mobile will bond with nRF52. This problem that mainly the nRF52 is the bond device. therefore, this none of nRF Connect. By the way, there is the HID service in the nRF52, so the mobile will auto bond procedure with the nRF52 device.

• What is the SDK/SD used?
  Ans: I use SDK 15.2.0, SD 6.1.0

[CFF.K]

Hi

I test 2 situations.

(1) Different Mac address of nRF52

Step1: I set BLE_ADV_EVT_FAST in adv type, and start to adv.

Step2: I change the mac address of the nRF52 after the mobile connects with nRF52.

Step3: The nRF52 starts adv. the mobile doesn't connect with this nRF52.

(2) Set BLE_ADV_EVT_DIRECTED in second adv packet

Step1: I set BLE_ADV_EVT_FAST in adv type, and start to adv.

Step2: I set BLE_ADV_EVT_DIRECTED in adv type after the mobile connects with nRF52.

Step3: The nRF52 starts adv. the mobile doesn't connect with this nRF52.

By the way, the directed peer address set other mac address in the BLE_ADV_EVT_DIRECTED.

I don't know this test could help you analyze this question.  and I don't sure this directed test is right. because I find many direct types in nRF52 ADV. Below these types:

#define BLE_GAP_ADV_TYPE_CONNECTABLE_SCANNABLE_UNDIRECTED 0x01 /**< Connectable and scannable undirected
advertising events. */
#define BLE_GAP_ADV_TYPE_CONNECTABLE_NONSCANNABLE_DIRECTED_HIGH_DUTY_CYCLE 0x02 /**< Connectable non-scannable directed advertising
events. Advertising interval is less that 3.75 ms.
Use this type for fast reconnections.
@note Advertising data is not supported. */
#define BLE_GAP_ADV_TYPE_CONNECTABLE_NONSCANNABLE_DIRECTED 0x03 /**< Connectable non-scannable directed advertising
events.
@note Advertising data is not supported. */
#define BLE_GAP_ADV_TYPE_NONCONNECTABLE_SCANNABLE_UNDIRECTED 0x04 /**< Non-connectable scannable undirected
advertising events. */
#define BLE_GAP_ADV_TYPE_NONCONNECTABLE_NONSCANNABLE_UNDIRECTED 0x05 /**< Non-connectable non-scannable undirected
advertising events. */
#define BLE_GAP_ADV_TYPE_EXTENDED_CONNECTABLE_NONSCANNABLE_UNDIRECTED 0x06 /**< Connectable non-scannable undirected advertising
events using extended advertising PDUs. */
#define BLE_GAP_ADV_TYPE_EXTENDED_CONNECTABLE_NONSCANNABLE_DIRECTED 0x07 /**< Connectable non-scannable directed advertising
events using extended advertising PDUs. */
#define BLE_GAP_ADV_TYPE_EXTENDED_NONCONNECTABLE_SCANNABLE_UNDIRECTED 0x08 /**< Non-connectable scannable undirected advertising
events using extended advertising PDUs.
@note Only scan response data is supported. */
#define BLE_GAP_ADV_TYPE_EXTENDED_NONCONNECTABLE_SCANNABLE_DIRECTED 0x09 /**< Non-connectable scannable directed advertising
events using extended advertising PDUs.
@note Only scan response data is supported. */
#define BLE_GAP_ADV_TYPE_EXTENDED_NONCONNECTABLE_NONSCANNABLE_UNDIRECTED 0x0A /**< Non-connectable non-scannable undirected advertising
events using extended advertising PDUs. */
#define BLE_GAP_ADV_TYPE_EXTENDED_NONCONNECTABLE_NONSCANNABLE_DIRECTED 0x0B /**< Non-connectable non-scannable directed advertising
events using extended advertising PDUs. */

Could you support an example for the direct packet of the adv packet?

[Amanda Hsieh]

Hi,

One of my last suggestion is:

Are you doing the directed advertisement on the same phone? You may try to disable the directed advertisement and see if you still get the same result. 

--

You could check the HID mouse/keyboard example to see how to do that. 

-Amanda H.

[CFF.K]

Hi Amanda:

I don't know how setting direct mac address of direct adv type? How could I set p_advertising->peer_address.addr in the adv_mode_next_avail_get() ?

Below is my setting:

m_advertising.adv_modes_config.ble_adv_directed_enabled = true;
m_advertising.adv_mode_current = BLE_ADV_MODE_DIRECTED;
err_code = ble_advertising_start(&m_advertising, m_advertising.adv_mode_current);
APP_ERROR_CHECK(err_code);

[Amanda Hsieh]

Hi Ken, 

See this message sequence chart.

When you start the directed advertisement you will get a BLE_ADV_EVT_PEER_ADDR_REQUEST event. There you will have to call ble_advertising_peer_addr_reply() with the peer address. Please see this post. You could set the address in the BLE_ADV_EVT_PEER_ADDR_REQUEST event case or give the mac address to m_advertising.peer_address (see the mac order in this post). 

-Amanda H.

[CFF.K]

Hi Amanda:

I follow your advice that the type of adv set direct mode, and the direct mac address set the Samsung's mac address. The result of the Samsung mobile doesn't reconnect with nRF52. The nRF52 was bonded with the Samsung mobile. I think the Samsung mobile reconnect when the nRF52 broadcast the type of adv is BLE_ADV_MODE_FAST.

[Amanda Hsieh]

Hi Ken,

Could you provide the sniff log? I would like the intended behavior from which side.

Could you also try other phones or OS versions? Do they also have the same behavior?

-Amanda H.