先说结论：连上不等于传上去
“数据采集传输仪显示连接成功，灯也常亮，可平台上一条数据都没有。”这是华东一位运维工程师上周发来的原话，类似描述一个月能听到好几回。先把答案给出来：连接成功只代表 TCP 握手通了，不代表你发出去的报文被平台收下了。绝大多数这类上传异常，根子在现场端组包和平台侧约定对不上——MN 编号、口令、上报的 CN 号，任意一项错了，平台照样维持连接，但会把数据静默丢掉。
四层拆开看，问题会自己浮出来
协议层是最容易出错的一层。HJ 212 的报文结构是固定的：双井号开头、4 位十进制长度、数据段、4 位 CRC 校验、双与号结尾。长度字段是从数据段第一个字符算到最后一个字符的字节数，算错一位，多数平台直接判为非法包丢弃。CRC16 的计算范围是从双井号后第一位开始，到数据段末尾为止，不含结尾的双与号，这一段错了平台同样不认。再往下是字段本身：MN 是设备唯一编号，必须与平台登记的一字不差；PW 口令区分大小写；CN 号决定这条数据被归到哪张表——实时数据用 2011，分钟数据用 2051，小时数据用 2061，日数据用 2031；上位机反控取数走 1012、1013、1014 这几个命令码，3019、3020 这类现场端状态码如果平台没登记，也会被当作未知数据丢弃。时间戳是 14 位，格式为年月日时分秒，少写成 12 位就整包作废。
- 网络层看三件事：IP 和端口是不是指向正式环境（不少现场还留着厂家测试地址）、链路上有没有防火墙或 NAT 设备做空闲超时（常见三到五分钟静默断链）、设备有没有按周期发 9021 心跳保活。
- 设备层看采集侧：串口波特率和数据位校验位是否与仪表一致、协议类型选的是 Modbus RTU 还是自定义、寄存器地址有没有偏一位、量程系数有没有配对。
- 平台层看登记信息：平台是否只开通了部分 CN 号、同一 MN 是否被两条链路抢占（后连的会把先连的踢掉）、数据入库是否有延迟。
为什么先查报文，后查网线
排查顺序本身就是知识。很多人一上来就 ping、就换卡、就重启，折腾半天，问题其实在一串字符上。合理的顺序是：先看设备发出的原始报文，再看平台有没有应答，再看链路是否稳定，最后才回到采集侧。理由很实在——报文是成本最低的证据，设备本地日志或串口抓一段就能看到；而从网络往下查，变量太多，改一处测一次，很容易把真正的原因盖住。
每一步看什么、怎么动手
- 设备日志里有完整报文，平台却查不到数据：判断为组包或约定不一致，动作是把原始报文截出来，逐字核对长度字段、CRC 和数据段字段顺序。
- 平台返回了应答码但数据没入库：判断为平台收到后拒收，动作是核对 MN 与 PW，确认该 CN 号已在平台开通。
- 平台毫无应答，连接状态却显示成功：判断为链路或目标地址问题，动作是确认 IP 端口指向正式环境，用抓包看是否有 SYN 无 ACK。
- 连上三五分钟后自动掉线再重连：判断为中间设备空闲超时，动作是开启 9021 心跳，间隔按平台要求设置，一般不超过平台规定的最长空闲时间。
- 串口助手能收到数，报文里数据段却是空的：判断为采集层问题，动作是回到寄存器地址、数据类型和量程系数上逐项核对。
三个最容易踩的坑
- 把“连接成功”当成“链路正常”。TCP 通只说明端口开着，报文对不对、平台收不收，是两回事。
- 用串口助手收到乱码就断定仪表没问题。串口助手不校验 CRC，也不管时间戳格式，它显示正常不代表组包合法。
- 改完 MN 或口令没有重连。部分设备改参数后旧会话仍在用旧值，必须断开重连或重启才生效，于是“改了还是不行”。
几个现场常问的问题
- “我这边设备显示在线，平台就是没数，是不是平台的问题？”先别急着找平台。把设备发出的原始报文抓一段，看长度和 CRC 对不对，这一步能排掉大半嫌疑。
- “心跳到底设多少秒合适？”看平台侧的要求，通常要短于链路空闲超时时间。设得比超时还长，等于没设。
- “MN 号和平台上填的不一样，会是什么表现？”多数平台不报错，连接维持，数据进不来，表现和网络不通几乎一样，所以这一项要优先核对。
- “换了新的数据采集传输仪，参数照抄旧的还是没数，为什么？”旧设备能跑通说明参数大体没错，重点查新设备的协议版本、字段顺序和默认上报周期是否与旧机一致。