“通过串口收发短消息”的Q&A汇编

类别:VC语言 点击:0 评论:0 推荐:
P.bhw98 { PADDING-RIGHT: 0px; PADDING-LEFT: 0px; FONT-SIZE: 9pt; PADDING-BOTTOM: 0px; MARGIN: 10px 0px 5px; LINE-HEIGHT: normal; PADDING-TOP: 0px; FONT-FAMILY: Verdana, Arial } PRE.bhw98 { FONT-SIZE: 9pt; PADDING-RIGHT: 5px; PADDING-LEFT: 5px; PADDING-BOTTOM: 5px; MARGIN: 5px 0px; LINE-HEIGHT: normal; PADDING-TOP: 5px; BACKGROUND-COLOR: #f0f0f0 } PRE.diag { FONT-SIZE: 9pt; PADDING-RIGHT: 5px; PADDING-LEFT: 5px; PADDING-BOTTOM: 5px; MARGIN: 5px 0px; LINE-HEIGHT: normal; PADDING-TOP: 5px; } CODE.bhw98 { FONT-SIZE: 9pt; COLOR: #000000 } TABLE.bhw98 { BORDER-RIGHT: #808080 1px solid; BORDER-TOP: #808080 1px solid; FONT-SIZE: 9pt; MARGIN: 3px 0px 10px; BORDER-LEFT: #808080 1px solid; LINE-HEIGHT: normal; BORDER-BOTTOM: #808080 1px solid; FONT-FAMILY: Verdana, Arial } TD.bhw98 { BORDER-RIGHT: darkgray 1px solid; PADDING-RIGHT: 10px; BORDER-TOP: darkgray 1px solid; PADDING-LEFT: 5px; FONT-SIZE: 9pt; PADDING-BOTTOM: 0px; MARGIN: 0px; BORDER-LEFT: darkgray 1px solid; LINE-HEIGHT: normal; PADDING-TOP: 3px; BORDER-BOTTOM: darkgray 1px solid; FONT-FAMILY: Verdana, Arial; BACKGROUND-COLOR: #f0f0f0 } STRONG.bhw98 { FONT-WEIGHT: bolder; FONT-SIZE: 20pt; COLOR: #228b22; FONT-STYLE: italic; FONT-FAMILY: Verdana, Arial } LI.bhw98 { FONT-SIZE: 9pt; MARGIN: 3px 0px 0px 3px; LINE-HEIGHT: normal; FONT-FAMILY: Verdana, Arial } H1.bhw98 { MARGIN-TOP: 25px; FONT-WEIGHT: bolder; FONT-SIZE: 12pt; MARGIN-BOTTOM: 5px; LINE-HEIGHT: normal; FONT-FAMILY: Verdana, Arial } H2.bhw98 { MARGIN-TOP: 20px; FONT-WEIGHT: bolder; FONT-SIZE: 10.5pt; MARGIN-BOTTOM: 5px; LINE-HEIGHT: normal; FONT-FAMILY: Verdana, Arial } H3.bhw98 { MARGIN-TOP: 15px; FONT-WEIGHT: bolder; FONT-SIZE: 9pt; MARGIN-BOTTOM: 5px; LINE-HEIGHT: normal; FONT-FAMILY: Verdana, Arial } SPAN.server { COLOR: #0000ff } SPAN.client { COLOR: #ff0000 } SPAN.comment { COLOR: #008000 }

就"通过串口收发短消息"专题,本人将同网友交流、探讨的部分技术问题整理成如下文字。希望这篇文章能对更多对SMS感兴趣的朋友有所帮助。由于本人是业余爱好,时间和金钱都有限,没有力量将很多型号的手机和模块一一试验,可能存在这样那样的差错,希望行内高人批评指正。

Q 我写了个短信发送程序,使用PDU格式发送,程序在广州使用一点问题也没有,在河南却怎么也发不出去。不知道为什么,短信"你好吗"格式如下:

河南: 0891683108200005F011000D91683170031618F20008A9064F60597D5417

广州: 0891683108301705F011000D91683170031618F20008A9064F60597D5417

A 发送短信时要用SIM卡属地的SMSC号码。如果是在广州办的卡,即使在外地还是要用广州的SMSC号码。你的两个短信内SMSC号码不同,但用的是同一张SIM卡,不知是否是此原因。

Q 短信中心的号码可否直接使用SIM卡中的号码,而不要用户输入?我用过的短信软件好像都是不用输SMSC号码的。

A 有一条"AT+CSCA"指令,可用于设置或查询服务中心号码。若手机中已存在此号码,有两种解决办法:

用"AT+CSCA?"指令查询出来,然后自动将此号码写到PDU的SCA中。 PDU的SCA字段只写一个"00": "08 91 68 31 ..." -> "00"

可用"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函数是读返回的这个字符串还是其中的单个字符或不完全的字符串?请问超时控制设多少最合适啊?

A 关于读串口,程序中是这样设定超时控制的:

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的第二个参数),则

若无任何数据,等待500+1*128=628毫秒返回。也就是说,若没有连上手机,根本不存在应答,ReadComm会持续阻塞628毫秒,而后返回。 若数据连续传输,且字符间隔也未超过了100毫秒,但时间已经到了628毫秒,返回已读取的字符(串)。接收到的可能是不完全的字符串。 若在628毫秒内,字符间隔超过了100毫秒(第一个字符之前等待的时间不算),返回已读取的字符(串)。接收到的应该是完整的字符串。

在手机正确连接的情况下,主要是最后一条起作用。一段数据是连续传输的,若波特率是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",以判断是否已经读到完整的数据。

[相关资源] 科脑工作室(Kernel Studio):www.kernelstudio.com

发布时间:2004-03-16

 

本文地址:http://com.8s8s.com/it/it1152.htm