1. 一次数据采集的全貌：传感器、信号链与数据文件的三角关系
1.1 我为什么想把这篇文章写出来
前几天帮朋友排查一套环境监测装置，现场用的是一块STM32F103C8T6开发板，接了一个MQ2烟雾传感器，再通过串口把数据发给PC，PC端用串口助手存成CSV。表面上看所有环节都“通”了，串口助手里数字也在跳，但导出文件一分析，发现数值长期飘在1.2V到1.8V之间，跟实际烟雾浓度完全对不上。最后查了两天，问题出在传感器供电上——3.3V的稳压芯片纹波大得惊人，而MQ2这类电阻型传感器对电源噪声又极其敏感。
这类问题几乎每个做采集的人都遇到过。很多教程只告诉你“传感器接ADC，程序一读，数据就出来了”，却没人告诉你从传感器敏感元件到最终的数据文件之间，隔着一整条信号链路。任何一环的电气参数、时序、格式处理没做对，最后写进文件里的数字都可能是废数据。
所以我决定把这条链路完整拆开讲一遍。本文适合刚接触嵌入式采集的初学者，也适合那些已经能把数据读出来、但总觉得数据质量不对的工程师。内容会从传感器输出特性一直讲到文件格式选择，每个环节都会给出我踩过的坑和现在还在用的处理方法。
1.2 一条典型采集链路需要拆成几段来看
我习惯把一次采集分成四段：
第一段是传感器本身，它负责把物理量（烟雾浓度、温度、压力、加速度等）变成某种电学量，比如电阻变化、微弱的电压、几毫安的电流。第二段是信号调理电路，包括阻抗匹配、放大、滤波、电平移位，目的是让信号在幅度、阻抗、带宽上都符合ADC的输入要求。第三段是ADC采样与量化，把连续模拟量转换成离散数字量，同时受采样率、分辨率、参考电压的影响。第四段是数据传输与文件落盘，数字量通过串口、SPI、USB或网络传到处理器或上位机，最终按某种格式写入文件。
这四个分段不是孤立的。传感器输出阻抗决定了信号调理输入阻抗要怎么设计；调理电路输出幅度决定了ADC参考电压选1.2V还是3.3V；ADC位数和采样率决定了数据文件里每秒钟会产生多少字节；而数据文件的格式反过来也限制了你后续能做什么分析。所以我会尽量把每一段之间的接口参数讲清楚，而不是孤立地讲某个模块。
1.3 每个环节的职责与常见误区
先说几个最常见的认知误区：
很多人以为传感器输出就是“标准的0~3.3V电压”，直接接ADC就行。但实际上绝大多数传感器输出都不是一个理想的电压源，像光电二极管输出的是nA级别的电流，电荷型压电传感器输出的是电荷，应变片则是电阻变化。这些都要经过转换电路。
还有人把软件滤波当作万能药，信号调理得很随意，觉得反正程序里可以做均值、做低通。但ADC采到的已经是带噪的模拟量量化结果，如果模拟信号本身被噪声淹没或超出了ADC量程，软件滤波只能把信噪比略微提升，无法恢复已经丢失的信息。
更有一种情况是数据文件格式想当然，比如用浮点数直接写CSV，结果换了一个平台后小数点被截断，或者时间戳只有秒级导致同一秒内多条数据无法区分。这些都是在“从传感器到数据文件”链路的最后一环出错，但排查起来往往最花时间，因为问题不在电路上，而在格式和处理逻辑上。
2. 传感器侧：物理量怎么变成电信号，以及你一定踩过的阻抗匹配坑
2.1 传感器输出的三种基本类型
拿到一颗传感器，先别急着接板子，第一件事是看它的输出类型。我把常见传感器分成三大类：
- 电阻型：比如MQ2烟雾传感器、PT100热电阻、光敏电阻。它们把物理量映射成一个电阻值，通常需要外加分压电路或电桥才能变成电压。
- 电压型：比如霍尔传感器、绝大部分MEMS加速度计、温湿度模块（I2C输出的除外）。这类输出的是一个有限的电压范围，有的可以直接接ADC，有的需要电平移位。
- 电流型：比如4-20mA输出的压力变送器、光电二极管。电流型的好处是抗干扰能力强，适合长线传输，但要在接收端并联一个精密电阻把电流转成电压。
三种类型的调理思路完全不同。电阻型要先考虑激励电压和分压电阻怎么选；电流型要计算取样电阻的阻值和功耗；电压型则要注意输出阻抗和ADC输入阻抗的分压效应。
2.2 为什么MQ2烟雾传感器的模拟输出不能直接接STM32的ADC
MQ2是典型的热线型半导体传感器，它的敏感材料加热后阻值随烟雾浓度变化。市面上大多数MQ2模块板载了一个比较器和一个模拟输出口，模拟输出实际上是一个分压电压：传感器的可变电阻和一个固定电阻串联，中间抽头输出给AO口。看起来可以直接接ADC，但实际使用中有一个很要命的特性——MQ2的响应速度很慢，阶跃响应时间达到好几秒，而且它的内阻会随着温度和湿度漂移。
更关键的是，MQ2模块的模拟输出阻抗一般在几kΩ到几十kΩ之间。而STM32F103的ADC输入阻抗如果在采样时间较短时会很低，两者直接连接会形成额外分压，导致ADC读到的电压比传感器真实输出低。我曾经用PCLK=14MHz、采样周期设为1.5个时钟去读MQ2，结果同一浓度下数值比配置为239.5个时钟周期时低了将近15%。这不是传感器坏了，而是ADC输入阻抗把信号“拉低”了。
正确做法是让MQ2的模拟输出经过一个高输入阻抗的电压跟随器，比如用LM358或MCP6002，再进ADC。如果不想加运放，那就把ADC采样周期调长，实现上也凑合能用，但无法彻底解决阻抗动态变化带来的误差，所以不建议在精密场景里省掉缓冲器。
2.3 传感器供电噪声对最终数据文件的影响有多大
这个问题经常被忽略。传感器输出的电压信号，本质上是以供电电源为参考的。如果电源电压不稳，比如开关电源的纹波有100mV，且传感器的分压比例是1:1，那么输出信号里就直接叠加了约50mV的噪声。当你的ADC参考电压是3.3V、12位分辨率时，1个LSB大约是0.8mV，50mV噪声相当于60多个LSB，数据文件里看到的就是一条“毛茸茸”的曲线。
我做过一个对比实验：同一颗MQ2传感器，分别用LDO（AMS1117-3.3）和某品牌的DC-DC模块供电，采集相同的静态浓度。使用DC-DC模块时，数据文件里的数值标准差达到9.6；换成LDO后，标准差降到了1.8。这还只是在静态环境下的差异，一旦传感器检测到气体变化，噪声会直接淹没小信号。
所以我的建议是：传感器供电、模拟电路供电、逻辑电路供电尽量分开。低成本方案可以共用LDO，但在LDO输出端加一个RC滤波，比如10Ω串联电阻加10μF和0.1μF电容并联到地，能明显降低高频噪声。不要指望程序里的滤波能救回来，因为模拟噪声一旦混入信号，数字端无论如何都分不清哪些是真实变化、哪些是噪声。
3. 信号调理：放大、滤波、电平移位，少了哪一步数据都是废的
3.1 从差分信号到单端信号，接线方式决定了共模干扰的大小
模拟信号在传感器端往往是差分的，比如桥式应变片输出的是两个电压之间的差值。如果你把两个输出端分别接ADC的两个通道，再做软件差分，那是在“数据文件”层面补救电路问题，效率很低。更稳妥的方式是先用仪表放大器（如AD620、INA128）完成差分转单端。
差分转单端最大的意义在于共模抑制。长线上感应的工频干扰和射频干扰同时出现在两根线上面，仪表放大器会把它当成共模信号滤掉，只放大差模信号。我曾经在一个工厂配电间里做压力采集，现场有大功率变频器，传感器输出到调理板的线有2米长。一开始用单端接法，数据文件里50Hz工频干扰大得吓人，经过FFT分析，50Hz分量比真实信号还高20dB。换成差分输入后，同样的采样条件下50Hz分量下降了40多dB，信号一下就“干净”了。
如果你的传感器只有单端输出，也至少要把信号地线和屏蔽层可靠接到板子的模拟地上，而且尽量使用双绞屏蔽线传输信号，屏蔽层只在传感器端单点接地，避免形成地环路。
3.2 放大倍数怎么定：不只跟量程有关，还要看ADC参考电压
很多人以为放大倍数就是把信号放大得越接近ADC满量程越好，这个直觉没错，但实现时要精细计算。
假设压力传感器满量程输出是0~20mV，ADC参考电压是3.3V，12位分辨率。如果完全不放大，20mV对应的数字量只有20/3300*4096≈24.8，也就是24~25个LSB，分辨率极低。此时你需要一个放大倍数，把20mV放大到接近3.3V，理论上需要165倍。但实际电路不能做到165倍放大，因为失调电压和噪声也会被一起放大，所以需要分两级，比如第一级放大50倍，第二级放大3.3倍。
更精确的设计方法是先确定ADC的“有效利用区间”。比如你希望信号只占ADC量程的80%，即2.64V，那么放大倍数就是2.64V/20mV=132倍。取标准电阻值，第一级51倍，第二级2.6倍，总增益132.6，最后满量程对应2.652V。这样既能充分利用ADC动态范围，又留有一定裕量防止过冲。
千万别反过来设计：先随便选一个放大倍数，满量程只有1V，然后指望通过软件乘以3.3来换算。软件放大只能改变数字量的大小，不能改变量化误差，原本10mV的分辨率不会因为乘以3.3就变成3mV。
3.3 滤波到底该在硬件做还是软件做？我的建议
很多工程师迷恋软件滤波，觉得写个低通滤波函数就万事大吉。但硬件滤波和软件滤波解决的问题方向不同。
硬件滤波（尤其是RC低通滤波）能滤掉ADC采样前的高频噪声和混叠频率。ADC采样遵循奈奎斯特采样定理，如果信号中存在高于采样率一半的频率成分，它们会折叠到低频区间形成混叠。混叠一旦发生，软件就无法区分真实低频信号和混叠出来的假信号。所以在ADC之前加一个低通滤波器，截止频率略低于0.5倍采样率，是必须的。比如采样率是1kHz，低通截止频率设为200~300Hz比较合适。
软件滤波的优势是灵活，可以在采集后处理阶段进行更复杂的滤波，比如卡尔曼滤波、滑动平均。但它不能解决混叠问题，因为混叠已经发生在硬件采样阶段。我个人的经验是：硬件滤波解决“会不会混叠”，软件滤波解决“信噪比还能不能再提升”，两者配合使用。如果预算有限只能做一个，那一定是硬件滤波优先。
4. ADC采样与时钟：采样率、分辨率、位深和数据吞吐量的真实关系
4.1 12位ADC和16位ADC的差距，没有你想的那么大
同学经常问：STM32F103是12位ADC，要不要换成16位的ADS1115来提高精度？我会反问一句：你的噪声底是多少？如果你的信号调理电路噪声峰峰值有10mV，参考电压3.3V，那么12位ADC的量化噪声是3.3V/4096≈0.8mV，14位是0.2mV，16位是0.05mV。当你的电路噪声是10mV时，12位和16位ADC的输出在LSB级别上几乎看不出差别，因为你采到的信号本身就在抖动。此时即使换了16位ADC，有效分辨率也只有9~10位。
真正该做的是先把前端噪声降下来。有一个经验公式：ADC有效位数ENOB≈(SNR-1.76)/6.02，SNR是信号与总噪声之比。如果你希望达到12位有效分辨率，SNR需要达到74dB左右。如果前端噪声太大，就算ADC是24位，有效位数也高不起来。
所以我的建议是：先测一下ADC输入端的噪声底。用示波器看峰峰值，或者直接连续采集静态电压做标准差计算。如果标准差对应的电压值超过ADC的一个LSB，那换更高位数的ADC意义不大，先优化硬件才是关键。
4.2 采样率不是越高越好，过采样也不是万能药
很多人做振动采集时喜欢把采样率拉满，STM32ADC在最快采样周期下能达到1Msps，听起来很爽，但数据文件会迅速变大，同时模拟前端带宽和抗混叠滤波未必跟得上。比如你关心的是1kHz以内的振动信号，采样率设200kHz，除了浪费存储，还容易引入高频噪声混叠。
过采样技术确实能通过“采多次求平均”来提高有效分辨率。以4倍过采样为例，理论上可以提高1位有效分辨率，因为过采样将量化噪声分散到更宽的频带内，再通过数字滤波去掉带外噪声。但这里有前提：信号本身是平稳的，噪声是近似白噪声，且每次采样之间不存在固定频率干扰。如果电路有周期性噪声，比如电源的100Hz脉动，过采样无法消除它。
我在采集正弦波时习惯先把采样率设为信号最高频率的10~20倍。比如要分析10kHz以内的谐波，采样率设128kHz，既能满足奈奎斯特要求，又留足抗混叠滤波过渡带空间。数据量也会比较合理，128ksps下每通道每秒产生128k个采样点，12位即2字节，也就是256KB/s，文件增长速度还能接受。
4.3 时钟抖动和采样保持电容：数据文件里毛刺的真正来源
ADC的采样保持电路在采样脉冲有效时，内部开关闭合，保持电容充电到输入电压。如果采样时间不够长，电容没充满，或者信号源的内阻太大，充电时间常数过长，就会导致测量值偏低。这就是为什么STM32F103的ADC用短采样周期读高阻信号源会偏小的原因。
时钟抖动指的是采样时刻的随机波动，对高频信号影响较大。举个例子，你采一个1kHz正弦波，时钟抖动1ns，造成的电压误差大约等于信号变化率乘以抖动时间，即2π×1000×幅度×1ns，如果幅度是3.3V，误差约为20μV，可以忽略。但如果信号变成1MHz，同样抖动1ns，误差就变成20mV，对于12位ADC来说已经是25个LSB，会出现明显毛刺。
所以高频采集一定要用稳定的时钟源，避免软件定时翻转GPIO触发采样。STM32内部定时器触发ADC是比较稳的，但要注意定时器时钟和ADC时钟来自同一个PLL，PLL抖动通常不会太大。最忌的是在中断里调用ADC转换函数，中断响应的时间不确定性会直接变成采样时刻抖动，在数据文件里表现为时间间隔不均匀，这比幅度毛刺更麻烦。
5. 数据传输与上位机对接：串口、USB、网络，以及最容易被忽略的帧格式
5.1 从MCU到PC的几种常见通路对比
ADC转换完的数字量存在MCU的寄存器里，要变成数据文件，必须先传到上位机。常见通路有：
- UART串口：最简单，但速度有限。115200bps下，每秒最多约11.5KB，去掉帧头帧尾开销，实际能传10KB左右。适合低速采集（比如每秒几十个采样点）。
- USB虚拟串口：速度比UART高，能到几Mbps，但驱动不稳定时容易丢包。
- 以太网：适合分布式采集或长距离传输，但协议栈复杂。
- 无线（WiFi/蓝牙/LoRa）：适合移动或难以布线的场景，但丢包和时延要额外处理。
我常用的方案是：低速传感器用UART，数据量在10kBps以内，帧号+类型+数据+CRC，简单可靠。高速采集（比如200kHz音频）则用USB高速模式或直接在SD卡上落盘，再用FAT文件系统导出。
5.2 一条数据帧里应该包含什么：带不带时间戳结果完全不同
很多人在传输时只传“当前值”，比如每100ms发一个数字12，上位机接收后存进CSV。但这里有个大坑：如果传输链路有延迟，或者MCU与上位机的计时时钟不完全同步，你记录的数据时间坐标就是错的。尤其是多个传感器并行采集时，时间轴对不齐会导致后续分析完全乱套。
我建议无论多简单的采集，数据帧一定包含三个字段：采样序号、时间戳、数值。时间戳优先用MCU内部的计数器，比如一个1ms递增的32位变量，或直接用RTC。采样序号用来检测丢包，PC端如果发现序号跳变，就知道这段时间数据丢了。
一个典型帧格式可以是这样的：
| 帧头 0xAA 0x55 | 设备ID(1字节) | 采样序号(4字节) | 时间戳(4字节) | 通道数(1字节) | 数据2字节/通道 | CRC16(2字节) |CRC校验不能省。串口传输偶尔会受电磁干扰，哪怕是一个bit翻转，都会让数值变成垃圾。加了CRC后，接收端可以直接丢弃错帧，并在文件里标记，而不是把错误数据当成真实值存下来。
5.3 用串口服务器把RS485传感器数据转成MQTT：我的实战配置经验
项目里遇到过需要把多台分布在车间的传感器数据汇总到上位机的情况，传统的RS485总线加USB转485在几十米内还行，距离远了就得换思路。我最后用了一种组合方案：现场传感器走RS485，通过一个串口服务器（比如TAS-WIFI-265S）把串口数据转成WiFi，再通过MQTT协议发布到局域网服务器。
这个方案里串口服务器的配置是关键。第一次配置时，我直接用了串口服务器的默认串口参数，结果传感数据进了服务器后乱码。原因是现场某款传感器的波特率是9600，而串口服务器默认是115200。后来我把串口服务器的串口波特率、数据位、校验位、停止位全部设成和传感器一致，再测试就正常了。
还有一个坑：MQTT的topic设计。如果每台传感器一个topic，上位机订阅时要订阅多个；如果多台共用topic，则要在payload里带上设备ID。我建议payload用一个JSON格式：
{"device":"sensor_01","ts":1700000000,"channel1":3.2,"channel2":4.5}这样上位机解析灵活，后续接数据库也方便。但注意，JSON解析在资源受限的MCU上开销较大，所以我更推荐MCU端只发紧凑二进制帧，由MQTT网关（串口服务器或树莓派）转换成JSON。这样既保留了MCU端的效率，又方便上位机处理。
6. 数据文件落地：CSV、二进制、HDF5，怎么选才不后悔
6.1 为什么建议先落原始数据，再做处理
我见过不少人在采集端直接做均值滤波、去毛刺，然后只保存处理后的数据。听起来省空间、省分析时间，但一旦处理算法有bug或后续想换一种滤波方式，原始数据没了，就只能重新采集。
正确的流程应该是：原始数据原封不动地落成物理文件，处理过程在离线阶段进行。这样既可以复现实验，也能在不同算法之间横向比较。尤其是科研和工业测试领域，原始数据的完整性往往比处理后的数据更值钱。
我自己的习惯是：采集程序只负责“忠实记录”，最多加一个时间戳和通道编号，不做任何滤波和数学运算。所有滤波、归一化、特征提取都在后处理脚本里做。这样一旦发现某次异常，我可以回到原始文件重新分析，而不是被预处理过程“骗”了。
6.2 CSV看着简单，但浮点格式和换行符会坑死人
CSV是最常见的数据交换格式，Excel能直接打开。但用CSV存采集数据时有几个细节不注意会很难受：
- 浮点精度：用Python写入时默认会把float转成最长表示，比如3.141592653589793，文件很大。如果传感器精度本来只有0.01，就应该在写入时限定格式，比如
f"{value:.4f}"，避免文件膨胀。 - 分隔符：有的初学者用空格分隔，Excel默认按逗号分列，导致每列错位。建议强制使用英文逗号，并在文件名中注明。
- 换行符：Windows和Linux的换行符不同。在Linux上生成的CSV用Excel打开可能会出现一行显示所有内容的情况。建议写文件时用
newline=''参数，让Python统一管理换行。 - 空值和异常：采集过程中偶尔会有传感器断线导致无效值。最好在CSV里用明确的标记，比如
NaN或-9999，而不是留空或写一个0。0在数值上有意义，和“无效”是完全不同的语义。
6.3 一个可复用的数据文件记录函数设计（以Python为例）
如果上位机使用Python做数据接收和落盘，我会用一个简单的工具函数来保证文件格式一致：
import csv import time from pathlib import Path class DataRecorder: def __init__(self, base_dir="data", columns=None): self.base_dir = Path(base_dir) self.base_dir.mkdir(exist_ok=True) self.columns = columns or ["timestamp", "sample_sn", "value"] self.file = None self.writer = None def start(self): fname = time.strftime("rec_%Y%m%d_%H%M%S.csv") self.file = open(self.base_dir / fname, "w", newline="") self.writer = csv.writer(self.file) self.writer.writerow(self.columns) def write(self, ts, sn, values): row = [ts, sn] if isinstance(values, (list, tuple)): row.extend(f"{v:.6f}" for v in values) else: row.append(f"{values:.6f}") self.writer.writerow(row) def close(self): if self.file: self.file.close()核心逻辑很简单：文件名字带上时间戳防止覆盖；用csv模块写行；数值统一格式化成6位小数；write参数可以是单个值或列表，适配多通道。在采集循环里调用recorder.write(time.time(), sample_sn, channel_values)即可。
如果你采集的数据量大、多通道、还带元数据，那CSV不够用，建议直接用HDF5。HDF5支持复杂层次结构、压缩、随机读取，很适合长期存储原始采集数据。但它的学习成本稍高，我建议只有确实需要时才上。
7. 从模拟到文件的完整实测：记录一条现场压力数据的每个细节
7.1 测试环境搭建
为了把前面的理论串起来，我做了一个实际测试：用一个量程0~1MPa的压力变送器，输出为4-20mA，经过一个250Ω精密电阻转成1~5V电压，再送入一个24位ADC采集模块，通过串口把数据发给树莓派，最终在树莓派上写成CSV文件。
供电上我没有直接用开关电源，而是用了一个24V转5V的DCDC后再加LDO稳压到5V给变送器供电。电阻选的是0.1%精度的250Ω电阻，因为它直接决定了电压换算成电流的精度。如果用5%精度的普通电阻，换算误差可能达到5%，数据文件再好看，实际压力却是错的。
7.2 逐环节排查噪声和丢失数据点的过程
采集开始后，我先用万用表测量250Ω电阻两端的电压，稳定在0.857V，对应电流0.000V/250Ω？算一下：0.857V/250Ω=3.428mA，因为变送器量程起点是4mA，说明现在压力略低于量程起点，这是正常的。
接着看上位机接收到的数据，发现数值在0.856~0.858V之间波动，这个波动幅度大约是2mV，相对于4-20mA的满量程电压跨度4V来说，只有0.05%的变化，和数据手册上变送器的精度等级基本吻合，所以可以接受。
但后来我又发现一个间歇性现象：每过几秒会出现一个异常大的数值，比如0.9V。用示波器抓串口波形，发现是树莓派的USB转串口芯片受到了WiFi模块的干扰，偶发数据帧被接收程序错误解析。排查了半小时，最后在程序里加了一个数据范围判断，超出0~5V的帧直接丢弃，同时打印一条警告。经过修正后，再连续采集1小时，丢失和异常点数为0。
这个问题的教训是：最后一个环节的防错也很重要。单纯依赖硬件屏蔽不能完全杜绝干扰，软件层合理的合法性检查可以兜底。但注意，合法性检查不能太宽松，否则会放过真正的异常信号。
7.3 最终拿到数据文件该如何快速验证质量
文件写完之后，不要急着分析业务含义，先做三件事：
第一，看时间间隔是否均匀。用Python读取CSV的timestamp列，计算相邻时间戳的差值，绘制直方图。正常采集时，差值应该是固定值附近的一个小范围，比如100±2ms。如果差值出现明显的双峰或长尾，说明系统的调度有抖动，数据的时间坐标不可靠。
第二，看数值的统计特性。对静态数据，计算均值和标准差。如果你的传感器静态输出标准差超过它标称精度的3倍，那大概率还有噪声问题。信号值本身有上升沿时，检查是否有过冲，过冲幅度超过5%说明滤波不够或采样率不足。
第三，做一次FFT频谱分析。把数据文件读出来，快速傅里叶变换后看有没有明显的异常频峰。如果出现了50Hz或者100Hz的尖峰，大概率是工频干扰滤波没做好；如果出现高频白噪声，可能是采样电路或ADC的时钟问题。这一步能很快定位问题出在模拟段还是数字段。
我最后得到的那份压力数据文件，时间戳间隔标准差是0.8ms，静态标准差为0.4mV，频谱上噪声平坦，说明链路是健康的。后续分析做的压力-时间曲线，不需要再额外清洗，就能直接用。
说到底，“从传感器到数据文件”并没有一个可以一劳永逸的万能方案，每个环节都有取舍，也有对应的验证方法。只要你把链路拆开，逐段检查接口参数和噪声，哪怕用的是最便宜的STM32和传感器，也能写出干净可靠的数据文件。我自己每次换一个新传感器或者一块新板子，都会重新走一遍这条链路，直到拿到一份统计特征合理的文件才继续下一步。这个习惯，救过我不下十次。
