ESP32 Forum

I have a BLE Peripheral application which is waiting for characteristic read events. The event I am waiting for is ESP_GATTS_READ_EVT. On receipt of that, I issue an esp_ble_gatts_send_response(). In my unit testing, all was working. However, I had failed to test for longer data sized responses. It seems that if I try and respond with > 22 bytes of response payload, we get the error:

BT: attribute value too long, to be truncated to 22

logged to the console. However we don't get an error indication back from esp_ble_gatts_send_response() ... it returns ESP_OK and it is later in the logs that the error message is returned.

When the error occurs, I seem to see that we very quickly get a second (and then subsequent) ESP_GATTS_READ_EVT received.

When we look at an ESP_GATTS_READ_EVT we see that among its data structure properties is a field called "is_long". This is mysteriously documented in our docs as:

The value is too long or not

On the very first event to read the characteristic, the passed in value of "is_long" is 0 while on the subsequent events, we find that "is_long" has the value 1.

There are many guesses that can be made here ... they could be:

1. We can't have a characteristic > 22 bytes in length
2. We can have a characteristic that is > 22 bytes in length but somehow must "chunk" it into 22 byte parts.

If (2) is correct, then I'd like to have explained (so that I may then document for others) what the procedure should be for working with data lengths. Is there something "magic" about 22? Is this a dynamic setting?

http://community.silabs.com/t5/Bluetoot ... a-p/147729

You will see that per the BLE spec long reads and writes are chunked and packetized.

This is also sort of related to the answer you got here https://esp32.com/viewtopic.php?f=13&t=2235

Thank you sir. The article you reference seems like the help I needed. I will study it in great depth. Again, thank you. My plan is to try and write it up for other readers/ESP32 users in the future ...

I plan to try and cover the helper table that the ESP32 BLE designers have added, but I also want to try and capture other patterns such as direct calls to the published ESP-IDF BLE functions. Hopefully this will make it clearer to future readers. For example, I studied the BLE APIs to send data and I don't remember anywhere reading that we had to chunk data. That sounds/feels pretty important and should likely be included in the ESP32 API docs.

This will likely bring us to a philosophical consideration on documentation. For example, does (should?) using ESP-IDF BLE APIs required the programmer to have in depth comprehension of BLE protocols? My hope is not. For example, I can write apps that use the TCP/IP sockets APIs without having to understand the ICMP, IP, TCP wire formats, error handling, time to live and other considerations. While, of course, knowing these facts does no harm, my hope is that we can raise the abstraction and knowledge levels for general consumption.

Hi Kolban. Your question came at a perfect time. I just started writing gatt server functionality in my app. One thing that I've found very helpful is the iPhone app LightBlue. There is source code on github by Pluto-Y for an iPhone app clone called Swift-LightBlue. It is not quite complete and has some issues but has been useful to see what is needed to create an iPhone bluetooth app.

The link to the BLE doc posted earlier in this thread was very helpful in understanding what is going on. For now, it looks like folks that want to do BLE apps on the ESP32 will need to dig deep into the protocol.

I'm currently trying to figure out the "user type" characteristic value. This seems needed to get real time control of GPIO pins.

I very much look forward to your next youtube video on implementing BLE...

Robin

Howdy Robin,
Might I interest you in taking a look at this thread?

https://esp32.com/viewtopic.php?f=13&t=2330

My focus at the moment is:

1) Learn BLE
2) Encapsulate in C++ to make it easier

Very nice video. I used the nordic app as well but had some issues with it. Sometimes it is just too smart (like thinking a device that advertises that it is a heart rate monitor really is).

Robin