How to read the Value below for ATT with only Handle (0x002a) but no UUID

How to read the Value below for ATT with only Handle (0x002a) but no UUID,as shown in the following figure

Parents
  • Hi,

    The handle is just a handle to the GATT table, and not standardized. In principle it can also change with a new versino of the device you are connecting to (it is normally automtically assigned). The normal way to get the handle is to perform a service discovery. I do not have any other methods to suggest. That said, there are some very specific use cases we have seen in the past where this may be usefull, and it is possible with the old SoftDevice and nRF5 SDK. If you are using that, you can refer to this thread.

  • As you said, in normal situations, UUID and ble_lbs.on_ble_evt can only be triggered; But I can receive the data shown in the picture using Cypress BLE4.1. The data in the picture is sent by Central BLE4.1 (Cypress BLE4.1 remote control). I can capture this data using Sniff 52840 and know that a handle has been assigned. Why is S132 of 52833 not working (the remote control car I made using 52833)?
    Static void ble_evt_handler (ble_evt_t const * p-ble_evt, void * p-context){
    Ret_code_t err_code;
    NRF-LOG-INFO ("ble_evt_handler:% d", p-ble_evt ->header. ev_id);
    Switch (p-ble_evt ->header. ev_id)
    In the above code, even if my remote control is activated, no information can be printed after I connect, but the connection parameter exchange information between them is printed out
    Is there any other triggering event for S132 when receiving data that does not display UUID? Can BLE4.1 transmit data like that? How should 52833 be compatible?

  • The Handle of 52832 is specified in order. This situation is where no service has been detected, making the Handle of this service characteristic value on the slave side the same as the Handle of the host, which can be viewed using Watch in Keil. This way, you can receive information from the host side's Handle.

  • Hi,

    I don't fully understand what you are doing and what is not working. Can you elaborate?

    Also, why can't you do a normal service discovery (if that is the problem)?

Reply Children
  • Can you back-track a bit and give a high level overview of what you are doing and why? Why don't do a service discovery to find the handles? Or am I missing something else? Please elaborate.

  • Normally, the handle is found through the service. However, Central does not send data according to service characteristics, but only according to handles.
    The following is the data code sent by Central. I changed the handle to 0x002a, and now I can also receive data on the peripheral end. Of course, Wireshark did not capture UUID; Note that the UUID in the attached image is an old Central device from our company:

    uint32_t ble_lbs_rc_data_send(ble_lbs_c_t * p_ble_lbs_c, uint8_t *status,uint8_t statalen)
    {
        VERIFY_PARAM_NOT_NULL(p_ble_lbs_c);

        if (p_ble_lbs_c->conn_handle == BLE_CONN_HANDLE_INVALID)
        {
            return NRF_ERROR_INVALID_STATE;
        }

        NRF_LOG_DEBUG("Writing LED status 0x%x", status);

        nrf_ble_gq_req_t write_req;

        memset(&write_req, 0, sizeof(nrf_ble_gq_req_t));

        write_req.type                        = NRF_BLE_GQ_REQ_GATTC_WRITE;
        write_req.error_handler.cb            = gatt_error_handler;
        write_req.error_handler.p_ctx         = p_ble_lbs_c;
        write_req.params.gattc_write.handle   = 0x2a;//p_ble_lbs_c->peer_lbs_db.led_handle;
        write_req.params.gattc_write.len      = statalen;//sizeof(status);
        write_req.params.gattc_write.p_value  = status;
        write_req.params.gattc_write.offset   = 0;
        write_req.params.gattc_write.write_op = BLE_GATT_OP_WRITE_CMD;

        return nrf_ble_gq_item_add(p_ble_lbs_c->p_gatt_queue, &write_req, p_ble_lbs_c->conn_handle);
    }

  • Hi,

    bao008 said:
    Normally, the handle is found through the service. However, Central does not send data according to service characteristics, but only according to handles.

    It sounds like there is an issue with the central then? And that this should be fixed there?

    That said, you can specify the handle directly as you have indicated as long as you know it. (The service discovery procedure is only there to find the services and characteristics, and the corresponding handles. After that, only the handles are used). For that, you can refer to the thread I linked to in my first reply.

Related