先给结论：连上不等于传上去
客户的原话是这样的：“数采仪面板上显示连接成功，平台那边一条数据都没有，是不是设备坏了？”多数情况下设备没坏，网络也没断。真正的问题出在应用层——报文发出去了，但平台没有认下来，或者认下来之后判为无效直接丢弃。按 HJ212-2025 的要求，TCP 通道建立只说明链路通了，一条数据要真正入库，还得走完报文结构、长度与校验、命令码、设备编码、应答回执这一整条链路，任何一环对不上，现场看到的就是“连接成功、平台无数据”。
所以排查不要从换设备开始，先抓一次包，看看现场机到底发出去了什么。
原因按四层拆开看
协议层（现场最常见）
- 数据段长度字段与实际字符数不一致，尤其是数据段首尾的 && 边界没算对，平台解析直接判格式错误。
- CRC 校验取的是 && 之间的数据段，四位十六进制、前导零不能省略。不少现场中途改过字段，却忘了重新计算校验值。
- 命令码与数据段范围不匹配。实时数据走 2000–2999（如 2011 上传污染物分钟数据），历史补发走 3000–3999（如 3020）。把历史数据用 2011 发出去，平台按分钟数据解析，多出来的字段被丢掉。
- QN 请求编号重复，或时间戳不是 YYYYMMDDhhmmss 格式，平台去重时整包丢弃。
- MN 设备唯一标识与平台登记的不一致，包括分隔符、大小写这类细节。
- 数据标记位填错。维护、停运、超标这些标记一旦填反，平台会把正常数据判为无效。
网络层
- TCP 长连接被中间的防火墙或 NAT 空闲老化清掉，设备侧还认为连着，实际已经是半开连接，表现就是连接正常但没有任何上行。
- 心跳间隔大于平台侧的超时设置（1013 设置超时时间、1014 获取超时时间），平台先一步断开。
- 4G 专网只放通了网关，没有放通平台 IP 和端口。
设备层
- 串口参数与仪表不一致，数采仪采上来的是空值，发出去的也是空数据段。
- 时钟漂移，数据时间落在未来或很早以前，平台按时间窗过滤掉。
- 本地缓存写满后不再入队，新数据根本没往外发。
平台层
- 设备或排口还没审核绑定，数据进来了但落库后不展示。
- 长报文分包上传时，PNUM/PNO 处理异常，平台只收到一部分。
- 平台侧对长度和校验的判定比设备端更严格，比如要求十六进制大写。
排查顺序本身就是知识
先抓包，是为了把问题一刀切成两半：发没发出去。发出去了，问题在报文或平台；发不出去，问题在网络或设备。这个顺序不能倒过来，否则很容易在平台侧空等半天，最后发现现场根本没上线。
第二步看报文本身：数据段长度、CRC、命令码、MN、QN 时间戳，逐项对一遍，比看面板指示灯有用得多。
第三步看应答。平台收到 2011 或 3020 之后会回对应应答码，没有应答回来，就说明没被接收，这时候再去查平台登记信息。
最后才查网络和设备硬件。顺序反过来，往往花了两天时间换模块，问题还在原地。
每一步的现象、判断和动作
- 现象：数采仪面板显示已连接，抓包看不到上行报文。判断：设备侧根本没发。动作：查本地缓存、采集任务是否启动、串口是否有值。
- 现象：抓包有报文，平台无应答。判断：报文被平台判非法。动作：核对数据段长度、CRC、命令码与数据段范围是否匹配。
- 现象：平台有应答但数据不显示。判断：设备或排口未绑定，或数据标记载荷被判无效。动作：查平台设备登记与标记位。
- 现象：偶发中断，重启后恢复。判断：长连接被中间设备老化清理。动作：调整心跳间隔，检查防火墙会话超时。
- 现象：补发历史数据时全部失败。判断：命令码用错，或分包序号不规范。动作：改用 3020 一类历史命令，核对 PNUM/PNO 与总包数。
三个容易误判的坑
- 把面板“连接成功”当成通信正常。这只代表 TCP 握手完成，应用层有没有应答是两回事。
- 只看数采仪上的绿灯，不看平台侧的数据有效率。有些数据其实到了，只是被判无效后统一处理掉了。
- 拿测试工具手工拼一条报文能通，就断定是现场设备问题。手工报文的时间戳和 QN 都是新的，现场机时钟漂移或编号重复时，问题恰好被掩盖。
常见问题
问：数采仪显示已连接、平台一条数据都没有，是不是设备坏了？答：先别换。抓包看有没有上行报文，有报文就查长度、校验和命令码，没报文再查采集和网络。
问：升级到 HJ212-2025 以后，原来能用的报文怎么就不行了？答：新版对报文结构、标记位和超时的要求更明确，字段顺序、长度计算、校验写法都会影响解析，逐项对照比整体重写更快。
问：我这个情况到底要不要传？答：看平台侧的设备登记和数据标记要求，标记位填对了才不会被判无效。
问：平台说校验失败，可我看着报文挺正常的？答：核对十六进制大小写、前导零有没有省、数据段首尾边界有没有算进长度，这三处最容易出错。