NUS service connect by MAC address

RE: NUS service connect by MAC address

davidz — Mon, 01 Jul 2024 17:32:49 GMT

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.

RE: NUS service connect by MAC address

Hieu — Fri, 28 Jun 2024 08:50:45 GMT

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.

RE: NUS service connect by MAC address

davidz — Fri, 28 Jun 2024 06:06:57 GMT

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.

RE: NUS service connect by MAC address

Hieu — Wed, 26 Jun 2024 13:15:28 GMT

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.

RE: NUS service connect by MAC address

davidz — Tue, 25 Jun 2024 21:05:34 GMT

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.

RE: NUS service connect by MAC address

Hieu — Tue, 25 Jun 2024 11:49:37 GMT

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?

RE: NUS service connect by MAC address

davidz — Tue, 25 Jun 2024 04:45:41 GMT

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

RE: NUS service connect by MAC address

Hieu — Mon, 24 Jun 2024 12:43:21 GMT

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