NUS service connect by MAC address

[davidz]

I am using nRF5 SDK v17.1.0.

Is it possible to connect a peripheral device by MAC address, and the device is advertising with a different UUID from the central device?

That is, the central device has NUS_C service enabled, and the UUID is different from the peripheral. The peripheral has a dynamic UUID, so that it is desirable to connect

with MAC address. The MAC address of the peripheral is known. 

I tested the connect by MAC address with NUS service enabled on the peripheral, but the central device can not find the peripheral. 

Connect by UUID works no problem when the peripheral uses a static UUID. 

The connection by MAC address code is as the following:

        err_code=nrf_ble_scan_filters_disable(&m_scan);
        APP_ERROR_CHECK(err_code);

        err_code=nrf_ble_scan_all_filter_remove(&m_scan);
        APP_ERROR_CHECK(err_code);


        err_code = nrf_ble_scan_copy_addr_to_sd_gap_addr(&m_mac_filter, target_mac_addr);
//        memcpy(&m_mac_filter.addr,target_mac_addr, 6);

        err_code = nrf_ble_scan_filter_set(&m_scan, SCAN_ADDR_FILTER, &m_mac_filter);
        m_mac_filter.addr_type = BLE_GAP_ADDR_TYPE_RANDOM_STATIC;    
        
        err_code = nrf_ble_scan_filters_enable(&m_scan, NRF_BLE_SCAN_ADDR_FILTER, false);
        APP_ERROR_CHECK(err_code);

[Hieu]

Hi davidz,

Scan and connect filtering by address is entirely possible. Your code looks correct too.

I know you are already using nrf_ble_scan_copy_addr_to_sd_gap_addr(), but could you please check if the address is inverted?

An easy way to test this is to add both the current version of the address and an inverted version of the address to the filter list and see if there is any difference.

Hieu

[davidz]

Yes I checked both inverted address already. The commented out code "//        memcpy(&m_mac_filter.addr,target_mac_addr, 6);" is actually the inverted address. Either direction does not work. Very strange. 

However, if I try to connect via BLE_GAP_EVT_ADV_REPORT event, then the central can connect to the peripheral, but then disconnect immediately. The debug info at the central showed the following:

<info> app: GAP connected.
<info> app: ATT MTU exchange completed handle 0x0
<info> app: GAP disconnected. conn_handle: 0x0, reason: 0x16

At the peripheral side, the peripheral showed "GAP disconnected reason 0x13". What could be the cause? 

The following is the code used at BLE_GAP_EVT_ADV_REPORT event at the central:

if (memcmp(target_mac_addr, p_adv_report->peer_addr.addr, sizeof(p_adv_report->peer_addr.addr)) == 0)
 {

          err_code=sd_ble_gap_connect(&p_gap_evt->params.adv_report.peer_addr,
                                 &m_scan_param,
                                 &m_connection_param, APP_BLE_CONN_CFG_TAG);
          APP_ERROR_CHECK(err_code);
                                  
  }

[Hieu]

The disconnection reasons follow standard Bluetooth Spec status codes. The codes are also documented here: S140 SoftDevice v7.2.0: Bluetooth status codes (nordicsemi.com)

Looks like the central is actively disconnecting from the peer. You mentioned some UUID change. Are there some logics in the application that check for a specific UUID on the peripheral's server?

[davidz]

I used the default NUS service. Does the NUS central device verifies UUID before it accepts NUS service? Since the peripheral has dynamic UUID that changes each time, if the central only accepts fixed UUID for NUS service, then it won't work. 

[Hieu]

The default implementation of the NUS Client requires that the Server has the NUS with its expected UUID, yes.

Refer to the ble_db_discovery_evt_register() call in ble_nus_c_init().

However, I just check the examples and even though the client searches for the UUID, it doesn't disconnect if the UUID is not found.

You might want to check for all places that trigger a disconnection in your application and see which part is the cause.

[davidz]

I have checked around, but can not find the reason that the central/client disconnects yet. 

Does the peripheral need to have scan response, so that the central can stay connected? I added scan response at the peripheral, but the central still disconnected like before. 

I will test adding back the NUS UUID at the peripheral side. 

[Hieu]

Scan response isn't required to maintain a connection, unless some specific application logic makes it so. I don't think that is a cause for disconnection.

I suggest adding some log before all the disconnect function call in your central app.

Just in case something is mixed up, the device that log disconnect reason BLE_HCI_LOCAL_HOST_TERMINATED_CONNECTION 0x16 is the one initiating the disconnect.

[davidz]

Thank you very much for the confirmation. 

After adding the logs, it turns out that the central indeed is disconnecting after it connects to the peripheral.

By disabling the disconnecting, the central can stay connected.