
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Email to a Friend
- Printer Friendly Page
- Report Inappropriate Content
Read Bluetooth® service characteristic using its UUID – KBA235669
Version: **
Note: This article is applicable only to Bluetooth® host stack library.
1. Read Bluetooth® characteristic data using its UUID
To read any data using its UUID or “by type”, send a read-by-type request using the wiced_bt_gatt_client_send_read_by_type API. See vol 3 (Host), part F: Attribute protocol, section 3.4.4.1 in the latest Bluetooth® specification for details.
Figure 1: Bluetooth® characteristic UUID
Consider the following example based on the ble-ess that is required to send the temperature data on the read-by-type request:
Code Listing 1
wiced_bt_uuid_t uuid; |
Once the read-by-type request is sent, a response will be sent back by the peer server which will be received in GATT_OPERATION_CPLT_EVT of the GATT event handler.
For example:
Code Listing 2
uint16_t len = 0; |
Note: The stack is developed in a way that the data is read in the GATTC_OPTYPE_READ_HANDLE event only even when you send a read-by-type request.
2. Get multiple handles with the same UUID
Note: If two or more handles have the same UUID, you can read only the one with the lowest handle.
Consider an example of user descriptors of temperature and pressure characteristics in the Environmental Sensing service.
Figure 2: User descriptors
Figure 2 shows that both have the same UUID, which is 2901. Now, if a temperature characteristic has a user descriptor with handle ‘D’ and the pressure characteristic has a user descriptor with the handle ‘14’, only the temperature user descriptor handle will be read.
2.1 Method 1
This is applicable if the peer device sends only one handle with the requested UUID per read-by-type request:
To get the next lowest handle, send another read-by-type request and update the starting handle in the read-by-type API to one more than the handle of the descriptor read.
For example:
Code Listing 3
wiced_bt_gatt_client_send_read_by_type(connection_id, 0x1, 0xFFFF, &uuid,(uint8_t *)&f,sizeof(f), GATT_AUTH_REQ_NONE); //for temperature descriptor wiced_bt_gatt_client_send_read_by_type(connection_id, 0x000B, 0xFFFF, &uuid,(uint8_t *)&f,sizeof(f), GATT_AUTH_REQ_NONE); //for pressure descriptor as 0x000B is 1+0x000A. |
2.2 Method 2
This is applicable if the peer device sends all the handles with the requested UUID per read-by-type request.
In this case, no additional implementation at the client side is required apart from simply sending the read-by-type request. See the “app_gatt_read_by_type_handler” in this code example to learn how this method is handled at the server end.
The pending_events flag indicates the number of remaining events for the concerned request.
For example:
Server (COM9) Client (COM4)
On reading the temperature descriptor (test1 as the sample value), the pending_events flag will be set to ‘1’, indicating that there is another event (pressure descriptor) that too matches with the UUID and starting and ending handle parameters in the read-by-type request. To check the value of the pending_events flag, use the following command in GATT_OPERATION_CPLT_EVT:
Code Listing 4
uint8_t pending; |
Therefore, the flag can be used to check whether there are more events to be read from the server corresponding to the same request.