温湿度监控在农业、医疗、建筑、文物保存和档案管理等领域都有广泛的应用[1]。 传统的有线布线方式应用在较大空间范围内进行多点分布式测量时容易对空间内建筑造成损坏,影响美观且费用较高。 因此,设计一个组网方便、数据传输及时可靠的分布式无线温湿度采集系统具有良好的实用价值。
随着物联网技术的不断成熟和发展,针对上述需求,在此采用 Zig Bee 无线局域网实现多点分布式温湿度测量, 采用 Wi Fi 无线局域网实现数据与上位机之间的无线的传输。 ZigBee 技术是一种近距离、低复杂度、低功耗、低速率、低成本的双向无线通讯技术, 其使用的 2.4 GHz 频段全球通用[2];Wi Fi技术是目前应用非常广泛的一种无线上网技术,通过传输控制协议 TCP(transmission control protocol)连接,可以方便、稳定地实现温湿度监测系统与上位机软件的数据通信。
1 系统整体设计
所设计的基于 ZigBee 和 Wi Fi 的温湿度无线监测系统,上位机软件采用 VB 6.0 设计开发,可以实时地将数据显示到界面上,同时还可以将数据保存到 Access 数据库中,方便查询历史数据;针对 WiFi局域网中 IP 地址不固定导致 TCP 无法连接问题,上位机软件利用用户数据报协议 UDP(user datagram
protocol)组 播实现了 “系统发现 ”功能 ,当监测系统的 WiFi 模块和上位机软件在同时接入 IP 局域网的情况下,二者之间能自动地建立 TCP 连接而无需进行 IP 地址设置等操作。
该监测系统由监测终端节点、 协调器、WiFi 模块和上位机软件等 4 个部分组成。 ①监测终端根据预设参数接入 ZigBee 局域网,实时监测被测空间的温度和湿度并将数据送到协调器;②协调器根据预设参数建立 ZigBee 局域网,接收各终端发送来的数据,并将数据通过串口发送到 WiFi 模块;③WiFi 模块根据预设值接入 WiFi 网络, 然后通过 “系统发现”功能连接到远端的 TCP 服务器,并将从串口接收到的数据发送到远端;④上位机软件建立 TCP 服务器,并通过“系统发现”功能将自身的 IP 地址和TCP 服务器端口号发送到 WiFi 模块 , 当建立 TCP连接后将 TCP 客户端发送来的数据实时显示到界面,同时将这些数据保存到数据库。 系统的整体设计框图如图 1 所示。
2 系统硬件设计
2.1 终端节点硬件设计与实现
终端节点的硬件组成如图 2 所示,终端节点由CC2530、传 感器 、指示 、电源 、串口及天线等 6 个 模块组成。
CC2530 是 一个 ZigBee 片 上解决方案芯片 ,该芯片结合领先的 RF 收发器, 内有一个业界标准的增强型 8051CPU,系统内 8 kB 运存、256 kB 闪存。 该芯片还结合了德州仪器的 ZigBee 协议栈 Z-Stack,提供了一个强大和完整的 ZigBee 解决方案。
节点传感器模块选用 SHT11 温湿度传感器。 该传感器将温湿度检测、信号放大调理、A/D 转换、I2C总线、CRC 数据校验集于一体, 能够实现温湿度值
的精确测量和传输[5-6]。 SHT11 与 CC2530 电路原理如图 3 所示。
电源和串口模块选用 PL2303 芯片。 该芯片是一个高度集成的 RS232-USB 接口转换器, 解决了PC 上只有 USB 口而没有 RS232 口的问题, 同时也解决了供电问题, 利用常见的 5 V 输出电源适配器就能供电。 用户通过这个串口可以使用 PC 设置终端节点的一些运行参数。
指示模块包括 LED1 和 LED2 指示灯, 当节点通电后 LED1 常亮,当节点接入 ZigBee 网络后LED2常亮,否则 LED2 周期闪烁[7]。
2.2 协调器节点硬件设计与实现
协调器节点硬件组成如图 4 所示,协调器节点的硬件组成与终端节点基本一致。 为了能够方便对协调器进行设置,在串口部分使用了跳线,协调器串口跳线原理如图 5 所示。 当开关拨到上部时,PL2303 与 CC2530 相连, 实现上位机对 CC2530 的设置;当开关拨动到中部是 CC2530 与 RTL8710 相连,实现 CC2530 和 RTL8710 的数据传输;当开关拨动到下部时,PL2303 与 RTL8710 相连,实现上位机对 RTL8710 的设置。 系统正常工作时应将开关拨到中部位置。 当协调器通电后 LED1 常亮,当协调器创建网络完毕后 LED2 常亮,否则 LED2 周期闪烁。
2.3 WiFi 模块硬件设计与实现
Wi Fi 模块硬件组成如图 6 所示 。 WiFi 模块采用 RTL8710 芯片, 该芯片集成了一个 ARM CortexM3 MCU,802.11n 无线网络控制器, 串口等外设于一体,内置了轻量级 TCP/IP 协议,为一个完整且自成体系的 Wi Fi 网络解决方案。
3 系统软件设计
3.1 终端节点软件设计与实现
当终端节点上电后, 首先从 Flash 固定地址读取系统参数,如果能正常读取且校验成功则使用参数进行系统初始化,如果不能正常读取则等待串口命令。终端节点的串口只有在设置系统参数时与 PC连接,PC 按照一定的数据格式向节点发送命令,数据格式见表 1。
表1 数据包格式
字段名 | 格式 | 长度/B | 说明 | |
帧头 | 0x1B | 1 | 数据起始位 | |
类型 | 0xXX | 1 | 数据类型 | |
长度 | 0xXX | 1 | 净荷长度 | |
净荷 | 0xXX | N | 数据内容 | |
校验位 | 0xXX | 1 | 数据之和 |
根据数据包格式,整个数据包以“帧头”0x1B 开始。 “类型”表示数据包的类型,如 0x00 表示当前数据包是温湿度值(该数据格式同样用于 ZigBee 数据传输);0x01 表示当前数据包是设置设备编号参数。“长度”表示数据包中数据内容的长度,一个完整的数据包长度为(N+4)B。 “净荷”为实际传输的数据内容,在应用中根据需要可以继续扩展,如在传输温湿度值时净荷的首字节用于表示设备编号,其后才是温湿度测量值。 “校验位”为该字节前面(N+3)B数据之和的最低位字节。
当参数检查通过后,终端节点进入正常程序运行,流程如图 7 所示,定时器设置为 10 s。
SHT11 传 感器输出的温度数据需要经过一定的转换才能使用。
①温度转换公式
T=d1+d2So T(1)
式中:T 为温度值,℃;SoT为主控芯片从 SHT11 中读取到的温度数据;d1和 d2
为温度转换系数, 其取值见表 2。
VDD/V | d1/℃ | VDD/V | d1/℃ | SoT/bit | d2/℃ |
5 | -40.00 | 3 | -39.60 | 14 | 0.01 |
4 | -39.75 | 2.5 | -39.55 | 12 | 0.04 |
3.5 | -39.66 |
②相对湿度转换公式
RHlinear=c1+c2So RH+c3So RH2(2)
式中:RHlinear为相对湿度;SoRH为主控芯片从 SHT11中读取到的湿度数据;c1,c2和 c3为湿度转换系数,其取值见表 3。
③温度补偿公式 由于湿度的测量受温度影响,所以在测量湿度时还应考虑到传感器的温度补偿。 该补偿公式为
RHtrue=(T-25)(t1+t2So RH)+RHlinear(3)
式中:RHtrue为绝对湿度;t1,t2为温度补偿系数,其取值见表 3。
SoRH/bit | c1 | c2 | c3 | t1 | t2 |
12 | -4 | 0.0405 | -2.8X10-6 | 0.01 | 0.00008 |
8 | -4 | 0.648 | -7.2x10-4 | 0.01 | 0.00128 |
结合该系统设计,SHT11 电压 VDD为 3.5 V,温度精度 So T为 14 bit,湿度精度 SoRH为 12 bit,将系数结果代入式(1)—(3),可得
T=-39.66+0.11SoT
RHlinear=-4 +0.0405So RH-2.8×10-6So RH2
RHtrue=(T-25)(0.01+0.00008So RH)+RHlinear(4)
3.2 协调器软件设计与实现
协调器是整个 ZigBee 网络的核心,它需要具有创建 ZigBee 网络,为节点分配地址,将从节点收到的数据通过串口透传到 WiFi 模块,等功能,此外协
调器同样支持从串口接收 PC 命令。 其命令格式同表 1,协调器软件流程如图 8 所示。
3.3 WiFi 模块软件设计与实现
WiFi 模 块是 ZigBee 网 络和 IP 网 络的转 换模块,它将 ZigBee 协调器发来的数据通过 TCP 连接发送到上位机,同时 WiFi 模块还是“系统发现”功能的客户端。 WiFi 模块程序流程如图 9 所示。
传统的服务调用需要客户端明确知道目标服务的地址,并基于这个地址创建服务调用。 但是目前网络接入设备和路由设备之间一般均为动态路由,所以网络接入设备的 IP 地址不固定,而 IP 地址一旦发生变化就会使客户端与服务器之间的服务调用无法建立。 故在此设计了“系统发现”功能,即以 WS_Discovery 机制 Ad_Hoc 操作模式为基础,通过简化其协商流程和内容而来。
标 准 WS_Discovery (web services dynamic dis-covery)由服务器端(WS_Serve)和客户端(WS_Client)组成。 其协商流程如图 10 所示。
当服务器启动后,通过 UDP 广播定时向网络发送 Hello 消息报文, 客户端收到该报文后通过 UDP广播发送 Probe 消息报文, 该消息中包含客户端所需要调用的服务; 而服务端在收到 Probe 消息后首先判断能否满足该消息中的条件,如果可以满足则通过 UDP 单播的形式 向该客户 端发送 PM(probematch)消息,该消息中包含目标服务的相关信息。 当客户端收到 PM 消息后,就根据消息中携带的信息与目标服务建立连接, 而如果客户端从 PM 消息中得到的信息还不足以建立服务,就会进一步向服务器发送 Resolve 消息, 并在消息中携带想要向服务器查询的内容,服务器则会回复 RM(resolve match)消息并在消息中携带被查询内容; 当服务器下线时,会向客户端发送 Bye 消息,通知客户端服务停止。
标准 WS_Discovery 机制需要经过多次消息交换,而且是以简单对象访问协议 SOAP(simple object access protocol)对 协商内容进行封装 ,此协议为一种基于 XML 的文本协议, 因此会使得协商时数据量较大进而增加 WiFi 模块的内存负担。 所以,“系统发现”功能首先将协商流程简化 ,并且将协商内容由文本变为二进制,其消息格式同表 1。
Wi Fi 模块启动后,创建 UDP 并监听 3700 端口(标准 WS_Discovery 为 3702);当上位机启动后 ,会通过 UDP 定时向 239.255.255.250 地址的 3700 端口发送 Hello 消息;当 WiFi 模块收到此消息,向服务器回复 Probe 消息, 该消息携带有与服务器约定好的服务编号; 上位机收到 Probe 消息并判断服务
编号是否合法,如果合法则向 Wi Fi 模块回复 PM 消息, 并在消息中携带 TCP 连接的 IP 地址和和端口号。 WiFi 模块收到 PM 消息后就可以与 TCP 服务器
建立服务连接。
“系统发现” 功能消息的示例见表 4。 表中,1B为帧头;A1,A2,A3 分别 表示 Hello 消 息 、Probe 消息、PM 消息的类型;类型字段后面给出消息净荷的长度;各条消息的最后一个字节为校验字节。
表 4 “系统发现”协商消息示例
Hello 消息 | 0x1BA100BC |
Probe 消息 | 0x1BA207000103040A0D07EA |
PM 消息 | 0x1BA306C0A8006403E87B |
由表可知,Probe 示例消息中,客户端所携带的服务编码为 000103040A0D0708;PM 示例消息中,TCP服务器的 IP 地址为 192.168.0.100,端口号为 1000。
3.4 上位机软件设计与实现
上位机软件使用 VB 进行设计, 主要功能有数据校准和数据保存。
SHT11 在测量过程中,受到环境 、电路的干扰 ,以及测量数据由多位小数向 1 位小数转换的过程会导致测量数据精度降低,与真值之间出现偏差[8]。为了校准该偏差,在此选用精创公司的工业级温湿度记录仪 RC-4HC 的测量数据作为约定真值, 通过大量的试验比较 SHT11 与 RC-4HC 之间的测量数据, 发现两者之间确实存在一个较为稳定偏差,而且不同的 SHT11 与 RC-4HC 之间的偏差值也有所不同,测量数据见表 5。
表5
序号 | 测量值 | 真值 | 误差 | |||
温度 | 湿度 | 温度 | 湿度 | 温度 | 湿度 | |
1 | -5.2 | 8 | -4.9 | 9 | -0.3 | -1 |
2 | -2.8 | 10 | -2.5 | 12 | -0.3 | -2 |
3 | 4.6 | 14 | 4.8 | 16 | -0.2 | -2 |
4 | 6.7 | 14 | 7 | 15 | -0.3 | -1 |
5 | 8.4 | 15 | 8.6 | 16 | -0.2 | -1 |
6 | 9.7 | 17 | 10 | 17 | -0.3 | 0 |
7 | 11.2 | 18 | 11.4 | 19 | -0.2 | -1 |
8 | 13.6 | 20 | 13.8 | 20 | -0.2 | 0 |
9 | 15.1 | 20 | 18.1 | 20 | -0.2 | 0 |
10 | 17.9 | 21 | 18.1 | 22 | -0.2 | -1 |
11 | 19.5 | 24 | 19.6 | 25 | -0.1 | -1 |
1 -5.2 8 -4.9 9 -0.3 -1
2 -2.8 10 -2.5 12 -0.3 -2
3 4.6 14 4.8 16 -0.2 -2
4 6.7 14 7 15 -0.3 -1
5 8.4 15 8.6 16 -0.2 -1
6 9.7 17 10 17 -0.3 0
7 11.2 18 11.4 19 -0.2 -1
8 13.6 20 13.8 20 -0.2 0
9 15.1 20 15.3 20 -0.2 0
10 17.9 21 18.1 22 -0.2 -1
11 19.5 24 19.6 25 -0.1 -1
12 21.8 26 22 28 -0.2 -2
13 23.7 26 23.7 27 0 -1
14 24.5 26 24.6 28 -0.1 -2
15 26.7 27 26.7 27 0 0
16 28.4 27 28.6 27 -0.2 0
17 31.4 24 31.5 26 -0.1 -2
18 34.7 22 34.9 23 -0.2 -1
19 36.3 22 36.5 23 -0.2 -1
20 38.6 22 38.9 22 -0.3 0
平均值 18.24 20.15 18.43 21.1 -0.19 -0.95
校准后 18.44 21.15 18.43 21.1 0.01 0.05
通过计算测量值、真值和误差的平均值,在测量值的基础上再减去一个平均误差值,从而极大地降低整体误差。 由表可知,温度平均误差为-0.19,取值为-0.2;湿度平均误差-0.95,取值为-1。 所以使用校准公式对测量值 Tc和 RHc进行校准,即:
T=Tc-(-0.2)=Tc+0.2
RH=RHc-(-1)=RHc+1(5)
上 位 机 软 件 的 数 据 保 存 功 能 采 用 了 VB 中Adodb 控件与 Access 数据库连接[9-10]。Access 数据库共设计 2 个表,分别用于保存测点参数、测点数据,见表 6 和表 7。 其中,表 6 的主键为测点号,表 7 的主键为编号。
表 6 测点参数记录
字段 | 测点号 | 温度 上限 | 温度 下限 | 湿度 上限 | 湿度 下限 | 温度 校准 | 湿度 校准 | 是否 启用 |
类型 | 字节 | 单精度 | 单精度 | 字节 | 字节 | 单精度 | 字节 | 布尔 |
表 7 测点数据记录
字段 | 编号 | 测点号 | 时间 | 温度值 | 湿度值 |
类型 | 自动编号 | 字节 | 时间 | 单精度 | 字节 |
4 测试结果及分析
系统最多有 6 个测点,启用 3 个测点进行丢包测试。 将 3 个测点分别置于协调器周围 100 m 范围内,WiFi 模块和上 位机在 WiFi 路由 器 20 m 范围
内。 为方便统计收发包数,设置测点在发送一定数量包后停止发送,测试数据见表 8。
表 8 系统丢包率测试数据
测试 序号 | 测点 发包数 | 协调器 接收数 | 上位机 接收数 | ZigBee 丢包率/(%) | WiFi 丢包率/(%) |
1 | 1080 | 1078 | 1078 | 0.185 | 0 |
2 | 12960 | 12935 | 12935 | 0.193 | 0 |
3 | 25920 | 25873 | 25873 | 0.181 | 0 |
测试共进行 3 次, 测点每 10 s 发送 1 个包,持续时间分别约为 1,12,24 h; 测点发送数为 3 个测点发送总和。 由表可知,在 100 m 范围内,ZigBee 丢包率很小, 且丢包率不随测量时间的变化而变化;基于 WiFi 和 TCP 的连接方式稳定,IP 丢包率为 0。
选取 3 个测点对系统进行了功能测试,分别将测点 1 置于户外、测点 2 置于楼道、测点 3 置于室内。 3 个测点的温度报警上限均为 30 ℃,下限为 0 ℃;
温度预警上限为 40%,下限为 20%。 监测系统主界面如图 11 所示。 测点 1 的温度和湿度均低于下限值,分别发出温度报警和湿度报警;测点 2 仅湿度低于下限,只有湿度报警。
用鼠标双击测点区域可以查看测点实时数据与曲线。 测点的实时数据及曲线如图 12,图中上方曲线为温度曲线,下方曲线为湿度曲线。
5 结语
所设计的基 于 ZigBee 和 WiFi 的 无 线 监 测 系统,以 CC2530 和 RTL8710 为核心芯片,实现了测点与监测软件的无线连接。 经过测试,该系统能够实现各测点温湿度的实时监测和显示,显示界面清晰明了,系统组网方便可靠,具有一定的实际应用价值。