当前位置：首页 > news >正文

基于STM32+Python+MySQL实现在线温度计设计和制作

news 2025/8/23 11:27:06

在线温度计设计和制作

摘要

本毕业设计主要设计自主研发的温度采集和温度数据的储存处理显示过程，继而实现在线温度计系统。在线温度计主要主要包括温度采集单元、数据的储存处理和显示。

在线温度的整体概述为：

数据采集部分使用Client/Server构架，由温度采集单元采集数据，经初步处理的数据上传到数据服务器，数据服务器对数据进行储存。

数据查询部分采用Browser/Server构架，用户在页面上发送查询请求，服务器在收到页面的查询请求后对数据库的数据进行查询、处理和显示。

Clint为STM32F030，使用ARM Development Tools（评估版）进行设计和调试完成，其主要功能是采集来自DS18B20的温度数据，和实现与服务器的通信。

Browser为JavaScript+html，其中JavaScript采用Highcharts+jQuery框架实现数据的可视化显示。

Server使用Ubuntu Server 14.04.1 LTS 使用语言:Python2.7网站后台服务器框架:django1.8数据库:mysql。

各个系统间通信利用wifi网络的高带宽实现数据加密和双向鉴权，保证通信链路上的可靠性。

该系统实现了对数据的采集。与服务器之间数据的可靠通信，实现数据在互联网上的显示、统计、储存等功能，为数据分析者提供在线的实时、可靠、直观的温度数据，方便其对大数据的分析利用。

关键词：温度采集；STM32；物联网；数据传输；数据的可视化

引言

目前的温度采集，基本以现场有线采集和工控系统内部处理使用为主，成本高、部署难度大、可重用率低对现场实施人员要求高。

温度采集融入工业大数据是现在发展的趋势。

工业大数据是一个全新的概念，从字面上理解，工业大数据是指在工业领域信息化应用中所产生的大数据。

随着信息化与工业化的深度融合，信息技术渗透到了工业企业产业链的各个环节，条形码、二维码、RFID、工业传感器、工业自动控制系统、工业物联网、ERP、CAD/CAM/CAE/CAI等技术在工业企业中得到广泛应用，尤其是互联网、移动互联网、物联网等新一代信息技术在工业领域的应用，工业企业也进入了互联网工业的新的发展阶段，工业企业所拥有的数据也日益丰富。工业企业中生产线处于高速运转，由工业设备所产生、采集和处理的数据量远大于企业中计算机和人工产生的数据，从数据类型看也多是非结构化数据，生产线的高速运转则对数据的实时性要求也更高。因此，工业大数据应用所面临的问题和挑战并不比互联网行业的大数据应用少，某些情况下甚至更为复杂。

工业大数据应用将带来工业企业创新和变革的新时代。通过互联网、移动物联网等带来的低成本感知、高速移动连接、分布式计算和高级分析，信息技术和全球工业系统正在深入融合，给全球工业带来深刻的变革，创新企业的研发、生产、运营、营销和管理方式。这些创新不同行业的工业企业带来了更快的速度、更高的效率和更高的洞察力。工业大数据的典型应用包括产品创新、产品故障诊断与预测、工业生产线物联网分析、工业企业供应链优化和产品精准营销等诸多方面。本文将对工业大数据在温度数据采集的应用场景进行逐一梳理。

一、概述

1.1 在线温度计系统概述

在线温度计系统的整体描述为：将孤立的温度数据孤岛通过wifi组成一个统一的信息网络，基于这个信息网络实现对温度大数据的利用，该系统一般包括数据采集终端网络、数据处理平台、用户终端，第三方平台等。

如图2-1所示，当传感器数据被采集到终端后，终端主控芯片和数据处理平台的数据服务器建立无线链路，可以按需求配置为将数据包实时主动推送或定时推送，也可以根据服务器的请求被动的发送数据包，数据服务器收到数据包后根据数据来源有序的存放在数据库中，用户可以通过网页服务器提供的web页面查看、管理和分析数据。也可以通过API接口直接和数据服务器交互得到分析后的数据。

图2-1 在线温度计系统原理图

在线温度计有以下几个方面的发展趋势：

