企业官网建设流程全解析

简介：面向RDI垂直式与水平式ADCP设备用户、技术维护团队及河流海洋水文科研人员的一份命令配置与数据输出结构文档，聚焦设备首次投用或重新配置时的参数理解与数据解析难题。内容围绕CR、CF、BA、BC、BP、EX、EB等固定命令逐条解析其物理含义与操作细节，并说明向导命令BX、WF、WN、WS、WV、TP在WinRiver II中的联动设置，重点讲透EX坐标转换标志位、ASCII输出文件结构、导航数据格式与流量报告生成流程，兼顾淡水盐度、盲区、深度单元划分等实操细节。资源包为单个docx文档，约682KB，体量轻便却覆盖命令手册与数据结构规范两类内容。已有506人学习下载，适合作为设备调试、故障参数查询与长期监测数据管理的案头参考，也可帮助读者建立从命令配置到后处理分析的完整认知链条。

1. 命令解释器：为什么 ADCP 到手第一件事是发一条 CR1

刚接上 ADCP 就急着采数据，是很多人的第一反应，也是我见过翻车最快的一种做法。设备内部状态可能还留着上一次作业的残留配置——上一次的盐度、上一次的盲区、上一次的坐标转换标志，全都还在。你看到的第一组流速剖面，很可能是一份“别人的配置”产出的数据。RDI 这套命令体系的核心设计动机就在这：先让设备回到一个已知状态，再逐条覆盖你需要改的参数。

CR1就是那条“复位到出厂默认”的命令，通常是整串配置里第一条发出去的。它把设备拉回“已知”状态，之后每一条CF、BA、EX、WS才有意义——因为你确切知道自己在上一次状态的基础上改了什么。命令解释器的工作方式像一台只认短码的状态机：两三个字母的指令加若干位数字，逐字段写入设备内部的配置寄存器，改完立刻影响下一次发射脉冲的行为。搞懂这套命令的字段语义和 ASCII 输出的列对应关系，本质上就是搞懂了“设备怎么想”和“文件怎么写”之间的映射——后面所有流量计算、后处理、故障排查，都建立在这层映射之上。

2. 命令状态机：一条 CF 为什么能同时锁定五件事

2.1 从 CR1 到 CF11110：出厂态与运行态的分层

很多人会问，既然CR1已经把设备拉回出厂默认，为什么紧接着还要发CF11110？因为这两条命令管的不是同一层东西。CR1针对的是配置项本身，CF针对的是运行行为：是否自动集成循环、是否自动发射脉冲、输出二进制数据还是别的格式、串口输出是否启用、内部数据记录是否关闭。

CF11110这五个数字位，从左到右分别对应：自动集成循环开、自动发射循环开、二进制输出开、串行输出开、数据记录关。它是一条“把设备变成一台可被上位机实时驱动的传感器”的命令——一旦这几位没配对，你会遇到“命令都发成功了，但一个字节都收不到”的经典现象。血泪经验是：CF的位序在不同型号手册里表述略有差异，但行为是一致的，就是决定数据往哪儿走、什么时候走。

这层设计其实很讲究。配置项（盐度、盲区、单元大小）描述的是“物理世界怎么测”，运行行为描述的是“测完怎么交给你”。分成两层的好处是：你可以复用同一套物理配置，切换不同的输出/记录策略，而不用重发一整串命令。

2.2 阈值类命令：BA、BC、BE、WA、WE 的判定链路

底部检测和水跟踪各自有一套阈值判定，它们串成一条判定链，任何一环设错，结果就是“底部跟踪丢失”或“速度全是坏值”。

这张表最值得琢磨的是BA和BC的区别。BA是“要不要相信这里有个底”，BC是“信了这个底之后，它的速度值可不可信”——前者决定底跟踪是否存在，后者决定存在之后那个数能不能用。把两者混为一谈，就会出现“底跟踪明明有回波但速度一直是 −32768”的困惑，而 −32768 正是速度坏值的填充码。

