前阵子在帮一个移动测量项目集成传感器，拿到了一只 ERDI 的 905nm 激光测距模块。模块很小，引脚就四根：VCC、GND、TX、RX，看起来接上就能读数。结果等我用 USB 转串口连好，打开串口助手，屏幕上滚过的是一串像AA FF 95 03 5A 1B这样的十六进制字节。距离在哪里？哪几个字节算一帧？完全没有头绪。翻手册、对协议、改接线，前后折腾了两天才把数据稳定读出来。
这篇文章就是把整个过程整理出来：上电之前必须先确认哪三件事、硬件接线为什么容易翻车、数据帧怎么逐字节拆解、Python 上位机怎么写，以及实测现场最常见的乱码、丢帧、信号质量下降三个问题。无论你手头是 ERDI 的 905nm 模块，还是其他厂家的 UART 测距模块，这套排查思路和代码框架都能直接平移过去。
1. 上电前的三件事：协议、串口参数和输出模式
1.1 905nm 测距模块的"性格"决定了它怎么说话
905nm 是红外波段的不可见激光，这类模块大多采用脉冲飞行时间法测距：发射一束极窄的红外脉冲，测量反射回波回来的时间差，再换算成距离。因为激光不可见，你眼睛看不出它有没有在工作，唯一的信息来源就是串口输出的字节流。
这类模块的 UART 输出有几个共同特点：TTL 电平、TX 引脚持续输出或者命令应答式输出、数据按固定帧格式封装。ERDI 905nm 模块文档里给的输出格式是十六进制帧，具体结构下一节会详细拆。这里先强调一个非常容易被忽略的事实：激光测距模块的固件版本不同，帧格式可能不一样。哪怕型号完全相同，出厂固件升级后，功能码或者校验算法都可能调整。所以拿到模块的第一件事不是写代码，而是先按文档里的帧格式，把模块实际输出的原始数据逐帧核对一遍。
1.2 波特率猜错了，后面全是乱码
UART 通信的铁律是收发双方波特率必须一致。ERDI 905nm 模块出厂常见波特率是 115200，也有部分版本是 9600。怎么确认？看文档最快；文档丢了就用串口助手挨个试。选一个波特率，观察输出是不是有规律的帧结构。如果屏幕上出现一堆乱码但又隐约有点周期性，多半就是波特率不匹配。
另外还要确认数据位、停止位和校验位。绝大多数模块是 8 位数据、1 位停止位、无校验，也就是常说的 8N1。如果模块手册写的是偶校验或者 2 位停止位，串口助手里的参数就要跟着改，不然即使波特率对了也读不出正确帧。
这里有一个实用的调试技巧：先不接单片机的 RX，只把模块的 TX 接到 USB 转串口的 RX，打开串口助手的十六进制显示看裸数据。如果能看到重复出现的帧头（比如AA FF）和固定的帧长度，波特率基本就确认了。这一步花五分钟，后面能省两小时。
1.3 连续输出和应答模式，操作逻辑完全不同
同样是 UART 测距模块，存在两种完全不同的工作模式。第一种是连续输出模式：上电后自动按固定间隔输出测距结果，比如 20ms 一帧或 100ms 一帧，读取端只需要被动收数据，最简单。第二种是应答模式：平时不输出，收到特定查询命令（比如AA FF 04 01 05）才回一帧，适合电池供电的低功耗场景。
ERDI 905nm 模块默认一般是连续输出，但我见过有些固件支持通过命令在两种模式之间切换。如果上电后串口完全没有数据，别急着怀疑硬件坏了，先查一下模块是不是处在应答模式，或者某个引脚需要拉高/拉低来触发输出。这类"文档里一句话、现场半小时"的情况，在测距模块调试里太常见了。
2. 硬件接线里最容易翻车的三个细节
2.1 电平匹配别想当然
很多 905nm 测距模块的逻辑电平是 3.3V，而不是 5V。如果你手里的 USB 转 TTL 是 5V 逻辑，直接把它的 TX 接到模块 RX，等于让 5V 信号往 3.3V 引脚上灌电流，短时间可能没事，长时间或者环境一热，模块的输入级就可能损坏。
反过来，模块 TX 输出 3.3V 信号，接到 5V 单片机的 RX，多数情况下能识别（不少 5V 器件把 3.3V 判定为高电平），但这不是规范用法。最稳妥的方案是供电按模块要求来，信号线走双向电平转换器，或者用两个电阻组成分压把 5V TX 降到 3.3V。如果只是临时测试，串一个 1k 电阻在模块 RX 前面也能凑合，但别当成长期方案。
ERDI 模块的供电范围要按手册确认。有的版本支持 5V 输入，内部有稳压，有的只能 3.3V。默认按照 3.3V 设计外围电路是最安全的。
2.2 共地是底线，电源要干净
UART 是异步串行通信，收发双方必须有共同的参考地。USB 转串口一般从 USB 口取电，地线和电脑是共地的；但如果你用独立电源给模块供电，这个电源的地必须和 USB 转串口的地接在一起，否则信号参考电位不一致，会出现间歇性乱码甚至完全无法通信。
我调试时遇到过非常典型的案例：模块和一个直流电机驱动共用一个电源，电机一转，串口数据就开始丢帧。量了一下，电机启动瞬间模块供电电压被拉低，导致模块输出异常。后来把模块改成独立稳压供电，重新整理地线走向，问题立刻消失。记住一个原则：测距模块的电源要干净，地和信号回路要短。大功率负载和精密传感器共电源，是嵌入式调试里最常见的隐性故障源。
2.3 裸数据是最好的老师
接线确认无误后，先用串口助手以十六进制模式观察数据，别急着上代码。这一步至少要看三样东西：帧头是否稳定出现、帧长是否固定、帧与帧之间是否有固定间隔。把这三个信息记下来，后面写解析逻辑时就心里有数了。
我习惯把原始数据直接存成文本文件，方便后面用脚本统计分析。如果数据量太大，抓 5 秒就够，几百帧足够分析帧结构了。看到的裸数据越原始越好，任何在串口助手里的"ASC 显示"都可能掩盖字节的真实结构，调试协议阶段永远用十六进制显示。
3. 逐字节拆解数据帧：从十六进制看到距离值
3.1 帧头、数据区、校验：所有模块协议的共同骨架
虽然各家模块的帧格式细节不同，但骨架基本一致：
| 字段 | 常见长度 | 作用 |
|---|---|---|
| 帧头 | 1~2 字节 | 固定值，用于查找帧边界，常见 0xAA 0xFF、0x5A 0x5A |
| 功能码/长度 | 0~2 字节 | 区分测距、温度、版本等不同帧类型 |
| 数据区 | 2~8 字节 | 距离值、信号强度、状态等 |
| 校验和 | 1 字节 | 通常是前面所有字节求和取低 8 位，或异或 |
以 ERDI 905nm 模块文档中给出的典型帧格式为例（具体以你手里模块的文档为准）：
AA FF | 距离低字节 | 距离高字节 | 信号质量 | 校验和距离值是两个字节拼接而成，低字节在前，也就是小端序。比如AA FF 95 03 5A 1B，距离低字节 0x95 = 149，距离高字节 0x03 = 3，拼接起来是 0x0395 = 917。如果单位是 cm，就是 9.17 米。信号质量 0x5A = 90，表示回波强度比较理想。最后一个 0x1B 是校验和，等于0xAA + 0xFF + 0x95 + 0x03 + 0x5A最后取低 8 位，算出来是 27，也就是 0x1B，对得上。
3.2 一次完整的帧解析过程
解析的关键不是"读一帧"，而是在持续不断的字节流里稳定地找到每一帧。过程分四步。
第一步找帧头。从字节流里找到AA FF，这就是一帧的起点。第二步按固定长度读取后续字节，如果帧长 6 字节，就再读 4 字节。第三步做校验，把帧头和数据区所有字节求和，取低 8 位，与最后一个字节比对。第四步等校验通过后再解析数据位，提取距离和信号质量。
这里有一个常见误区：在校验通过之前就急着解析距离，很容易拿到错位的数据。半帧错位很常见，比如串口缓冲区里正好丢掉第一个字节，帧头变成FF 95，程序找不到完整的AA FF，后续字节全乱。这时候不能慌，只要继续从字节流里往下找下一个AA FF，就能重新同步。帧头的作用本来就是"指路标"，丢了就重新找，不要试图从错位中间去猜数据。
3.3 校验和失效时的处理逻辑
如果校验连续失败，先用脚本统计失败率。偶尔失败，比如 1%~2%，属于线路噪声的正常范围，通过重读或者滤波就能解决。如果失败率超过 30%，一定有硬伤，优先怀疑波特率不对、电平不匹配、地线接触不良。
还有一种情况：模块固件把校验和定义成只对数据区计算，不包含帧头。碰到这种情况，AA FF 95 03 5A 1B里的最后一个字节就要用0x95 + 0x03 + 0x5A来算。协议文档里一般会写清楚，没有写的话可以通过已知数据反推：拿几帧输出，分别把帧头加数据、只算数据、做异或，看哪种算法算出来的结果正好等于最后一个字节，就能反推出模块实际使用的校验方式。
4. 代码落地：用 Python 搭一个可用的测距工具
4.1 环境准备和串口枚举
Python 读写串口用 pyserial，一条命令就能装好。接下来是找到串口设备名：Linux 下一般是/dev/ttyUSB0或/dev/ttyACM0，Windows 下是 COM3、COM4 之类。插上 USB 转串口后，可以用python -m serial.tools.list_ports列出所有可用串口，确认名称。
这里有个经验：如果 USB 转串口用的是 CH340 芯片，Linux 下设备名往往是/dev/ttyUSB0；用 FTDI 芯片的可能是 ttyUSB0 或 ttyUSB1。如果系统里插了多个 USB 串口设备，想准确找到目标设备，看/dev/serial/by-id目录下的软链接比猜 ttyUSB 序号可靠得多。
4.2 核心解析逻辑：重同步、校验、提取一个都不能少
下面是可直接运行的完整脚本，实现了前面说的帧解析逻辑。示例帧格式为AA FF | 距离低 | 距离高 | 信号质量 | 校验和：
#!/usr/bin/env python3 import serial import time PORT = '/dev/ttyUSB0' # Windows 下改成 'COM3' BAUD = 115200 def checksum_ok(frame): # frame: 6 字节，校验和 = (AA + FF + dist_lo + dist_hi + quality) & 0xFF return (sum(frame[:-1]) & 0xFF) == frame[-1] def read_distance(ser): while True: head = ser.read(2) if len(head) < 2: return None if head != b'\xAA\xFF': # 不是帧头，丢掉一个字节，继续找 continue body = ser.read(4) if len(body) < 4: return None frame = [head[0], head[1], body[0], body[1], body[2], body[3]] if not checksum_ok(frame): # 校验失败，这一帧不用 return None dist_cm = frame[2] | (frame[3] << 8) quality = frame[4] return dist_cm, quality def main(): ser = serial.Serial(PORT, BAUD, timeout=0.2) try: while True: result = read_distance(ser) if result: dist, quality = result print(f"{time.time():.3f} distance={dist} cm quality={quality}") else: time.sleep(0.01) finally: ser.close() if __name__ == '__main__': main()这段代码有两个设计点值得说明。第一，read(2)判断帧头不满足时，继续读下一轮，实现的是"滑动窗口找帧头"的思路：每轮只处理一个字节，错了就丢掉再试，比一次性读一大块再切分更简洁，也更好理解。第二，校验失败直接返回None，由上层决定是重试还是记日志，这样把"数据有效性判断"和"业务处理"分开，后面扩展缓冲、滤波逻辑时改起来更顺手。
4.3 把数据变成可读、可存、可监控的形态
光在终端打印还不够。实际项目里，我会把这个脚本再包一层，让结果同时输出到三个地方：终端实时显示、CSV 文件记录、通过 UDP 转发给其他程序。CSV 记录格式很简单，时间戳、距离、信号质量，每行一条。这样程序跑一整天，也能用事后统计脚本分析距离的稳定性，比如标准差、最大跳变、弱回波占比。
如果想过监控测距模块的健康状态，信号质量字段是很好的参考。比如室内白墙反射质量高，读数稳定；远处黑色物体质量低，读数跳动大。你完全可以在脚本里加一个阈值判断：当 quality 低于某个值（比如 30）时，在日志里标记一条"弱回波"，而不是把这条数据当作可靠距离用。这个习惯看起来简单，到了现场排障时价值非常大。
5. 实测中绕不开的三个坑：乱码、丢帧、信号差
5.1 乱码：先查波特率，再查电平，最后查地线
乱码在串口调试里太常见了，而且原因不唯一。我总结的排查顺序是"波特率、电平、地线"三步，不要跳着来。
第一步查波特率。把模块 TX 只接串口 RX，用不同波特率扫描。115200 下帧头稳定出现AA FF说明对了；如果变成D5 5F这类完全对不上的值，基本就是波特率不对。第二步查电平。确认模块是 3.3V 还是 5V 逻辑，USB 转串口是否匹配。3.3V 模块配 5V 串口，偶尔能通，但信号摆幅小、抗干扰差，环境复杂一点就乱。第三步查地线。用万用表量模块地和 USB 转串口地之间的电阻，正常应该接近 0 欧；如果显示开路，把地线补上再看。
整个过程可以用下面这张表收拢常见情况：
| 现象 | 可能原因 | 排查动作 |
|---|---|---|
| 每字节都是乱码 | 波特率不匹配 | 切换 9600/115200 等常用值 |
| 帧头出现但数据偶发错位 | 电平不匹配/干扰 | 检查逻辑电平、缩短杜邦线 |
| 完全无数据 | 模式不对/线没接对 | 确认应答模式或 TX/RX 是否接反 |
| 电机启动时丢帧 | 供电被拉低 | 模块独立稳压供电，整理地线 |
5.2 周期性丢帧：刷新率与数据消费速度的竞争
连续输出模式下，模块按固定间隔发帧。如果上位机读得不够快，或者 USB 转串口的接收缓冲区太小，就会丢帧。丢帧的典型特征是：数据整体连续，但每隔 N 帧缺一帧，时间戳上出现一个缺口。
遇到这种情况，先确认串口超时时间别设太长，0.1 到 0.2 秒足够。再检查读取循环里有没有耗时操作，比如打印到一个很慢的终端或者每次循环都刷新界面。还有一种隐蔽原因：部分 USB 转串口芯片的接收缓冲区只有几十字节，如果数据率高于读取速度，缓冲区溢出后最老的帧会被系统丢弃。解决办法是提高读取频率，或者换用缓冲更大的 USB 串口方案。
5.3 信号质量数据是测距的"第二通道"
很多人在解析时只盯着距离值，忽略信号质量字段。这个字段的价值在于：它告诉你当前这个距离读数有多可信。实测里我遇到过读数为 0、突然跳到最大值、连续几帧剧烈跳动的情况，回头看日志，几乎全部伴随信号质量大幅下降。
处理策略不复杂，距离值连同质量一起输出，质量低于阈值的帧标记为不可靠，由上层逻辑决定是重新测一次还是直接丢弃。在自动化测量场景里，这一点尤其重要。你宁愿报告里写"不确定"，也不能让一个错的读数混进统计结果，后面排查问题时会省非常多的时间。
6. 测距模块的现场局限与滤波思路
6.1 反射率、视角和阳光：三个会影响读数的外部因素
905nm 激光测距模块不是全能的。它依靠目标反射回波工作，所以目标表面的反射率直接决定测距上限和稳定性。白色墙面、水泥地这类漫反射表面效果好；黑色橡胶、深色织物会大量吸收红外光，最大量程会明显缩短。倾斜的表面会把回波反射到其他方向，读数容易产生跳变。
晴天户外使用还要考虑环境光干扰。905nm 波段虽然在红外区，但太阳光谱里同样包含这个波段，强烈的背景光会压缩回波的动态范围。这时候把模块的测距模式调成多次测量取平均，或者调整增益设置，算是比较实际的应对办法。还有注意别拿模块对着玻璃、镜面这类镜面反射物体测距，反射光偏离接收口径，读数会直接失效。
6.2 统计滤波：中值、滑动平均与置信度门控
原始距离数据总是带噪声的。针对测距模块，我推荐三种滤波手段，按需组合使用。
第一种是中值滤波。连续取 5 个有效读数，排序后取中间值，可以干掉单点跳变。第二种是滑动平均，对连续读数求平均，适合目标缓慢移动的场景，但也会让响应变迟钝。第三种是置信度门控，结合信号质量字段，质量低于阈值的读数直接不进滤波器，避免把错误数据当成真值平均进去。
实际使用中，我的顺序是：先做置信度门控，再做中值滤波，最后根据应用决定要不要滑动平均。这样既能抑制随机噪声，又不会因为一两个坏点把测量结果带偏。如果你只是做距离报警之类简单的应用，中值滤波就够了，没必要上太复杂的算法。
6.3 移植到单片机固件的最后几点提醒
如果你的最终目标不是 PC 上位机，而是把模块接进 STM32、ESP32 这类单片机，解析逻辑要改成事件驱动。我会用一个环形缓冲区接收串口中断数据，然后在主循环里跑一个状态机：空闲态找帧头，找到后按固定长度收数据，收满后做校验，校验通过就置一个标志位，让主逻辑取走距离值。
有个容易忽略的细节：不要在串口中断里做耗时的校验和解析。中断只负责把字节搬进缓冲区，解析交给主循环，否则中断阻塞时间太长，会影响单片机其他任务，比如定时器或者 PWM 输出。另外一个提醒是，距离单位一定要在文档里确认，不要靠猜。同一个数值，可能是厘米、毫米或者 0.1 米，单位弄错了，整个系统都会跟着错。
就我自己的使用体验来说，ERDI 905nm 模块本身并不难驱动，真正的难点在于"先理解协议，再动手接线"这个顺序。很多人，包括我自己，习惯先插线上电，再对着乱码猜协议，这是最大的时间陷阱。如果你正卡在某一步，建议退回原点：用串口助手看裸数据，抓几帧数据反推帧结构和校验算法，把协议彻底确认了再写代码，后面会顺利很多。另外建议从第一天就把信号质量字段纳入数据记录，它在排查现场问题时，省下的时间远超你记录它花掉的时间。
