先说结论：多数是传上去了，平台没认
“数采仪界面上连接状态是绿的，国发平台上就是查不到数。”这是过去大半年我们接到最多的一类电话，八成出在刚做完国发5.0联网的现场：设备是新装的，参数照着平台下发的表格填，网也通，唯独平台页面上没有曲线，或者只有零星几个点。
结论先给：这类故障里，真正“没发出去”的比例不高，多数是报文发出去了、TCP 也握手了，但平台在应用层把包丢掉，或者收下了却判成无效数据。在 HJ 212 这套体系里，连接成功只说明端口通、握手完成；报文能不能被接收、能不能被解析、能不能入库，是另外三件事。所以别急着“再连一次”，先想办法证明平台到底收没收到。
一、按四层拆：问题一般卡在哪
协议层：报文结构、CRC、时间戳
- 封包结构。HJ 212 的包是 ## 加 4 位数据段长度，再接数据段（QN、ST、CN、PW、MN、Flag、CP 等字段），最后是 4 位 CRC 和回车换行。长度字段和实际字符数差一位，平台就当成不完整的包。
- CRC 计算。多项式 0xA001，结果 4 位十六进制、低字节在前。现场用串口助手自测通过、上平台却被丢，有不少是高低字节写反。
- QN 时间戳。17 位，精确到毫秒。数采仪时钟跑快两三个小时，数据就落进“未来时段”，页面上翻当前时间当然看不到。
- Flag 标志位。4 位十六进制，最低位表示是否拆包。多因子长报文需要拆包时置 1，平台会等后续包合并；只发一包却又置了 1，平台就一直等，不入库。
- ST / MN / PW。ST 是系统编码，MN 是设备唯一编码，都由平台分配，PW 要和平台登记的一致。抄错一位，平台按未知设备处理，连接照样挂着，数据不落。
网络层：连得上，不等于回得来
这是最容易被“连接成功”三个字掩盖的一层。数采仪主动外连平台端口，中间的防火墙、4G 私网、APN 专网通常只放行这一个方向的连接，平台下发 3011 提取实时数据、3012 提取历史数据 这类命令时，回程包过不来，或者被中间设备当成畸形包丢弃。表现出来就是心跳（2021/2022）正常、连接不掉线，但数据传不动。
设备层：数采仪自己
- 时钟。没配 NTP，或者时区被设成 UTC，QN 与平台差 8 小时。这是查得最多、改得最快的一个点。
- 通道开关。多通道设备里，某个因子的“上传”没勾选，本地有数、平台没有。
- 采集侧没数。仪器通讯口没通、量程设错，数采仪存的是 0 或恒定值。这种情况平台上有数据，只是看着像没传。
- 补传队列。断网期间积压的报文没发完，缓冲区满，新数据进不来。
平台层：到了但被判无效
平台不只看“有没有包”。设备运行状态、报警标记、数据标记位缺失，都可能让一条数据进“异常数据”而不是“有效数据”。另外，上传间隔与平台侧期望不一致（9012 设实时数据间隔、9013 设历史数据间隔），数据会按错误的归集口径落到别的时段。还有一种：排口或监测点在平台侧没关联到这台设备，包收到了也不显示。
二、为什么先查平台，最后才动参数
顺序本身就是经验。我们现场的固定顺序是：平台接收记录 → 数采仪发出的原始报文 → 网络抓包 → 参数核对。
理由有两个。第一，参数是唯一改了之后不容易回滚的东西，现场的 ST、MN、因子编码一改动，平台侧的历史对应关系可能要重新梳理，越改越乱。第二，平台侧有没有收到包，能一刀把故障切成两半：平台压根没见到这个 MN 的包，往网络和设备查；包收到了但被标异常，基本就是字段和参数的问题，网络设备不用碰。
顺序反过来会怎样？先改参数、再抓包，你拿到的已经是被改过的报文，没有对照，判断不了原始状态是不是就有问题。
三、现象、判断、动作对照
| 现象 | 判断 | 动作 |
|---|---|---|
| 平台侧查不到该 MN 的任何报文 | 包没出设备或没出网络 | 开数采仪调试日志，看有没有 1011/1013 发包记录 |
| 有发包记录，平台无记录 | CRC 或包结构问题，被平台静默丢弃 | 导出原始报文，逐字节核对长度字段与 CRC 高低字节 |
| 平台收到但落库时间偏移 | QN 时间戳与平台时间不一致 | 核对设备时钟与时区，与平台服务器时间对齐 |
| 只有部分因子有数 | 因子编码或通道开关问题 | 核对 CP 段因子编码与通道上传勾选 |
| 连接反复断开重连 | 心跳与超时参数不匹配 | 核对 9011 的超时时间与重发次数设置 |
| 数据进了异常列表 | 标记位或设备状态字段缺失 | 补齐 Flag 与设备状态、报警标记 |
四、三个容易误判的坑
坑一：把“TCP 连接成功”当成“上传成功”
界面上的绿灯只代表 socket 建起来了，代表不了应用层。我们在现场见过连接稳定挂了三天、平台一条数据没有的设备，事后发现是 CRC 一直算错。
坑二：一看没数据就先改 MN 和 ST
平台侧其实已经在“异常数据”或者“未关联设备”里收到了包，只是没进正常列表。这时候改编码，等于把原本能对上的记录也拆散了，后面更难查。
坑三：拿自制调试工具测通了，就认定设备没问题
自制工具往往只按自己的实现算 CRC、只发实时数据，而现场跑的是历史数据补传，两种命令的 CP 段结构并不完全一样。工具通过、平台不收，这种情况真不少。
五、几个客户常问的问题
问：数采仪显示连接成功，平台就是没数据，是不是平台那边坏了？
先别怀疑平台。按上面的顺序，先在平台侧查有没有这个 MN 的收包记录。没有记录，问题在现场；有记录但不显示，问题在字段和关联关系。
问：我把 MN 直接填成设备序列号了，行不行？
不行。MN 是平台分配的设备唯一编码，和 ST 是配套的，自己填的序列号平台不认，连接能建起来，数据不入库。
问：补传一开，平台数据一下子多出一大片，会不会有影响？
补传本身是正常机制，关键是时间戳要准。QN 不对的补传数据会落到错误时段，反而把正常的均值算乱。开补传之前，先把时钟对齐。
问：平台下发的 3011 提取命令我这边收不到，影响上传吗？
影响。收不到提取命令，说明回程链路不通，平台拿不到实时值，只能靠设备主动上报的历史数据，时效性会差很多。
国发5.0联网说到底不是“通不通”的问题，而是“对不对”的问题。连接是门槛，报文才是内容。把平台日志和原始报文这两样东西拿到手，多数故障半小时内能定位到具体字段。