语音传输（共7篇）
语音传输 篇1
1 前言
无线语音技术从早期的模拟无线语音到目前的数字无线语音技术, 经历了一个比较漫长的过程。随着无线通信技术的发展, 特别是无线射频收发器成本的逐年下降, 数字无线语音通信逐渐成为市场应用主流。最简单的例子莫过于对讲机, 目前仍然广泛使用的是模拟对讲机, 而高档的数字对讲机正在降低成本, 逐渐蚕食模拟对讲机的市场。
ZigBee原本定位于小数据量的通信, 但是本身250 kb/s的通信速率也是足以满足基本语音通信的, 几大射频芯片厂商都有基于ZigBee的语音通信方案, 本文将对ZigBee语音通信技术做一些探讨。
2 ZigBee语音通信分析
ZigBee传输语音数据属于数字传输, 数字通信系统在本质上有着一些巨大的优势:首先是抗干扰能力强。模拟信号在传输过程中很难与叠加的噪声分离, 噪声会随着信号被传输、放大, 严重影响通信质量。数字通信中的信息是包含在脉冲的有无之中的, 只要噪声绝对值不超过某一门限值, 接收端便可判别脉冲的有无, 以保证通信的可靠性。其次是远距离传输仍能保证质量。因为数字通信是采用再生中继方式, 能够消除噪音, 再生的数字信号和原来的数字信号一样, 可继续传输下去, 这样通信质量便不受距离的影响, 可高质量地进行远距离通信。此外, 它还具有适应各种通信业务要求 (如电话、电报、图像、数据等) , 便于实现统一的综合业务数字网, 便于采用大规模集成电路, 便于实现加密处理, 便于实现通信网的计算机管理等优点。
标准的ZigBee传输数据率为250 kb/s, 目前厂商支持的传输速率可以达到1 Mb/s, 更高的传输速率意味着更低的接收灵敏度, 也意味着更短的通信距离, 因此在话音质量要求不高的场合, 尽量使用最低可接受最差通话质量, 即最低通信流量, 以保证通话距离。
在250 kb/s的通信速率下, 理论上有25 kB/s的传输流量, 可以满足电话质量, 即ITU-TG·711标准, 8 kHz取样, 8 bit量化, 码率64 kb/s, 而AM广播采用ITU-TG·722标准, 16 kHz取样, 14 bit量化, 码率224 kb/s, 标准ZigBee 250 kb/s也是可以满足的。
无线语音通信因为传输的数据量要尽量少, 因此通常需要采用语音压缩算法先将数据进行压缩, 然后再传输, 接收方按照对应的解压算法解压后播放, 常见的三种语音编码解码算法为:μ-law、a-law、ADPCM。
μ-law算法是一种压扩算法 (companding algorithm) , 主要用于北美和日本的数字通信系统。与其他压扩算法一样, 其目的是减少音频信号的动态范围。在模拟域中, 这可以提高发送过程中的信噪比 (SNR) ;在数字域中, 则可以减少量化误差 (quantization error) (因而提高了信号-量子化噪声比 (SQNR) ) 。反过来, SNR的这些改善又可以减少带宽和等效SNR。
a-law算法也是一种标准的压扩算法, 被欧洲数字通信系统用来优化/修改数字化模拟信号的动态范围。
a-law算法以更坏的小信号比例失真 (proportional distortion) 为代价, 提供的动态范围比μ-law稍微宽一点。
自适应差值脉冲编码调制 (ADPCM) 是在差值 (或增量) 脉冲编码调制 (DPCM) 基础上发展起来的, 它主要改变了量化级数, 从而可以进一步减小某一特定信噪比所需的带宽。DPCM将PCM值编码成当前值和之前值的差。对于音频, 这种编码方法可以将每次采样的位数相对PCM减少25%左右。
3 系统构成
ZigBee语音通信系统由音频ADC芯片采集语音数据, 经由I2S总线传输到带语音处理单元的单片机 (如ZICM2410芯片) 中, 经过硬件编解码单元, 进行数据压缩, 可选μ-law、A-law和ADPCM等, 然后进入MAC层的FIFO, 最后通过PHY层调制成射频信号发射出去。接收端的结构与发射端相同。
因为采用射频数据打包的分组传输方式, 因此可以实现数字全双工通信, 这也是普通模拟对讲机不能实现的。系统数据流图如图1所示。
为保证语音数据的高速传输, 语音芯片和CPU最好使用I2S总线, I2S (Inter—IC Sound) 总线是飞利浦公司为数字音频设备之间的音频数据传输而制定的一种总线标准, 该总线专责于音频设备之间的数据传输, 广泛应用于各种多媒体系统。它采用了沿独立的导线传输时钟与数据信号的设计, 通过将数据和时钟信号分离, 避免了因时差诱发的失真, 为用户节省了购买抵抗音频抖动的专业设备的费用。CPU和音频编解码芯片的连接如图2所示。
4 ZigBee语音路由分析
点对点的通信通常距离不远, 在语音通信中更是如此, 因为数据量本身已经接近最大带宽, 又考虑到音频图像等的传输对于细节数据不太敏感, 一般不做确认重发机制, 所以通信距离甚至只能达到数据通信距离的一半。如果要增加通信距离, 则必须增加中继节点, 随之而来的是音质降低了一半。
以已经实现的一个无线语音中继系统为例, ZICM2410模块本身可以实现16 kHz采样率, 8 bit位采样 (单身道) , 也就是每秒钟可以传输16 KB的数据, 但是为满足中继需要, 只能降到8 kHz采样率, 时隙上的分析如下。
如图3所示, 16 kHz, 8 bit采样, 每4 ms发送一次64 B的语音数据, 8 kHz, 8 bit采样, 每8 ms发送一次, 增加中继之后, 源节点每8 ms发送一次 (8 kHz, 8 bit) , 而中继节点收到数据后, 会有一个存储转发的过程, 大致4 ms, 这时, 如果通过ZigBee分析仪查看, 依然会看到每4 ms一个无线数据包, 和之前16 kHz采样时的时间占用是一样的。
这样的时隙下, 即使发送机、接收机和中继器放在一起, 也是不会有影响的, 因为接收机接收时会有帧序号比对, 收到中继的重复数据包会立即丢掉, 一旦离开源节点信号覆盖范围, 接收节点就只能收到中继节点的数据了。
如果位置选择合适, 则这种中继可以延续下去;否则再加一级中继, 会打乱原先系统的时隙。
5 ZigBee语音应用
ZigBee语音传输比较合适的是导游解说系统。在同一处旅游景点, 可能有不同的导游向不同的游客介绍景观。如果使用一般的扩音系统, 往往会出现导游之间互相比嗓子, 或者抢游客的尴尬局面, 在一些文化底蕴很浓的场合, 这样闹哄哄的场面往往会破坏景点本身的意境。
使用ZigBee技术可以非常容易地解决这个问题, 如图1所示的点对点通信, 只要发送端设置为广播模式发送数据, 即可在有效通信范围内, 配置不限数目的接听节点 (因为接收节点并不发数据, 因此技术上不存在节点限制, 只有空间上的体积限制) , 而不同导游之间, 采用不同的物理频段 (标准ZigBee总共16个) , 彼此之间是不会干扰的。
6 小结
ZigBee语音通信目前还在应用的初级阶段, 在成本上还有些高, 对于价格敏感的应用, 还不太适用。较为便宜的类ZigBee通信方式 (不使用O-QPSK等编码方式) 正在较大规模地应用, 这些通信方式, 抗干扰性不强 (临道抑制比差, 抗WiFi干扰能力弱) , 将来ZigBee价格和应用难度降下来之后, 必然会取而代之。
局域网内实时语音传输实现 篇2
在局域网内对音频信号进行采集, 并在网内实时传输, 每个用户可以收到对方的话音信号, 并将自己的话音信号实时发送到需要接收的客户端。
对音频这类多媒体传输业务而言, 为了满足传输实时性的要求, 常常采用一种应用层分帧 (ALF) 的策略:由上层应用完成对数据流的分割, 得到应用数据单元 (ADU) , 传输层将ADU作为整体处理。另外, 为了克服传统分层体系串行处理在效率方面的不足, 尽量将对数据的串行操作转换为并行操作, 从而充分发挥并行处理器、多任务操作系统的能力, 提高协议的效率。
1 路由选择
在网络上传输封装了音频数据的IP数据报 (Datagram) 。发送端从传输层接收数据段 (Segment) , 为之加上IP报头, 封装成数据报;然后将数据报送往数据链路层。中间站点为数据报寻径, 并且当网络的MTU减小时, 将数据报分片。接收点将分片重新组合, 经过差错检查后, 去掉数据报的IP头, 将数据段提交给与发送端对应的传输层协议[1]。
1.1 基本概念
站在IP层的角度, 网络传输音频数据报主要有3种方式:单播 (Unicast) 、组播 (Multicast) 和广播 (Broadcast) 。
单播是Internet上最常见的通信方式, 它在2个特定的IP地址间进行数据通信;全网广播在子网内部向所有IP地址发送数据包, 所有在子网内部的IP站点都能够收到数据包;组播介于单播和广播之间, 它对一组特定IP地址传送数据。
1.2 最佳方式
对音频数据的传输而言, 由于数据量庞大, 需要占用很大的网络带宽, 如果采用单播模式, 那么有多少个接收端就得传输多少份数据, 所需的网络带宽与接收端的数目成正比;如果采用广播或组播方式, 那么源端只需要传输一份数据, 组内或同一网段上的所有接收端均可以收到, 因此广播和组播对提高网络带宽的利用效率是很有意义的。
2 传输协议
2.1 基本概念
从TCP/IP概念模型来看, 传输协议为传输层的范畴。传输层主要解决2个方面的问题:传输层提供标准的传输服务;对下面的网络层而言, 由于网络层提供的分组传输是不可靠的, 有必要在传输层增强网络层提供的服务质量。传输层在数据传输中的地位和作用如图1所示[2]。
2.2 传输低层协议
2.2.1 TCP
TCP是面向连接的传输控制协议。TCP利用网络层IP协议提供的不可靠的分组传输服务, 为应用进程提供可靠的、端到端的、面向连接的字节流通信。Internet许多著名的服务, 如Telnet, FTP, HTTP等, 都采用TCP作为其传输协议。
TCP传输控制协议一般不直接用来传送音、视频数据本身, 但是, 对于音、视频传输中的控制信息而言, TCP是最合适的。
2.2.2 UDP
UDP是无连接的用户数据报传输协议。与TCP相比, UDP的报头要简单得多。对音、视频数据的传输而言, UDP比TCP更为适用。TCP的大量确认应答使音、视频数据不得不因为等待应答而放弃, 造成不必要的延迟和更大范围的数据丢失。相比较而言, UDP只要网络流量足够, 音、视频数据就可以源源不断的到达接收者。因此, 在IP网络上传送音视频数据, 往往采用UDP协议, 而不是TCP协议。
3 编程原理
Window Socket支持数据报 (SOCK_DGRAM) 和流式 (SOCK_STREAM) 两种类型的套接字[3]。前者采用UDP协议传输, 而后者采用TCP协议传输。编程实现流式数据传输方式的主要过程如表1, 表2所示。其中表1表示连接建立的过程, 而表2表示数据传输的过程。括号中表示的是完成相应操作的Window Socket函数[4]。
4 Windows Socket控件通信原理
Windows Socket程序接口, 是以BSD UNIX中流行的Socket接口为原则, 定义了一套可使网络程序开发人员在Microsoft Windows环境下开发标准TCP/IP网络程序[5]。
WinSock控件支持TCP协议和UDP协议。由于TCP是一种面向连接的通信技术, 它要求每一个通信必须先建立一个连接, 故不适合基于组播技术的数据传输。在局域网上对数据包进行组播传输需采用UDP协议, 数据传输率高, 适合IP组播的数据传输。
5 DirectSound对象
在Windows系列操作系统中, Microsoft提供了强大的DirectX工具。其中的DirectSound技术可以实现对声音的实时捕捉和播放。
5.1 播放功能概述
DirectSound缓冲区对象表示一个包含声音数据的缓冲区, 这些数据以PCM格式被存储。该对象不仅可以用于开始、停止或暂停声音的播放, 还能够设置声音数据中诸如频率和格式等属性。
5.2 音频捕获
DirectSoundCapture对象可以查询音频捕获设备的性能, 并为从输入源捕获音频而创建缓冲区, 它还能够捕获压缩格式的音频。DirectSoundCaptureBuffer对象表示一个用于捕获音频的缓冲区, 它可以循环利用。
5.3 播放声音的过程
(1) 锁定 (IdirectSoundBuffer::Lock) 从缓冲区的一部分;
(2) 写数据:将捕捉到的声音数据写入将要发送的数据包中;
(3) 解锁 (IdirectSoundBuffer::Unlock) :对 (1) 的锁定部分进行解锁;
(4) 将声音传送给主缓冲区, 并从哪里输出 (IdirectSoundBuffer::Play) 。
6 应用实例的设计及实现
基于以上技术, 在此开发了局域网上的音频组播系统, 以实现服务器端和客户端之间的音频通信。
6.1 设计思想
系统的应用平台是Windows操作系统, 使用的是Winsock2规范, 系统的开发工具是Microsoft Visual C++6.0[4]。此次设计的软件, 对组播组的成员, 分为Server和Client 2种。进行通信之前, Server和Client都必须先加入一个组播组。
(1) Server:
可以随时发言, 实时接听, 不受他人限制。对来自Client的发言申请作出响应, 然后将该信息拷贝到发送缓冲区发送出去。图2为Server端数据流程图。
(2) Client:
可以实时接听, 每次发言前必须发出申请信息。当申请信息发送出去后, 组播组内的所有成员都可以收到。当Server发送出对申请信息的响应信息后, 各个Client将根据自己的本地地址与信息中包含的地址信息做比较, 如果发现申请信息中的地址信息与本机地址一致, 则说明是自己的发言申请的响应, 于是处理;如果信息中的地址信息与本机地址不一致, 那么不处理。图3是Client端数据流程图。
6.2 实现步骤
6.2.1 Server端的实现
在应用程序的头文件中定义如下数据结构[6]:
(1) 为了实现组播数据传输, 首先要加入组播组。
IP组播数据包的包头中包含一个TTL字段, 用于控制一个IP组播数据包的传播范围[7]。
若TTL值为0, 则组播数据包只能在本地主机的多个线程间传播;
若TTL值为1, 则组播数据不允许传出本地网络之外;
当TTL大于1时, 路由器传送这个数据包到组成员所属的其它网络。
以下函数用于实现组播组加入:
(2) 定义一个CdirectSound类, 实现声音的捕捉和播放。主要成员变量和函数如下[7]:
(3) 定义play函数实现音频数据的实时播放[7]:
(4) 定义Capture函数实现音频数据的实时捕捉[3]:
6.2.2 Client端的实现
Client端的编程过程与Server端很相似。添加一个Application按纽, 给它添加处理“单击”事件的成员函数OnApplication () 。另外一点就是主对话框的receive () 成员函数对收到的数据包的处理[8]。
7 结 语
本文通过基于局域网的实时语音组播的研究, 探讨了在Visual C++6.0环境中实现对局域网声音的实时捕捉和组播传送的关键技术和方法。从基本概念、路由选择、传输协议等角度, 层层深入, 循序渐进, 通过分析比较TCP、UDP等实现数据传输的过程[9], 提出了实现语音传输的最佳方式:即利用COM组件对象模型提供的2个声音信号的采集接口类IDirectSoundCapture8, IdirectSoundCapture Buffer8和播放接口类IDirectSoundBuffer8, 采用UDP数据传输协议, 从Server和Client2个角度, 提出了具体的设计实现的设计思想及编程代码, 有很大的研究价值及现实意义。
摘要：多媒体和网络技术的迅速发展为基于网络的视、音频通信提供了可能, 在很多的网络通信中, 都需要将某一发送端的话音实时的传输给接收端。实时语音组播系统为这些应用需求提供了一个不错的解决方案, 实时语音组播系统可以分成发送端、接收端和网络传输3个子系统。在此从TCP/IP通信的原理, 包括路由选择、传输协议、编程实现等角度, 给出了比较完善的解决方案, 从而实现了在局域网内语音信号的实时传输, 有很好的参考和借鉴意义。
关键词：局域网,实时语音,TCP/IP,单播,组播,音频捕捉
参考文献
[1]陈坚, 陈伟.Visual C++网络高级编程[M].北京:人民邮电出版社, 2001.
[2]曹衍龙, 刘海英.Visual C++网络通信编程实用案例精选[M].北京:人民邮电出版社, 2006.
[3]曹章元, 刘加明.Visual C++6.0类库大全[M].北京:电子工业出版社, 1999.
[4]求是科技.Visual C++音视频编解码技术及实践[M].北京:人民邮电出版社, 2006.
[5]Microsoft.Microsoft MSDN library[EB/OL].[2007-08-13].http://www.microsoft.com.
[6][美]JAMSA Kris.C/C++/C#程序员实用大全[M].北京:中国水利水电出版社, 2002.
[7][美]KRUGLINSKI David J.Visual C++技术内幕[M].4版.北京:清华大学出版社, 2001.
[8]王华, 叶爱亮.Visual C++6.0编程实例与技巧[M].北京:机械工业出版社, 1999.
[9]陈坚.实用Visual C++编程大全[M].西安:西安电子科技大学出版社, 2000.
语音传输 篇3
以往设计的无线数据传输产品往往需要相当的无线电专业知识和价格高昂的专业设备, 传统的电路方案不是电路繁琐就是调试困难, 因而影响了用户的使用和新产品的开发。随着无线传输技术的发展, 由于采用了低发射功率以及高接收灵敏度的设计, 因而满足了大量无线传输的要求。这些无线数据传输系统可以广泛应用于遥控装置、工业控制、无线通信、电信终端、车辆安全、自动测试、家庭自动化、报警和安全系统等[1]。对于一些信息传输实时性要求比较高的自组织网络, 如何及时、准确地传输信息是提高系统性能的关键因素。本文即提出了一种有效解决数据传输冲突的无线语音传输系统设计方案。
2 无线语音传输系统体系结构
本文设计的无线语音传输系统采用三层结构:中央服务器层、工作站层和呼叫器层。无线数据传输主要在一台主机 (工作站) 和多台分机 (呼叫器) 之间, 通过射频收发模块完成。呼叫器层主要实现各种呼叫信息和数据的采集, 并通过工作站和后台中央服务器连接。后台中央服务器由普通PC机组成, 其功能是响应和处理各类呼叫信息。中央服务器和工作站之间采用通用以太网连接, 呼叫和处理的信息可以以电子文档形式存储在后台服务器中。
无线语音传输系统结构如图1所示。
本文主要对工作站和呼叫器层之间通信过程所涉及的数据传输问题做出讨论。
图2给出了无线呼叫系统工作站和呼叫器部分的硬件结构框图。系统的工作站与呼叫器的控制功能由微控制器实现, 射频收发模块主要由射频集成芯片构成。微控制器主要用来控制射频集成芯片的收发, 数据的识别和提取, 进行反碰撞处理。射频集成芯片选用Nordic公司的nRF401。该芯片集成了高频发射、高频接收、PLL合成、FSK调制、FSK解调、双频道切换等功能。nRF401接收机采用具有较强抗干扰能力的FSK频移键 (Frequency-Shift-Keying) 调制方式, 改善了噪声环境下的系统性能;采用DSS+PLL频率合成技术, 工作频率稳定可靠。与ASK幅移键控 (Amplitude-Shift-Keying) 和OOK开关键控 (On-Off Keying) 方式相比, 这种方式的通信范围更广, 特别是在附近有类似设备工作的场合。
3 数据传输防碰撞技术研究
3.1 防碰撞问题的提出
无线语音传输系统在遥控装置、工业控制、无线通信、电信终端、车辆安全、自动测试、家庭自动化、报警和安全系统等都有广泛应用。以服务行业的营业场所中较为常见的呼叫系统为例。顾客需要服务人员能够提供准确、及时的服务, 要求所设计的系统要有较好的实时性和可靠性。一方面, 顾客提出的申请能够很快地得到响应, 使顾客感觉不到时间的浪费;另一方面, 中央服务器不能由于接收到的是错误信息, 使服务员打扰并未提出服务申请的顾客。针对系统的要求, 可以得出导致服务中出现错误的原因有二:一是由于无线信道的复杂性, 信息在无线信道的传输过程极易受到干扰而产生错误, 接收方无法接收到正确的信息;其二是由于多个呼叫器同时竞争通信信道向中央服务器发出呼叫, 各个呼叫器发出的数据相互干扰, 使中央服务器不能正确地辨别出是哪一台呼叫器发出的申请。这两种错误可能使没有发出呼叫申请的顾客得到了不需要的服务, 而有服务要求的顾客又得不到满足, 反而降低了服务的效率和准确度, 起不到服务行业中需要的无线呼叫系统的作用[2]。对于前一种情况可以采用适当的校验和纠错方式, 降低中央服务器向服务员提供错误呼叫信息的概率, 无需本文详细讨论。而对后一种情况, 需要找到一种合适的反碰撞方法, 这正是本文要解决的问题。
在分机请求发送数据的同时, 另一台分机请求发送数据, 或一台分机在发送数据的过程中, 另一台分机请求发送数据, 都会造成通讯冲突。为了防止因通讯冲突而造成的数据传输错误, 本系统参考CSMA/CD (Carrier Sense Multiple Access /Collision Detect) 技术。CSMA/CD即载波监听多路访问/冲突检测[3], 它的工作原理可用8个字来表示:“先听后说, 边听边说”。呼叫分机在发送数据前, 先检测信道是否空闲, 若空闲, 则发送数据。在发送数据的同时, 仍继续监听信道, 以检测是否存在冲突。一旦检测到冲突, 就立即停止发送, 并向总线上发一串阻塞信号, 通知总线上其他各有关站点停止数据传输。这样, 通道容量就不致因白白传送已受损的帧而浪费[4]。
本次设计的语音传输系统对于信息传输的实时性及抗干扰性要求较高。要解决这个问题, 必须尽可能避免重复冲突现象的发生。即要求如果发生多台通讯冲突现象, 各分机的“等待时间”应不同。延时等待算法和冲突等待算法有“错时等待”的特点, 能有效地解决重复冲突问题。
3.2 监听信道忙延时等待
系统采用“先听后说”的工作方式, 分机在发送呼叫信息前, 先监听信道状态。如果信道忙, 说明有其他分机正在占用信道传输数据。根据前述数据帧格式, 一帧数据共128位, 一台分机传输数据所需的时间为:T=128 bit/波特率。
因此, 本次数据传输还需占用0到T的信道时间。为了避免同时监听到信道空闲而发生的冲突现象, 各分机采用下列延时等待公式决定延时监听时间:
undefined
上式中, ti为第i台分机的延时时间, n是分机的总台数, E是应急呼叫设置位 (若为应急呼叫, 则设置E为1) 。如果某些分机相对其他所有分机优先级别较高可由系统呼叫主机设定设置为应急状态。
分机i以ti的间隔时间监听信道, 当监听到信道处于空闲状态时, 即可进行到工作流程的下一步。
3.3 通讯冲突延时等待
尽管系统采用“先听后说”的工作方式, 但也可能发生两个站点因同时监听到信道空闲而同时发送数据的现象, 即发生通讯冲突。检测通讯冲突的方法是:发送数据的呼叫分机将接收到的信息与原来发送的信息逐个比特位进行比较, 如果两者一致, 说明没有冲突;如果两者不一致, 则说明发生了冲突。
造成这种通讯冲突的原因与信号在信道上的传播时延有关。传播时延是信号由信道上的一个站点传播到另一个站点的时间, 信息传播时延可由式 (2) 计算:
undefined
设A、B是系统中的两台呼叫分机, 它们之间的传播时延是tpab。分机A检测到信道空闲后, 就发送数据;分机B在分机A开始发送数据的 (0, tpab) 的时间内检测信道, 由于信号还没有传播到分机B, 因此分机B检测到信道状态仍处于空闲状态, 分机B也发送数据, 造成通讯冲突。分机检测到通讯冲突后, 立即停止发送, 并向总线上发一串阻塞信号, 用以通知总线上其他各有关站点等待。冲突等待时延采用式 (3) 计算:
tj=tpmax (j+1-E*j) (3)
上式中, tj为第j台分机时延检测时间, tpmax为任意两个站之间的最大传播时延, 由公式 (2) 计算得到。E的含义同式 (1) 。
无论是 (1) 式还是 (3) 式, i (j) 值小的分机先检测信道, 在数据传输比较繁忙的时段, i (j) 值大的分机总是要持续一个较长的时延才能检测信道, 这就会造成系统中各分机竞争不均衡的现象。为了避免这种现象, 我们将i (j) 设置为分机检测总线的优先级别, 并把系统设置成优先级循环的工作方式。初始状态, i (j) 的值为分机编号, 优先级分别为1、2、……、n。当优先级为k的分机传输数据后, 系统主机将原来优先级为k+1至n的分机的优先级分别设置为1至n-k, 将原优先级为1至k的分机的优先级设置为n-k+1至n。
基于防碰撞技术的数据传输系统的软件流程图如图3所示。
4 小结
参考CSMA/CD构建载波监听多路访问/冲突检测工作原理, 设计基于“错时等待”策略的监听信道忙延时等待算法和通讯冲突延时等待算法, 有效地降低信道争用的冲突问题。特别是处理信道争用二次冲突方面, 与一般的CSMA/CD退避算法[5]比较, 有着明显的优势, 从而大大提高了信息传输的实时性。
参考文献
[1]陈红梅, 陈健.一种无线语音传输系统设计方案[J].西安电子科技大学通信工程学院 (710071)
[2]防数据碰撞的无线呼叫系统设计[J].单片机嵌入式系统应用, 2004 (2) .
[3]黎琼, 徐海峰.智能家居中红外控制系统通讯协议分析[J].微计算机信息 (测控自动化) , 2007 (1) :28-30.
[4]林雪明.医院护理呼叫通讯系统设计及防冲突算法研究[J].电子技术应用2009 (6) .
语音传输 篇4
目前,现场总线已经发展成为集计算机网络、现场控制、生产管理等内容于一体的现场总线控制系统FCS(Field-bus Control System)。CAN总线由于具有结构简单、连接方便、数据可靠性高、通信实时性强、节点设置不受限制、通信介质无特殊要求以及易实现多主结构等优点,已广泛应用于工业生产的各个环节[1,2]。
排队论(queuing theory) 主要应用于计算机网络、生产、运输、库存等各项资源共享的随机服务系统。它研究的内容有3个方面 :系统的性态 ,即与排队有关的数量指标的概率规律性;系统的优化问题 ;统计推断,根据资料合理建立模型。其目的是正确设计和有效运行各个服务系统,使之发挥最佳效益[3]。
本文基于排队论对CAN总线协议建立了M/M/1队列模型,仿真分析了语音与数据混合传输的性能指标,同时使用硬件通信系统进行实验测试,实现了语音与数据的混合传输。
1 系统性能仿真分析
1.1 系统模型的建立
系统负荷对语音通信质量的影响主要表现为当系统的负荷增加时,系统的传输时延增加。下面从CAN的数据链路层的传输协议入手,分析系统负荷对传输时延的影响。
CAN的通信介质访问协议为载波监听多路获取/冲突避免(CSMA/CA)[1],采用多主竞争方式结构:网络上任意节点均可以在任意时刻主动地向网络上其它节点发送信息,而不分主从,即当发现总线空闲时,各个节点都有权使用网络。在发生冲突时,采用非破坏性总线优先仲裁技术:当几个节点同时向网络发送消息时,运用逐位仲裁原则,借助帧中开始部分的表示符,优先级低的节点主动停止发送数据,而优先级高的节点可以不受影响地继续发送信息,从而有效地避免了总线冲突,使信息和时间均无损失。
因此,从CAN的通信介质访问协议来看,CAN处理报文的过程可以看作为M/M/1队列模型。M/M/1是最简单的排队系统模型[3]。在该排队系统中,第一个M代表顾客的到达时间间隔,第二个M代表服务时间,二者均为指数分布,1为服务台数。在该队列模型中,将顾客的平均服务率看作为帧的传送率μ,即为CAN总线的带宽B,也是单个帧传输时间τ的倒数,即μ=B=1/τ。将顾客的平均到达率看作为网络的帧产生率,可由式(1)求得。
设网络中各节点的数据帧产生率为λi,网络的节点数为M,则网络的帧产生率λ:
undefined
所以,网络的负载率ρ=λ/μ。
很明显,在任何随机排队系统中,若ρ>1,则队列会无限地增长。这是一种不稳定的现象,不是研究对象。在CAN网络中要求ρ=λ/μ≤1。
由M/M/1模型所满足的微分方程可以得到本模型的状态微分方程:
undefined
式中:pk为在t时刻服务队列长度为k的概率,k=0,1,2,…;p′k(t)为pk(t)的导函数。
当系统达到平衡状态时,由数学期望可求得网络中的平均帧数undefined。
设t→∞时,pk(t)趋向稳定,即p′k(t)=0。
则pk(t)与t无关,可简记为pk。由式(2)可知:
undefined
利用递推法得到方程的通解为pk=ρkp0,利用undefined,可得:
undefined
由服务队列的概率生成函数undefinedpkzk可得出平均帧数undefined。
根据DC Little的理论,当一个帧被传送到对方节点且刚好离开系统时,系统中的平均帧数应正好等于该帧在系统中平均等待(延迟)时间T内到达的帧数,即undefined。由此可得帧的平均延迟时间:
undefined
1.2 模型的仿真结果及分析
模型分析采用的参数:CAN总线的数据传输速率为5 kbps、10 kbps、20 kbps、50 kbps、100 kbps,传输数据的字节数为8 B,系统负载率ρ在区间[0,1]间取值。对式(3)利用Matlab仿真,结果如图1所示。
在本系统中,对语音的通信要求是语音的压缩编码帧在20 ms内得到传输。从图1可看出,在帧传输平均时延为20 ms时,CAN总线的传输速率越大,系统的负载率越大,频带利用率越高;另一方面,传输速率越大,能传输的距离就越小。其中,传输速率为10 kbps时,负载率为0.68。不同的环境可选择不同的传输速率。
2 通信系统实验结果及分析
2.1 实验系统简述
本实验系统使用RS232BCAN智能转换器将现有的硬件系统构成一个小的实验通信网络,硬件系统主要包括:微控制器PIC18F258、语音处理模块AMBE-2000、A/D-D/A 转换器PCM3500以及一些外围电路,系统结构如图2所示。
2.2 实验测试结果
在硬件通信系统测试时,CAN总线传输速率设定为10 kbps,分别测试以下3种情况:
(1) 在CAN总线中只传输语音信号时,设定语音信号的发包率为500帧/s。
测试结果:在接收端判断语音有极小的延迟,几乎不能分辨,语音质量清晰、自然。
(2) 在CAN总线中只传输数据时,分别测试了数据包发送间隔时间为10 ms、20 ms、50 ms、100 ms、500 ms、1 000 ms情况下的数据发送和接收情况。
测试结果:数据包发送间隔为10 ms时,接收端收到的数据少于发送的数据,数据传输出现丢包;发送间隔分别为20 ms、50 ms、100 ms、500 ms、1 000 ms时,收到的数据和发送的数据相等,数据传输无丢包现象,20 ms为一极限值。
(3) 在CAN总线中混合传输语音信号和数据时,分别测试了数据发送间隔为1 ms、10 ms、20 ms、50 ms、100 ms、500 ms、1 000 ms情况下的数据发送和接收情况及语音传输情况,测试结果如表1所示。
CAN总线上语音和数据混合传输的情况下,数据发送间隔为20 ms和100 ms时的时序图如图3所示。
2.3 实验结果分析
在只传输语音的情况下,传输速率为500帧/s时,CAN总线负载率约为40%;在只传输数据的情况下,传输速率为500帧/s时,CAN总线负载率约为70%。语音和数据混合传输时,语音和数据的传输速率均为500帧/s时,CAN总线已超负载,通过RS232BCAN转换器可以测出数据有丢包现象,根据数据的传输优先级高于语音的传输优先级,理论上语音信号应该有丢包现象,但实验测试中,接收端语音仍较为清晰。原因分析如下:
(1) 当串口设置为1 ms发送1次数据时, RS232BCAN转换器并不能准确地按照要求及时发送数据。
(2) 设计电路板时,已从硬件和软件2个方面考虑到了允许丢包1/3。
(3) 实验仅用了2个CAN节点,同时发送的几率小,干扰也较小。
(4) 实验中对语音信号采用人耳倾听辨别主观评定法,在丢包较少的情况下,人耳无法辨别差别,并且人耳允许的声音延迟较大。
总之,实验测评的结果和理论分析的结果基本吻合,当CAN总线传输速率为10 kbps、负载率小于70%时,对语音信号的传输几乎无影响。
3 结语
本文通过理论分析和实验系统测试,证明可以在CAN总线上以极低的语音通信速率(3.2 kbps)进行语音与控制数据混合传输,并找到了比较合理的传输信息量匹配。整个系统结构简单、能耗低、具有极高的性价比,适用于工业生产监控系统中的语音通信和数据传输。
参考文献
[1]丁恩杰,马方清.监控系统与现场总线[M].徐州:中国矿业大学出版社,2003.
[2]雷煌.基于CAN总线的矿井分布式SCADA监控与数据采集系统[D].太原:太原理工大学,2002.
语音传输 篇5
近年来, 语音业务作为一种新兴的网络业务得到了广泛的应用。但是由于目前IP网络所采用的是尽力而为的服务方式[1], 造成在通话过程中存在着较大的通话时延、抖动和一定的丢包, 使得通话效果往往难以令人满意。一般来说, 端到端的通话时延不应超过400ms[2]。为了改进语音通信的服务质量, 有必要对实时语音流进行测试, 以获取时延、抖动等参数, 从而进一步分析影响通话效果的主要因素。
根据是否发送主动探针 (a c t i v e probe) , 网络测量技术可分为主动测量和被动测量技术[3]。主动测量是通过向网络发送探针来推测网络的情况, 被动测量是通过监听网络中已有的分组流来推测网络的情况。被动测量具有不影响网络负荷的优点, 因此, 本软件主要采用被动测量的思想, 实时加载一条真实的VoIP流, 并对该流的时延、抖动、丢包等服务质量参数进行测量和记录。
2、实时语音通信设计与实现
2.1 通信连接的建立
本软件所测试的对象为实时加载的一条VoIP流。为了实现更为真实的VoIP通信, 本软件采用最常见的VoIP通信模式, 采用服务器端进行连接管理, 客户端启动后首先连接到服务器获取所需通信的对端的连接信息, 然后建立与通信对端间的直接连接, 传输语音数据。连接建立过程依照SIP协议的相关规定, 其连接建立过程如图1所示。
2.2实时语音数据的采集与播放
为了实现交互式会话, 本系统采用多线程技术, 一个线程专门用来采集和发送语音分组, 另一个线程用来接收和播放对方发过来的语音数据。语音的采集和播放采用低级音频函数W a v e X, 其基本操作步骤如下。WaveX采用Windows消息映射机制来实现事件的处理。
2.2.1 音频数据的采集
(1) 打开录音设备:waveInOpen
(2) 为录音设备准备缓存:
waveInPrepareHeader
(3) 为输入设备增加缓存:
waveInAddBuffer
(4) 启动录音:waveInStart
(5) 清除缓存:
waveInUnprepareHeader
(6) 停止录音:waveInReset
(7) 关闭录音设备:waveInClose
2.2.2 音频数据的播放
(1) 打开输出设备:waveOutOpen
(2) 为输出设备准备缓存:
waveOutPrepareHeader
(3) 写数据到输出设备缓存:
waveOutWrite
(4) 清除输出缓存:
waveOutUnprepareHeader
(5) 停止输出:waveOutReset
(6) 关闭输出设备:waveOutClose
为了降低网络传输的数据量, 本系统采用G.729编码方案对语音数据进行压缩和解压。G.729将模拟信号以8Kbps的速率进行数字化, 并采用共轭代数结构代码预测法以8:1的比例进行压缩。
3、传输质量关键指标测量
本软件主要对语音流传输过程中的时延、抖动和丢包数这3个传输质量参数进行测量。为了计算时延和抖动, 通信两端需要进行时间同步, 以消除由于两客户端间的时间差造成的测量误差。
3.1 传输质量参数的计算
(1) 丢包
本软件能记录测试过程中被丢弃的数据包的总数 (packet＿lost) 。发送的每个语音数据分组将被附上16bit的数据包序号 (packet＿num) , 所有数据到达接收方后将被缓存, 播放时接收方检查所播放数据分组的序号, 每发现一个丢失的数据包packet＿lost增加1。每检测到一个延迟太大, 到达时其前后相邻数据包均已播放的包, packet＿lost也增加1, 该数据包将直接丢弃。
(2) 抖动计算
本软件所测试的抖动 (jitter) 是指两个相邻语音数据包的时延差值, 其计算公式见式1。这里delay1代表相邻的第一个包时延, delay2则是第二个包时延。
(3) 时延计算
现有的时延测量包括对双向时延和单向时延的测量, 端到端双向时延测量可简单地通过环回时延 (RTT, round trip time) 获得, 但是VoIP应用的性能更多依赖于单向性能, 因此本系统测量单向时延。时延delay为该数据包发送端开始发送的时刻 (t＿recv) 到接收端完成接收的时刻 (t＿s e n d) 之间的差值, 其计算如式2。
t＿recv和t＿send只能由发送端或接收端从本机时间读取, 而通信的两台计算机不可能精确时间同步, 会对所计算的时延的准确性产生影响, 因此本软件需要设计时间同步机制。
3.2 时间同步机制的设计
本软件采用相对时间来记录数据包的收发时刻, 客户端软件选择各自的系统开始运行时刻作为时间起点, t＿r e c v和t＿send为数据包收发的绝对时刻到时间起点间的间隔。本软件采用Query Performance Counter () 函数进行精确计时。该函数返回高精度性能计数器的值, 其计时的最小单位是CPU Tick, 还需要系统频率才能计算出所经过的时间。利用Query Performance Frequency () 函数可获得系统的频率值, 即每秒的T i c k数。n Start Counter是在发送端选取的时间起点处调用Query Performance Counter () 得到的开始点计数。nStopCounter是发送语音数据包时再次调用该函数时得到的计数值。本机发送时刻t＿sendtime的计算见式3, 该时刻将作为时间戳随数据包发送。同理, 可以得到接收刻t＿recv。
接收端收到数据包后读取时间戳t＿sendtime, 然后减去两机之间的时间差adjust, 得到t＿send用于计算delay。adjust反映通信两端之间时间起点时刻之间的差值, 由通信两端之间周期性做时间同步请求操作来获得。数据收发端之间的时间同步请求过程如图2所示。根据图2所示过程, 同步请求包传输时间delay＿time的计算见公式4, adjust的计算如式5。
4、结论
本文结合Winsock网络编程、WaveX低级音频API以及多线程技术, 设计并实现了一款实时语音流服务质量测试工具。在有线和无线局域网中进行的大量测试证明本系统能够实现两客户端之间的实时语音交互通信, 并能对该语音流的收发数据包数量、时延、抖动、丢包数等传输质量参数进行比较准确的测量和记录, 可供改变的测试参数包括采样位数、静音阈值等。
该软件还存在一定的不足, 采用多线程技术所引入的切换时间以及发送同步请求包所带来的时延会使得通信两端时间同步出现误差, 从而影响测量准确性。如何完善本测试工具的功能, 提高其测量准确性, 还需要进一步深入研究。
参考文献
[1]A.H.Muhamad Amin.VoIP performance measurement using QoS parameters[C].Proceedings of the Second International Conference on Innovation in Information Technology (IIT'05) , 2005:2-8.
[2]V.Paxson.End-to-end Internet Packet Dynamics[J].IEEE/ACM Transaction on Networking, 1999, 7 (3) :277-292.
[3]谢海波, 王海燕.无线局域网QOS技术发展综述[J].现代电信科技.2005, 34 (08) :50-53.
语音传输 篇6
GMR-1(Geostationary Earth Orbit Mobile Radio interface) 3G系统是欧洲电信标准委员会ETSI制定的可与地面3G核心网互联的地球同步卫星移动通信标准,由全球移动通信系统GSM标准衍化而来,提供基于同步卫星的移动通信业务,具有覆盖范围广、频率利用率高、不受地理条件限制和运营成本影响的特点,是地面蜂窝系统的必要扩展,在人烟稀少地区以及地面蜂窝系统受到严重破坏时,发挥着重要的作用。特别是今年来,随着移动互联网的发展,人们对网络的依赖度逐渐增高,对信息随时随地可以获取的需求逐渐增强,使得与互联网结合的宽带卫星通信系统不断发展,成为目前通信领域研究的一大热点。但是与地面通信相比,卫星通信因环境复杂存在数据传输延迟大,信道链路复杂,受外界环境影响大,易造成数据包的抖动,本文采用RTP(实时传输)协议,设计并实现一种缓存传输数据,通过绝对时钟对数据进行调度,降低数据抖动,实现语音数据的稳定传输。
2 GMR-1 3G系统介绍及协议结构
2.1 GMR-1 3G系统元素介绍
GMR-1 3G系统由GEO卫星、地球移动站MES(mobile earth station)、关口站(gateway station)、卫星操作中心(satellite operation center)、核心网C N(core network)、网管站OAM(operation administration and maintenance center)等模块组成,如图1所示。其中关口站的核心设备是基站收发台和基站控制器。一般来说,基站控制器可以控制若干基站收发台,其主要功能是进行无线信道管理、实施呼叫和通信链路的建立和拆除,并为本控制区内移动台的过区切换进行控制等。GMR-13G支持电路域话音、传真业务及支持分组域业务,其与核心网之间的Iu口其最高速率可达592kbit/s,极大的提高数据的传输速率。
2.2 GMR-1 3G协议结构介绍
本系统定义两个协议接口,分别为终端与关口站的uu口,关口站与核心网之间的lu口,终端到GEO卫星的上下行链路使用L波段其协议由下而上可分为物理层、数据链路层与层三,层三的作用在于无线资源管理、移动性管理和连续管理。GEO卫星到关口站的上下行链路使用ku或c波段,关口站分为信令处理单元与业务处理单元,语音数据处理单元为关口站业务处理单元模块主要由IUUP协议及RTP协议构成,用于实现与MES、CN的语音数据传输,如图2 所示。
其中Fp协议在于实现逻辑信道与物理信道的映射,IUUP协议是lu接口的无线网络层用户面协议,通常用来传输与RAB(Radio Access Bearers)相关的用户数据,一个IUUP实体对应一个RAB,IUUP实体与对应的RAB一起建立、删除和重配;IUUP通常有两种模式:透传模式与支持模式。透明模式下lu接口与其对等实例不进行任何IUUP协议信息交换,即不发送IUUP帧,其数据主要负载在RTP协议上,利用RTP协议缓存语音数据,根据特定的时间中断实现语音数据的低抖动传输,本文主要目标放在RTP协议及其实现上,并在下一节详细介绍RTP协议及其实现。
3 语音数据传输设计与实现
RTP(Realtime Transmission protocol)在协议层中的位置如图3 所示,下层采用UDP协议,能很好地保证传输的实时性,一般用于音频、视频方针数据等实时媒体应用中。
3.1 RTP数据包格式
RTP数据包格式主要分为RTP头,RTP负载如图4所示是RFC3550 中规定的RTP协议头格式。
版本号(V);2 bits,用来标志RTP的版本号。
填充位(P):1 bits,0 代表无填充字节,1,代表RTP包的尾部包含附加的填充字节。
扩展位(X):1 bits,0 代表无扩展头,1, 代表RTP包的尾部包含一个扩展头。
CSRC计数器(CC):4 bits,含有固定头部后面跟着的CSRC的数目。
标志位(M):1 bits,不同的有效载荷含义不同,对于视频标记为一帧的结束,对于音频标记为回话的开始。
载荷类型(PT): 7 bits,有效负载类型,用于说明RTP报文中有效载荷的类型。
序列号(Sequence number): 16 bits,用于标示发送者发送的RTP报文的序列号,每发送一个RTP报文,序列号加1,该字段用于当网络状况不好时,统计丢包数;
时间戳(Timestamp):32 bits时间戳反映了该RTP报文的第一个八位组的采样时刻,接收者使用时间戳来计算延迟和延迟抖动,并进行同步控制。
同步信源(SSRC):32 bits,用于标识同步信源,该标示符采用随机数随机产生,同一视频会议的两个同步源不同;
贡献源列表(CSRC list):每个CSRC标识符占32 bits, 可以有0~15 个,每个CSRC标识包含在该RTP报文有效载荷中的贡献源。
语音数据传输设计:话音数据传输中的低时延对用户体验非常重要,所以在话音数据传输过程中,通信双方采用socket网络数据报通信如图5 所示;
通信双方首先加载套接字库,创建本地socket,调用bind函数与本地IP及端口号绑定;
通信双方通过sendto(),recvfrom() 函数实现数据的发送及接收;
当通信结束调用closesocket关闭套接字回收资源。
4 话音数据传输流程及设计实现(如图6所示)
语音数据通过终端采集编解码之后发向基站,基站处将语音数据分为两个线程,接收线程与发送线程。其中接收线程根据数据来源区分上下行数据,下行则接RTP包,判断版本号及负载类型是否正确,序列号是否比最后一次收到的序列号大,大则放入下行发送数据缓存区,否则丢弃,上行则加入必要的RTP头信息,放入到上行发送缓冲区,接收线程继续判断是否收到新数据。发送线程主要是根据时间戳判断当前时间与发送时间之间的时间差,利用select()精确延时判断发送时刻,将上下行数据低抖动发送到对应的接收端。
4.1 语音数据发送时间延时测量
为精确统计发送数据包的时刻且不影响发送线程,我们采用网口数据捕获工具wireshark,该软件早期称为ethereal,使用Win PCAP接口直接与网卡进行数据报文交换,使用显示过滤器筛选数据源发送端口过滤出必要信息通过统计时间判断时延抖动,如图7 所示。
4.2 结果分析
本设计中发送线程首先根据上行TM数据的RTP实体中保存的时间戳计算出发送时间,在利用Linux系统函数gettimeofday() 函数获取当前时间,两者相减获取时间偏移量,利用select()函数提供的延时功能消减数据包的抖动,此设计可动态调整发送时间;在测试结果中可以看出最大偏移40ms时间间隔为39.86s且在数据统计中出现次数较少,其余数据包间隔基本在40ms左右,总体标准偏差为0.06,利用数学方差公式:
计算统计标准偏差方差为0.00389,且方差用于统计数据抖动的大小,从而可以看出我们所设计传输方案可保证语音数据的低抖动传输;
5 总结
GMR-1 3G系统支持话音域,分组域及传真业务,卫星通信中复杂的传输环境给话音传输低抖动提出非常大的挑战,话音业务的能否稳定传输严重影响用户的通话体验;本文通过设计多线程将语音接收与发送分离,利用RTP实时传输协议实现了一种低抖动话音数据传输,通过结果数据统计分析,数据传输抖动小,很好地保证了话音质量。
参考文献
[1] Douglas E.Comer.Internet working with TCP/IP,Volume Prineiples,Protoeols,and Arehiteeture(Fifth Edition)[M].Beijing:The People's Posts and Telecommunications Press,2009(7):65-69
[2] 3GPPTS 29.007 V4.14.0[S
[3] GEO-Mobile Radio Interface Specifications;Part 4:Radio interface protocol specification;Sub-part 8:Mobile Radio Interface Layer 3 Specification;GMR-1 04.008[S
[4] GEO-Mobile Radio Interface Specification:Part3 network specification;sub-part18:terminal-to-terminal call(TtT);GMR-1 03.296[S]
[5] GEO-Mobile Radio Interface Specification:Part3 network specification;sub-part 20:Technical realization of HighPenetration Alerting;GMR-1 03.298[S]
[6] GEO-Mobile Radio Interface Specification;part 4:Radio interface protocol specification;sub-part 6:Mobile earth station-Gateway Station Interface Data Link Layer specification;GMR-1 04.006[S]
语音传输 篇7
短距离红外通信多采用编码方式实现, 如果单纯考虑语音通信时, 可理解为是模拟信号的传输, 此时可以不采用编码方式, 只要接收方能正确把发送方信号还原成语音 (模拟) 信号即可, 基于此, 本设计的思想是把语音信号通过单片机A/D采集后按信号幅度调制成不同占空比的PWM信号后送红外管发送 (对于进入A/D之前的信号及接收后的音频信号放大等处理本文不做探讨) 。
2 硬件设计
2.1 STC12CA60S2简介
STC12CA60S2是STC生产的单时钟/机器周期 (1T) 的单片机, 是高速、低功耗、超强抗干扰的新一代8051单片机, 指令代码完全兼容传统8051, 但速度快8-12倍。内部集成MAX810专用复位电路, 2路8位PWM, 8路高速10位A/D转换器。
2.2 发送端设计
STC12CA60S2时钟电路、复位电路可与传统51单片机相同, 通过对模拟输入通道功能控制寄存器P1ASF的设置, 采用P1.1对应的通道1做为音频信号的输入端, 可将经前置处理好的模拟音频信号从此脚引入, 实现音频信号到数字信号的转换。通过对工作模式寄存器CMOD设置, 采用系统时钟2分频做计数脉部源, 实现频率为21k Hz的PWM信号, 脉冲宽度实时与采集到的音频数字信号成正比例对应 (仅用高8位) 用脉宽直接反映音频信号的幅值从P1.3引脚输出, 将P1.3连接到红外发送管进行红外发送。
2.3 接收端设计
接收端直接使用一体化红外接收管结合功率放大电路接扬声器。
3 软件设计
3.1 程序框图
3.2 源代码
4 结束语
本设计用PWM产生21k Hz的信号用于红外语音传输, 经过实际测试, 踞离可达2米, 对于红外发射管来说把信号调制成38k H时传输距离最远, 如想调制成38k Hz信号传输, 可在单片机外部增加一个与门, 把P1.7引脚输出的方波同P1.3输出语音信号与运算后实现。
摘要：红外通信以其成本低、实现容易的优点, 在短距离通信中得到广泛的应用。本文探讨使用STC12CA60S2单片机的内置A/D及PWM功能实现红外语音通信的一种简易方法。
关键词：红外语音通信,STC12CA60S2,信息传输
参考文献
[1]丁向荣.单片微机原理与接口技术-基于STC15系列单片机[M].电子工业出版社, 2012:219-246.
[2]郭天祥.51单片机C语言教程[M].电子工业出版社, 2009:282-298.