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.
