Sending more than 20 bytes with BLE

[Anh-Minh]

Hi,

I am currently developping an application, in which i want to read and write on ESP32 with Bluetooth Low Energy ( BLE ). I am currently working with the C++ library from Mr.Kolban which is very interesting ( thank you !! ).

I want to send commands through BLE, which are often more than 20 bytes. How can i do to split my data, and receive an entire command ?

Thank you

[kolban]

Howdy,
Is your ESP32 application a BLE client (central) or a BLE server (peripheral)?

[Anh-Minh]

Hi,

My ESP32 is a server ( central ), and i want to interact with a smartphone ( client ), in which i will send the differents commands.
Later, i want to read data from the ESP32 too, does it changes anything ?

[kolban]

Ive never been able to get my mind around (properly) the phrases client/server and peripheral/central. See the following:

https://docs.mbed.com/docs/ble-intros/e ... LEInDepth/
https://devzone.nordicsemi.com/f/nordic ... ient-slave

I think in our story the ESP32 will be the server (it owns data). It will also be the peripheral (the device which performs the advertising). The phone will be the client (it requests data from the server) and it will also be the Central (the device which determines when and if to connect to a peripheral).

[Anh-Minh]

I think in our story the ESP32 will be the server (it owns data). It will also be the peripheral (the device which performs the advertising). The phone will be the client (it requests data from the server) and it will also be the Central (the device which determines when and if to connect to a peripheral).

Yes exactly. This schematic represent well what i want to do :



The command i want to send is mostly >20 bytes. Can i program the ESP32 to receive different packages of 20bytes, and then concatenate them after ? Do you have another solution ?

[chegewara]

Unless you dont need to send messages longer than about 500-512 bytes you dont have to worry, library will take care of it (have not tested longer messages). Messages longer than mtu are fragmented/defragmented, the issue is with notifications/indications. Those messages are truncated to (mtu - 3) bytes.

[fly135]

Unless you dont need to send messages longer than about 500-512 bytes you dont have to worry, library will take care of it (have not tested longer messages). Messages longer than mtu are fragmented/defragmented, the issue is with notifications/indications. Those messages are truncated to (mtu - 3) bytes.

Well that explains a lot. When I first started on the BLE I was thinking that messages couldn't be that long as well. I had reversed engineered the original product with a BLE sniffer (easier than getting answers to my questions about the original product), and saw that it had a message format for accumulating a larger message from small ones. Then when the new phone app designed for my project was communicating with my software it was sending larger messages without the accumulation protocol. I assumed that the stack was taking care of that and stopped thinking about it. Nice to see an actual answer.

John A

[Anh-Minh]

Unless you dont need to send messages longer than about 500-512 bytes you dont have to worry, library will take care of it (have not tested longer messages). Messages longer than mtu are fragmented/defragmented, the issue is with notifications/indications. Those messages are truncated to (mtu - 3) bytes.

When i want to write value on my ESP32 with nRF connect app, only the first 20 bytes are received. I don't really understand how it works

[chegewara]

Ive no problems with this before but it seems to be bug. Can you open new issue on github?
https://github.com/nkolban/esp32-snippets/issues

[JoaoLopesF]

I had the same problem of he limit of Ble payload .
My Mobiles Apps need more than this ...

In my projects with ESP32, for the Ble connection, I use the C routines of pcbreflux ( ble_uart_server): (thanks pcbreflux for it).

With Esp-IDF 3.0, I migrated everything to C++ except the pcbreflux ble C routines (I have a C++ wrapper class for them - thanks Kolban I seen how do callbacks in your Ble C++ lib). I made small modifications in code of pcbreflux, not in core, but in interfaces and callbacks to C++ class.

For the Android and iOS App programming, I based in the Nordic examples, which worked well.

Ble has this limit, but you treat the long messages as several messages within the limit, dividing them when sending and joining them when receiving by yourself

What I do to work with larger messages:

  - All messages (mobile and esp32) ends with a specific character (in my case \n)

  - On Android (Java and now Kotlin) or iOS (swift 4):
    - When sending if the message is large,
     I split it in pieces and send it (with a small delay forced between them in Android, IOS not need it)
Tip: If I have more than one message to send in moment, I just join it with delimiter \n and send all to one call of routine that split it
to Ble, generating few messages instead call it for each message.

  - In Esp32, idem only that does not need the delay

  - When receiving messages (app or Esp32), I work with a buffer, and only process the messages upon receiving a \n (since the message can be divided into several pieces)

Now I working to balance use of Esp32 cpu cores. The work of split/join ble messages is now to in task in CPU 1, leaving CPU 0 to system (Ble, timers (tg), etc)

My idea is when I have time, put together a complete solution:
- Android and iOS app and Esp-IDF and put in github.
 
Hope this helps.