Bluetooth packets limited to 20 bytes

I've been having a play with the AT-09 4.0 BLE Bluetooth device. I was a bit concerned that it could only send 20 bytes at a time which means data is lost. I created this to cope with it. It takes the message, no matter how long it is, and cuts it into smaller pieces and reassembles it in my iPhone app. The description is in the code. The LongMessage string should begin with a $ and end with a #. The SendLongMessage function adds an additional # at the end of the string so the iPhone app knows that it's the end of the completed message.

The reason for the post is........ is there a better way of doing it?

void SendLongMessage(String LongMessage){
  /*
    The AT-09 can only send 20 bytes per message so it gets cut up. I cut the 
    message into 18 charcter segments long and sends them consectively. The way I configured 
    the iPhone app is to look for a $ initially and ending in a #. This sigifies the 
    beginning of the message. The next nessages jest end in a #. The final message ends in ## 
    which means the message is completed. The app adds the strings / substrings 
    together and displays the complete message.
  */
  softSerial.flush();
  LongMessage.trim();
  int Len = LongMessage.length(); //Length of the message to send
  int OldPos = 0; //Start position of substring
  int Leng = 18; //End position of the string
  String SubStr;

    while (SubStr.indexOf("#") == -1){
    Serial.print("\nSubStr- ");
    SubStr = LongMessage.substring(OldPos, Leng);
    OldPos = OldPos + 18;
    Leng = Leng + 18;
      if (OldPos + 18 > Len){
        Leng = OldPos - Len;
      }
    String NewStr = SubStr + "#";
    softSerial.write(NewStr.c_str());
    delay(50);  
  }
}

Since radio is unreliable, data might be lost, but not as a result of packet size.

I find it much simpler to avoid Strings, and use the simple and much more reliable C-string functions in the <string.h> library to packetize data.

For help on this forum post the complete code, preferably the smallest example that will compile, run and demonstrate the problem.

What about classic Bluetooth, WiFi, LORA?

A few remarks

Quite heavy on dynamic memory use with the Strings and substrings.

$ and # might appear in the text - may be you need a less common header / trailer ?

Including metada in a first header packet such as packet count and devise an encoding strategy if you come across the header or trailer symbol(s) in the data you want to send over.

Don’t trim. May be I do want to send the extra tab or spaces


Side note

In serial communication, the industry often uses custom framing techniques to ensure data integrity and reliable packet transmission. This typically includes using start and end markers (e.g., flags like 0x7E or 0xFF) to delimit packets, along with checksums (e.g., CRC or simple parity) to detect errors.

On serial lines Flow control mechanisms such as XON/XOFF or RTS/CTS are employed to manage data transmission rates and prevent buffer overflows.

While there isn’t a universal standard specifically for handling UTF-8 data over serial lines, some protocols, such as Modbus RTU or Serial Line Internet Protocol (SLIP), provide structured ways to send data over serial links. These protocols focus on ensuring correct framing and error detection.

For multi-byte UTF-8 handling, a common practice is to split data at byte boundaries, ensuring that no multi-byte characters are split between packets.