AT command responses (understanding order of code

Question

I'm sending AT commands to an ESP8266 from an Arduino Uno/Nano (ATmega328) and attempting to parse the end of the strings received in response to establish how the ESP reacted and whether it was successful (and whether it's ready to receive another command yet). I'm aware that parsing AT command responses has been discussed before here: Get AT command response

But I have a specific issue not covered there that might also be of interest to other people on here...

First, a function is called which sends the AT command to the ESP to connect to ThingSpeak (datalogging server). This works fine in manual mode and also connects when trying to parse the response BUT it only parses the first line that comes back. For example, the expected output in the serial monitor would be:

c
AT+CIPSTART="TCP","api.thingspeak.com",80
CONNECT

OK
Connected to ThingSpeak!

Where c is just the command character I type to initiate the connection.

The actual response, however, is as follows:

c
AT+CIPSTART="TCP","api.thingspeak.com",80
Cannot connect to ThingSpeak!


CONNECT

OK

This means that the parsing function is ending before it receives the response... As shown in the code below, there is a 10 second timeout currently specified. Even with a 20 second timeout, the same thing happens, despite the fact that when executed manually, the response arrives in around one second.

Just to test the parsing function, I tried searching for "80" and it returned true as this is found at the end of the first line of the response. Whether it searches for "OK" or "OK\r\n" the result is the same, it returns false and THEN the rest of the response is received.

Here's the code:

boolean waitForResponse(String target, unsigned long timeout)
{
  unsigned long startTime = millis();
  String responseBuffer;
  char charIn;

  //keep checking for ESP response until timeout expires
  while ((millis() - startTime) < timeout)
  {
    if (ESP.available())
    {
      responseBuffer += ESP.read();
    }
  }
  Serial.println(responseBuffer);
  if (responseBuffer.endsWith(target))
  {
    return true;
  } else {
    return false;
  }
}

void openCxn()
{
  ESP.print("AT+CIPSTART=\"TCP\",\"api.thingspeak.com\",80");
  delay(500);
  if (waitForResponse("80",10000L))
  {
    Serial.println("Connected to ThingSpeak!");
  } else {
    Serial.println("Cannot connect to ThingSpeak!");
  }
}

Any idea why it returns before the full response is received (well within the timeout period)? Is it something to do with the endsWith() function?

Consequently, do you have any ideas of how to make it parse the entire response instead of just the first line?

To reiterate, I am only interested in the end of the response (e.g. "OK" or "OK\r\n").

Answer 1

Your if after the while Is indeed wrong Because you might have read more stuff back and thus you don't end with target string even though ok was received.

You should just test if responseBuffer ends With target And return true Only when you receive a new Char in the while loop and not after. After you have timeout just return false.

Answer 2

Any idea why it returns before the full response is received (well within the timeout period)?

Yes, your main problem is the following

if (ESP.available())

This makes the waitForResponse function return whenever the UART (or some other serial IO buffer) is empty - which is not what you want. What you want is to read from the serial port until you have received a line terminated with "\r\n".

Is it something to do with the endsWith() function?

Yes, that is an additional problem combined with ESP.available because you are attempting to match the end of a response line from the modem with what ever random data chopping occurs in the serial path. If you are extremely lucky this will be on line boundaries, but most likely not and you should not rely on that.

This is a general protocol problem known as framing that applies to any kind of asynchronous serial communication. For modem communications the framing characters are \r and \n.

Do yourself a favour and implement a readline function that reads one by one character until it the previous character was \r and the current character is \n and then return everything it read so far.

Then use that function exclusively¹ for reading modem response data. This applies both to Intermediate result codes like CONNECT as well as Final result codes (e.g. OK etc). "Parsing" the response lines can then be as simple as

if (responseLine.equals("CONNECT\r\n")) ...

or

if (isFinalResultCode(responseLine)) ...

As I said before, the only correct way to process modem output is to divide the output into complete lines and iterate one full line at the time.

---

¹ The only exception is when parsing AT+CMGS response data.