Sending more than 20 bytes with BLE
Sending more than 20 bytes with BLE
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
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
Re: Sending more than 20 bytes with BLE
Howdy,
Is your ESP32 application a BLE client (central) or a BLE server (peripheral)?
Is your ESP32 application a BLE client (central) or a BLE server (peripheral)?
Free book on ESP32 available here: https://leanpub.com/kolban-ESP32
Re: Sending more than 20 bytes with BLE
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 ?
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 ?
Re: Sending more than 20 bytes with BLE
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).
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).
Free book on ESP32 available here: https://leanpub.com/kolban-ESP32
Re: Sending more than 20 bytes with BLE
Yes exactly. This schematic represent well what i want to do :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).
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 ?
Re: Sending more than 20 bytes with BLE
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.
Re: Sending more than 20 bytes with BLE
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.chegewara wrote: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.
John A
Re: Sending more than 20 bytes with BLE
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 workschegewara wrote: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.
Re: Sending more than 20 bytes with BLE
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
https://github.com/nkolban/esp32-snippets/issues
-
- Posts: 59
- Joined: Thu Aug 17, 2017 5:40 pm
Re: Sending more than 20 bytes with BLE
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.
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.
Who is online
Users browsing this forum: Baidu [Spider], Bing [Bot] and 97 guests