This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Find a service characteristics' handles

Hello,

I am implementing a custom service with several characteristics, one of which is the current temperature. A second characteristic notifies the user if the temperature is above a predefined level, so I would like this second characteristic to be able to read the temperature characteristic's value.

I can get the temperature value this way: ble_gatts_value_t test_value; sd_ble_gatts_value_get(p_my_service->conn_handle, 29, &test_value); uint16_t temperature_value = *(test_value.p_value);

The 29 is the temperature characteristic handle, which I found by debugging the program and reading the handle number when the characteristic was initialized. How do I find this value programmatically instead of hardcoding it? Thanks.

Other info: SDK 13.0 PCA10040 Eclipse 4.5.2

EDIT: Specifically I was trying to find the service characteristic handles on the server itself (more a problem of where data is stored than how the ble communication works). I just found a blog post that basically answers my question here

  • There is something called "GATT Service Discovery" procedure where GATT Client "interrogates" the Server and builds its own map/tree of Services/Characteristics/Descriptors etc. Few things to note about the procedure:

    • Theoretically GATT Client should do this every time but there are exceptions listed by the specification and some proprietary tricks. Firstly GATT Server can indicate that it's static meaning it will never change numbers and presence of GATT handles. Then Client can cache the handles as long as it wants (most of mobile devices do it for instance). Secondly if you have control over GATT Client layer (which is the case of custom FW on nRF5x device but not the case of mobile app sitting on top of Android or iOS API and BT stack) then you can also provide the handle "out-of-band" e.g. in advertising data or simply hard-code it. But the responsibility is on client, in all GATT methods (commands exchanged over BLE link) only handle numbers are used and if you by mistake target wrong handle you can either get error or even worse it can work but on wrong value handle.
    • Once you do GATT Service Discovery there is no sequence defined (neither recommended) by BT SIG Core specification. Instead you have list of GATT Methods available and it's up to GATT Client to enumerate GATT Server handles' space (which is theoretical from 1 to 65,535 but according to GATT chapter of BT SIG Core spec it must be continuous so once you reach end you are sure there are no more valid handles till 0xFFFF).
    • So you can find pretty much any GATT Characteristic Value handle or CCCD in 3 simple steps (see

    There are also examples in nRF5 SDK (see Soft Device sequence charts here, here and here), there is also way to use pretty bulky but in general reliable module components\ble\ble_db_discovery. However if you want to be optimal and don't care about all the handles (just looking for specific one) you can find some optimized methods in older SDKs (see e.g. this Q&A).

  • Well glad you've found the answer, let me comment anyway:)

    • Finding internal handles of GATT Server is typically useless for the app because it uses own references (obtained from the stack at the time of Server provisioning) for custom objects and standard objects (pre-created by the stack e.g. to be compliant with BT SIG Core GAP&GATT) you should not care. If you do you can see them easily by running BLE sniffer during GATT Service discovery procedure or you can go harder way and try to explore stack API functions to read all handles and then guess what they are (some stacks might not support this at all).
    • For Nordic SD you have found the answer for custom GATT objects above, that is valid.
    • It might be useful to go through some more complex BLE training (and maybe not just once;), I do recommend this one directly from BT SIG (it covers only BT LE 4.0 but it remains valid).
Related