分享
 
 
 

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

王朝vc·作者佚名  2006-01-09
窄屏简体版  字體: |||超大  

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

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有