WA50也容易被忽视。它处理的是鱼群、悬浮物这类“强回波但不是底”的假目标。阈值给低了，鱼群被识别成河底，水深瞬间跳变；给高了，真正的软泥底反而被滤掉。这就是典型的需要按水体条件现场调的参数，没有万能值。

2.3 坐标转换 EX：五位标志位如何决定数据在哪个坐标系里

EX是整套命令里最值得单独拆的一条，因为它决定了你拿到的速度分量到底是什么方向上的投影。它的五位标志位层层叠加，每一位都改变一次数据处理路径：

EX 1 1 1 1 1 │ │ │ │ └─ 第5位：允许 bin mapping（深度单元映射） │ │ │ └─── 第4位：允许三波束解算（某波束低于 WC 相关阈值时） │ │ └───── 第3位：在转换中使用倾斜（Pitch/Roll） │ └─────── 第2位：坐标系选择（与第1位组合） └───────── 第1位：坐标系选择（与第2位组合）

前两位组合出四种坐标系，这是理解EX的关键：

• EX00xxx：径向波束坐标，即波束 1/2/3/4 各自的原始径向速度，航向、纵摇、横摇一概不施加。排查硬件问题时看这个。
• EX01xxx：仪器坐标，X/Y/Z 相对 ADCP 本体，姿态不施加。
• EX10xxx：船舶坐标，X/Y/Z 相对船体，航向不施加；若第 3 位为 1，则纵摇/横摇施加。
• EX11xxx：地球坐标，东/北/垂直，航向施加；若第 3 位为 1，纵摇/横摇施加。

这里有个常被忽略的细节：文档明确写了EX10xxx是给“EA 命令用户但不是 EB 命令用户”的，EX11xxx则是 EA 和 EB 都能用。换句话说，坐标系的选取和航向偏差校正（EB）之间存在耦合关系，EB校正的是 ADCP 航向值与航向参考之间的电/磁偏差，只有到了地球坐标这一层，航向才真正参与运算，EB的修正才有落点。选了仪器坐标却去调EB，等于白调。

第 4 位允许三波束解算，是个容错设计：四波束中只要有一束的相关性掉到WC阈值以下，就用剩下三束合成速度矢量。代价是误差模型变化，数据质量标记也会跟着变。第 5 位允许 bin mapping，则是把深度单元边界对齐到实际水深，避免单元跨越河底。

2.4 剖面几何：WS、WN、WF、TP 与 &R 怎么拼出一次测量的空间骨架

剖面几何由几条命令共同决定，它们之间的关系不是独立的，而是互相约束：

• WS50设定深度单元厚度 0.5 米；
• WN50设定深度单元数量 50 个；
• WF50设定发射后盲区，把第一个单元推离换能器 50 厘米；
• TP000020设定脉冲间隔 0.20 秒；
• &R20设定底跟踪发射脉冲长度，以百分比表示。

&R最容易被误读。它不是“深度”，而是“相对于水深的百分比”。&R20在 100 米水深下意味着底跟踪脉冲长 20 米；改成&R30就是 30 米。脉冲越长，底跟踪的信噪比越好但垂直分辨率越差——这是深水和浅水要用不同&R的根本原因。

WF的作用也常被低估。发射脉冲结束后，同一个换能器要立刻转为接收，必须等一段短时间让声能散开，这段延迟就是盲区。WF50把第一个单元推到 50 厘米之外，避开这段“自己吵自己”的区间。WS、WN、WF三条命令合起来，才决定第一个有效单元的中心深度落在哪里。

提示：TP的时间格式是TPmmsscc，即分、秒、百分之一秒。TP000020是 0 分 0.20 秒，不是 20 秒。这个字段看错导致采样率差 100 倍的案例不少。

ES0把盐度设为 0（淡水），影响的是声速修正，进而影响深度换算。在咸淡水交界处作业，这条命令设错，所有深度值会系统性偏移，而偏移量随盐度变化，事后很难补救。

3. 二进制数据流：PD0 文件里的字节布局为什么必须先懂再解析

3.1 固定前导 + 变长前导 + 数据类型 ID 的三段式

