如果启用 ATE1（回显），是否应该将响应附加到 AT 命令？
Should a response be appended right to an AT command if ATE1 (echo) enabled?
我即将实现一个用于 PC 的控制台程序，它与 GPRS 调制解调器（特别是 SIM800L）一起工作。
我刚刚了解了由于出现 UCR（未经请求的结果代码）而难以解析响应的原因。
所以我用谷歌搜索了一下，发现了这个 post:
引用：
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
我很困惑。我想它应该可以工作，但前提是响应总是在相应的命令之后。
但我找不到它的强项。 AT 命令的描述和 SIM800L 数据表均不包含该声明。
还是我理解错了？
I guess it should work but only if a response always goes right after
a corresponding command.
是的，是的。至少对于大多数 u-blox 蜂窝模块：
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
我即将实现一个用于 PC 的控制台程序，它与 GPRS 调制解调器（特别是 SIM800L）一起工作。
我刚刚了解了由于出现 UCR（未经请求的结果代码）而难以解析响应的原因。
所以我用谷歌搜索了一下，发现了这个 post:
引用：
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
我很困惑。我想它应该可以工作，但前提是响应总是在相应的命令之后。
但我找不到它的强项。 AT 命令的描述和 SIM800L 数据表均不包含该声明。
还是我理解错了？
I guess it should work but only if a response always goes right after a corresponding command.
是的，是的。至少对于大多数 u-blox 蜂窝模块：
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