3. 串口通信参数配置与调制解调器匹配

水下调制解调器虽然通过水声信道传输数据，但它与上位机、控制器之间的接口通常仍是标准的异步串口（UART/RS-232/RS-485）。这意味着开发者面对的第一道门槛并不是声学问题，而是串口参数能否与调制解调器"对上"。参数不匹配时，最常见的现象是：能收到零星乱码、完全收不到数据、或者发送看似成功但设备毫无响应。本节围绕波特率、数据位、停止位、校验位、流控这五个参数，说明它们各自约束什么、如何从手册中读出正确取值，以及如何验证配置是否真正匹配。

五个参数各自约束什么

异步串口没有共享时钟线，收发双方依靠约定的波特率对每一位进行采样。因此波特率是首要参数，它决定位宽，一旦偏差超过约 2%~3%，采样点就会漂移到错误位，表现为成片乱码。水下调制解调器常见的串口速率有 9600、19200、38400、57600、115200 bps，部分设备还提供 230400 或 460800。需要注意：这里的串口波特率与设备在水声信道上的"空中速率"是两个完全不同的概念，前者是电缆侧接口速率，后者是声学链路速率，手册中往往分别标注，切勿混用。

数据位通常为 8 位，少数老设备用 7 位；停止位常见 1 位，个别设备用 2 位；校验位可选无校验（None）、奇校验（Odd）、偶校验（Even）。这三者共同构成"帧格式"，一般记作 8-N-1 这样的简写。水下调制解调器多采用 8-N-1，因为其上层协议（如自定义帧、Modbus、NMEA 风格语句）自身已带校验字段，串口层再加校验意义不大。

流控是最容易被忽略的一项。硬件流控使用 RTS/CTS 两根信号线，当调制解调器内部缓冲区将满时拉高 CTS 阻止上位机继续发送；软件流控使用 XON/XOFF 控制字符。水下设备在发射声波期间往往无法及时接收串口数据，若关闭流控又高速灌数据，就会丢字节。因此手册若标注支持 RTS/CTS，应优先启用硬件流控，并确认所用线缆确实连接了这两根线——很多现场故障恰恰是"配置开了流控，但线缆只接了三根线"。

从手册中读出正确参数

拿到一台新调制解调器，不要凭经验猜参数，而应按手册的固定位置逐项确认。通常需要查阅三处：一是"串口接口"或"电气特性"章节，给出默认波特率、帧格式与是否支持流控；二是"命令集"章节，说明进入配置态的方式（例如上电后若干秒内发送特定转义序列，或拨动某个配置引脚）；三是"出厂默认值"表，列出波特率、地址、唤醒方式等。若手册给出的是可配置项，还要确认修改后是否立即生效、是否需要断电重启、是否写入非易失存储。

一个常见的实操细节是：设备出厂波特率可能是 9600，而用户程序按 115200 打开，结果一个字节都收不到。此时应先用 9600 连接，发送查询命令（如 AT 或厂商自定义的 VER?），确认通信正常后再用配置命令把波特率改为目标值，最后把上位机同步改为新速率并重新连接。顺序不能颠倒，否则会"改完就失联"。

# 示例：使用 pyserial 按手册默认值连接并查询
import serial

ser = serial.Serial(
    port="COM5",
    baudrate=9600,        # 手册默认值
    bytesize=serial.EIGHTBITS,
    parity=serial.PARITY_NONE,
    stopbits=serial.STOPBITS_ONE,
    timeout=1.0,
    rtscts=False          # 先关闭，确认线缆后再开
)
ser.write(b"VER?\r\n")
print(ser.readline())     # 期望返回型号与固件版本
ser.close()

上面这段代码的价值在于"先建立最小可信连接"。只有查询命令能稳定返回可读字符串，才说明波特率、数据位、停止位、校验位四项已经对齐；若返回的是乱码，优先怀疑波特率；若能收到完整字符但偶发错位，怀疑停止位或校验位设置；若完全无响应，则检查端口号、线序（TX/RX 是否交叉）与共地。

流控的启用与验证

确认基本帧格式后，再处理流控。若手册声明支持 RTS/CTS，应把上位机与设备两端都设为硬件流控，并确认线缆中 RTS、CTS 两根信号线真实连通。验证方法是：以较高波特率连续发送一段较长数据（例如 4 KB），同时观察是否出现丢字节。若关闭流控时丢字节、开启后不丢，说明流控确实在起作用。反之，如果开启流控后完全发不出数据，多半是 CTS 线未接或被拉死，此时应回到"仅 TX/RX/GND"的三线接法排查。

参数匹配检查表

下表可作为现场配置时的对照清单，字段均取自设备手册与上位机实际设置，逐项打勾后再进入联调。

最后要强调的是，串口参数匹配只是"电缆侧"的正确性，它保证上位机与调制解调器之间的字节流不丢失、不错位，但并不能保证水声链路本身可用。实际排障时应分层判断：先确认串口层能稳定收发查询命令，再确认设备能成功发射与接收声学帧，最后才检查上层协议的地址、唤醒与重传机制。把串口参数这一层做扎实，后续的声学与协议问题才不会互相混淆。