*.PD0原始文件保留了从 ADCP 输入的全部原始数据，它的组织方式是“头部声明 + 分块数据”，每一块由数据类型 ID 标识：

这张表的用法是：先读头部拿到数据类型数量和 ID 列表，再用固定前导里的偏移信息，逐个定位每个数据块的起始字节。不要硬编码偏移量——数据块的数量和顺序会随配置变化，硬编码的解析器在换一套配置后必然错位，而且错位之后读出来的数看起来“像那么回事”，排查起来极其痛苦。

3.2 导航子类型 ID：0x2022、0x2100、0x2101、0x2102、0x2104

NMEA 数据被集成进 PD0 流时，用固定的 ID 标记子类型：

0x2022 -> 通用 NMEA 结构 0x2100 -> $xxDBT（测深仪） 0x2101 -> $xxGGA（GPS 定位） 0x2102 -> $xxVTG（对地航向航速） 0x2104 -> $xxHDT（航向）

这里有个真实的坑：通用 NMEA 结构（0x2022）的内容是可变长的，同一个 ID 可以出现多次，格式也可能各不相同。文档里明确说明了 BBConv 这类解码工具不能用于通用 NMEA 结构数据，因为多实例和格式变体超出了它的兼容范围。如果你的解析器只按固定长度切块，遇到 0x2022 就会全盘错位。稳妥做法是先解析 0x2022 前面的长度字段，跳过未知内容，再继续找下一个 ID。

3.3 一段最小可用的解析骨架

import struct def parse_pd0(buf: bytes, offset: int = 0): # 头部：6 字节 + 2*数据类型数 header = buf[offset:offset + 6] num_types = struct.unpack_from('<H', header, 2)[0] # 数据类型数量 ids = struct.unpack_from(f'<{num_types}H', buf, offset + 6) pos = offset + 6 + 2 * num_types # 固定前导与变长前导总是存在，先跨过去 pos += 59 + 65 blocks = {} for type_id in ids: if type_id in (0x0100, 0x0101): # 速度 / 相关幅度类 nbytes = 2 + 8 * 50 # 按 WN=50 估算，实际应读前导 elif type_id == 0x0600: # 底部跟踪 nbytes = 85 elif type_id == 0x2022: # 通用 NMEA，变长 nbytes = struct.unpack_from('<H', buf, pos)[0] # 内部长度字段 else: nbytes = 0 # 未知类型，跳过 blocks[type_id] = buf[pos:pos + nbytes] pos += nbytes return blocks

这段骨架能跑通的关键不在字节运算，而在三处判断：第一，数据类型数量必须从头部动态读，不能写死；第二，速度类数据块的字节数依赖深度单元数WN，示例里按 50 估算只是为了说明结构，实际应当从变长前导里取；第三，遇到0x2022必须先读它自己的长度字段再跳过，否则后面所有块的位置全错。参数offset留出来的意义是支持在一个大文件里连续解析多个 ensemble——PD0 文件就是一条连续的数据记录流，集合之间不会做分割，文件大小会自动增长以容纳至少一个完整集合。

4. ASCII 输出：三行头、七列前导与 bin 级数据的生成逻辑

4.1 经典 ASCII 输出的头部约定

ASCII 输出是给后处理、表格软件和数据库用的。WinRiver II 每打开一个新的 ASCII 输出文件，会先写三行：

• 第 1 行：附注 1，可以在横断面上右键“添加记录”录入；
• 第 2 行：附注 2，同上；
• 第 3 行：配置摘要，包含WS（单元厚度，cm）、WF（盲区，cm）、ADCP 入水深（cm）、WN（单元数）、WP（每集合脉冲数）、集合时间（百分之一秒）。

这第三行是后处理时唯一能确认“这份文件当时是什么配置”的线索。文件里不记录EX坐标标志、不记录ES盐度、不记录&R，只看 ASCII 文件本身无法反推这些。所以配置日志必须单独留存，这属于血泪经验级别的建议。

4.2 每集合数据的列结构：从时间戳到流量

