Search code examples
iotat-commandmodemgprssim800

Should a response be appended right to an AT command if ATE1 (echo) enabled?

I am about to implement a console program for PC which works with a GPRS modem (SIM800L, particularly).

I've just learnt what it is hard to parse the responses due to appearance of UCR (Unsolicited Result Codes).

So I had a bit googling and found this post:

https://embeddedfreak.wordpress.com/2008/08/19/handling-urc-unsolicited-result-code-in-hayes-at-command/

Quoting:

Turn ON the ECHO (ATE1) Most of application samples that I’ve seen turn off the ECHO (by sending ATE0). The reason is unknown, but most of them saying to reduce the serial port communication (hence reducing the parser effort). But that is not correct.

If you want to build robust communication, you should turn ON the ECHO. The reason is simple, you can detect the sequence of the command/URC that’s received by the modem. Here’s the actual sequence of the illustration above (viewed from the modem’s echo):

application>AT+CMGL=4 # List all of SMS inside the ME
ME> OK # There's no SMS inside the ME
ME> RING # Incoming call
ME> RING # Incoming call

I am confused. I guess it should work but only if a response always goes right after a corresponding command.

But I couldn't find a strong point for it. Neither description of AT commands nor SIM800L datasheet does contain that statement.

Or maybe I just understand it in a wrong way?

Solution

  • I guess it should work but only if a response always goes right after a corresponding command.

    Yes, it is. At least for most of u-blox cellular modules:

    The module avoids this collision by delaying the URCs presentation in case the AT command interface is busy. The AT command interface can be busy in the following cases:

    • During a data call (data mode)

    • During the execution of an AT command in command or online command mode

    The command execution starts when the command line is completed by the command line termination character and the AT interpreter in the module accepts it; the command execution ends when the final result code for the command is sent out. Inside this period, the module is not allowed to send the not buffered URCs. For most of the messages, the DCE needs to be configured whether or not to send a URC. After enabling, for most of the URCs, if the AT command interface is busy, the pending URCs are buffered and their sending to the DCE is deferred.

    https://www.u-blox.com/sites/default/files/u-blox-CEL_ATCommands_UBX-13002752.pdf