有关 AT 命令处理的一般说明。
不不不!这种做法永远不会可靠。你MUST等待>
发送“text”之前要接收的字符
发送”。或者实际上它不仅仅是>
字符,是四个
人物。引用自3GPP 规范 27.005 http://www.3gpp.org/ftp/Specs/html-info/27005.htm:
- TA 应发送一个四字符序列
<CR><LF><greater_than><space>
(IRA 13, 10, 62, 32) 命令行后
终止于<CR>
;之后可以从 TE 输入文本
我/助教。
(TA(终端适配器)这里指调制解调器,TE(终端设备)指AT命令的发送者)
对于任何可中止的 AT 命令(27.005 明确规定 AT+CMGSThis command should be abortable.
)发送任何字符都会
中止命令的操作。去引用国际电联V.250 http://www.itu.int/rec/T-REC-V.250-200307-I/en:
5.6.1 中止命令
...
正在中止
命令的完成是由
从DTE到DCE的传输
任何字符。
(这里的DCE(数据通信设备)指调制解调器,DTE(数据终端设备)指AT命令的发送者)
这意味着当您在发送“\r\n>”之前发送“要发送的文本”时
通过调制解调器,该命令将被中止。没有办法等待“长久”
足以”等待发送响应。你MUST读取并解析
从调制解调器返回的响应文本。
这同样适用于每个命令之后的最终结果代码(例如OK
,
ERROR
, CME ERROR
以及更多)。例如发送“AT+CMGF=1”
然后发送下一个命令而不先等待 OK 是乞求
对于问题。所以在发送 AT 命令时,您总是MUST等待
在发送下一个命令之前获取最终结果代码。
请永远、永远不要使用delay
等待任何 AT 命令响应。它是
就像踢掉挡道的狗以获得它们一样有用
移动。是的,有时它可能确实有效,但在某些时候你
会为采取这种方法感到抱歉......
回答你的问题。
根据您得到的回复,我可以看到您的问题不是命令
流产(虽然你的解析有如上所述的严重问题
你应该修复),并且 CME 错误是你最好的线索。来自部分
27.007 中的“9.2.1 一般错误”给出了operation not supported
作为
值 4 的说明。
27.005 规定:
如果由于网络或ME错误发送失败,则返回最终结果码+CMS ERROR:。
请注意,这是 +CMS ERROR 而不是 +CME ERROR,但它是适用的,请参见下文。
我猜动作顺序如下:
SM100B GSM调制解调器的AT命令处理部分接受短信数据
并将其格式化为适当的格式并将其发送到
与 GSM 网络通信的调制解调器。就成功发送了
SMS 数据发送到网络并将其报告回 AT 命令处理
然后打印的部分+CMGS: 25
和最终结果代码OK
。然而
短时间后网络发回短信拒绝消息,
然后作为 +CME ERROR 响应给出。
如果我上面的猜测是正确的,那么回复应该已经送达了吧
改为 +CMS ERROR?不,因为最后的回应
已给出 AT+CMGS 命令(OK),并且
永远不应该为一个命令返回多个最终结果代码
(除非是错误的(注1))。
虽然 +CME ERROR 可以替换 ERROR 最终结果代码,
它不仅仅是最终结果代码。从AT+CMEE命令说明来看:
设置命令禁用或启用结果代码 +CME ERROR:作为与以下相关的错误指示
MT 的功能。启用后,MT 相关错误会导致 +CME ERROR:最终结果代码
常规错误最终结果代码。当错误与语法、无效参数有关时,通常返回 ERROR,
或 TA 功能。
因此 +CME ERROR 既可以是最终结果代码,也可以是未经请求的代码
结果代码(可能也是中间结果代码)。
但AT+CMGS命令无法等待接收网络
拒绝并返回+CMS ERROR?可能不会。也不自知
关于短信发送的网络细节,可能是这样的
今天的拒绝可能会比以前晚得多。这样的
更改有时是 GSM 相关 AT 命令的问题,这些命令有
最初与 GSM 行为紧密相关的古老遗产
随着技术转向 GPRS,有时变得越来越不真实,
UMTS、LTE 等
Note 1:
我的一位前同事曾经抱怨标准的制定方式
已指定语音呼叫处理,因为经过 ATD1234;命令
你首先得到最终的结果代码 OK,然后当调用时
结束后您会得到一个新的最终结果代码“NO CARRIER”。这简直太可怕了
糟糕的设计,呼叫结束指示应该是特定的未经请求的
回应而非最终回应。
所以总结一下
您的短信似乎被网络拒绝。尝试找出原因。
您的 AT 命令处理也存在一些严重问题
你应该解决的问题;没有办法处理 AT 命令
读取并解析来自调制解调器的响应文本。