一个集合（ensemble）写进 ASCII 文件时，前六行是引导、缩放、导航和排流信息，从第七行开始按 bin 深度逐列写 bin 级数据。整个列序大致可以分成几段：

1. 时间戳：年、月、日、时、分、秒、百分之一秒；
2. 集合编号、该段中的集合数；
3. 姿态：纵摇、横摇平均值，罗经修正后的平均航向（含一周误差修正 + 航向偏移量 + 磁变）；
4. 平均温度；
5. 速度分量：东向、北向、垂直；
6. 底跟踪速度、GPS 速度、底轨参考标志；
7. 深度读数：由测深仪校正的海底深度、GGA 高度、GGA 高度差、HDOP×10 + 卫星数/100、四波束各自的深度读数；
8. 距离与时间：本集合航程、向北/向东累计距离、总运行时间、补偿距离；
9. 导航：纬度、经度、GGA/VTG 东向与北向速度、行驶距离；
10. 流量值：剖面中部、顶部、底部估算、两端岸流量估算、对应距离与深度；
11. bin 级数据：bin 数、测量单位、速度参考、强度单位与比例因子、吸声系数，然后是每个 bin 的深度、速度表、速度方向、东/北/垂直分量、误差速度、四波束强度、良好百分比。

有一个设计细节值得单独说：子段和平均集合数据不会反映在 ASCII 输出文件里。文件里给的是 WinRiver II 作为工作集使用的全部选定数据，包括所有WN个 bin 的数据组，哪怕它们在显示器里被标为“坏”。这意味着文件比屏幕上看到的多——后处理时如果直接对整列求平均，会把坏值一起算进去。

注意：坏值有固定的填充码。速度是 −32768，流量是 2147483647，经纬度是 30000。这些数不参与运算，但会被“正常”写进文件。不做过滤直接统计，结果会离谱到无法解释。另外，缺失数据（ADCP 根本没发上来的）不会被填短划线，而是直接缺列。

4.3 通用 ASCII 输出：把列序交给你自己定

经典格式是固定的，通用格式是可配置的：先加载测量文件，回放或重处理目标横断面，在输出配置里逐项挑选要导出的字段并按顺序排好，插入分隔符，最后可以把这套选择存成模板复用到其他测量。

这个机制的价值在于解耦：同一份测量文件，做流量分析导一套列，做泥沙分析导另一套列，不用重测。代价是模板与测量条件绑定——如果模板里选了某个字段，而当前测量的配置没有产生该字段，输出会缺列，后面的列全部左移。用模板前先核对配置，这是踩过坑之后的习惯。

5. 避坑与排查：五条来自现场的参数事故记录

5.1 底跟踪有回波但速度恒为 −32768

现象：底部跟踪判定为“有底”，水深读数也合理，但输出速度列全是 −32768。原因：BC相关幅度阈值设得过高，底跟踪位置被接受，但速度数据因相关性不足被标为坏值。解决：把BC从 220 往下调，逐档观察速度列是否出现真实数值，同时用BE限制误差速度上限，防止放宽阈值后引入野值。

5.2 浅水区第一个 bin 全是无效数据

现象：在河道近岸浅水区，最靠前的几个 bin 一直是空或坏值。原因：WF盲区设置与WS单元尺寸不匹配，第一个单元中心落在盲区以内，或者落在脉冲长度 + 滞后决定的不可用区间。解决：按“ADCP 入水深 + 盲区 +（单元尺寸 + 脉冲长度 + 滞后）/2”核算第一个单元中心深度，调小WF或加大WS，再重新采一段验证。

5.3 近底一层 bin 数据始终不可信

现象：最深的那个 bin 速度总是异常，且换多个断面都这样。原因：旁瓣效应。波束指向垂直方向约 20 度，旁瓣从底部反射的能量会污染近底水体的回波，受影响厚度约为传感器到底部距离的 6%，再加上脉冲前后沿分别从底和面反射造成的污染，实际就是 6% 旁瓣层再加一个单元的数据不可用。解决：不是调参数能解决的，接受这一层的缺失，交由后处理的底部外推算法（幂律法或不滑动法）估算，别硬用。