可以兼容的传感器信号越来越多，应用的领域各种各样，行业不同，对数据的要求不同，比如说大气数据采集就需要大规模，大范围，但其对温度数据的动态范围不高，对温度数据的精度，对数据的实时性要求相对不高。但若是用于锅炉内温度数据的采集，则对温度的动态范围要求极大，实时性要求也非常高。这两种情况下对温度传感器的选型必然是不同的，作为数据平台不可能重复造轮子，于是必然要求能兼容各种温度传感器的信号。
从单一的数据向大数据发展。
没有经过处理的数据永远仅仅是数据，只有经过深加工，也就是附加各种分析算法，将数据可视化。大数据才有其真正的利用价值。

1.2 本设计方案思路

本设计以实现数据的良好检测、分析显示为主要目的；以温度采集，可靠数据通信，Linux数据服务器，WEB服务器的搭建为主要设计内容。

在传感器数据采集方面使用数字温度芯片；在数据链路方面使用无线wifi连接，在WLAN配置的易用性方面，选用TI公司推出的SmartConfig配置方案，使用手机APP将数据采集终端快速的并入数据网。在数据储存上使用MYSQL关系数据库系统，管理上使用Django的ORM对数据进行管理，在数据可视化中选择Highcharts进行数据的可视化显示。

1.3 研发方向和技术关键

温度传感器的矫正方案(可用性，通用性)；
通信系统的可靠性，易用性；
数据的可靠存储；
对数据分析算法的友好性；
数据的可视化显示。

1.4 主要技术指标

温度范围： -55至+125摄氏度
温度采集速率： 10Hz
通信延时： 1s
数据可视化形式：曲线显示

二、总体设计

数据采集部分使用Client/Server构架，由温度采集单元采集数据，经初步处理的数据上传到数据服务器，数据服务器对数据进行储存。

数据查询部分采用Browser/Server构架，用户在页面上发送查询请求，服务器在收到页面的查询请求后对数据库的数据进行查询和处理显示。

Clint为STM32F030，使用ARM Development Tools（评估版）进行设计和调试完成，其主要功能是采集来自DS18B20的温度数据，使用ESP8266实现与服务器的通信。

Browser为JavaScript+html，其中JavaScript采用Highcharts+jQuery框架时间数据的可视化显示。

Server使用Ubuntu Server 14.04.1 LTS 使用语言:Python2.7网站后台服务器框架:Django1.8数据库:MYSQL。

各个系统间通信利用Wi-Fi网络的高带宽实现数据加密和双向鉴权保证通信链路上的可靠性。

三、温度采集终端

3.1 硬件设计

3.1.1 总体设计

采用STM32的主控芯片，加载DS18B20数字温度采集芯片作为温度采集，通信使用ESP8266 高性能Wi-Fi网络解决方案，整体系统集成度高，复杂度小，故障率低，性能稳定可靠。

3.1.2 主控

主控采用STM32单片机，Stm32单片机最高可工作到72MHz，系统主时钟采用无源晶振，频率为8MHz，通过片内锁相环实现倍频，配置芯片内部存储器，可实现我们所需要的工作频率，作为系统的工作时钟，主控电路如图4-1所示。

图4-1 主控电路主时钟

3.1.3 实时时钟（RTC）

作为温度数据需要有一个和当前环境相关的一个主键，那就是温度采集的时间，STM32单片机自带RTC时钟，因此不需要外置的时钟芯片，作为内置时钟，减小了额外的硬件开销，怎加了系统的可靠性(芯片级的相对PCB级的可靠性更高)。

STM32的实时时钟（RTC）是一个独立的定时器。STM32 的 RTC 模块拥有一组连续计数的计数器，在相应软件配置下，可提供时钟日历的功能。修改计数器的值可以重新设置系统当前的时间和日期。

RTC模块和时钟配置系统(RCC_BDCR 寄存器)是在后备区域，即在系统复位或从待机模式唤醒后 RTC 的设置和时间维持不变。但是在系统复位后，会自动禁止访问后备寄存器和 RTC，以防止对后备区域(BKP)的意外写操作。所以在要设置时间之前，先要取消对备份区域（BKP）的写保护。

RTC的简化框图，如图4-2所示。

图4-2 RTC框图

RTC由两个主要部分组成（参见图4-2），第一部分(APB1 接口)用来和 APB1 总线相连。此单元还包含一组16bit寄存器，可通过APB1总线对其进行读写操作。APB1接口由APB1总线时钟驱动，用来与APB1总线连接。

