简介面向气象数据处理、雷达产品开发与教学科研人员的CINRAD雷达基数据格式参考文档聚焦SA/SB与CA/CB两类雷达帮助读者厘清二进制基数据的存储与解析规则适合需要编写解码程序或核对字段含义的初中级开发者查阅。压缩包内为1个doc文档约92KB以字节顺序表形式逐项列出雷达信息头、径向数据收集时间、儒略日、不模糊距离、方位角与仰角编码、径向数据状态、体扫仰角数、反射率与多普勒数据的首库距离、库长、库数、各类数据指针、速度分辨率、VCP模式及Nyquist速度等字段并给出反射率、速度、谱宽的量化编码公式与无回波、距离模糊的取值约定。文档还说明每个体扫单独存为一个文件、径向数据按仰角由低到高排列、单条径向长度固定为2432字节以及SA/SB与CA/CB在库长和最大库数上的差异。已有2806人学习可作为格式对照与排错时的速查手册。1. 雷达基数据为什么一个 2432 字节的定长块能装下一整圈扫描拿到一份雷达基数据文件第一反应往往是「这不就是一堆浮点数吗」。真打开看前 128 个字节里塞着毫秒级时间戳、儒略日、方位角、仰角、库长、库数、三个数据指针后面紧跟着定长 2432 字节的径向块反射率、速度、谱宽三段数据首尾相接。没有分隔符没有 JSON 那种自描述结构全靠偏移量硬算。这种设计在今天看来近乎「反人类」但它恰恰是九十年代硬件条件下最合理的选择定长记录让磁带上顺序读写不需要回退指针偏移让解析器可以跳过不关心的字段编码压缩让一个字节承载 0.5 dBZ 的精度。搞懂这套格式的价值不在于「会读文件」而在于理解一个更底层的问题当存储和带宽都是稀缺资源时数据格式会退化成什么样。CINRAD SA/SB 与 CA/CB 两套格式的差异本质上就是 S 波段和 C 波段在探测距离、库长、库数上的物理差异被硬编码进了字节布局。读懂了字节顺序和编码公式你才能解释为什么同一个反射率值在 S 波段和 C 波段文件里解出来的数字不一样为什么仰角数组里明明有 11 次 PPI 扫描却只存了 9 层。这些坑后面会一个个拆开。2. 字节布局的底层逻辑定长径向块与指针偏移怎么配合2.1 为什么径向数据必须是定长 2432 字节先看一个反直觉的事实SA/SB 雷达的反射率最大 460 个库速度 920 个库谱宽 920 个库加起来 2300 个字节加上 128 字节头正好 2428再补 4 字节保留凑成 2432。CA/CB 则是 800 1600 1600 4000 字节数据区加 128 字节头得 4128补 4 字节到 4132。这个「凑整」不是随意为之而是为了让每条径向记录长度恒定解析时第 n 条径向的起始偏移就是n * 2432不需要任何索引表。常见的实现思路是读取时先定位到文件头取出反射率、速度、谱宽三个指针偏移 33、35、37 处的双字节它们表示「偏离雷达数据信息头的字节数」。注意这里的「雷达数据信息头」指的是 128 字节的径向头不是文件头。所以反射率数据的实际文件偏移是径向起始 指针值。指针值在 SA/SB 里通常是 129反射率、129A速度、129AB谱宽其中 A、B 是前一段的库数。这个设计的好处是即使某条径向的库数变化指针也能自适应解析器不用假设固定布局。但这里有个容易翻车的点指针是双字节字节顺序必须和文件整体一致。SA/SB 和 CA/CB 都采用小端序低字节在前如果你用大端序解析指针会变成一个荒谬的大数直接越界。我一般会先读偏移 0 处的双字节看值是不是 1表示雷达数据如果是 256说明字节序搞反了。2.2 128 字节头里的关键字段与编码公式径向头里真正影响解析的字段就那么几个但每个都有编码陷阱。方位角在偏移 18双字节编码方式是[数值/8.] * [180./4096.] 度。这个公式拆开看先把整数除以 8 得到「半度单位」再乘以 180/4096 换算成度。等价于数值 * 180 / 32768也就是把 0 到 360 度映射到 0 到 65535 的整数空间。仰角在偏移 22同样的编码。这种定点数表示在浮点协处理器昂贵的年代是标配代价是解析时必须严格按公式还原不能想当然地除以 100。不模糊距离在偏移 16双字节数值/10. 千米。Nyquist 速度在偏移 45数值/100. 米/秒。这两个字段的精度分别是 0.1 公里和 0.01 米/秒够用但不富裕。真正麻烦的是数据区的编码反射率(数值-2)/2. - 32 dBZ速度在 0.5 米/秒分辨率下(数值-2)/2. - 63.5 米/秒在 1.0 米/秒分辨率下(数值-2) - 127 米/秒。注意速度的两种分辨率对应不同的公式分辨率字段在偏移 36值 2 表示 0.5值 4 表示 1.0。如果你统一用 0.5 的公式去解 1.0 的文件速度会整体偏移一倍风场结构全乱。提示数值 0 表示无回波低于信噪比阈值数值 1 表示距离模糊。这两个特殊值在解码前必须单独判断否则(0-2)/2.-32会算出 -33 dBZ看起来像弱回波实际是无效数据。2.3 体扫模式与仰角层数的映射关系VCP 模式字段在偏移 37值 11 表示降水模式 16 层仰角21 表示降水模式 14 层31 表示晴空 8 层32 表示晴空 7 层。但实际文件里的仰角层数往往比标称值少原因在项目正文里写得很清楚SA、SB、CB 雷达在低层每个仰角上扫描两次程序保存时记为一个仰角层。以 21 模式为例VCP 仰角序列是 0.5、0.5、1.5、1.5、2.4、3.4、4.3、6.0、9.9、14.6、19.5共 11 次 PPI 扫描但 0.5 和 1.5 各重复一次去重后只剩 9 个有效仰角。这个「重复扫描」不是冗余而是低仰角需要更高的时间分辨率来捕捉快速变化的降水系统。解析时如果按 PPI 次数分配数组会多出两层空数据如果按去重后的仰角数分配又得处理同一仰角两条径向的合并。常见的做法是用Elvation[MaxCuts]存去重后的仰角值MaxCuts20留足余量实际有效元素个数由文件头里的「体扫内的仰角数」字段偏移 23决定。但注意这个字段在某些早期文件里可能不准稳妥的做法是遍历所有径向按仰角值去重计数。3. 数据区解码从字节到物理量的完整链路3.1 反射率、速度、谱宽的三段式布局SA/SB 的数据区从偏移 128 开始反射率占129到129A-1速度占129A到129AB-1谱宽占129AB到129ABB-1。A 是反射率库数最大 460B 是多普勒库数最大 920。CA/CB 则是反射率 800 库、速度 1600 库、谱宽 1600 库数据区从偏移 128 开始反射率占 128 到 927速度占 928 到 2527谱宽占 2528 到 4127。注意 CA/CB 的指针字段虽然存在但实际布局是固定的三段连续指针值通常就是 129、929、2529 这类固定偏移。解码时最容易出错的是库数与实际数据长度的对应关系。反射率库数在偏移 27SA/SB或由文件头决定但数据区里反射率段之后紧跟着速度段如果反射率库数读错速度段的起始位置就全错。我一般会做一次交叉验证用指针值算出的速度起始偏移和用反射率库数算出的偏移对比两者一致才继续。import struct def decode_radial(buf, is_c_bandFalse): # buf: 单条径向的完整字节SA/SB 为 2432 字节CA/CB 为 4132 字节 # 读取方位角偏移 18双字节小端 az_raw struct.unpack_from(H, buf, 18)[0] azimuth az_raw * 180.0 / 32768.0 # 等价于 [数值/8.]*[180./4096.] # 读取仰角偏移 22 el_raw struct.unpack_from(H, buf, 22)[0] elevation el_raw * 180.0 / 32768.0 # 读取反射率指针偏移 33 ref_ptr struct.unpack_from(H, buf, 33)[0] # 读取速度指针偏移 35 vel_ptr struct.unpack_from(H, buf, 35)[0] # 读取谱宽指针偏移 37 spw_ptr struct.unpack_from(H, buf, 37)[0] # 反射率库数SA/SB 在偏移 27CA/CB 固定 800 if is_c_band: ref_gates 800 vel_gates 1600 spw_gates 1600 else: ref_gates struct.unpack_from(H, buf, 27)[0] vel_gates struct.unpack_from(H, buf, 29)[0] spw_gates vel_gates # 谱宽库数通常与速度相同 # 解码反射率从 ref_ptr 开始每个字节 (v-2)/2.-32 ref_data [] for i in range(ref_gates): v buf[ref_ptr i] if v 0: ref_data.append(-999.0) # 无回波 elif v 1: ref_data.append(999.0) # 距离模糊 else: ref_data.append((v - 2) / 2.0 - 32.0) # 解码速度需要先读分辨率字段偏移 36 vel_res struct.unpack_from(H, buf, 36)[0] vel_data [] for i in range(vel_gates): v buf[vel_ptr i] if v 0: vel_data.append(-999.0) elif v 1: vel_data.append(999.0) elif vel_res 2: # 0.5 米/秒分辨率 vel_data.append((v - 2) / 2.0 - 63.5) else: # 1.0 米/秒分辨率 vel_data.append((v - 2) - 127.0) return azimuth, elevation, ref_data, vel_data这段代码的关键在于三个指针的读取顺序和库数的来源。ref_ptr、vel_ptr、spw_ptr都是相对径向头起始的偏移不是相对文件头。ref_gates在 SA/SB 里从偏移 27 读但有些文件这个字段可能为 0此时要回退到用指针差值推算vel_ptr - ref_ptr就是反射率库数。速度分辨率的判断也不能省vel_res 2和vel_res 4对应两套完全不同的解码公式混用会导致速度值整体偏移 63.5 米/秒风场直接反向。3.2 距离库长与库数的物理约束SA/SB 的反射率库长 1000 米、最大 460 库对应最大探测距离 460 公里速度库长 250 米、最大 920 库对应 230 公里。CA/CB 的反射率库长 500 米、800 库对应 400 公里速度库长 125 米、1600 库对应 200 公里。这些数字不是随便定的而是和波段频率、脉冲重复频率绑定的。S 波段波长长衰减小能打得更远但分辨率粗C 波段波长短分辨率细但衰减大所以库长减半、库数翻倍来补偿。解析时如果库长字段偏移 25 和 27读出来是 0说明文件头损坏或者字节序错了。正常的 SA/SB 文件这两个值应该是 1000 和 250CA/CB 是 500 和 125。我见过有人把库长当成「米/10」来解析结果算出 100 米和 25 米整个距离轴压缩十倍回波全挤在近处。项目正文里写得很明确库长单位就是米不需要再除。3.3 数组存储与无效值标记的工程约定项目正文给出的程序示例里用三维数组VolRef[MaxCuts][MaxRads][RGates]存反射率MaxCuts20、MaxRads按每度一个径向、RGates按波段取 460 或 800。无效数据标记 -999.0距离折叠标记 999.0。这个约定看似简单但实际使用时有两个坑一是MaxRads按每度一个径向意味着 360 个方位但实际径向数可能略多或略少方位角量化误差直接按索引int(azimuth)存会丢数据或覆盖二是 -999.0 和 999.0 都是合法浮点数如果后续做插值或平滑必须先把它们掩掉否则会把无效值当成极端回波参与计算。常见的实现思路是先遍历所有径向按方位角排序遇到同一度内多条径向时取最近的一条或做平均再填入数组。Elvation[]数组只存去重后的仰角值有效元素个数由实际扫描层数决定不要硬编码 9 或 11。4. 避坑与排查解析雷达基数据时最常见的五个翻车点4.1 字节序搞反导致指针变成天文数字现象读出来的反射率指针是 33024 而不是 129速度指针是 33280 而不是 929。原因文件是小端序解析时用了大端序的H。解决统一用H读双字节或者先读偏移 0 处的值如果是 256 而不是 1说明字节序反了切换解析模式。4.2 速度分辨率字段没读风场整体偏移现象速度值全部落在 -63.5 到 63.5 之间但实际风场应该有正负 30 米/秒以上的值且正负分布明显不对称。原因偏移 36 的分辨率字段值为 41.0 米/秒但代码按 0.5 米/秒的公式解码。解决解码前先读vel_res值为 2 走(v-2)/2.-63.5值为 4 走(v-2)-127。4.3 仰角层数按 PPI 次数算多出两层空数据现象21 模式下解析出 11 层仰角但第 2 层和第 4 层数据几乎为空或与相邻层重复。原因低仰角重复扫描被当成了独立层。解决按仰角值去重0.5 和 1.5 各只保留一层有效层数应为 9。判断依据是Elvation[]数组里相邻元素是否相等。4.4 库数读 0 导致数据段错位现象反射率解出来全是 -32 dBZ 左右的平坦值速度段起始位置对不上。原因偏移 27 的反射率库数字段为 0某些早期文件或损坏文件。解决用指针差值推算库数vel_ptr - ref_ptr即反射率库数spw_ptr - vel_ptr即速度库数再和文件头字段交叉验证。4.5 无效值 -999.0 参与插值污染结果现象做径向插值或平滑后局部出现极端负值或 NaN。原因-999.0 和 999.0 被当成正常数据参与运算。解决在插值前用掩码数组masked array或先替换为 NaN运算完再还原标记。注意 999.0 是距离折叠物理上不是真实回波不能和 -999.0 混为一谈。5. 设计取舍定长格式的代价与解析器的边界这套格式最核心的取舍是「用空间换确定性」。定长径向块让随机访问变成简单的乘法指针偏移让字段扩展不需要改变整体布局定点编码让每个字节的利用率最大化。代价是灵活性几乎为零新增一个字段只能塞进保留区库数变化必须靠指针自适应跨波段兼容得靠编译期常量切换。项目正文里DataFormat.h用const int RGates 460这种编译期常量来区分波段意味着同一个可执行文件不能同时读 S 和 C 波段数据必须改常量重编译。这在今天看来很笨拙但在嵌入式或早期工作站环境下编译期常量能省掉运行时分支是合理的工程选择。如果让我设计一个现代解析器我会把波段判断做成运行时参数库数从文件头动态读取指针偏移做边界检查无效值用 NaN 而不是 -999.0。但即便如此底层字节布局还是得按这份说明来因为历史数据不会变。验证解析是否正确的方法很朴素找一个已知天气过程的文件解出来的反射率平面图应该能看到明显的回波结构速度图应该有正负交替的冷暖平流特征谱宽在强回波区应该偏高。如果解出来是一片噪声或者全零先查字节序再查指针最后查分辨率字段。从那以后我每次写解析器都会先拿一条径向手动算一遍方位角和反射率和已知值对上了再批量跑。这个习惯帮我省掉了至少三次「整体偏移但看起来像真的」的翻车。希望帮到你。本文还有配套的精品资源点击获取
简介面向气象数据处理、雷达产品开发与教学科研人员的CINRAD雷达基数据格式参考文档聚焦SA/SB与CA/CB两类雷达帮助读者厘清二进制基数据的存储与解析规则适合需要编写解码程序或核对字段含义的初中级开发者查阅。压缩包内为1个doc文档约92KB以字节顺序表形式逐项列出雷达信息头、径向数据收集时间、儒略日、不模糊距离、方位角与仰角编码、径向数据状态、体扫仰角数、反射率与多普勒数据的首库距离、库长、库数、各类数据指针、速度分辨率、VCP模式及Nyquist速度等字段并给出反射率、速度、谱宽的量化编码公式与无回波、距离模糊的取值约定。文档还说明每个体扫单独存为一个文件、径向数据按仰角由低到高排列、单条径向长度固定为2432字节以及SA/SB与CA/CB在库长和最大库数上的差异。已有2806人学习可作为格式对照与排错时的速查手册。1. 雷达基数据为什么一个 2432 字节的定长块能装下一整圈扫描拿到一份雷达基数据文件第一反应往往是「这不就是一堆浮点数吗」。真打开看前 128 个字节里塞着毫秒级时间戳、儒略日、方位角、仰角、库长、库数、三个数据指针后面紧跟着定长 2432 字节的径向块反射率、速度、谱宽三段数据首尾相接。没有分隔符没有 JSON 那种自描述结构全靠偏移量硬算。这种设计在今天看来近乎「反人类」但它恰恰是九十年代硬件条件下最合理的选择定长记录让磁带上顺序读写不需要回退指针偏移让解析器可以跳过不关心的字段编码压缩让一个字节承载 0.5 dBZ 的精度。搞懂这套格式的价值不在于「会读文件」而在于理解一个更底层的问题当存储和带宽都是稀缺资源时数据格式会退化成什么样。CINRAD SA/SB 与 CA/CB 两套格式的差异本质上就是 S 波段和 C 波段在探测距离、库长、库数上的物理差异被硬编码进了字节布局。读懂了字节顺序和编码公式你才能解释为什么同一个反射率值在 S 波段和 C 波段文件里解出来的数字不一样为什么仰角数组里明明有 11 次 PPI 扫描却只存了 9 层。这些坑后面会一个个拆开。2. 字节布局的底层逻辑定长径向块与指针偏移怎么配合2.1 为什么径向数据必须是定长 2432 字节先看一个反直觉的事实SA/SB 雷达的反射率最大 460 个库速度 920 个库谱宽 920 个库加起来 2300 个字节加上 128 字节头正好 2428再补 4 字节保留凑成 2432。CA/CB 则是 800 1600 1600 4000 字节数据区加 128 字节头得 4128补 4 字节到 4132。这个「凑整」不是随意为之而是为了让每条径向记录长度恒定解析时第 n 条径向的起始偏移就是n * 2432不需要任何索引表。常见的实现思路是读取时先定位到文件头取出反射率、速度、谱宽三个指针偏移 33、35、37 处的双字节它们表示「偏离雷达数据信息头的字节数」。注意这里的「雷达数据信息头」指的是 128 字节的径向头不是文件头。所以反射率数据的实际文件偏移是径向起始 指针值。指针值在 SA/SB 里通常是 129反射率、129A速度、129AB谱宽其中 A、B 是前一段的库数。这个设计的好处是即使某条径向的库数变化指针也能自适应解析器不用假设固定布局。但这里有个容易翻车的点指针是双字节字节顺序必须和文件整体一致。SA/SB 和 CA/CB 都采用小端序低字节在前如果你用大端序解析指针会变成一个荒谬的大数直接越界。我一般会先读偏移 0 处的双字节看值是不是 1表示雷达数据如果是 256说明字节序搞反了。2.2 128 字节头里的关键字段与编码公式径向头里真正影响解析的字段就那么几个但每个都有编码陷阱。方位角在偏移 18双字节编码方式是[数值/8.] * [180./4096.] 度。这个公式拆开看先把整数除以 8 得到「半度单位」再乘以 180/4096 换算成度。等价于数值 * 180 / 32768也就是把 0 到 360 度映射到 0 到 65535 的整数空间。仰角在偏移 22同样的编码。这种定点数表示在浮点协处理器昂贵的年代是标配代价是解析时必须严格按公式还原不能想当然地除以 100。不模糊距离在偏移 16双字节数值/10. 千米。Nyquist 速度在偏移 45数值/100. 米/秒。这两个字段的精度分别是 0.1 公里和 0.01 米/秒够用但不富裕。真正麻烦的是数据区的编码反射率(数值-2)/2. - 32 dBZ速度在 0.5 米/秒分辨率下(数值-2)/2. - 63.5 米/秒在 1.0 米/秒分辨率下(数值-2) - 127 米/秒。注意速度的两种分辨率对应不同的公式分辨率字段在偏移 36值 2 表示 0.5值 4 表示 1.0。如果你统一用 0.5 的公式去解 1.0 的文件速度会整体偏移一倍风场结构全乱。提示数值 0 表示无回波低于信噪比阈值数值 1 表示距离模糊。这两个特殊值在解码前必须单独判断否则(0-2)/2.-32会算出 -33 dBZ看起来像弱回波实际是无效数据。2.3 体扫模式与仰角层数的映射关系VCP 模式字段在偏移 37值 11 表示降水模式 16 层仰角21 表示降水模式 14 层31 表示晴空 8 层32 表示晴空 7 层。但实际文件里的仰角层数往往比标称值少原因在项目正文里写得很清楚SA、SB、CB 雷达在低层每个仰角上扫描两次程序保存时记为一个仰角层。以 21 模式为例VCP 仰角序列是 0.5、0.5、1.5、1.5、2.4、3.4、4.3、6.0、9.9、14.6、19.5共 11 次 PPI 扫描但 0.5 和 1.5 各重复一次去重后只剩 9 个有效仰角。这个「重复扫描」不是冗余而是低仰角需要更高的时间分辨率来捕捉快速变化的降水系统。解析时如果按 PPI 次数分配数组会多出两层空数据如果按去重后的仰角数分配又得处理同一仰角两条径向的合并。常见的做法是用Elvation[MaxCuts]存去重后的仰角值MaxCuts20留足余量实际有效元素个数由文件头里的「体扫内的仰角数」字段偏移 23决定。但注意这个字段在某些早期文件里可能不准稳妥的做法是遍历所有径向按仰角值去重计数。3. 数据区解码从字节到物理量的完整链路3.1 反射率、速度、谱宽的三段式布局SA/SB 的数据区从偏移 128 开始反射率占129到129A-1速度占129A到129AB-1谱宽占129AB到129ABB-1。A 是反射率库数最大 460B 是多普勒库数最大 920。CA/CB 则是反射率 800 库、速度 1600 库、谱宽 1600 库数据区从偏移 128 开始反射率占 128 到 927速度占 928 到 2527谱宽占 2528 到 4127。注意 CA/CB 的指针字段虽然存在但实际布局是固定的三段连续指针值通常就是 129、929、2529 这类固定偏移。解码时最容易出错的是库数与实际数据长度的对应关系。反射率库数在偏移 27SA/SB或由文件头决定但数据区里反射率段之后紧跟着速度段如果反射率库数读错速度段的起始位置就全错。我一般会做一次交叉验证用指针值算出的速度起始偏移和用反射率库数算出的偏移对比两者一致才继续。import struct def decode_radial(buf, is_c_bandFalse): # buf: 单条径向的完整字节SA/SB 为 2432 字节CA/CB 为 4132 字节 # 读取方位角偏移 18双字节小端 az_raw struct.unpack_from(H, buf, 18)[0] azimuth az_raw * 180.0 / 32768.0 # 等价于 [数值/8.]*[180./4096.] # 读取仰角偏移 22 el_raw struct.unpack_from(H, buf, 22)[0] elevation el_raw * 180.0 / 32768.0 # 读取反射率指针偏移 33 ref_ptr struct.unpack_from(H, buf, 33)[0] # 读取速度指针偏移 35 vel_ptr struct.unpack_from(H, buf, 35)[0] # 读取谱宽指针偏移 37 spw_ptr struct.unpack_from(H, buf, 37)[0] # 反射率库数SA/SB 在偏移 27CA/CB 固定 800 if is_c_band: ref_gates 800 vel_gates 1600 spw_gates 1600 else: ref_gates struct.unpack_from(H, buf, 27)[0] vel_gates struct.unpack_from(H, buf, 29)[0] spw_gates vel_gates # 谱宽库数通常与速度相同 # 解码反射率从 ref_ptr 开始每个字节 (v-2)/2.-32 ref_data [] for i in range(ref_gates): v buf[ref_ptr i] if v 0: ref_data.append(-999.0) # 无回波 elif v 1: ref_data.append(999.0) # 距离模糊 else: ref_data.append((v - 2) / 2.0 - 32.0) # 解码速度需要先读分辨率字段偏移 36 vel_res struct.unpack_from(H, buf, 36)[0] vel_data [] for i in range(vel_gates): v buf[vel_ptr i] if v 0: vel_data.append(-999.0) elif v 1: vel_data.append(999.0) elif vel_res 2: # 0.5 米/秒分辨率 vel_data.append((v - 2) / 2.0 - 63.5) else: # 1.0 米/秒分辨率 vel_data.append((v - 2) - 127.0) return azimuth, elevation, ref_data, vel_data这段代码的关键在于三个指针的读取顺序和库数的来源。ref_ptr、vel_ptr、spw_ptr都是相对径向头起始的偏移不是相对文件头。ref_gates在 SA/SB 里从偏移 27 读但有些文件这个字段可能为 0此时要回退到用指针差值推算vel_ptr - ref_ptr就是反射率库数。速度分辨率的判断也不能省vel_res 2和vel_res 4对应两套完全不同的解码公式混用会导致速度值整体偏移 63.5 米/秒风场直接反向。3.2 距离库长与库数的物理约束SA/SB 的反射率库长 1000 米、最大 460 库对应最大探测距离 460 公里速度库长 250 米、最大 920 库对应 230 公里。CA/CB 的反射率库长 500 米、800 库对应 400 公里速度库长 125 米、1600 库对应 200 公里。这些数字不是随便定的而是和波段频率、脉冲重复频率绑定的。S 波段波长长衰减小能打得更远但分辨率粗C 波段波长短分辨率细但衰减大所以库长减半、库数翻倍来补偿。解析时如果库长字段偏移 25 和 27读出来是 0说明文件头损坏或者字节序错了。正常的 SA/SB 文件这两个值应该是 1000 和 250CA/CB 是 500 和 125。我见过有人把库长当成「米/10」来解析结果算出 100 米和 25 米整个距离轴压缩十倍回波全挤在近处。项目正文里写得很明确库长单位就是米不需要再除。3.3 数组存储与无效值标记的工程约定项目正文给出的程序示例里用三维数组VolRef[MaxCuts][MaxRads][RGates]存反射率MaxCuts20、MaxRads按每度一个径向、RGates按波段取 460 或 800。无效数据标记 -999.0距离折叠标记 999.0。这个约定看似简单但实际使用时有两个坑一是MaxRads按每度一个径向意味着 360 个方位但实际径向数可能略多或略少方位角量化误差直接按索引int(azimuth)存会丢数据或覆盖二是 -999.0 和 999.0 都是合法浮点数如果后续做插值或平滑必须先把它们掩掉否则会把无效值当成极端回波参与计算。常见的实现思路是先遍历所有径向按方位角排序遇到同一度内多条径向时取最近的一条或做平均再填入数组。Elvation[]数组只存去重后的仰角值有效元素个数由实际扫描层数决定不要硬编码 9 或 11。4. 避坑与排查解析雷达基数据时最常见的五个翻车点4.1 字节序搞反导致指针变成天文数字现象读出来的反射率指针是 33024 而不是 129速度指针是 33280 而不是 929。原因文件是小端序解析时用了大端序的H。解决统一用H读双字节或者先读偏移 0 处的值如果是 256 而不是 1说明字节序反了切换解析模式。4.2 速度分辨率字段没读风场整体偏移现象速度值全部落在 -63.5 到 63.5 之间但实际风场应该有正负 30 米/秒以上的值且正负分布明显不对称。原因偏移 36 的分辨率字段值为 41.0 米/秒但代码按 0.5 米/秒的公式解码。解决解码前先读vel_res值为 2 走(v-2)/2.-63.5值为 4 走(v-2)-127。4.3 仰角层数按 PPI 次数算多出两层空数据现象21 模式下解析出 11 层仰角但第 2 层和第 4 层数据几乎为空或与相邻层重复。原因低仰角重复扫描被当成了独立层。解决按仰角值去重0.5 和 1.5 各只保留一层有效层数应为 9。判断依据是Elvation[]数组里相邻元素是否相等。4.4 库数读 0 导致数据段错位现象反射率解出来全是 -32 dBZ 左右的平坦值速度段起始位置对不上。原因偏移 27 的反射率库数字段为 0某些早期文件或损坏文件。解决用指针差值推算库数vel_ptr - ref_ptr即反射率库数spw_ptr - vel_ptr即速度库数再和文件头字段交叉验证。4.5 无效值 -999.0 参与插值污染结果现象做径向插值或平滑后局部出现极端负值或 NaN。原因-999.0 和 999.0 被当成正常数据参与运算。解决在插值前用掩码数组masked array或先替换为 NaN运算完再还原标记。注意 999.0 是距离折叠物理上不是真实回波不能和 -999.0 混为一谈。5. 设计取舍定长格式的代价与解析器的边界这套格式最核心的取舍是「用空间换确定性」。定长径向块让随机访问变成简单的乘法指针偏移让字段扩展不需要改变整体布局定点编码让每个字节的利用率最大化。代价是灵活性几乎为零新增一个字段只能塞进保留区库数变化必须靠指针自适应跨波段兼容得靠编译期常量切换。项目正文里DataFormat.h用const int RGates 460这种编译期常量来区分波段意味着同一个可执行文件不能同时读 S 和 C 波段数据必须改常量重编译。这在今天看来很笨拙但在嵌入式或早期工作站环境下编译期常量能省掉运行时分支是合理的工程选择。如果让我设计一个现代解析器我会把波段判断做成运行时参数库数从文件头动态读取指针偏移做边界检查无效值用 NaN 而不是 -999.0。但即便如此底层字节布局还是得按这份说明来因为历史数据不会变。验证解析是否正确的方法很朴素找一个已知天气过程的文件解出来的反射率平面图应该能看到明显的回波结构速度图应该有正负交替的冷暖平流特征谱宽在强回波区应该偏高。如果解出来是一片噪声或者全零先查字节序再查指针最后查分辨率字段。从那以后我每次写解析器都会先拿一条径向手动算一遍方位角和反射率和已知值对上了再批量跑。这个习惯帮我省掉了至少三次「整体偏移但看起来像真的」的翻车。希望帮到你。本文还有配套的精品资源点击获取
改进与应用实践)
