学文网数据采集论文第1篇
基于表层化方式的DeepWeb数据采集方法将DeepWeb数据采集问题建模为一个优化问题:已知一个DeepWeb数据库DB,对DB的采集可以表示为寻找一个查询集合Q={q1,q2,...,qn},在给定的约束条件C满足的条件下,查询集合Q从DB获取的DeepWeb数据最多,即查询集合Q对DeepWeb数据库资源的覆盖率达到最大。其中,C表示许向Web数据库提交查询请求的次数。基于表层化方式的DeepWeb数据采集问题的目标就是针对一个给定的DeepWeb数据库,寻找一组查询集合,使用该查询集合能够对DeepWeb数据库资源的覆盖率达到最大。基于表层化的方法的主要思想是通过向DeepWeb数据的查询接口提交查询把数据从Web数据库中挖掘出来。这方法能够充分利用搜索引擎爬虫,将DeepWeb数据的采集转换为SurfaceWeb数据采集的方式,不需要做很大的改变就可以无缝的将DeepWeb数据集成到现有的搜索引擎中。基于表层化方式的DeepWeb数据采集方法的关键是为查询接口生成合适的查询,其目标是为DeepWeb数据的查询接口生成有效的查询实例,构造表单查询,以便将Web数据库中的内容发现出来。一个查询接口可能包含多个输入项,如果每个输入项有100个有效的取值,那么对于一个有3个输入项的查询接口,组合生成的查询数量是1,000,000。因此,在迚行DeepWeb数据采集时,为每个查询接口生成所有可能的查询是不实际的。而且,对于查询接口中的一些文本输入项,其对应的有效的取值进不止100个,如***书查询接口的书名,作者等。基于表层化方法的DeepWeb数据采集的目标是以最小的查询数量达到最大的DeepWeb数据覆盖率。因此,如何为查询接口生成有效的查询是实现DeepWeb数据覆盖率最大化的重要环节。目前,针对这一问题的研究主要有基于词频的方法[11],基于集合覆盖的方法[12,13],基于强化学习(ReinforcementLearning,RL)的方法[14-16],面向领域的方法(HiWE[17]、DeepBot[18,19]),基于属性值***的方法[20],基于查询模板的方法[21],基于本体的方法[22-24]等。通过对查询接口的分析发现,查询接口根据输入项素的个数可分为:简单查询接口(SimpleQueryInterface)和复杂查询接口(ComplexQueryInterface)。简单查询接口包含一个输入项,即为简单的关键字查询接口,使用方式与搜索引擎接口一样;复杂查询接口则包含两个或多个输入项。因此,本文根据查询构造方法支持的接口类型将已有工作分为两类:简单查询接口查询构造方法,复杂查询接口查询构造方法。
1.1简单查询接口查询构造方法简单查询接口只有一个输入项,因此,对简单查询接口迚行查询构造时并不需要考虑表单输入项乊间的关系,只需要为该输入项生成候选查询关键字集合。基于词频的方法[11],基于集合覆盖的方法[12,13],基于强化学习(ReinforcementLearning,RL)的方法[14-16]属于此类的研究。基于词频的方法[11]基于一个假设:在实际数据库或文档集合中的高频词比随机选择的词具有更高的资源覆盖能力,而且高频词作为查询能够获取更多的查询结果。因此,该方法对简单搜索接口所在页面和查询返回的结果迚行抽样,然后在每一轮查询结果中选择高频词构造查询迚行资源采集。但是该方法有个明显的不足:在每次查询时,高频词无法确保获取更多的新页面。为此,Wang等人[12,13]将DeepWeb数据库采集问题建模为集合覆盖问题,利用目标数据库采样方法迚行DeepWeb数据爬取:首先从目标数据库中获取部分样本,引入文档权重和查询权重,基于文档权重和查询权重利用贪心选择策略选择能够覆盖样本数据库的文档重复率低的查询词集合,使用该查询词集合采集目标数据库。该方法将原始数据库的查询选择转换为对样本数据库的查询选择问题。但是该方法无法保证样本数据与目标数据库是同分布的,因此覆盖样本数据库的查询词集合可能不适用于整个目标数据库。为此,Jiang和Wu等人提出了基于强化学习(RL)的DeepWeb数据采集框架[14-16],该方法与以往方法的有很大的不同:乊前的方法大多是基于统计信息选择查询,如词频,文档频率,词频-逆文档频率:而该方法不仅利用统计信息,还利用语言特征(词性、词的长度、语)以及HTML本身的特征(关键词的标签、属性信息、位置信息等)[14]。RL方法许爬虫根据从已执行的查询中获取经验,自动学习查询选择策略,从而为每一轮查询选择收益最大的查询关键词迚行资源采集。该方法充分利用查询关键词的不同特征和爬虫的爬取经验,自动的确定当前最优的查询选择,减少了爬虫的采集负载和大量空结果集的出现。但是该方法学习过程相对复杂,并且仅能应用于GET提交方法的表单,无法应用于POST类型的提交表单。
1.2复杂查询接口查询构造方法不同于简单查询接口,复杂查询接口包含两个或多个输入项,对于表单中的选择输入项(如select,radio,checkbox)其输入值是确定的,但是文本输入项(如text)的值则是无法确定的,文本输入项可能只接受数值类型的输入值(如商品价栺)也可能只接受区间类型的输入值(如日期),而且表单不同的输入项乊间可能存在关联关系。值得注意的是,复杂查询接口并不一定为所有的输入项都准备输入值才能获得查询结果,因此,对复杂查询接口迚行查询构造时,首先需要确定输入项的值域或约束,然后选择迚行查询构造的输入项并为其准备输入值,生成表单查询实例。HiWE[17],DeepBot[18,19],基于属性值***的方法[20],基于查询模板的方法[21],基于本体的方法[22-24]等则属于此类工作。HiWE[17]是一面向特定领域(仸务)的采集方法,该方法需要人工提供领域属性及属性取值集合,并且通过查询接口属性集合与领域属性集合的相似性刞断,自动选择领域相关的查询接口;接着利用人工提供的属性取值填充表单,生成表单查询;然后迚行DeepWeb数据的采集,并根据采集经验利用表单选择输入项素的取值更新属性取值。但是该方法没有考虑自动为文本输入项产生新的查询词,只能依赖人工提供的知识。不同于HiWE,Wu[20]提出一基于属性值***的查询构造方法。该方法将基于查询的DeepWeb数据采集建模为***的遍历问题:定义基于属性值的***模型,将一个结构化的Web数据库看作是一个单一关系的数据表,每个属性值为***中的一个结点,边为两个不同的属性取值在一个数据实例中的共现关系。该工作得出结论认为结构化的数据库属性值***中结点的度分布与幂律分布(powerlaw)相似,并以此为依据采用贪心选择策略选择度大的结点生成表单查询。但是该方法需要将每一次的查询结果更新到已有的属性值***中,然后选择下一个新的待提交的查询词,这方法更新属性值***的代价较高。DeepBot[18,19]是一个基于浏览器内核开发的DeepWeb数据采集的框架,它与HiWE类似,都采用面向特定领域的方式。DeepBot接受一组领域定义集合作为输入,自动识别与该集合相关的表单;然后利用领域定义集合为匹配的表单素赋值,生成表单查询。其中,领域定义集合用于定义采集仸务。该方法通过领域定义与表单乊间的相似度计算自动选择匹配的表单,许表单素和领域定义乊间存在不完全匹配的情况。DeepBot采用浏览器内核解决网页客户端浏览器脚本解析问题,但是该方法完全依赖人工提供的领域定义集合,不能自动产生新的查询词。为此,Madhavan[21]提出了一基于查询模板的DeepWeb数据自动采集方法,该方法自动刞断查询接口中输入素接受的数据类型,选择查询接口中的输入项的一个子集作为约束项构造查询模板。在约束项乊间利用笛卡尔积的形式产生不同的查询请求。约束项的取值有两方式确定:对于选择输入项,则利用查询接口提供的取值集合;对于文本输入项,首先利用表单所在页面的信息构造刜始候选词,然后从查询结果文档中提取额外的关键词更新候选词列表,重复该步骤直到不能提取新的关键词为止或是达到停止条件,最后将这些查询词作为该文本输入项的取值集合。该方法通过表单查询返回结果验证查询模板的有效性,并且采用自底向上的有效模板的增量式算法构造查询模板。虽然该方法能够自动实现DeepWeb数据查询请求的生成,但是对于包含多个输入项的查询接口来说,其对应文本输入项取值集合的确定,查询模板有效性的验证过程复杂,导致DeepWeb数据采集的效率较低。基于本体的查询构造方法[22-24]与上述方法不同,该方法通过本体直接定义查询接口中每个素的类型和取值以及素乊间的依赖关系,将本体作为输入直接生成表单查询。[22]是一针对语义网环境的DeepWeb数据查询方法。[23]是一基于本体的属性自动抽取和查询转换方法,该方法将WordNet作为本体,利用本体在DeepWeb数据中加入语义层实现表单查询的生成。[24]是一基于面向实体DeepWeb数据查询的方法,该方法将Freebase作为本体知识,利用本体和查询日志(querylogs)产生实体查询,用于DeepWeb数据的采集。但是基于本体的方法与HiWE和DeepBot类似都依赖外部的人工指定的输入信息,自适应性差。
2DeepWeb数据采集查询构造方法分析
仸何一查询构造方法的一个非常重要的特征是其自动化程度,这是指在查询构造过程中需要用户完成的工作量。除此乊外,由于DeepWeb数据面向的领域广泛,类型多样,因此,查询构造方法最需要具备扩展性,如:在DeepWeb数据源的类型或领域发生变化时,该方法仍然能够正常工作。本节从支持的查询接口提交方法,查询词提供方式,自动化程度,扩展性角度对比分析目前已有的查询构造方法。表1是目前已有的查询构造方法定性比较的结果,在自动化程度一列,“AUTO”表示完全自动、“SEMI”表示半自动、“NO”表示人工完成。在扩展性方面,划分为三个层次,分别用“好”、“中”、“差”表示使用相关方法或工具的可扩展程度。基于表层化方法的DeepWeb数据采集的目标是以最小的查询数量达到最大的DeepWeb数据覆盖率,因此,构造的表单查询的好坏直接影响目标的实现。虽然已有的查询构造方法能够表明确实可以使大量的DeepWeb数据内容对用户可见,但它也存在一些局限性,如表2所示。从表1可以看出,这些查询构造方法只能处理提交方法是GET类型的DeepWeb数据库,不能应用于使用POST方法的DeepWeb数据库。除此乊外,从表2可以看出,已有的查询构造方法都存在不同程度的局限性。通过对相关工作的分析可以看出,目前,缺少一能够同时处理GET和POST提交方法,具备自动,可扩展应用到不同领域的表单查询构造方法。因此,DeepWeb数据采集的查询构造方法仍然需要做迚一步的研究。表层化的方法通过向DeepWeb数据的查询接口提交查询把数据从DeepWeb数据库中挖掘出来,得到的DeepWeb数据可以用于构造以数据分析和挖掘为目的的各应用或是数据集成应用。利用该方法迚行DeepWeb数据采集有以下优点:(1)该方法能够无缝的集成搜索引擎爬虫,不需要对搜索引擎爬虫做改动就可以实现DeepWeb数据的采集;(2)基于表层化方法的DeepWeb数据采集系统可以将对应的DeepWeb数据库的数据保存到本地,这样可以根据需求对得到的DeepWeb数据迚行预处理,如:连接来自不同DeepWeb数据库的数据,初除重复内容等;可以为DeepWeb数据预先创建索引,以便快速响应用户查询请求;(4)该方法可以使从DeepWeb数据库得到的内容和从SurfaceWeb得到的内容以相同方式采集。虽然基于表层化处理方式的DeepWeb数据采集方法确实可以使大量的DeepWeb数据内容对搜索引擎用户可见,但它也存在严重的局限性。(1)有很大一部分DeepWeb数据库的内容无法通过现有的DeepWeb数据采集技术爬取到,原因在于,目前的表层化处理方法只能处理查询接口的提交方法是GET类型的DeepWeb数据库,不能应用于使用POST方法的DeepWeb数据库;(2)该方法对保持采集的DeepWeb数据库的数据的时新性(datafreshness)非常困难,因为DeepWeb数据库的内容是动态,多变的,搜索引擎爬虫可能无法跟上快速变化的DeepWeb数据。表层化的方法面临的最大的挑战是如何为DeepWeb数据库的查询接口选择合适的查询,这涉及到两个主要问题:第一,需要为查询接口中的各表单输入项找出合适的输入值,对于表单中的选择输入项(如下拉、单选、多选等),它们的输入值是已知的,可以直接利用查询接口中提供的取值即可,但是对于表单中的文本输入项,则需要为其预测合适的输入值;第二,必须控制向查询接口提交查询请求的数量,以免对DeepWeb数据库的提供商(DeepWeb数据所在站点)带来不合理的负载。通过对表层化方式的DeepWeb数据采集方法分析,我们发现现有的表层化方法在解决DeepWeb数据采集的难题时,也存在不同程度的局限性,这导致现有的DeepWeb数据采集方法难满足大数据的规模性,多样性和高速性的特点,因此如何克服现有DeepWeb数据采集方法的局限性,在现有方法的基础上做出迚一步改迚是未来需要研究的问题。
3研究展望
数据采集论文第2篇
多路视频数据实时采集的软件实现
常永亮(飞行试验研究院测试所陕西西安710089)
【摘要】介绍了视频数据的采集、多路视频数据间的切换、视频数据的保存及基于C/S结构的实时视频数据传输与显示，在对四路飞行视频数据进行实时采集的运行时，各项需求已达到要求。
【关键词】视频数据、Divx编码、RTP/RTCP协议、TCP/UDP协议、媒体流、帧
1引言
随着信息技术的不断发展，人们将计算机技术引入视频采集、视频处理领域，用计算机处理视频信息和用数字传输视频数据在很多领域已有广泛的应用，在我们的飞机试飞中也被大量的应用。
视频***像采集的方法较多，基本可分为2大类：数字信号采集和模拟信号采集。前者采用***像采集芯片组完成***像的采集、帧存储器地址生成以及***像数据的刷新；除了要对采集模式进行设定外，主处理器不参与采集过程，我们只要在相应的帧存储器地址取出采集到的视频数据即可得到相应的视频数据，这种方法，无论在功能、性能、可靠性、速度等各方面都得到了显著的提高，但成本高。后者采用通用视频A/D转换器实现***像的采集，其特点是数据采集占用CPU的时间，对处理器的速度要求高，成本低、易于实现，能够满足某些***像采集系统的需要。
此系统要求每秒采最大25帧（设为可调），客户端实时显示最大25帧（设为可调），保存为MPEG4格式，画面要求为最大分辩率为1024X768。
多路视频实时采集使用的是VisionRGB-PRO卡（英国Datapath公司），此卡可同时实时采集两路视频数据，基本达到了本系统的要求，再用一台VGA矩阵切换器将前端数据源的四路视频数据进行人为切换采集。
2硬件环境的构建（硬件框架）
***一系统硬件框架***
上***为整个采集系统的硬件框架。
此采集系统主要实现对前端四路视频数据的人为切换式实时采集，在服务器端可同时采集和储存两路视频数据（在此只用一个视频采集卡），也可以一次只采集一路视频数据，再经网络实时传输到客户端显示,服务器端也实时显示所采集的视频。
在进行视频切换方面可在服务器端或客户端自行切换，在服务器端可通过串行口操作VGA矩阵切换进行相应的视频输入输出口的切换，在客户端可通过网络－服务器程序相应模块－串行口－VGA矩阵切换进行相应的视频输入输出口的切换。
3软件实现概述
3.1服务器端的实现
***二服务器端程序流程***
上***为服务器端实时采集视频的程序流程***。视频数据量较大,这就要求视频数据处理系统具有实时采集,大容量存储和实时处理的特点。在服务器端的实现是整个系统的关键，在此也承担了大量的工作，因此对软件和硬件方面要求也很高就成为必然。
软件要实现对视频数据的实时采集（最多两路）、控制视频接口、把视频数据实时编码保存并发送到多个客户端。以上就是要在服务器上实现的主要功能。
在采集方面最主要的是要有实时性，在此以事件驱动的方法从端口获取数据，采集到视频数据流在桌面显示的同时再编码保存，视频采集的数据要经软件的相应模块将其设为位***型式的视频帧，以利于在服务器端的显示和编码保存，在此采用Divx编码，Divx编码后形成以帧为格式的MPEG4流。Divx解码也是以帧的格式解压，因此有利于向客户端发送数据时以帧为单位发送视频数据流。
此处用到Divx编码就不得不把Divx编码作简要的介绍。
DivX由DivXNetworks公司开发的，即为我们通常所说的DVDrip格式，它采用了MPEG4的压缩算法同时又综合了MPEG-4与MP3各方面的技术，也就是使用DivX压缩技术对DVD盘片的视频***像进行高质量压缩，同时用MP3或AC3对音频进行压缩，然后再将视频与音频合成并加上相应的外挂字幕文件而形成的视频格式。其画质直逼DVD并且体积只有DVD的数分之一。这种编码对机器的要求也不高，所以DivX视频编码技术可以说是一种对DVD造成威胁最大的新生视频压缩格式,实际上Divx=（视频）MPEG4+（音频）MP3。
媒体流分为四个流：视频流、音频流、文本流、MIDI流，用视频卡采集的是两路视频流，保存时每路视频流多加了一个文本流，文本流主要应客户要求加入的服务器时间和一些人为输入的文本信息，在记录两个媒体流时一般有两种记录方法，在此采用的是将视频流和文本流记到一个文件中的方式，这样有利于文件以后的保存和查阅。
在采集软件实现方面主要应用了相应的SDK（Softwaredevelopmentkit）和API(应用编程接口)，还可用VFW(VideoforWindows)。但后一种方法实现简单单路视频采集卡可以，对于多路视频的采集用第一种方法更加灵活，但实现比第二种复杂的多。在服务器实现软件方面主要有以下几大块：一是采集；二是保存；三是向客户端发送；四是串口的通行；五***像的形成；六是桌面显示；七是对***像亮度、颜色、位置等的调整；采集通道、采样率、采集时间的选择；等等。
在服务器端各方面协调工作是关键，程序启动首先默认上次设定的视频采集卡通道，如有视频数据就显示、保存，如果没有视频数据就等待，如果要调整视频采集卡通道可用串口给VGA矩阵切换器发送相应的命令让VGA矩阵切换器进行相应的输入输出通道切换。也可经客户端经网络到服务器串口到VGA矩阵切换器进行VGA矩阵切换器相应的输入输出通道切换（在后面介绍客户端时再介绍）。每次切换后将自动保存原视频文件，如切换后有视频数据将自动重新生成一个新的视频文件。
在服务器桌面显示的画面是没经任何编码处理的，但网络传输和保存的视频数据是经Divx编码的，这样有力的减轻了网络间传输和服务器的负担。
用局域网实时传输视频数据已在一些领域大量的应用，局域网以有线局域网居多，因为有线局域网技术成熟、传输速度快，但是长时间传输大量视频数据时也会引起传输速率不稳定，引起数据堵塞，会导致视频传输的质量大幅度下降，容易引起画面的重影、抖动、花屏、延迟等现象。
为了在局域网上有效的、高质量的实时传输媒体流，需要多种技术的支持，包括网络传输层协议的选择、编(解)码技术，网络传输层质量控制技术等等。
实时传输协议RTP是针对Internet上多媒体数据流的一个传输协议，实时传输控制协议RTCP负责管理传输质量在当前应用进程之间交换控制信息，RTP/RTCP协议只适合服务器端和客户端相对动态的实时多媒体数据流传输。但是，对于***像采集速度固定的实时视频采集，有时会引起采集的数据来不及压缩而直接丢弃而达不到实时的要求，所以没有采用RTP/RTCP协议，而是从发送端出发，实时判断网络状况，采用暂停发送的控制策略进行实时传输。
网络传输层质量控制技术采用的是TCP/UDP协议，UDP是一种不可靠的、无连接的协议,UDP适用于一次只传送少量数据、对可靠性要求不高的应用环境。它不提供检错和纠错功能，一旦网络出现堵塞时，大量的数据报文会丢失。对于Divx编解码技术，是以帧为单位进行编解码的，分为关键帧和非关键帧。在传输过程中，由于压缩率比较高，只要一帧中错一比特位，将影响其后的更多的比特位，直接造成***像的模糊、花屏等现象。只有等到下一次关键帧的到来才有可能恢复***像的清晰。为了保证传输的正确性，自己需要在应用层制定协议。如此一来，只能选择使用TCP来进行网络通信，TCP的目的是提供可靠的数据传输，并在相互进行通信的设备或服务之间保持一个虚拟连接。TCP在数据包接收无序、丢失或在交付期间被破坏时，负责数据恢复。它通过为其发送的每个数据包提供一个序号来完成此恢复。再辅助以暂停发送的控制策略，较好的解决局域网中实时视频传输容易引起的重影、抖动、花屏的问题。
为了达到视频传输的实时性，总的思想是最少的发送冗余信息，最大程度上发送最新的视频。
在服务器端视频采集采用从VisionRGB视频采集卡捕获视频***像，得到的是位***型式的视频帧，然后用Divx编码进行压缩，通过Winsock实现压缩后的视频数据在局域网中的实时传输，在客户端接收完的数据交给Divx解码器解压，最后实现视频显示。如***三所示:
***三网络间传输流程***
如果局域网通信速率很高且状态稳定，则进行实时视频传输就可以达到非常好的效果。但是在网络出现异常时会导致数据传输率不稳定或明显下降，造成发送端数据积压。此时就要采取一定的策略来控制发送端（服务器端），以达到实时性的要求，暂停发送策略很好的解决了这一现象。使用此策略有时会有丢帧的现象(100M局域网没有发现丢帧现象)，但就客户端的要求是满足的，在服务器端的采集、显示、保存不受暂停发送策略的影响，也就是不会有丢帧的现象,虽然应用了暂停发送策略，但已经能够满足在客户端实时监控需求了。
3.2客户端的实现
在上面讲服务器端的实现时已经大概讲到客户端的实现，因为只要把服务器端实现好客户端实现难点就小的多。如***四所示：
***四客户端程序流程***
在客户端也可以自行选择要采集的通道，但对服务器端的采样率等都不能通过客户端进行设置，实现客户端时主要是要实时监听和服务器网络连接状态和判断接受的视频数据是否正常是否启用暂停发送策略等。每秒接收的帧数可自行调节，但不能大于服务器端每秒采集的帧数。
在客户端还要实时Divx解码,如果不解码就无法显示，Divx解码速度是完全可以达到实时显示的要求。Divx解码和显示在不同的两个线程中实现的，这样做主要是为了显示流畅。可以在两个不同客户端显示两个不同的视频通道采集的数据。
4结论
本系统作为电视跟踪系统的一部分,负责多路视频数据的实时采集、存储和视频编解码算法的实现、基于C/S结构的实时视频数据传输显示，在通过各种测试后在试运行期间已达到本系统的预期要求，本系统还支持事后的视频回放。
本系统的开发难点和重点在服务器端，服务器端的开发直接影响到整个系统开发。
参考文献
[1]《Windows核心编程》Microsoft公司〔美〕著
数据采集论文第3篇
通过对电极形状、数目的选择，接地屏蔽层的合理设计和对传感器结构参数的比较优化，最终确定传感器模块采用16极板的ECT系统传感器。为便于在设计中及时发现错误并改正，提高工作效率，设计了基于FPGA的数据采集系统，该方法能够根据需要实现系统的重构。另外，为了有效地抑制杂散电容干扰，采用锁相环技术实现相干检测，进一步完成了对C/V转换电路的设计。计算机成像模块通过接口电路将数据缓存区的数据传输给计算机，采用迭代算法实现对***像的重建。
2传感器模块
ECT系统由均匀安装在管道表面的电极对组成，目前常用的有8极板、12极板、16极板等模型，极板数目越多，则可以获得的测量数据就越多，数据源的增多将提高重建***像的显示质量，然而也会引入信噪比降低、边缘效应增大等隐形问题。综合考虑采用16极板的传感器系统。
3数据采集系统设计和处理模块
结合航空发动机实际工作情况，可知此数据采集过程需满足高速率、高精度、大存储量以及对环境适应性强的性能要求，基于以上比较，本文选取FPGA芯片作为核心的逻辑控制器件。该器件选用Xilinx公司的Spartan—3系列FP-GA芯片，其核心芯片为XC3s500E。选用LTC1407型A/D转换器，VerilogHDL语言作为描述语言实现了对整个系统的采样、数据处理等过程的控制，并以XilinxISEDesignSuite13．1软件为平台，仿真验证了这一系统的可行性。
3．1C/V转换电路
电容作为一个特殊物理量，测量系统中存在的杂散电容值往往要大于被测电容值，而基于ECT技术的测量系统对微小电容的检测存在一定的局限性，因此，应系统要求，本文选择了抗杂散电容能力较强的物理电路。
3．2A/D转换电路
本系统采用的A/D转换电路是一个双通道的模拟信号采集电路，它由可变增益放大器LTC6912—1和A/D转换芯片LTC1407—1两部分组成。通过外部调节，自主改变可变增益放大器的放大倍数可以为芯片提供合适的电压信号，从而提高整个系统的转换精度。
3．3系统流程控制
考虑到FPGA不善长流程控制，在本文设计中引入了MCU软核，用于数据采集过程的流程控制。
4计算机成像模块
***像重建基本思想是依据有限的投影数据，采用简单有效的***像重建算法以实现Radon逆变换的过程。其主要数学理论基础是基于Radon变换和Radon逆变换，奥地利数学家Radon于20世纪初期在其发表的论文中证明，任何N维物体可以通过其N－1维投影来重建。
5仿真结果与验证
由于航空发动机尾气是多相流介质，且各项介质具有不同的相对介电常数。一旦发动机尾气内组分浓度发生变化，相应地就会引起多相流混合介质等价介电常数发生变化，并导致极板间电容值和实时采集的投影数据皆更变的连锁效应，为模拟管内充满相对介电常数为1的物质时所测得的120个电容测量值。如果其中掺杂进去相对介电常数为3的物质流，便可得到120组新的电容测量数据，由数据通过计算机成像便可重建出管道内物质分布，如***10所示，***中四幅***像表示发动机管中存在相对介电常数为3的物质流由汇聚到摊开的形状变化过程。结果表明:当设计管道内放入两相或多相介质时，通过本系统能够成功采集数据，并经USB接口传送给计算机能实现***像重建，最终重建出飞机发动机中介质分布***像，验证了本设计的可行性。
6结束语
数据采集论文第4篇
1.1系统架构设计系统采用客户端/服务器端形式，基于SOA模式并结合三层架构理论搭建，客户端基于iOS系统通过Xcode结合ArcGISAPIforiOS定制开发，分为数据管理层、服务层与终端应用层三部分。（1）系统数据访问层主要对森林抚育相关不同数据进行分类管理维护。外业采集数据、省、县及小班森林抚育评价信息数据、用户信息、实时定位导航数据为动态数据，基础地理信息数据、影像数据采用文件形式由SQLServer2008与ArcGIS综合作用维护管理。（2）服务层，代表森林抚育检查验收数据采集系统的核心功能，同时负责处理数据访问层数据与实现应用终端地***操作、显示更新、路径导航，数据存储等业务逻辑，整合共享各种功能、信息。（3）终端应用层是系统核心模块，完成系统定位导航，信息录入与森林抚育质量评价工作。与服务层信息交互，发出与接收服务请求，调用服务层所服务完成受检单位资料***，***地***加载等功能，并传输信息数据至服务层以完成对受检人员实时定位、采集数据上传的工作。
1.2系统功能设计在对系统流程与架构全方位了解后，对系统各部分功能模块进行深入分析，系统需具备以下功能模块。（1）GIS与导航定位功能模块，实现在检查人员确定受检小班后，数据采集系统定位检查人员当前位置并由矢量地***显示由当前位置到受检小班的路径、方位、距离信息。（2）森林抚育数据采集功能与评价模块。GPS定位位置属于受检小班内部时，数据采集功能模块会呈现为可工作状态，检查人员进行实地测量，将样地树种组成、龄组、经纬度、胸径、伐根地径等信息录入采集系统，系统结合已导入系统的受检地材积表自动计算用于森林抚育质量评价的各项参数并按照《全国森林抚育检查验收办法》森林抚育质量评价得分标准对受检小班各个方面进行打分工作并汇总上报到上级单位森林抚育检查验收服务器。
2系统实现
2.1系统服务器端关键技术及其实现系统服务器端部署基于WebService，服务端程序负责接收移动终端通过SOAP所封装的请求，通过HTTP协议传至Web服务器，进行数据信息交互以实现对移动终端实时定位追踪，管理空间与属性数据，并对移动终端所发回数据进行编辑汇总调用相应服务，将所请求服务解析为xml消息并返回移动终端。
2.2iOS客户端关键技术及其实现
2.2.1移动空间定位技术系统采用iOSSDK所提供CoreLocation移动定位技术定制开发，CoreLocation提供GPS、蜂窝基站、Wi-Fi三种方式对空间地理位置进行定位。通过创建定位管理器并对精度以及定位更新时间间隔进行设置，CoreLocation根据设置自动选择定位方式并将定位数据录入系统供地***功能模块使用。
2.2.2地理***层与加载系统GIS系统功能模块基于ArcGISAPIforiOS进行开发定制，所加载地***分为***地***与离线地***两类。***地***是由移动终端获取服务器端由ArcGISServer所受检县地理***层数据以及受检小班空间地理位置。离线地***数据是考虑到有些受检小班地处偏远地带，无线信号较弱，无法访问服务器，通过ArcGISAPIforiOS中的AGSTiledLayer类建立离线***层访问，加载预存于移动数据采集系统的地理***层缓存数据用以数据采集工作。
3结语
数据采集论文第5篇
关键词：EPPCPLDFIFO数据采集
数据采集系统中，通过微机COM端口的RS-232串行通讯及通过微机并行端口的并行通讯具有开发使用方便的特点，前者可与工作于11.0592MHz晶振下的8052单片机在波特率115200时，实现10ksps(samplespersecond)的连续数据采集和传输而不丢失数据，若要达到更高速率的数据采集，可以通过并行口通讯方式实现。当前微机均可通过配置CMOS，将基地址为378H的并行口设置为EPP模式以支持通过数据口双向传输通讯，并由芯片硬件自动产生握手信号，实现高速传输的目的。
为充分实现EPP模式的高速特性，外设应当及时响应EPP的握手信号，当数据采集系统工作于非实时多任务的WIN98操作系统环境下，为实现数据高速、均匀性采样，还需要在外设配置必要的数据缓冲存储器。如果数据采集速率低于EPP模式数据读入平均速率，就可能实现数据的连贯有效性。有资料[1]说明在EPP模式，可实现500kBytes/s以上的传输速率，这表明通过EPP模式，可以实现500ksps的数据采集系统。通过对EPP模式的深入实验分析，发现要实现500ksps，外设硬件及微机软件程序均要采取一些策略：硬件上必须配置FIFO数据缓冲存储器，才能协调数据采集严格的时间间隔要求与数据传输给微机的非实时、非均匀性之间的矛盾；软件程序方面应当采取双字读的方法，否则EPP模式下仅能实现250kBytes/s数据读取可行性。
1EPP模式读取速率的实验分析
***1为实验EPP模式读取速率的电路，实验程序为
Delphi结合内嵌汇编语言，涉及EPP读取的关键代码如下：
FUNCTIONREADDATA:BYTE;
VAR
STARTTIME,STOPTIME,DELAY:INT64;
NUMBER:LONGWORD;
QUERYPERFORMANCECOUNTER(STARTTIME);
FORNUMBER:=0TO999999DO
BEGIN
A***
MOVDX,$37C
INAL,DX
MOVRESULT,AL
END;
END;
QUERYPERFORMANCECOUNTER(STOPTIME);
DELAY:=STOPTTIME-STARTTIME;
END;
此为循环1000000次读取EPP数据口程序，循环仅为方便用计时及示波器观察而设，并在执行前后分别读取系统计数值，DELAY值除以1.2后为执行花费的时间（单位为微秒），执行前先通过对地址379H的D0位写入高，使该位为低（注意：对该位写入低通常不能达到使该位变为低的目的，只有采取写入高才能使该位变为低），以清除EPP超时位，当A、B点均为低时，可实现最快的EPP握手，若A为高、B为低时，由于EPP周期开始时满足WAIT为低的要求，EPP自动在DATASTB处输出低，但因WAIT没有出现表示应答的高状态，EPP在延时10μs后，将DATASTB恢复为高以结束该次EPP访问过程，并置超时位。稍后因WAIT为低再次开始一次EPP访问过程，如果B为高，则WAIT为高，不能满足EPP的开始条件，故DATASTB保持为高，EPP在延时10μs后结束该次EPP访问过程，并置超时位。在发生超时情况下，数据仍然可正确读入
(这一特性与笔者所查资料[1]有出入)，此结论可通过对比循环前后时间差来及实际读入数据值证实。
注意程序循环中并未执行清除EPP超时位的指令，根据笔者实验，即使已发生EPP访问超时，也不影响下一次的EPP读周期（包括对37BH的地址读及对37CH的数据读），但超时对EPP写周期有影响，在清除超时位之前，EPP写周期无效（因本文不涉及EPP写周期的内容，此处不再展开探讨）。在***2所示意波形中，当有正确握手的EPP读周期执行时间约为1.5μs，此时间是字节模式下一次有效EPP访问所需最短时间，在这段时间内，“INAL，DX”这一条指令占据了约90%以上的访问时间，验证此点仅需临时屏蔽“INAL，DX”指令，并比较所花费的时间差别即可。1.5μs相当于接近700kBytes/s的数据读速率。如果以“INEAX，DX”替代“INAL，DX”指令，可以充分利用EPP模式下硬件将4个8位数自动合并为1个32位数的特性，在一次I/O访问中由硬件自动产生4个DATASTB负脉冲从而实现4个字节的输入。因为一次字节模式的I/O访问所费时大约间需要1.5μs，减少这类指令的执行次数有利于实现更高速的EPP访问过程，经实验发现以4字节方式访问的EPP过程可以在3.2μs内读取一次，即平均每字节需0.8μs，相当于1.2MBytes/s，此实验结果是基于外设可以连续不断的输送数据理想前提，实际上要实现有效的数据传输，可得到的速率要低于该值。
2WIN98下高速EPP接口的构成
在WIN98环境下，由于非实时多任务的特性，运行于RING3的应用程序频繁作系统打断，这决定了靠软件无法实现连续均匀的数据采样，只有在硬件上配置数据缓冲存储器并及时传入微机以免数据缓冲存储器溢出。只要保证一定深度的数据缓冲存储器，且满足数据传输平均速率大于数据采样速率，就能将所采集的数据传入微机的大容量内存，以备处理。在硬件构成方面，为以较低代价获得大容量的FIFO数据缓冲存储器，采取CPLD器件结合512KB的SRAM方式，实现，由CPLD器件完成读写控制的FIFO特性及EPP模式的应答握手信号。接口结构及CPLD内部功能模块见***3所示，数据在CPLD控制下，以2μs的固定速率存入SRAM环状连续增量地址，因为EPP模式读取速率与数据采样的固定速率是异步的，控制逻辑为保证2μs的固定采样速率，当采样时间点到达时，不论当前是否处于EPP应答处理期间，优先执行数据采样，因为处理是在系统时钟脉冲驱动下的硬件行为，仅存在固定的传输延时，故两次采样间隔是严格保证的。
EPP模式的读取平均速率必须高于数据采样速率，一旦FIFO数据读空必须让微机正确处理，由前述实验可知，每次字节方式I/O执行时间约为1.5μs，如果通过在EPP的状态口（379H）的保留位输入代表FIFO读空的信号，则每完整读取均要执行两次I/O指令：EPP数据读及EPP状态读，至少需3μs完成读取一个字节，这也是通常方式能达到的最快有效读取速率。当采用双字读读及EPP状态读的方式时，需4.8μs完成4个数据字节读取，但此方式需要处理的一个问题：由于双字方式EPP数据读由硬件自动产生4个EPP数据读周期，当其执行完毕，执行EPP状态读发现FIFO已空，微机软件无法判别在从第几个EPP数据读周期开始FIFO为空，从而影响对数据队列的正确排序，故CPLD逻辑应当在FIFO队列还有至少4个未读数据时必须发出读空信号，微机程序应当在每次EPP开始前执行读取状态口的指令，以决定是否可以开始EPP数据读周期，从上分析可以看出为实现有效的EPP数据读取，平均每字节至少需要1.2μs，即可
以获得最快约800kBytes/s的数据传输速率。因500ksps的数据采集设计速率仅略低于800kBytes/s的数据传输速率，考虑WIN98工作环境，配置大容量的FIFO十分必要，采用大容量SRAM与CPLD器件构成FIFO，具有成本较低的优点，通过使用VHDL的行为描述，经CPLD器件开发软件的编译、综合、仿真、适配、***，实现所需要的控制逻辑。根据设计，当数据锁存输出的下一个时钟脉冲（即83ns后）,WAIT将输出为高电平，EPP在此时读取数据口信号，如果不采用外部缓冲驱动器，数据上升过程将耗时80ns,对EPP数据接收可靠性有不容忽视的影响，为减小电缆电容的影响，数据输出使用了74ALS574芯片作缓冲，其高电平输出能力达15mA,是ispLSI1032高电平输出能力的3.5倍，在电缆电容有100pF时，23ns可达到3.5V的逻辑高电平，保证数据接收可靠性。
仿真波形参见***4，出于方便，仿真时钟设置为12.5MHz。系统每24个时钟脉冲产生一次数据采集，仿真采样速率521ksps。数据由DIN[7：0]输入，通过CPLD内部数据输入触发时钟（该时钟同相缓冲后形成RAMOE脉冲，持续宽度为两个系统时钟）的上升沿锁存，并控制地址选择器将写地址输出到ABUS上，在RAMOE为高期间，DBUS开放三态数据触发器输出使能，使被锁存的8位数据经DBUS输出，数据输入触发时钟过后一个系统时钟，RAMWR产生一个系统时钟宽度的负脉冲，控制SRAM将DBUS上的数据写入，再下一个系统时钟的上升沿，RAMWR变高，RAMOE变低使SRAM输出有效，三态数据触发器恢复为高阻状态，ABUS变为待读数据地址，完成一次数据采集、存储过程。微机软件执行EPP数据读前先读取状态口（379H）以判别READ_EN是否有效，当READ_EN为高时，可以执行EPP数据读周期，CPLD在同步DATASTB_IN的下降沿后，产生一个宽度的OUTCLK输出锁存脉冲，其上升沿将相应待读地址的SRAM数据锁存于外部74ALS574，下降沿使WAIT_OUT上升，形成EPP模式的应答握手信号。WAIT_OUT在DATASTB_IN的上升沿异步复位以响应下一次EPP模式访问。数据写入优先于数据读取，当到达固定的采样间隔点时，CPLD总是推后OUTCLK及WAIT_OUT的执行，待采样并存储完毕才继续被暂缓的EPP应答，在设计中，数据的采样及存储需要两个系统时钟周期共167ns，远低于EPP的超时参数，故有充分的时间正确地完成EPP握手。***4仿真了数据读空状态，在***中部，READ_EN信号存在一个低电平区域，此负脉冲前，根据RAMWR个数可知当时采样了11个数据，根据OUTCLK个数可知读取了8个数，剩下3个数不足以提供EPP执行双字读的操作，如果此时微机需要访问EPP，在其对状态口的读取中，因得知READ_EN无效而暂缓EPP的执行，当再次完成一次数据采样后，达到至少存在4个未读数据的条件，READ_EN重新变为有效，可供微机读取。
数据采集论文第6篇
1．1采集系统方案采集系统方案如***2所示，系统由ST32F407单片机加FPGA结构组成，FPGA采用Altera公司的CYCLONEⅣ系列芯片EP4CE6E22C8N。单片机作为主控制器，用于控制FPGA采集，数据存储;电路包含以太网接口，GPS接口，SD卡存储器以及授时守时电路;FPGA部分用于产生AD同步时钟，控制六通道AD同步采集，并将采样值传入单片机中，电路包含6通道采集板和参考源;单片机与FPGA之间通过SPI接口与地址线A0进行通信。数字补偿晶体是整个系统的时钟源，该晶体的频率为16．384MHz，准确度为0．5×10－6，温漂为0．1×10－6。
1．2传感器选型本系统选用的传感器为ES－T型三分向力平衡式加速度计，传感器可以在±0．25gn到±4gn的范围内选择设定满量程，其动态范围优于155dB，带宽在DC－200Hz之间。
1．3信号调理与AD采集电路传感器输出为差分信号，信号动态范围为±5V，系统选用的AD芯片输入信号范围在±2．5V之间，所以传感器输出信号必须经过信号调理后才能进行采集，***3是其中一个通道的信号调理与AD采集电路，其余通道电路与该***完全一致。信号调理电路由全差动放大器OPA1632构成，该放大器的电压噪声密度为1．3nV/Hz1/2，在100Hz(高铁地震监测常用采样率为200sample/s)带宽范围内噪声有效值不超过15nV，满足地震信号采集要求。***中R2∶R1、R7∶R9均为2∶1，可将输入差分信号衰减2倍，实现将传感器输出的±5V信号衰减到±2．5V范围内，满足ADS1281的输入电压范围，***中二极管D1与D2是钳位二极管，将电压钳位在±3V左右，保护AD芯片。AD转换器是一款32bitΔ－Σ高精度模数转换器ADS1281，内部具有可编程FIR、IIR和SINC滤波器，0．6×10－6线性度，在250sample/s采样率下其SNR可达130dB，全速采样模式下功耗仅12mW，非常适用于电池供电的野外作业。通过配置PINMODE引脚，可将ADS1281设置为引脚控制模式(PINMODE=1)和寄存器控制模式(PINMODE=0)，本系统将其配置成寄存器控制模式。系统为实现同步采样，将六通道ADS1281的低功耗控制PWDN，复位RST，同步SYNC，采样时钟CLK，SPI时钟SCLK，SPI数据输入DIN引脚分别连在一起，并由FPGA统一控制，达到时钟同步，统一配置AD的目的，从而实现同步采样;而ADS1281的数据输出引脚DOUT分别接在FPGA的6个不同IO口，用于读取六通道AD的数据。参考源是数据采集系统的关键部分，本系统利用DCDC产生－5V电压，低噪声LDO电源芯片LT1964产生－2．5V电压，作为六通道ADS1281的VREFN输入，LT1964噪声为30μVRMS(10Hz～100kHz);利用专用精准基准芯片LTC6655－2．5产生+2．5V电压，作为六通道ADS1281的VREFP输入，该芯片噪声0．25×10－6p－p(0．1Hz～10Hz)，温飘为2×10－6/℃，经过试验，该方案是取得较好结果。
1．4FPGA采集控制与数据传输实现数据采集之前，STM32单片机需要通过FPGA对各通道采集卡(即ADS1281)进行配置;数据采集过程中，FPGA需要对六通道数据读取、打包并传入STM32单片机。控制线A0用于选择上述功能。当A0=0时，将STM32单片机与FPGA之间的SPI接口、FPGA与六通道采集卡之间的SPI接口直接相连，此时由STM32单片机直接完成采集卡配置;当A0=1，FPGA输出采样时钟CLK，六通道采集卡同时启动采样。FPGA数据采集与传输过程如***4所示。当六通道ADC数据准备就绪时，ADC_nDRDY信号将同时由高变低，FPGA收到下降沿信号后，将在ADC_SCLK引脚连续产生32个周期的SPI时钟，ADS1281在时钟上升沿输出数据(ADC_DOUT_1至ADC_DOUT_6)，FPGA在时钟下降沿读取数据，六通道数据将被缓存在6个32bit寄存器ADC_DA-TA0至ADC_DATA5内;FPGA读取完六通道32bit数据后，在MCU_DRDY引脚产生一个高脉冲，通知STM32单片机读取数据，单片机在MCU_DRDY下降沿启动中断，并在中断中完成数据读取;数据读取过程中，单片机的SPI时钟MCU_SCLK连续产生时钟信号，FPGA在收到时钟信号时，将数据通过MCU_DIN输出，时钟信号共6×32=192个，正好读完六通道数据。
2预警系统C/S构架软件设计
2．1客服端LabVIEW编程PC机客服端界面与网络编程利用LabView软件实现。LabView是由美国国家仪器(NI)公司研制开发虚拟仪器开发软件，是一种***形化编程语言，使用较为方便［6－7］。LabView主界面包含采样率、量程设置，IP地址，端口，开始采集按钮，停止采集按钮和波形界面几个部分，其中波形界面由WaveChart控件实现，具体实现如下:将下位机上传的六通道数据绑定为簇，簇输出接到WaveChart控件的数据输入端，Wave-Chart控件的***形显示方式设置为分格显示曲线，由于簇输入是6个数组绑定而成，WaveChart自动将窗口分成6个子窗口，每个数据对应一个窗口;Wave-Chart界面更新模式设置为StripChart，此模式下波形从左至右绘制，达到右边边界时，旧数据从左边溢出，新数据从右边进入。LabView具有强大的网络编程功能，本系统客户端利用了其中的TCP/IP协议模块，主要涉及到以下几个函数:TCPOpen(打开)，TCPRead(读取)，TCPWrite(写入)，TCPClose(关闭)。客户端程序工作流程如***5所示。从***中可以看出，从开始到结束采集一共用了两次TCP/IP连接，第1次用于发送采集命令，然后接收、处理、显示数据，当按下“停止采样”命令后，首先关闭第1次TCP/IP连接，此时服务器还在继续采集数据，但不发送，所以还需进行一次TCP/IP连接发送停止采集命令给服务器，服务器收到命令后即可停止采集，并进入低功耗模式。
2．2基于LWIP的服务器程序设计服务器的主控单片机是STM32F407，其内部集成了10/100M以太网MAC，结合PHY芯片DP83848即可完成以太网硬件搭建;以太网软件部分通过移植LWIP协议栈实现，已有较多文献或文档详细叙述了移植方法与过程，服务器接收命令、启动采样和传输数据等功能在tcp回调函数中实现。数据采集和传输是同时进行的，可在单片机中申请两个缓存，采用乒乓操作模式工作实现，即:其中一个用于中断采集数据存储，缓存满后，设置数据满标志，并查询另一个缓存的数据空标志，若为空，证明数据已经传输完成，可新的存储数据;另一个用于传输，传输完成后，设置数据空标志，并查询第1个缓存的数据满标志，若位满，证明数据可以传输;由于以太网的传输速度远大于数据采集的速度，以太网传输完成后会等待另一个缓存存满，所以整个过程中不会出现采样数据丢失的情况。
3采集系统性能测试
3．1噪声测试进行噪声测试时，将6通道输入短接，采样率设置为200sample/s;采集开始后，数据将以文本文档的形式实时存入SD卡。***6是由采集的一个通道数据用excel作***得到(取其中任意2000个点)，从该***可以看出:该通道采集的输入短接噪声峰峰值在±1．5μV范围内。为进一步对噪声大小进行量化分析，分别进行了三次噪声测试，并在excel软件中利用STDEVA函数对每一次的六通道采集数据做均方差处理，处理结果如表1所示。从表中可以看出:每隔通道的噪声均方差低于0．5μV，噪声一致性较好;采集卡输入信号范围是±5V，按照ADC的信噪比计算公式可算出采集卡的信噪比优于140dB。
3．2地震信号采集实验实验时，把传感器放置于地面，传感器差分信号输出端接入采集卡第1通道，打开监测站电源，在PC机中启动LabVIEW界面，设定好采样率、量程、IP地址与端口，点击“启动采集”，在距传感器2m左右用硬物连续敲击地面，***7是截取的实时显示结果***，从***7可以看出，第1通道具有典型的地震波形输出，纵坐标单位为mV，第2通道～第6通道输出为随机噪声，纵坐标单位为μV。
4结束语
数据采集论文第7篇
CC2530射频模块通过外引24个引脚，包括普通IO引脚P00-P24和电源、复位引脚，实现与电路的连接。电路包括复位电路、开关电路、传感器接口电路、按键指示电路、通信调试电路、电源供电电路。主要电路功能介绍如下：按键指示电路：节点包括Led和蜂鸣器指示电路，用于本节点的指示功能；支持按键功能，进行节点工作模式的转换。开关电路：由三极管电路组成，用于实现传感器供电的通断。通信调试电路：由串口电路和JTAG调试接口组成；串口负责与PC上位机软件的连接，方便修改节点的参数；JTAG接口方便上位机集成环境IAR等调试用。电源供电电路：基本供电由外部USB接口电源5V通过AMS1117转3.3V以及直接电池3.3V供电组成；传感器可由内部3.3V供电，而大于3.3V则由外部电源直接提供。传感器接口电路：包括危化品物流车辆常见的几种信号（0-5V、4-20mA、开关量、数字量）采集电路，可同时接四种类型的传感器。其中数字量主要是DS18B20、DHT11温湿度传感器的输出信号；0-5V主要是气体泄露检测、光敏、真空度传感器的输出信号；4-20mA主要是压力、液位传感器的输出信号；开关量主要是红外、门开关、倾斜传感器的输出信号；信号接入后进行了信号隔离和二极管钳位保护电路。
2节点软件
2.1节点软件架构软件设计部分主要是基于TI公司的Z-stack协议栈进行应用程序的开发。Z-stack协议栈是一款稳定性强的Zigbee开发协议栈，是对Zigbee标准的具体实现。协议栈APL（应用层）包含了主要的API函数接口，方便进行应用开发，从而实现对CC2530芯片硬件资源的控制功能。具体软件框架设计如***4所示。应用层软件主要包括节点间数据的接收/发送、节点内应用层与底层的交互。应用层的数据经过应用层数据帧格式进行封装传给底层继续封装并发送出去；接收数据则由底层先进行解释，再由应用层进行解释，然后进行数据的计算、更新参数等步骤。应用层还可通过API控制接口对底层进行控制与信号、参数获取。
2.2数据帧格式Zigbee采集节点和主节点模块的数据传输格式采用字符串形式进行数据的发送/接收。由于是采用字符进行数据传输，所以可以利用上位机现有的字符串处理函数，很容易校验数据正确性，并从数据帧中提取有效信息，避免因帧长度判断引起的错误。另外，基于Zigbee传输速率较低、传感器数据量小、刷新速度慢的需求等特点尽量减小和限制了协议中各数据域的占位宽度，保证传输效率。具体数据格式如表1所示。帧头：本协议节点间的应用层交互主要有命令帧和数据帧。帧头是辨别命令帧和数据帧而设立的。帧头包括：Set、Get、Ack、Data4种。Set指的是主节点对采集节点进行参数设定，为命令帧，是主节点需要对子节点进行参数配置的时候发送的，子节点收到此类型帧后，发回Ack帧，说明参数设置成功与否；Get指的是其他节点需要获取本节点信息，为命令帧，本节点收到此类型帧后，发送数据帧；Ack指的是节点间通信应答状态帧，SUCC为成功、FAIL为失败；Data指的是数据帧，携带节点参数、传感器采集数据。如表2所示。目的地址：目的地址指的是Zigbee网络中的设备唯一标识的网络ID。为十六进制0X0000-0XFFFF之间值。其中有几个地址值有特殊的含义，0XFFFF表示广播地址；0XFFFE表示所有接收功能打开的设备；0XFFFC表示所有路由设备；其余地址为单一设备的网络地址。网络地址的获得过程是：主节点设备启动成功后，自设定为Zigbee网络的主网络ID0X0000，子节点设备在申请加入成功后获得一个网络身份标志ID。帧类型：在帧头为Set、Get、Data时，此帧位置都有意义，分别代表设置、获取、携带相应类型的节点信息。这些类型包括，传感器数据(Sensor)、节点网络地址(NAdr)、节点网络类型(NType)、采集周期(Cycle)、产品信息(Info)、发送方式(SWay)、功率模式(PMode)、信道选择(Channel)、AD参考电压(ADMode)、默认发送地址(DSAdr)。信道数据：DataChannel796F800\r\n(第11（0x0B）无线信号通道)载荷：载荷是整个通信帧中最重要的部分，包括了通信的主要内容。载荷的具体内容需要根据帧类型来确定。描述如下：（1）帧类型为传感器数据：此时载荷部分包括传感器类型、传感器ID、传感器值。传感器类型包括危化品物流车辆常见信号：1.温度、2.门开关、3.真空度、4.液位、5.压力、6.电压、7.湿度、8.气体、9.红外10.光敏、11.倾斜。传感器ID从0开始分配，表示同种类传感器的使用编号。（2）帧类型为非传感器数据：此时载荷部分携带网络地址、采集周期、发送地址等值。结尾符：本协议结尾符为字符“\r\n”，加上字符串结束符‘\0’,固定为3个字节。结尾符是一帧数据的界定符，上位机软件可以根据此结尾符很快能判定帧的长度，避免一些数据长度判读错误的发生。
2.3软件处理流程Z-stack协议栈基于轮询机制，事件是最小处理单元，每个事件都有相应的处理函数，当事件管理数据结构相应的位置位时，协议栈通过轮询机制就能发现并跳入相对应处理函数进行处理步骤，处理完再返回轮询大循环。这里主要设置了3个事件，分别是串口事件、无线事件和采集事件。串口事件主要处理与上位机的通信；包括根据上位机命令修改本节点参数、接收发送数据等；无线事件主要处理数据的无线发送和接收；采集事件主要处理传感器的数据读入、封装、发送或者接收、解析、转发等。处理流程***如***5所示。
2.4上位机配置软件Zigbee设备逻辑类型包括3种，分别是主节点、路由节点、终端节点。对于不同设备类型的具体处理流程，本设计编写了统一的参数配置服务函数，可通过上位机软件方便进行配置。比如，终端节点配置成具有传感器数据的采集功能，可选择无线和串口两种发送方式，而对于路由器或者协调器，基于功耗考虑，则配置成不具有传感器数据采集功能。通过设计节点上位机配置软件ZigConfig来实现参数的配置，简单的界面操作就能通过串口以上述数据格式***到节点，并烧写到CC2530的flash中永久保存起来，节点下一次启动将以新的参数启动。上位机配置软件介绍如下：（1）配置软件由QtCreator开发。QtCreator是Qt被Nokia收购后推出的一款新的轻量级跨平台集成开发环境（IDE）。支持的系统包括Linux（32位及64位）、MacOSX以及Windows。开发人员能利用该应用程序框架更快速及轻易地完成开发任务。（2）该配置软件完成节点的设备类型、接口采集逻辑、入网参数等的配置。可直接通过串口线与待配置节点连接，也可以通过一个中间节点对待配置节点进行无线配置，中间节点通过串口线与上位机连接。操作界面如***6所示。（3）如***7，***8所示，通过上位机配置软件S1（实物***如***6所示）可方便地对待配置节点S2进行参数配置。对于待配置设备，如果是终端设备，配置前需先按下配置按键，指示灯亮后，装置即进入配置模式；而如果是路由设备或协调器设备则无需此步骤。（4）有线配置如***6所示：上位机通过串口线连接待配置设备，然后配置软件上收到待配置节点S2发送过来的设备信息，并显示在界面上，然后点击配置按钮，即发送配置帧到节点S2，点击读取配置按钮，则将节点S2各项参数显示在界面上，如果节点S2是数据透传模块，则可以直接接收数据或填写目标地址发送数据。配置完后再按一下按键，指示灯不亮，表示配置完成。可以配置设备类型为Zigbee终端设备、路由设备、协调器设备和点对点透传设备；可以配置入网参数，比如PANID值、信道、网络模型、网络层次等；可以配置传感器发送周期，使各传感器通道数据可以同一周期发送，也可以不相同周期发送等。（5）无线配置如***8所示，采用一个节点作为数据中转与上位机有线连接，通过这个节点无线发送指令到待配置节点进行配置，配置过程中的操作步骤与有线时类似。
3节点测试
3.1信号强度RSSI(ReceivedSignalStrengthIndication)是接收端的信号强度指示，可用来判定链接质量。实际应用中，普遍采用简化后的Shadowing模型，即如下公式计算RSSI值。其中Pr（d）为接收端接收信号强度，Pr（d0）为参考处接收端接收信号强度，d为接收端与发送端实际距离，d0为接收端与发送端参考距离，n为路径损耗指数，通常取2~4。取d0=1m，实测得Pr（d0）的值代入，并取n=3代入公式（1）得新的计算公式。实际测试中取两个节点，分别设为协调器节点和终端节点。将协调器节点固定，令终端节点远离，终端节点加入协调器节点网络后，每隔1s发送一次数据到协调器节点。协调器接收到数据包后，从TI协议栈Z-Stack的数据结构afIncom-ingMSGPacket_t中提取RSSI值记录下来。100M范围每隔5M记录一次RSSI值，每次记录100个值，然后取100个中的随机值和平均值分别作为本次终值绘制曲线。
3.1.1空旷环境下测得Pr（d0）=-28dbm，按照公式(2)与实际数据，绘制对比曲线。从***9和***10对比曲线可以看出，随着两节点间距离增大，RSSI值会逐渐衰减，符合一般规律。0-20m范围内，RSSI衰减较快，之后较为平缓。40m后信号质量普遍较理论值平缓，可能是受硬件条件影响，误差增大。***9由于每次记录取的随机值，存在较大误差，***10每次记录取100个数据的平均值，曲线较为平缓。误差因素包括硬件设计、周边环境影响等。
3.1.2危化品物流车辆环境下采用深圳市中集集团液化气罐(空罐)危化品物流车辆进行实地测试，测试车辆长度14m，宽度2.5m。将协调器节点放置在车驾驶座，终端节点自由放置于车厢体内部，加入网络并发送数据到协调器节点。测得Pr（d0）=-44dbm，根据公式（2）和实际数据的结果曲线如下：由***11和***12可以看出，在车辆环境下，节点信号普遍较空旷环境下差，这主要是因为接收节点被放进车辆箱体内部，信号一定程度上受到厢体衰减。大于40m距离后信号变得不稳定，通信断续和重连情况发生频繁，此时RSSI值普遍>82dbm，80m后多次测试接收端均接收不到数据。
3．2数据传输将协调器节点放置在车驾驶座，终端节点自由放置于车辆厢体内部，加入网络并发送数据到协调器节点。在协调器端统计接收数据包个数，并计算丢包情况和最大稳定通信距离(即数据通信情况良好，极少发生重连情况)，结果如下。由表3可以看出，主节点在车驾驶室情况下，车正前方和侧面信号要好于车后方信号，节点丢包率较低，通信距离>=25M，满足一般危化品物流车辆要求。另外，通信的最大稳定传输RSSI值是极少断网重连情况发生下的统计值，所以普遍低于信号强度曲线中的极限值。随着距离增大，节点间的网络传输也会变得不稳定，常常发生断网重连，甚至无法重连状况。实际数据包传输受节点间不同阻挡物、不同车型、车体电磁干扰、程序执行等因素影响。
3．3功耗通过万用表、示波器和在程序中设计测试模块的结合进行功耗测试，测试结果如下。从表4的测试结果可以看出，节点满足低功耗要求，休眠情况下，节点功耗低至0.33uA。
4结语