Reading text from SD card and sending sms via AT commands (length issue)

Hey guys

Must first post so be gentle :slight_smile:

I am putting together a data logging project that consists of storing RFID tags to a text file on an SD card. Then at a certain time of the day, read the SD card contents and them as a sms message via AT commands.

I have achieved this successfully, however I hit a snag when the amount of text inside the .txt file reaches a certain length. Once this length is reached the SMS fails to send.

it doesn't seem to be an sms character limit issue as I can send over 160 characters.

Through testing the limits, it looks like issue occurs when the amount of text is longer than one line of the text editor notepad. (what's he on about you are asking...)

If I open the text file on a pc in notepad and turn off word wrap and type text until it goes all the way to the end of the first line. i can send this amount of characters successfully.

If add one more character so that it runs over to the second line, the sms fails to send.

The issue is not related to reading the text from more than one line as i can send if the text file has 10 lines of text.

This code snipped grabs the contents and puts it into a String 'Buffer'

 File TagInfo = SD.open("TagInfo.txt");

  //   if the file is available, read the file
  if (TagInfo)
  {
    while (TagInfo.available())
    {

      buffer = TagInfo.readStringUntil('*');
      Serial.println(buffer); //Printing for debugging purpose



      SendSMS();

    }
    TagInfo.close();

Here's the AT command Snippet that sends the content of 'buffer' (the text file contents)

GSMSerial.println("AT+CMGF=1");
    delay(200);
    // runsl();
    GSMSerial.print("AT+CMGS=\"");
    delay(200);
    // runsl();
    GSMSerial.print(phone_no);
    delay(200);
    // runsl();
    GSMSerial.write(0x22);
    GSMSerial.write(0x0D);  // hex equivalent of Carraige return
    GSMSerial.write(0x0A);  // hex equivalent of newline
    delay(2000);
    GSMSerial.print(buffer);
    delay(500);
    GSMSerial.println (char(26));//the ASCII code of the ctrl+z is 26

Any idea of what 'limit' i am hitting here ?

Cheers
Jonny

what's he on about you are asking...

Exactly, as notepad doesn't care about record length.

Any idea of what 'limit' i am hitting here ?

There are two possibilities. The first is that readStringUntil() doesn't bother checking that there is sufficient memory to create the String object, so it crashes when there is too much data. The second is that SendSMS() can't handle Strings that large. The first thing you need to do/prove is where the error is.

The second thing to do is to establish a smart upper limit on the amount of data that is to be in one text message, allocate a char array of that size, and stop using Strings. That means that you'll stop using readStringUntil(), too. There is NOTHING that it does that you can't do be reading one char at a time from the file.

Hey Paul

Thanks for the response, much appreciated.

Doing some more testing, readstringuntil seems to be handling the length fine as a Serial.Print of the string ‘buffer’ prints the whole contents of the file even if it’s over the apparent the sms send Limit.

Every read of a tag saves the same string content length so I think I will do as your second suggestion and find the limit and put some logic in to control how big the file gets before sending the message.

That or read each line at a time, send the message and read the next line and so forth. This way I don’t need to worry about length.

That or read each line at a time, send the message and read the next line and so forth. This way I don't need to worry about length.

I was thinking more along the lines of maybe 5 or 10 records per SMS, not one. But, whatever works for you.