另一部分(RTC核心)由一组可编程计数器组成，分成两个主要模块。第一个模块是RTC的预分频模块，它可编程产生1秒的RTC时间基准TR_CLK。RTC的预分频模块包含了一个20位的可编程分频器(RTC预分频器)。如果在RTC_CR寄存器中设置了相应的允许位，则在每个TR_CLK周期中RTC产生一个中断(秒中断)。第二个模块是一个32位的可编程计数器，可被初始化为当前的系统时间，一个32位的时钟计数器，按秒钟计算，可以记录4294967296秒，约合136年左右，在本应用中，这已经是足够了的了。

3.1.4 温度传感器

DS18B20是由 DALLAS半导体公司推出的一种的“一线总线”接口的温度传感器。与传统的热敏电阻等测温元件相比，它是一种新型的体积小、适用电压宽、与微处理器接口简单的数字化温度传感器，如图4-3所示。

图4-3 DS18B20 原理图

一线总线结构具有简洁且经济的特点，可使用户轻松地组建传感器网络[2]，从而为测量系统的构建引入全新概念，测量温度范围为-55~+125℃，精度为±0．5℃。现场温度直接以“一线总线”的数字方式传输，大大提高了系统的抗干扰性。它能直接读出被测温度，并且可根据实际要求通过简单的编程实现 9~l2 位的数字值读数方式。它工作在 3—5.5 V 的电压范围，采用多种封装形式，从而使系统设计灵活、方便，设定分辨率及用户设定的报警温度存储在EEPROM 中，掉电后依然保存。

3.1.5 无线联网模块

ESP8266是一个完整且自成体系的Wi-Fi网络解决方案，能够通过外部应用处理器加载所有Wi-Fi网络功能。

ESP8266提供强大的片上处理和存储能力，使其可通过GPIO口集成传感器及其他应用的特定设备，实现了最低前期的开发和运行中最少地占用系统资源。ESP8266高度片内集成，包括天线开关balun、电源管理转换器，因此仅需极少的外部电路，且包括前端模块在内的整个解决方案在设计时将所占PCB空间降到最低，如图4-4所示。

图4-4 ESP8266串口Wi-Fi模块PCB图

装有ESP8266的系统表现出来的领先特征有：节能VoIP在睡眠/唤醒模式之间的快速切换、配合低功率操作的自适应无线电偏置、前端信号的处理功能、故障排除和无线电系统共存特性为消除蜂窝、蓝牙、DDR、LVDS、LCD干扰。

3.2 软件设计

3.2.1 总体设计和软件框架

单片机上的软件采用三层构架，如图4-5所示。

图4-5 软件构架图

最底层为CHIP层，这一层的直接操作寄存器配置芯片来直接和芯片及芯片内部外设打交道的芯片层，主要包括adc、bkp、can、cec、crc、dac、dbgmcu、dma、exti、flash、fsmc、gpio、i2c、iwdg、pwr、rcc、rtc、sdio、spi、tim、usart、wwdg等。这一层最基本的API由STMicroelectronics公司的STM32F10x_StdPeriph_Driver软件包提供，为了方便使用和提高效率，在兼容STM32F10x_StdPeriph_Driver的基础上使用STM32FGLIB对其优化使其对上层表现为效率更高，移植更方便，更便于理解，主要使用的方式为使用汇编或寄存器配置提高效率，外设配置文件化来达到目的。

第二层为HAL_Driver层，包含所有硬件外设驱动这一层依赖于CHIP层如果这一层的驱动完全依赖于STM32FGLIB，可以具有更高的移植性，当改变底层芯片时代码不需要任何改变，当外设接口改变，比如使用不同的IO口，不同的串口，或者是当SPI硬件接口不够用，必须使用软件模拟SPI时可以做到不更改代码，仅仅需要修改配置文件就可以兼容最新硬件的目的。

这一层对上提供外设硬件API，在本设计中DS18B20为温度传感器，则需要在HAL_Driver中增加DS18B20这一配置，并实现两个通用API：

Void DS18B20_Init(void);
Float DS18B20_GetTemp(void);

最上层为应用逻辑层，实现应用的逻辑调用，在这一层的逻辑实现是基于调用器的，考虑到MCU上资源的紧缺，没有使用完整的操作系统，完整的操作系统任务调度是需要复杂的现场保护恢复等实现，带来运行效率的下降和资源消耗，因此在本设计中参考协程的思想实现任务的简单调度。

/***SYS***/
#include "sys.h"
#include "sys_os.h"
#include "minos_delay.h"
#include "stm32_config.h"
int main(void)
{SYS_INIT();/***总循环***/while (1){RunTaskA(task_rtc， 1);//实时时钟（RTC）RunTaskA(TaskSensor， 2);//传感器数据采集RunTaskA(TaskSmartConfig， 3);//SmartConfigRunTaskA(TaskCache， 4);//数据缓存RunTaskA(TaskDataEx， 5);//数据通信}
}

3.2.2 数据采集

DS18B20的其内部结构如图4-6 所示：

图4-6　 DS18B20 内部结构图

DS18B20的地址序列码就是出厂前被被光刻在ROM上的64bit序列号，每颗DS18B20的64bit序列号均不相同。64bit地址序列码的排列是：前 8 bit是产品家族码，接着48bit是DS18B20 的序列号，最后8bit是前面56bit的循环冗余校验码(CRC=X8+X5 +X4 +1)。DS18B20的地址序列码的作用是使每一颗DS18B20的通信地址都各不相同，这样就可实现在一根总线上挂接多个DS18B20。

所有的单总线器件要求采用严格的信号时序，以保证数据的完整性。DS18B20共有6种信号类型：复位脉冲、应答脉冲、写0、写1、读0和读1[5]。所有这些信号，除了应答脉冲以外，都由主机发出同步信号。并且发送所有的命令和数据都是字节的低位在前。

这几个信号的时序分别为：

复位脉冲和应答脉冲:单总线上的所有通信都是以初始化序列开始。主机输出低电平，保持低电平时间至少480us，以产生复位脉冲。接着主机释放总线，4.7K 的上拉电阻将单总线拉高，延时 15～60 us，并进入接收模式(Rx)。接着 DS18B20 拉低总线 60~240 us，以产生低电平应答脉冲，若为低电平，再延时 480 us。
写时序:写时序包括写 0 时序和写 1 时序。所有写时序至少需要 60us，且在 2 次独立的写时序之间至少需要 1us 的恢复时间，两种写时序均起始于主机拉低总线。写 1 时序：主机输出低电平，延时 2us，然后释放总线，延时 60us。写 0 时序：主机输出低电平，延时 60us，然后释放总线，延时 2us。
读时序:单总线器件仅在主机发出读时序时，才向主机传输数据，所以，在主机发出读数据命令后，须马上产生读时序，以便从机能够传输数据[3]，所有读时序至少需要 60us，且在 2 次独立的读时序之间至少需要 1us 的恢复时间。每个读时序都由主机发起，至少拉低总线 1us。主机在读时序期间必须释放总线，并且在时序起始后的 15us 之内采样总线状态[4]。典型的读时序过程为：主机输出低电平延时 2us，然后主机转入输入模式延时 12us，然后读取单总线当前的电平，然后延时 50us。在了解了单总线时序之后，我们来看看DS18B20 的典型温度读取过程，DS18B20 的典型温度读取过程为：复位发 SKIP ROM 命令（0XCC）发开始转换命令（0X44）延时复位发送 SKIP ROM 命令（0XCC）发读存储器命令（0XBE）连续读出两个字节数据(即温度)结束。

3.2.3 数据通信

在线温度计设计和制作中数据通信是最重要的一环，数据通信的可靠与否决定了整套系统的可靠性，数据通信要求满足轻量和可靠。

底层协议使用TCP协议，因此简化了在通信可靠性上的设计，且不需要考虑数据的拼接等情况因此设计协议，如表4-1所示。

表4-1 通信协议表

帧头	数据长度	数据
5A	1个字节	不定长

这是外层协议用于对tcp数据分包，服务器接收到tcp数据后根据帧头对之后的数据进行分包，取出其中的数据，如表4-2所示。

表4-2 数据解析表

MAC	传感器类型	数据
4个字节	2个字节	不定长

单片机的流程为逆流程。每一片单片机拥有自己唯一的出厂ID这个ID全球唯一不可更改因此可以最为传感器数据采集终端的身份ID，这个身份ID为数据包的第一部分，为了兼容不同的传感器信号，以便服务器做出正确的处理，增加以为传感器类型字段，根据不同的传感器类型来对数据进行打包。

表4-3为不同传感器类型对应数据打包/解析方式。

表4-3 传感器类型解析表

传感器类型(2个字节)	时间戳	温度(x10)
0001	4个字节	2个字节

为了防止数据在传输时被篡改，数据采用端到端的加密方式。

端到端加密允许数据在从源点到终点的传输过程中始终以密文形式存在[12]。采用端到端加密（又称脱线加密或包加密），消息在被传输时到达终点之前不进行解密，因为消息在整个传输过程中均受到保护，所以即使有节点被损坏也不会使消息泄露。

端到端加密系统的价格便宜些，并且与和相比更可靠，更容易设计、实现和维护。端到端加密还避免了其它加密系统所固有的同步问题，因为每个包均是独立被加密的，所以一个报文包所发生的传输错误不会影响后续的报文包。此外，从用户对安全需求的直觉上讲，端到端加密更自然些。单个用户可能会选用这种加密方法，以便不影响网络上的其他用户，此方法只需要源和目的是保密的即可。

通过这种方式，服务器可以确保所有数据都是来自传感器数据采集终端而不是被伪造的，终端也能确保只有己方服务器才能收到数据，不会被第三方所窃取。

3.2.4 可靠性设计

在线温度计有可能会出现这么一种情况，那就是网络崩溃，无论是运营商网络崩溃，还是传感器数据采集终端连接的路由器崩溃，又或者是服务所在网络崩溃，甚至是服务器重启，维护等导致的网络链路断开都会导致本应该被存到数据库中的数据却没有存进去，也就是说这一段数据丢失了。

为了防止网络不可靠导致的数据丢失情况，本设计采用了一项可靠性设计来解决这一问题，那就是本地数据二级缓存，一级缓存可以在网络临时堵塞时对数据进行缓存，但是当网络不是临时性的，也就是说缓存数据超过一级缓存能缓存的极限后，二级缓存便会启动，二级缓存其本质上是一个对flash进行自编程的服务，二级缓存将达到缓存极限的一级缓存(一般为K级别)整块写入flash，数据在flash中也数据块的形式存在，整个缓存空间一般在M级别可以做到对数据的长时间缓存。

但由于一级缓存以流的形式缓存数据，而二级缓存以数据块的形式缓存，因此一级缓存在二级缓存服务启动后必须做乒乓交换。

在第一个缓冲周期，将输入的数据流缓存到“数据缓冲模块1”；在第2个缓冲周期，通过“输入数据选择单元”的切换，将输入的数据流缓存到“数据缓冲模块2”，同时将“数据缓冲模块1”缓存的第1个周期数据通过“输出数据选择单元”的选择，送到 “数据流运算处理模块”进行运算处理；在第3个缓冲周期通过“输入数据选择单元”的再次切换，将输入的数据流缓存到“数据缓冲模块1”，同时将“数据缓冲模块2”缓存的第2个周期的数据通过“输出数据选择单元”切换，送到“数据流运算处理模块”进行运算处理。如此循环。

3.2.5 易用性设计SmartConfig

SmartConfig的原理为首先使用设备在当前路由下以255.255.255.255为目的IP广播包含配置信息的UDP包。

ESP8266端首先会先扫描空间中的AP信号，扫描得到AP的相关信息，如AP工作在哪个通道等信息，然后配置ESP8266芯片工作在刚才扫描得到的通道上去接收UDP广播包(广播IP为255。255。255。255)，如果没有接收到特定的配置信息，继续配置ESP8266工作在另外的通道上，如此循环，直到收到特定的包含配置信息的UDP包为止。ESP8266从UDP包中解压得到要配置的AP的SSID，加密方式，密码等信息。

ESP8266主动连接上AP，SmartConfig整个过程结束。

最后使用SmartConfig的步骤如下:

启动ESP8266的电源
手机连接目标网络，启动SmartConfig
等待ESP8266连接成功。

四、数据处理平台

4.1 总体方案

该系统的数据处理平台由于并不涉及任何底层代码，主要为网络和数据应用，并需要适应各种算法，因此选用Python2.7作为开发语言。

Python就为我们提供了非常完善的基础代码库，覆盖了网络、文件、GUI、数据库、文本等大量内容，被形象地称作“内置电池（batteries included）”。用Python开发，许多功能不必从零编写，直接使用现成的即可。

除了内置的库外，Python还有大量的第三方库，也就是别人开发的，供你直接使用的东西。当然，如果你开发的代码通过很好的封装，也可以作为第三方库给别人使用。

Python又被称为胶水语言，可以很方便的和其他语言对接，也就是说需要调用次平台中的数据时，并不指定任何一种语言，可以选择最适合自己的一种语言，当然也可以使用Python，毕竟Python内置了大量的基础算法等可以快速开发，并且在效率上来说调用内置库的效率并不低，应为Python大量的内置库都是使用Python开发的。

对于服务器框架则选择Django 1.8.2，此系统起本质上已有数据驱动的，而Django最让人满意的就是其ORM框架，我们可以通过这个ORM框架搭建我们的数据库系统而不必关心其具体细节，加快开发速度，节约其后期的维护成本，毕竟大部分软件，其后期维护成本往往非常高昂。

数据库软件的选择为关系型数据库MYSQL。由于该系统使用了ORM框架，其底层的数据系统和上层无关，且鉴于前期数据量并不大，可以使用任一数据库系统。

为了让数据能可视化显示，同时减轻服务器负担，将计算量前段化，选用基于jQuery的Highcharts库。

至于服务器系统和部署，服务器选用Ubuntu Server 14.04.1 LTS，部署在阿里云青岛服务节点，表5-1为服务器硬件配置，该配置满足在调试阶段的最低配置要求。

表5-1 服务器硬件配置表

CPU	1核
内存	1024 MB
带宽	1Mbps（峰值）
公网IP	115.28.32.***

4.2 程序流图

4.2.1 应用层流图

应用层基于框架层之上，只处理应用逻辑，如图5-1所示，主要分为两块：一块为数据的接收储存，另一块为数据的处理查询。

图5-1 系统流程图

4.2.2 框架层流图

框架层所有的请求、返回都由中间件来完成。

中间件，就是处理HTTP的request和response的，类似插件，比如有Request中间件、view中间件、response中间件、exception中间件等，Middleware都需要在 “project/settings。py” 中 MIDDLEWARE_CLASSES 的定义。大致的程序流程如图5-2所示。

图5-2 Middleware处理流程图

首先，必须在“project/settings.py”中 MIDDLEWARE_CLASSES处定义，一个HTTP请求，将被这里指定的中间件从头到尾处理一遍，暂且称这些需要挨个处理的中间件为处理链，如果链中某个处理器处理后没有返回response，就把请求传递给下一个处理器；如果链中某个处理器返回了response，直接跳出处理链由response中间件处理后返回给客户端，可以称之为短路处理。

所以在view 层函数的时候，都必须以return response或者return HttpResponse(x) 结尾。

4.3 数据库设计

数据库在Django框架下遵循ORM设计，编码如下：

#coding:utf-8
from django.db import models
# Create your models here.
class Temp(models.Model):#温度m_time   = models.DateTimeField(blank=False，auto_now_add=False)#时间m_value  = models.FloatField(default=0.0)#温度值def __unicode__(self):return unicode(self.m_time)

数据库表设计如表5-2所示。

表5-2　原始温度数据表

字段名	数据类型	长度	说明	描述
Id	Long	4	非空，主键	序号
m_time	DateTimeField	4	非空	采集时间
m_value	FloatField	4	非空	温度数据

4.4 ４界面设计

#coding:utf-8
from django.shortcuts import render
# Create your views here.
from django.http import HttpResponse
from BiYeSheJi.models import Temp
from  datetime  import  *   
import time  
Data=[[1，2，3，4，5，6，7，8]，[11，12，13，14，15，16]]
CurveDataTMax=[]
CurveDataTMin=[]
from django.db.models import Max，Min，Sum，Count
def curve(request):TempDefaultValue=23.0DateDefaultValue='2015-11-11'TimeDefaultValue='11:11'if request.method == 'POST':# 当提交表单时TempDefaultValue=request.POST['CurveDataTMax0']DateDefaultValue=request.POST['CurveDataTMax1']TimeDefaultValue=request.POST['CurveDataTMax2']Temp.objects.create(m_time=datetime.strptime(request.POST['CurveDataTMax1']+request.POST['CurveDataTMax2']， "%Y-%m-%d%H:%M")，m_value=request.POST['CurveDataTMax0'])CurveDataTMax=[]CurveDataTMin=[]CurveDataTime=[]for tmp in t:CurveDataTMax.append(tmp['m_valueMax'])CurveDataTMin.append(tmp['m_valueMin'])CurveDataTime.append(tmp['m_time'].strftime("%Y-%m-%d %H:%M:%S"))return render(request，'曲线.htm'，{'CurveDataTMin': CurveDataTMin，'CurveDataTime': CurveDataTime，'CurveDataTMax': CurveDataTMax，'TimeDefaultValue':TimeDefaultValue，'TempDefaultValue':TempDefaultValue，'DateDefaultValue':DateDefaultValue，})

五、制作与调试

5.1 硬件电路的布线与焊接

5.1.1 总体特点

该系统所涉及的各部分硬件电路，总体的特点是：

电路原理简单，所用的器件均为常用器件，传感器也为常用数字是传感器。
需要用到linux服务器，为了方便维护将服务器托管在阿里公司的云上。
由于存在两个终端，在双方之间的通信协调是最容易出问题的地方需要特别注意。

5.1.2 焊接

焊接原则和注意事项:

主控芯片使用了QFP64封装，引脚多，间距小，芯片脆弱，焊接时需要特别小心，在核对引脚顺序的同时防止出现虚焊等现象，在焊接完成后使用万用表的通断测试功能检查焊接质量。

先焊接主控芯片，再焊接贴片电容电阻等小器件，最后焊接连接件等大体积器件，以降低难度，节约时间和降低出错率。

5.2 调试

5.2.1 联调测试

依次对CheckList项进行测试检查，检查项和结果如表6-1所示。

表6-1 联调CheckList表单

检查项	结果
1.系统供电是否正常	OK
2.传感器供电是否正常	OK
3.是否收到传感器数据	OK
4.传感器数据是否正常	OK
5.WireShark抓包测试终端数据发送是否正常	OK
6.使用Database Browser查看数据库数据是否异常	OK
7.使用Chrome登录WEB页面测试WEB服务器提供是否正常	OK

5.2.2 实物论述

图6-1 温度采集终端

图6-2　SmartConfig手机客户端

图6-3 数据处理平台Web主页

图6-4 每个时刻最大最小温度曲线

图6-5 页面编程调制过程图

5.2.3 问题解决

在将温度采集终端连上无线路由器时使用的配置方法为SmartConfig由于此协议需要硬件和硬件内部固件版本的支持，在开始使用时由于固件版本过低，使用了0.8版本导致无法使用此功能将ESP8266的固件将更改为V0.9.2.2版本后问题顺利解决。
服务器和设备使用HTTP协议通信，在PC机上使用软件模拟温度采集终端向服务器发送或索取数据测试通过但使用单片机进行通信时发现数据校验无法通过，使用wire-shark抓包，对比模拟器和实际终端在网络链路上的数据，发现数据一致性为100%，于是将问题定位在单片机数据的接受端，通过ARM Development Tools中的在线debug工具对其进行在线调试发现数据接收时的逻辑存在错误导致丢失最开始的一个数据包导致校验通不过，修改此部分代码后问题不再复现。

六、结论

本设计方案达到了任务书的要求，实现了熟读数据采集、传输\储存\处理和显示，实现了一个较为完整的在线温度计：

前端温度传感器能采集到正确的温度，在经过和矫正温度计的实验对比后发现实测温度和实际温度的偏差在+-1摄氏度以内，满足设计要求；
使用wire-shark抓包显示数据通信正常，使用Database Browser检查数据库发现数据没有存在丢失现象；
在线情况下，使用Google Chrome登录服务器网站，能正常查询显示温度数据，且温度数据和温度采集终端上传数据一致，温度数据以曲线显示，满足数据可视化的要求；

由于时间、水平和经验有限，在电路的设计选型制作，温度的测量精度，温度采集终端的接入，以及数据显示等方面，有改进的余地，比如传感器和电路板可以集成，温度可以增加线性矫正，数据显示可做更多处理，页面也可以重新设计，是用户体验更好。另外在系统的调试方面，由于时间和设备的原因，只进行了短时间，小规模的调试，关于设备的稳定性，带载量等有待进一步的调试。

这次毕业设计对于我来说，既是一次机遇，又是一次挑战。通过这次的毕业设计，我学到了很多东西，通过自己的实践，增强了动手能力。通过实际工程的设计也使我了解到书本知识和实际应用的差别。在实际应用中遇到很多的问题，这都需要我对问题进行具体的分析，并一步一步地去解决它。

查看全文

http://www.dtcms.com/a/345046.html