-
Hello together, I am working on a BLE remote control interface with a flexible web interface (web bluetooth) to allow to control actions on the ESP via a browser. See https://github.com/Tirus42/Arduino-BLE-Remote for details, the send operation is located there: https://github.com/Tirus42/Arduino-BLE-Remote/blob/6832e6bfcbdc5fab2857ab38abc1bb5b38dc6e3b/arduino-library/src/BLELedController.cpp#L489. For this, i send some data (in my example about 1,5kb) to the connected client by using This works, as long as the whole data block is not too large, I assume that the BLE stack contains a send queue which will be overloaded by to many packets. I saw in a example (https://github.com/h2zero/NimBLE-Arduino/blob/master/examples/Refactored_original_examples/BLE_server_multiconnect/BLE_server_multiconnect.ino Line 139) that a simple delay is used. But this seems not to be a reliable solution. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 3 replies
-
You should wait for the |
Beta Was this translation helpful? Give feedback.
-
Thank you again for your response. I tried this approach but run into the next problem. By testing this setup I got two different error cases:
I did see that in the current master branch the methods got a additional NimBLEConnInfo parameter to send data to only one client. Also I observed that the onStatus() callback always comes from the call stack inside the indicate() function. |
Beta Was this translation helpful? Give feedback.
-
I solved the problem by using functions from NimBLE directly instead of the Arduino wrapper. I use ble_gatts_notify_custom() to send the data block to each subscriber and handle the return code of the function call. This also allows to handle each subscriber individually even when all listen to the same characteristic. |
Beta Was this translation helpful? Give feedback.
You should wait for the
onStatus
callback to signal when its safe to send another packet. Note that you will not be able to send anymore than 512 bytes per connection event, which is determined by the client.