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);

[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.