ESP32 Forum

Anyone know what is the difference betweengatt server service table example and another "gatt server" example?

My problem is I can send use "esp_ble_gatts_send_response" & "esp_ble_gatts_send_indication" in the gatt server example,

but I can't use esp_ble_gatts_send_response in the service table example, it will show "E (14681) BT: Sending response failed
"

Below is the only code I added on top of the service table example code, it shows the error when I read the sensor location.

E (104789) BT: GATTS_SendRsp conn_id: 4 waiting for op_code = 00
E (104789) BT: Sending response failed

@dhs2017
Did you find the solution? I am also facing the same issue with the same example. Any help will be appreciated.

No, I give up, i turn out used another gatt server example and completed my task.

At a guess ... I think the distinction is as follows ...

When we are being a GATT server, we receive requests from data from clients. The data our server manages is contained in a unit called a "characteristic". In the ESP-IDF APIs, we have the ability to receive events and process those events when they arrive. For example, one event is a request to return a value for a characteristic read. In one design/implementation, it is your responsibility to receive the event and handle it in any way you see fit ... which might include describing the response to send back to the client.

In another design, the ESP-IDF provides that handling code for you in the form of a mapping table where the value of the characteristic is stored in the table and when a client request arrives, the ESP-IDF responds automatically to the caller with the current value in the table. I think both of these APIs are available to you and which one you decide to choose is a matter of taste and style.

For me, I like working in C++ and use a wrapper set of classes built around the ESP-IDF to try and hide the majority of the lower level complexities.

dhs2017 wrote:Below is the only code I added on top of the service table example code, it shows the error when I read the sensor location.

E (104789) BT: GATTS_SendRsp conn_id: 4 waiting for op_code = 00
E (104789) BT: Sending response failed

Code: Select all

  
case ESP_GATTS_READ_EVT:
 		memset(&rsp, 0, sizeof(esp_gatt_rsp_t));
      		rsp.attr_value.handle = heart_rate_handle_table[HRS_IDX_BOBY_SENSOR_LOC_VAL];
       		rsp.attr_value.len = sizeof(body_sensor_loc_val);
       		rsp.attr_value.value[0] = 0x01;
       		esp_ble_gatts_send_response(gatts_if, param->read.conn_id, param->read.trans_id,
		ESP_GATT_OK, &rsp);

PROBLEM_1
Check the response type of the characteristic in your attribute table if it is response by app or auto reaponse:
or This will determine if you are the one handling the response or the bluetooth stack will do this for you.

PROBLEM_2
Also why are you hardcoding the handle? It is not necessary that this is the handle being read because for any gatt server read event it will read this handle irregardless if the user wants to read another characteristic or descriptor.

Try: Since during the discovery procedure the central device knows the handles of the data the gatt server exposes, if the central reads characteristic X and thus in the requests to read it by its handle Y that describes X but you send handle Z as response(That you have hardcoded), I believe an error may happen.

PROBLEM_3 This length will always be 4 bytes as you are reading the size of the enumeration entry in the heart rate database. Even if the length of the data is longer. You should get the sizeof the data, not by the sizeof its entry number in the the database.

Correction: This code is valid if the entry is a single variable and not an array or struct for body_sensor_loc_val .

Thanks for the hints !

Also, when in mode ESP_GATT_AUTO_RSP, you can use esp_ble_gatts_set_attr_value to change the characteristic values you declared at init.

You can also use esp_ble_gatts_send_indicate with the conn_id handle you get on ESP_GATTS_CONNECT_EVT until a ESP_GATTS_DISCONNECT_EVT, you will then have realtime update on your connected device.