分类： C/C++
2008-03-13 17:19:16
Q 我写了个短信发送程序，使用PDU格式发送，程序在广州使用一点问题也没有，在河南却怎么也发不出去。不知道为什么，短信"你好吗"格式如下:
河南: 0891683108200005F011000D91683170031618F20008A9064F60597D5417
广州: 0891683108301705F011000D91683170031618F20008A9064F60597D5417
A 发送短信时要用SIM卡属地的SMSC号码。如果是在广州办的卡，即使在外地还是要用广州的SMSC号码。你的两个短信内SMSC号码不同，但用的是同一张SIM卡，不知是否是此原因。
Q 短信中心的号码可否直接使用SIM卡中的号码，而不要用户输入？我用过的短信软件好像都是不用输SMSC号码的。
A 有一条"AT+CSCA"指令，可用于设置或查询服务中心号码。若手机中已存在此号码，有两种解决办法：
可用"AT+CSCA=xxxxxxxx"指令设置服务中心号码。
Q 我在超级终端上，用at+cmgs发送短消息，格式好像没有错误，但总返回"ERROR"。我输入的就象这样：
at+cmgs=30 > 0891683108100005F011000D91683118405057F000000006C8329BFD0E01请问是什么原因？
A "at+cmgs"指令很特殊，回车后还需要输入数据。此处是"CR",不是"CRLF"，注意在超级终端里直接回车是不是生成了两个字符（查看设置）。象"at+cmgl"指令，即使最后输入"CRLF"也是不要紧的。
你的问题出在长度上。长度不是随便写的，你的例子中，长度应为21。除去SMSC段（0891683108100005F0），从"11"开始算（即"11000D91683118405057F000000006C8329BFD0E01"），除以2即得。
正确的写法应该是
at+cmgs=21 > 0891683108100005F011000D91683118405057F000000006C8329BFD0E01(">"是手机提示，不是输入的)
Q 我最近在编一个关于短消息的程序，在你的"通过串口收发短消息"中提到"Text Mode是纯文本方式，可使用不同的字符集，从技术上说也可用于发送中文短消息，但国内手机基本上不支持，主要用于欧美地区。"是不是说我用AT指令"AT+CMGF=1"或"AT+CMGF=0"对我后来的收发短消息没什么影响啊？
A Text mode写起来简单，直接发原文就行，发送非ASCII码内容也能发，但需要手机支持才能正确显示。如法语、德语的很多字符，编码大于0x80，他们都是用text mode。Text mode靠什么区分字符编码方式呢？有专门的字符集设定指令"AT+CSCS"。可以设定为扩充字符集"UCS2"。Siemens TC35/TC37资料上说，它的"AT+CSCS"支持"UCS2"字符集，但我目前没有机会去亲自试验。正在使用TC35/TC37模块的朋友不妨试一下。
据我了解，中文短消息方面，在国内卖的各种手机只支持PDU mode，这成了事实上的标准。其实PDU mode真的挺好用，估计以后text mode会萎缩。我们写的程序，我建议只采用PDU mode，即使是发纯英文信息也这样，编码倒是可以灵活采取7bit或UCS2，因为7bit能发的长度是UCS2的2倍(仅对纯英文而言)。如果发送纯数据，不需要手机显示，可用8bit。
Q 你的smstraffic类中的发送接收大循环中，是不是把所有收到的消息都放入消息队列后，然后执行删除程序啊？如果我是并发量很大的话，就是网关有很多短消息等着进入手机，读完所有短消息后，进行删除的过程中，因为短消息的排列顺序，而导致误删除呢（比如说我现在手机里有1－15条短消息，然后在我删除第一二条后，第三条自动填补为第一条，而新进来的短消息，16条排在了第三条，而被cancel掉呢？）我试过好象短消息的排列不是每次都一样啊？（在接收的时候，同一条短消息有时是14条，有时是第15条）这个怎么解决啊？
A 手机里消息都有一个物理序号，读出的时候带序号，删除也要根据序号删。"物理"二字很关键。这个序号相当于ID，无论它前面有没有删除、删除了多少消息，都不会变的。假如原来有1-15，删除了1和2，又来了一条消息，手机内部的软件有两种处理方式：有的放在第1条，有的则放在第16条，我都见过。其实，它愿意放到哪个空闲的地方都行。但无论怎样，不会引起混乱的，因为读出是什么序号，就删除什么序号的。在执行删除命令前，消息还是在原来那个地方，不会被后来的覆盖。
如果说网关有很多短消息等着进入手机，量很大，这种处理方式效率不高，因为AT+CMGL占用很长时间，这段时间手机无法从SMSC接收新消息。采用我说的"实时"接收方法比较好，消息来了直接传出来，不经过写入手机的过程。
Q 我用Nokia 8210串口数据线，连上电脑的com1口，用SmsTest运行提示"没有发现MODEM",跟踪发现gsmInit()检测中串口发AT指令没有回应"OK"。按您的提示我安装了Nokia modem驱动程序，（WIN2000 server系统）虚拟出com3口的一个8210 MODEM设备，再次调用smsTest还是提示"没有发现MODEM"。但用串口线，手机能通过LogoManager手机管理软件进行相应的图片LOGO，短信发送操作。
A Nokia手机本身没有带modem功能，用专业术语讲就是不具备TA(Terminal Adapter)接口，需要驱动转换，不管是真的串口，USB还是红外接口，反正它能虚拟出"标准MODEM"串口来。AT命令只能用标准异步通信。
在我的印象中，Nokia 8210需用红外线接口同PC通信。估计你装的那个驱动是IR->COM转换的，而不是驱动串口数据线的，可能你的电脑没有红外接口，所以com3也连不上？
要试(虚拟)串口是否连接正确，很简单，用windows自带的"超级终端"在特定虚拟端口连上，敲个"AT"回车，看有没有反应，正确回答应该是"OK"。
Nokia数据线上跑的是"Nokia语"- Nokia专有协议的数据，不是通用/扩展的AT命令集。LogoManager能听、能说"Nokia语"，所以不需要安装驱动就能工作。Nokia有一个免费的"Nokia PC Connectivity SDK"，可供开发Nokia手机使用。至于LogoManager是不是用的这个开发包，那就不得而知了。
Q 在SmsTest中，发出AT命令，然后接收应答，比如
WriteComm("AT+CMGF=0\r", 10);
ReadComm(ans, 128);在WriteComm函数后接着就调用ReadComm，是不是太急，这里的ReadComm函数是读返回的这个字符串还是其中的单个字符或不完全的字符串？请问超时控制设多少最合适啊？ COMMTIMEOUTS timeouts = { // 串口超时控制参数
100, // 读字符间隔超时时间: 100 ms
1, // 读操作时每字符的时间: 1 ms (n个字符总共为n ms)
500, // 基本的(额外的)读超时时间: 500 ms
1, // 写操作时每字符的时间: 1 ms (n个字符总共为n ms)
100}; // 基本的(额外的)写超时时间: 100 ms
ReadComm什么时候返回呢？按此timeout设定，若n=128（ReadComm的第二个参数），则
在手机正确连接的情况下，主要是最后一条起作用。一段数据是连续传输的，若波特率是9600bps，可以算出字符间隔是0.1毫秒左右，远小于100毫秒，不会读一个字节或部分数据就返回；通常是数据完毕后才可能出现等待100毫秒而返回的情况。举个例子，若在执行ReadComm(ans, 128)后150毫秒收到"OK\r\n"，则还需要额外等100毫秒，也就是说函数将在250毫秒后返回。这里传输4个字节数据的时间被忽略不计了。如果觉得读得太急，可将基本的(额外的)读超时时间调大一些。不过500毫秒内还没有应答，可能是连接故障造成的。
需要特别注意的是"AT+CMGL"指令及其应答。可能是由于需要扫描所有存储区域的缘故，手机在逐条送出短消息后，还需要延迟好几秒的时间才能送出最后的"OK"。当然可以通过设定上面的基本读超时时间和读字符间隔超时时间都很长（比如20秒），并且一次读很长的数据（比如2000），来达到目的。但这样一来，函数阻塞时间太长，若恰好这时要程序退出，你会赫然发现"该程序无响应"。SmsTest中解决办法是：循环读取串口数据，将每次读取的数据拼接起来，最后得到完整的应答。gsmGetResponse()每次可能读取部分数据，将新数据追加到已读数据后，且检测是否见到"OK"或"ERROR"，以判断是否已经读到完整的数据。