第3章数据采集层设计

3、数据采集层设计：传感器选型与接口协议（I2C/SPI/UART）、数据采集网关架构、边缘采集策略

好，咱们进入数据采集层。这一层是整个物联网系统的「触手」。传感器选错了，接口协议没搭对，网关架构设计不合理，后面所有优化都是白搭。我这些年踩过的坑，有一半都集中在这一层。

很多人选传感器，上来就问「精度多少」。其实这不对。你想想看，一个工业振动传感器，精度再高，但采样率只有10Hz，能抓到轴承的早期故障吗？抓不到。

我个人习惯，选型时先看三个维度：

量程与分辨率：量程要覆盖实际场景的1.5倍以上。分辨率不是越高越好，够用就行。比如温度传感器，0.1℃分辨率对大多数场景足够了，0.001℃反而引入噪声。
采样率与带宽：根据奈奎斯特定理，采样率至少是信号最高频率的2倍。实际工程中我一般取5-10倍。做音频采集，20kHz信号，采样率至少100kHz。
功耗与接口：电池供电的设备，功耗是硬指标。我记得有个项目，选了I2C接口的温湿度传感器，待机电流只有0.1μA，电池撑了两年。要是用SPI的，功耗直接翻10倍。

避坑指南：我曾经在一个农业大棚项目里，选了某款「高精度」土壤湿度传感器。结果发现它受温度影响极大，30℃和10℃测出来的值差了20%。后来换了一款带温度补偿的，问题才解决。所以，选型时一定要看数据手册里的「交叉灵敏度」参数。

这三种协议，是嵌入式工程师的老朋友了。但很多人用了一辈子，也没搞清楚什么时候该用哪个。我简单说说我的理解。

I2C：优点是线少，可以挂多个设备。缺点是速度慢，而且总线电容大了容易出问题。我做过一个项目，挂了8个I2C传感器，结果通信老是出错。后来发现是总线电容太大，加了电平转换芯片才搞定。

SPI：速度快，全双工，适合大数据量传输。但每加一个设备就要多一根片选线。我建议，如果传感器数量不超过3个，且需要高速采集，优先用SPI。

UART：最简单，但只能点对点。距离可以做到几十米，用RS232或RS485还能更远。我习惯把UART留给调试口和无线模块，因为它的协议栈最轻量。

我的经验法则：板内传感器，数量多且速度要求不高，用I2C；数量少且速度要求高，用SPI；跨板通信或与无线模块交互，用UART。

网关是采集层的「大脑」。它要负责把各种传感器的数据收上来，做初步处理，再转发到云端或边缘服务器。

我常用的网关架构分三层：

接口层：负责物理连接。一般会预留I2C、SPI、UART、GPIO、ADC等接口。我建议每个接口都加ESD保护芯片，别省这个钱。我见过一个项目，没加保护，雷雨天烧了三个网关。
协议层：负责数据解析。不同传感器的数据格式不一样，有的用Modbus，有的用自定义协议。我习惯在协议层做一个「协议适配器」，把不同协议统一成内部格式。这样上层处理就简单了。
处理层：负责数据缓存、滤波、压缩。这里我会用环形缓冲区来缓存数据，防止突发数据丢失。滤波的话，简单移动平均就够了，别动不动就用卡尔曼滤波，太复杂了。

注意：网关的存储空间有限。我建议只缓存最近1小时的数据，超过的就丢弃或上传。别想着把所有数据都存下来，除非你用的是工业级网关，带大容量SD卡。

边缘采集，说白了就是在数据产生的地方做处理，而不是一股脑全传到云端。这样做的好处是：减少网络带宽、降低延迟、保护隐私。

我常用的策略有三种：

定时采集：每隔固定时间采集一次。适合温度、湿度这种变化缓慢的信号。我一般设成1秒或10秒一次，具体看业务需求。
事件触发采集：当某个条件满足时才采集。比如振动传感器检测到超过阈值，才启动高速采集。这样可以大大降低数据量。我记得有个设备状态监测项目，平时一天只传几百KB数据，触发时才会传几十MB。
自适应采集：根据数据变化率动态调整采集频率。变化快时采得密，变化慢时采得疏。这个策略实现起来稍微复杂点，但效果最好。我一般用「斜率阈值法」来判断变化率。

一个小技巧：边缘采集时，别忘了做时间戳对齐。不同传感器的时钟可能不同步，我习惯在网关里用NTP统一校时，然后给每条数据打上UTC时间戳。这样后续分析时就不会出现时间错乱的问题。

嗯，数据采集层就讲这么多。核心就三件事：选对传感器、搭好接口、设计好采集策略。下一章咱们聊聊数据传输层，那又是另一番天地了。