Bluetooth client incoming buffer size

General Discussion
1

What is the max. size of the Bluetooth byte buffer used to store the incoming bytes? I'm trying to assess if there is a risk of buffer overflow, out of memory exception or anything alike if I'm not fast enough to read the BT client's data on the phone.
I'm now using a 100 ms timer to check if there are any data waiting to be read from the BT client. My BT server is an ESP32 using classic BT SPP. Commands and responses are serialized JSON objects. Some of those strings can be up to 2 KB in size.
Sofar I haven't seen any problems, but I prefer to be rather safe than sorry.

2

Hi

You are using Classic BT and not BLE, so if your setup is actually working as expected, that's fine. The golden rule about speed - less is more. Make sure the time interval is sensible for the task in hand. If you are trying to display values on a phone and they are updated every 100ms, your eyes will not be able to tolerate the changes.

Only send values, no decoration or titles, to keep the data as small as possible.

3

We don't impose a limit on the buffer size from the App Inventor side. However, a quick read through of the Android Bluetooth stack suggests to me that this is something negotiated between the devices and the maximum size of the buffer is 64 kB, so you're probably in the clear.

4

@ChrisWard: my setup is working. I scan the BT receiver only every 100 ms when I expect a response (i.e. after sending a command) to avoid delays and avoid the risk of running out of buffer space. When nothing is going on, I scan every 500 ms.
Not every screen requires "live updates". But some screens require results related to multiple commands and consequently multiple JSON objects being returned. What I've measured so far is a round trip from the initial command to the final update using the responses from ESP32 of approx 400...500 ms. This includes

  • adding one or more commands to a list of items to be sent
  • actually sending the JSON strings to ESP32
  • ESP32 de-serialising the JSON stuff and executing the command
  • ESP32 serializing one or more responses to JSON strings and sending those using BT
  • MIT AI de-serializing the received JSON strings again and figuring out what to do with the results (such as updating global variables and making a particular screen visible
  • return to BT module and clean up
5

Thanks. Now I can sleep again :sleeping: