解决方案:应用速递 | 助力数据采集 推动信息化系统云端发展

　　解决方案:应用速递 | 助力数据采集 推动信息化系统云端发展

　　本文来源于OCC组织发布的“屏头阁RVB2601开源应用思路合集”活动。

　　开发者nbfei通过调用串口与测量板通信，接收测量板的测量数据，控制其测量范围。另外，控制W800连接IOT studio，上传数据，接收控制指令，完成*敏*感*词*仪器的云端数据系统。

　　*敏*感*词*仪器云数据系统的实现过程请参考本文详细介绍。

　　01项目背景

　　本人参加2021年电竞，A题THD测量装置获全国二等奖。我正在对设备进行全方位升级，包括测量范围、精度、带宽、测量参数等，目的是实现硬件便携（袖珍仪器和数据采集卡结合）、手机+PC上位机显示、系统不局限于特定测量仪器的功能，可以方便地更换具有示波器、信号发生、万用表等功能的测量板，扩展相应的功能。此开发板的应用旨在用于远程控制、无线传输解决方案原型制作和云数据系统原型制作。

　　02 作品介绍

　　由于以上内容除了使用RVB2601实现云数据系统*敏*感*词*绕RVB2601的使用介绍。

　　图片左端是我设计制作的第一版测量板。主要实现输入任意波信号的采集，THD测量，频率、VPP和谐波归一化幅值等参数的测量，单周期波形的采集。见第三部分。测量板将采集到的数据通过串口发送给PC，蓝牙发送给手机。本作品提交时，由于需要串口，所以将蓝牙模块的串口断开连接到CH2601的串口0，RVB2601接收数据并分析每次测量。参数，然后将数据上传到IOT studio进行显示，个别数据会显示在液晶屏上。

　　03 各部分功能说明及分析

　　非常感谢平头哥的支持。本次测评活动，因为忙于考研复试和毕业设计，所以只发了个帖子，分享一下RVB2601应用板的使用心得。我将在五月左右开始。使用开发板熟悉环境并构建一个简单的应用程序应该需要八九天的时间。当时申请板子的时候，目的是给必社增加一个上传数据到云端的功能，但是做完前面的任务剩下的时间余量已经不够用了，不过基本实现了Web展示的功能，遗憾的是. 是单周期波形显示功能，暂未收录。

　　首先，我的毕业设计来自于2021年电竞赛题A的信号失真测量装置，在比赛过程中，我也完成了比赛要求。因此，最终的设计主要是整个电路的集成和参数的优化。另外，增加了PC上位机的显示。控制功能整体比较简单。在毕业设计*敏*感*词*中，电路设计阶段参考DSO模拟前级电路原理，单片机程序设计综合运用等效时间采样、平顶窗、频谱分析等应用原理，实现整个测量系统的设计和生产。项目整体设计完成后，期望通过应用的RVB2601+IOT studio实现WEB端的数据查看和测量控制。设计过程如下。

　　初次接触一块新板子或单片机，如使用MSP430、MSP432时，可参考官网提供的详细datasheet和userguide，使用例程了解工作机制，构建应用程序。刚收到RVB2601之后，我也是这么想的，但是官方的资料很少，目前为止套路也比较有限。我对物联网和操作系统的了解仅限于使用Bear Pi和LiteOS连接华为云。为了熟悉STM32的低功耗系列，另外我的主要方向是底层板级设计和程序开发信号处理，所以一开始不太习惯用RVB2601。在我看来，只有uart的操作被一次又一次的封装了。，分为不同的包，

　　好在这次需要用到的外设不多。我只需要调用一个串口，用来和测量板通信，接收测量板的测量数据，控制它的量程。另外，控制W800连接IOT studio，上传数据，接收控制指令。

" />

　　3.1 串口

　　由于本设备的PC端和移动端应用都是基于.NET框架开发的，所以我也是采用异步方式在两个平台上接收数据并对数据进行拼接分析。因此，在这款单片机的使用上，我也比较喜欢异步。发送和接收，这和我以前裸跑32/432不一样。我按照GitBook指导文档中CSI2驱动接口的异步接收和接收接口指令和例程实现了TX，但是无法实现非固定字节接收，这让我很苦恼。很长一段时间，我想过很多办法，比如读取串口接收寄存器中的缓冲区数等等，但基本上都失败了。后来看了sipower的帖子，嗯，试过了，嗯，可以的，

　　后来还是使用了同步收发，顺利完成了收发任务。

　　//串口接收函数<br />void get_input(char * str)<br />{<br /> char input = 'a'; <br /> uint32_t i ;<br /> uint32_t num = 0;<br /> for( i = 0; i initiatorType === 'script' && entryType === 'resource')

　　根据上一节的结论，我们不再详细记录资源加载各个环节的数据。这里我重点采集

资源加载的持续时间和资源加载的开始时间，这两个我们都可以从PerformanceEntry中获取。得到的，分别是duration和fetchStart。因为在我看来，前端加载和缩短加载时间是提升性能的有效手段。如果事后这两个值没有异常 ，那就考虑采集更多的指标

　　报表元素出现时间

　　确认元素出现最简单粗暴的方法是通过setInterval轮询元素是否出现，但是在现代浏览器中我们可以使用MutationObserver API来*敏*感*词*元素的所有变化，所以可以换种方式提问: 在body标签下出现.single-folder-container元素时，关键代码大致如下

　　const observer = new MutationObserver(mutations => { if (document.querySelector('.single-folder-container')) { observer.disconnect(); return; } }); observer.observe(document.querySelector('body'), { subtree: true, childList: true });

　　这就是问题所在：这段代码极其关键且难以测试。

　　第一个问题是，例如，Jest 环境中没有原生的 MutationObserver 对象。如果你简单地模拟 MutationObserver 对象来通过测试，那么测试的意义就没有了；

　　其次，即使你在像Headless Chrome这样支持MutationObserver的环境中测试，你是否知道它向你报告的元素是正确的？因为你不知道具体时间是多少（也就是你考李的预期），10秒肯定不对，但是2.2秒呢？

　　其他性能指标

　　理论上，以上两个都是我们期望采集

到的指标。但是我还想采集

另外两个指标：First Paint 和 First Contentful Paint。简单的说，就是记录浏览器绘制页面的一些关键时刻。这两个指标也可以从Performance API获取

　　window.performance.getEntries().filter(entry => entry.entryType === 'paint')

　　Paint Timing 将比纯技术指标更贴近用户体验，但我们将拭目以待它与实际用户看到元素出现的情况相比如何

　　后端时间

　　我猜想有两个可能的性能瓶颈：1）Redis 查询 2）MySQL 查询。

　　Redis主要用于session存储，后端采用Node.js + ExpressJS搭建，不易监控session读取性能。所以我优先考查MySQL的查询性能，比如统计findByFolderId方法的读性能：

　　const findFolderIdStartTime = +new Date();await FolderService.findByFolderId(parseInt(req.params!.id))appInsightsClient.trackMetric({ name: "APM:GET_SINGLE_FOLDER:FIND_BY_ID", value: +new Date - findFolderIdStartTime});

　　总结

　　最后，为了在日志平台上找到对应的指标，并对指定类型的指标进行统计，我们需要对上述指标进行命名。以下是命名规则。

　　上一篇文章即将结束。我已经解释了这个性能采集方案的思路，基本实现了我们的性能采集脚本。有了这些代码，我们基本上就可以完整的采集

到单次的性能数据了