NUS service without service discovery

RE: NUS service without service discovery

John Waddell — Fri, 28 Aug 2026 19:59:26 GMT

Yes, you can bypass ble_db_discovery_start() if the peripheral’s GATT attribute handles are fixed and you already know the correct RX/TX handles. In that case, store the handles in your own structure and use them directly with the GATT client APIs.

For example, the TX/write characteristic can be used with ble_gattc_write_params_t, where you set conn_handle, handle, write_op, offset, and your data buffer. For reads, you can use sd_ble_gattc_read() with the known characteristic handle.

The important part is that these handles are only safe to hard-code if the peripheral’s GATT database is guaranteed not to change. Nordic’s documentation also notes that discovery is what ensures the client is using the correct attribute handles.

Also, if you need notifications from RX, remember that knowing the characteristic value handle is not enough; you normally need the CCCD handle and must write the appropriate CCCD value to enable notifications.

If you're also dealing with other hardware/setup work alongside the BLE project, choosing a reliable pressure washing company is a completely separate consideration, but for this issue I'd focus on manually assigning and using the GATT handles.

RE: NUS service without service discovery

Josef80 — Tue, 02 Mar 2021 11:13:10 GMT

I solved my problem with the following solution.

void bypass_discovery(ble_nus_c_t * p_ble_nus_c)
{
ble_nus_c_evt_t nus_c_evt;
memset(&nus_c_evt,0,sizeof(ble_nus_c_evt_t));

// the handle values of rx, tx, and ccd may be different in your project.
nus_c_evt.handles.nus_rx_handle = 16;
nus_c_evt.handles.nus_tx_handle = 20;
nus_c_evt.handles.nus_tx_cccd_handle = 21;
nus_c_evt.conn_handle = conn_hndl;
nus_c_evt.evt_type = BLE_NUS_C_EVT_DISCOVERY_COMPLETE;
p_ble_nus_c->evt_handler(p_ble_nus_c, &nus_c_evt);
}

I made the following changes in the BLE_GAP_EVT_CONNECTED case under the ble_evt_handler function.

case BLE_GAP_EVT_CONNECTED:

// err_code = ble_db_discovery_start(&m_db_disc, p_ble_evt->evt.gap_evt.conn_handle);
// APP_ERROR_CHECK(err_code);

bypass_discovery(&m_ble_nus_c);

RE: NUS service without service discovery

Susheel Nuguru — Mon, 01 Mar 2021 10:16:07 GMT

Harry,

It is a generic application logic that you create a stucture that has characteristic UUID and its handle value as two members. For all the characteristic your application knows, save one entry for each of them with the handle value. When you need to write something, you need to search for the appropriate handle value for the given characteristic.

simplest_struct {

uint16_t char_uuid;
uint16_t handle_value;
}

The logic of searching through all the available UUIDs to and getting its appropriate handle value should not be hard. I, unfortunately, do not have time to write the actual code

RE: NUS service without service discovery

Josef80 — Sun, 28 Feb 2021 19:01:34 GMT

please help me to overcome this problem.

thanks

RE: NUS service without service discovery

Josef80 — Thu, 25 Feb 2021 13:44:43 GMT

I know that I should map handle value, but I don't know how to do it.

RE: NUS service without service discovery

Susheel Nuguru — Thu, 25 Feb 2021 12:26:44 GMT

There is no standard structure that you can use to save the handle values. You need to create one that maps handle value to your characteristic.

RE: NUS service without service discovery

Josef80 — Thu, 25 Feb 2021 10:08:16 GMT

Thank you for your reply.

I mean, is there a specific structure to save the necessary values for each connection?

Which part of the code do I need to change to use these values to receive and send data? The ble_nus_c_evt_handler should be changed?

Could you share a code snippet for this issue?

RE: NUS service without service discovery

Susheel Nuguru — Thu, 25 Feb 2021 09:11:02 GMT

If you want to store anything persistently then you should use flash storage drivers or libraries.