AT command response handler

Question

AT commands usually generate an OK/ERROR response

> AT\r
< \r\nOK\r\n

or a 2-lines response, such as:

> AT+CIMI\r
< \r\n<IMSI>\r\n
< \r\nOK\r\n

In both cases, the response handler implemented in the host detects the end of the response (and usually the possibility to send the next AT command) when OK or ERROR is received.

Actually I'm working on A7672E 4G module from SimCom. It features complex and proprietary AT commands which response is 2-lines but... "inverted":

> AT+CNTP\r
< \r\nOK\r\n
...<delay>...
< \r\n+CNTP: 0\r\n

I suppose the delay in the second line is caused by the real NTP request that the modem is making on the Internet (contacting the server and waiting its reply). So the modem replies immediately with OK, but takes time to send the final result.

I tested (even with oscilloscope) that the modem is again really available to process other AT commands after the OK:

> AT+CNTP\r
< \r\nOK\r\n
> AT\r
< \r\nOK\r\n
...<delay>...
< \r\n+CNTP: 0\r\n

However I'm not sure if it would be better to block the response handler until +CNTP: <err> message is received (so blocking sending other AT commands too) or unblock the receiver immediately after OK, giving the application the possibility to send other commands in the meantime.

Edited at 2023/10/02 08:03

I made another test. I configured two virtual serial port with CMUX and I sent AT+CATR=5 that instructs the modem to send URC messages to second virtual port only.

The final response +CNTP: <code> is transmitted to the virtual port that the host used to send the AT+CNTP command, so completely ignoring AT+CATR. This should demonstrate that the modem doesn't manage the final response as a URC.

Answer 1

Two of the first documentation references I could find does indeed specify the response to AT+CNTP as

Response
OK
+CNTP: <code>

That means that +CNTP: ... is an unsolicited result code. V.250 says:

5.7.1 Responses

There are two types of responses that may be issued by the DCE: information text¹ and result codes. ... There are three types of result codes: final, intermediate, and unsolicited.

where intermediate comes between start of executing a command line and the final result code, and unsolicited comes between a final result code and the next command line.

---

So to answer your question how to handle this, I would recommend handling it as an unsolicited result code properly. If you are writing some very special purpose software that must know what the ntp result was before continuing, you could perhaps as a special case substitute waiting for the final result code with waiting for this unsolicited result code, but I would consider that a hack and with no real benefits over just waiting for final result codes as normal and rather add an unsolicited result handler which checks for this instead.

---

¹ (my footnote) The difference between information text and intermediate result code is blurry and for practical purposes they are the same.