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.