5.4 深度值整体偏移且随位置变化

现象：不同断面之间深度读数存在系统性差异，且差异随水体盐度变化。原因：ES盐度设置与实际水体不符，声速修正错误，深度换算整体偏移。解决：在咸淡水交替区域按实际盐度分段设置ES，并在配置日志中记录每个断面用的盐度值，避免后处理时无法追溯。

5.5 换了套配置后解析器读出的数“看着像真的”

现象：PD0 解析程序在一套配置下工作正常，换配置后速度值仍在合理范围内，但与实际流速明显不符。原因：解析器硬编码了数据块偏移和每块字节数，没有从头部动态读取数据类型数量和WN，导致块边界错位，读到了相邻块的字节。解决：所有长度都从前导字段动态取，0x2022这类变长块先读内部长度再跳过，并在解析后做一次量纲和范围自检——速度绝对值超过合理上限就报警。

6. 流量估算的取舍：为什么外推方法没有标准答案

流量计算里最值得反复推敲的设计，是“未测量区域怎么办”。ADCP 只能测到换能器以下、旁瓣层以上的那一段水体，顶层、底层、两岸边的流量都得靠估算。WinRiver II 给出的不是一条万能公式，而是一组可以选的方法，选哪个直接改变结果。

顶部外推有三种：常数法、幂函数法、3 点外延。常数法把第一个好 bin 的叉积值直接平推到水面，实现最简单，但它违背了明渠流速垂直分布的基本水力描述——真实流速在水面附近并不是常数，尤其在水面风速大或者存在风生流的情况下。3 点外延用顶部三个 bin 拟合斜率再外推到水面，bin 数不足六个时退化为常数值。幂函数法则基于流动阻力的幂律理论：

u / u* = 9.5 * (z / z0)^b

其中 z 是到河床的距离，u* 是剪切速度，z0 是底部粗糙度高度，b 是指数，常用 1/6，对应曼宁公式。工程实现上的关键一步是：把幂律里的 u 换成叉积 X，然后用“幂律反导数在有效深度范围内的积分”等于“ADCP 实测数据积分”这个约束，反解出系数 a''。这一步是整个流量算法的核心——它保证了外推曲线必然穿过实测数据，而不是凭空外挂一条曲线。

底部外推只有两条路：幂函数法和不滑动法。前者假设整个剖面的幂律拟合可信；后者明确表示“我不认为全剖面幂律拟合准确”，改用底部 20% 的 bin 拟合一条强制在河床处归零的幂曲线，若连 20% 的 bin 都没有，就用最后一个好 bin 强制过点归零。这个选项的存在本身就说明了一件事：算法的作者清楚幂律在某些水流条件下不成立，所以留了一个“我不信全剖面”的开关。

两岸流量的估算用比率插值，公式是C × Vm × L × dm，三角形岸边系数 0.3535，矩形岸边系数 0.91。岸距这个输入很关键——采集模式开始和结束横断面时软件会提示输入，重处理时也能在边缘估计页面里改。我的习惯是现场就输，不留到后处理再补：现场知道船离岸多远，事后只能靠记忆猜。

还有一层容易被忽略的取舍：流量计算不依赖罗经航向，也不依赖船只位置。它依赖的是 ADCP 相对水的流速剖面、相对底的船速、以及到河底的距离这三样。这个设计的巧妙之处在于，横断面可以是任意曲线，只要起点和终点各自靠近一侧河岸，积分结果就与船的路径无关。代价是底部跟踪必须有效——船速要从底跟踪来，底跟踪失效时才退而用 GPS 加测深仪。这解释了为什么第 2 章里那些BA/BC/BE阈值那么重要：它们守的不只是一列速度数据，而是整条流量链路的输入。

我现在的做法是，每换一个测区，先发CR1，再逐条核对CF的五位、EX的五位、ES、WF与WS的组合，采样一小段确认底跟踪和水跟踪都出真实值之后才正式开测。这套流程走过一次翻车之后就再没跳过。希望帮到你。

本文还有配套的精品资源，点击获取