Incoming SMS's not being recognized by IDE (timeout) [Solved]

So here’s an interesting one. I loaded the Hologram-provided sample sketch for SMS-receive & act (attached). (Howto send data to dash pro? - #6 by zheng). Works swell. I added a single line to send a message back to the Cloud (“SMS receipt confirmed!”). The issue: The sketch works fine for several hours, but then seems to somehow time out, no longer recognizing incoming SMS’s. The SMS’s are indeed making it to the Dash – they report fine via the IDE serial monitor, but the sketch just seems to ignore them. Thoughts?

Other maybe-useful background & notes:
– LED continues to flash every 5 seconds; that, plus the fact that I’m seeing the SMS’s on the serial monitor, tells me the Dash is still running, and of course that the SMS’s are making it to the Dash. No network timeouts that I can see!
– My device is stationary, with a good connection to AT&T Mobility here in Michigan.
– Resetting the Dash (button near antenna) seems to reset some radio stuff, but the lack of SMS recognition continues.
– Resetting the Dash (middle button) brings everything instantly back to normal for a few hours.

// EFFECTS: Strips away the length number from the payload as it's not needed.
String stripOffLengthNumber(String payload) {

  int index = 0;
  while (payload[index] == ',') {
  while (payload[index] != ',') {

  payload.remove(0, index);

  return payload;

void setup() {
  /* Serial Setup */
  SerialUSB.begin(9600); /* USB UART */
  SerialCloud.begin(115200); /* Konekt Cloud */
  delay(4000); /* Delay 4 seconds to wait for Usb Serial to Init.*/

  /* Setup Konekt Dash */
  Dash.pulseLED(100,5000); /* Set the User Led to flash every 5 seconds */

  /* Serial Print Info */
  SerialUSB.println("Konekt Dash SMS Receiving Example Started!");
  SerialUSB.print("Using Boot Version: ");
  SerialUSB.println(Dash.bootVersion()); /* Print Dash Bootloader Version */
  SerialCloud.println("Hello, World!"); /* one-time message */

String tempBuffer = "";
String payload = "";
bool foundSMS = false;

void loop() {
  char currChar;
  /* the code here will pass data between Cloud<-->UART */

  while (SerialCloud.available()) {

    currChar = (char);

    // check if the current buffer hits the SMSRCVD code.
    if (!foundSMS) {

      if (tempBuffer == "SMSRCVD") {
        foundSMS = true;
    // If it received the SMSRCVD code, the payload will get populated until
    // we get a \n.
    else if (currChar == '\n'){

      SerialUSB.println("\nSMS received: ");

      payload = stripOffLengthNumber(payload);

      SerialCloud.println("SMS receipt confirmed!");    // This is the only new line added by me.

      // reset foundSMS and the payload for the next iteration.
      foundSMS = false;
      payload = "";
    else {

    // Only keep a sliding buffer length of size 7
    // (need to only check for SMSRCVD).
    if (tempBuffer.length() >= 7) {
       tempBuffer.remove(0, 1);

    // add latest char to our buffer.


Hi Michael,
Can you add this after the

if(currChar == 0) { continue; }

When the modem resets, you may end up with a null in the buffer and the Arduino String functions don’t handle this correctly and the string gets corrupted. I’ll make sure that this is added into our example code.

Thanks, Reuben! Makes sense. Implemented and testing now. Really appreciate the super-speedy answer.

You’re welcome. And it does look like our code on github is a little outdated. We’ll do some updating today

UPDATE: 3 days of testing now complete: Reuben’s “continue” statement (above) indeed fixed the issue!

Glad to hear it. Just for a little more background, this only became an issue in the latest firmware release. This is due to the smarter modem and system chip management which is now doing a better job of resetting things in the appropriate places and that reset is what can lead to a null character on the UART which then gets pulled into the We’re looking to see if this is something we can handle behind-the-scenes so you don’t need that line in your code.
Also, I think there’s a task open in github for the bug in the Arduino String class that this exposes so maybe they’ll end up fixing it on their end at some point.