简介面向气象数据处理、雷达产品开发与教学科研人员的CINRAD雷达基数据格式参考文档聚焦SA/SB与CA/CB两类雷达系统梳理基数据的存储方式、径向排列规则、径向数据长度、距离库长与库数等关键参数帮助读者在解析二进制文件、编写读取程序或核对数据字段时快速定位依据。压缩包内为1个doc文档约92KB按字节顺序与双字节顺序逐项列出雷达信息头、径向数据收集时间、儒略日、不模糊距离、方位角、仰角、体扫仰角数、反射率与多普勒数据的首库距离、库长、库数、各类数据指针、多普勒速度分辨率、VCP模式及Nyquist速度等字段并给出反射率、速度、谱宽的编码换算公式与无回波、距离模糊等特殊取值说明同时对比两类雷达在库数与数据区长度上的差异。已有2806人学习适合需要逐字段查阅、对照编码规则完成数据解码与校验的读者。1. 雷达基数据为什么一个 2432 字节的定长记录能装下一整层扫描拿到一份雷达基数据文件第一反应往往是「这不就是一堆浮点数吗」。真打开看前 128 字节里塞着毫秒级时间戳、儒略日、方位角、仰角、库长、库数、三个数据段指针后面才是按径向排列的观测值。更反直觉的是每条径向记录长度固定SA/SB 是 2432 字节CA/CB 是 4132 字节不管这一条径向上实际有多少个有效回波字节数一个不多一个不少。这种「定长记录 段内偏移」的设计是理解整个 CINRAD 基数据格式的钥匙。搞懂它你才知道为什么读文件时不能按「有多少数据读多少」的思路来也才能解释后面那些编码公式、指针偏移、无效值标记为什么长成那个样子。2. 定长径向记录为什么长度固定反而更省事2.1 一条径向记录里到底有什么把一条 SA/SB 径向记录拆开看结构是分层的。最前面 128 字节是径向头里面第 15-16 字节是「1-表示雷达数据」的标志位第 29-32 字节是自 00:00 起的毫秒数第 33-34 字节是自 1970 年 1 月 1 日算起的儒略日。再往后是方位角、仰角、库长、库数这些几何参数以及三个关键指针反射率数据指针、速度数据指针、谱宽数据指针它们记录的是「偏离雷达数据信息头的字节数」也就是从第 129 字节开始算的偏移量。这里有个容易看漏的细节指针是相对「雷达数据信息头」的偏移不是相对文件开头的绝对位置。所以真实数据位置 128 指针值。很多初次解析的人直接拿指针当绝对偏移去 seek结果读出来的第一个字节永远是错的这种翻车在解析器开发里太常见了。径向头之后是数据区。反射率从 129 字节开始长度由第 55-56 字节的「反射率距离库数」决定范围 0-460速度紧接其后库数由第 57-58 字节给出范围 0-920谱宽再往后库数同样取第 57-58 字节的值。三段数据加起来最多 460 920 920 2300 字节加上 128 字节头再补到 2432 字节的固定长度尾部就是保留区。2.2 定长设计背后的取舍为什么不定长因为雷达是实时流式产出的设备。每个体扫存成一个独立文件文件里按径向顺序排列从低仰角到高仰角。如果每条记录变长写入端要不断计算长度、回填偏移读取端要先扫一遍才能知道第 N 条径向在哪。定长之后第 N 条径向的起始位置就是N * 2432随机访问变成一次乘法这对需要按仰角、按方位快速定位的可视化程序来说是刚需。代价是空间浪费。一条径向上如果反射率只有 200 个有效库剩下 260 个库的位置照样占着字节填的是无效标记。但雷达数据本身对实时性要求高于存储效率这个取舍是划算的。我一般会这么理解这不是为归档设计的格式是为「边扫边写、边写边读」设计的格式。2.3 用代码把定长记录读出来下面这段 Python 演示如何按定长切分并定位三段数据关键在偏移计算和字节序处理import struct RADIAL_LEN 2432 # SA/SB 单条径向固定长度 HEADER_LEN 128 # 径向头长度 def parse_radial(buf): # buf 是一条完整的 2432 字节径向记录 # 第 15-16 字节数据类型标志1 表示雷达数据 data_flag struct.unpack_from(H, buf, 14)[0] # 第 29-32 字节毫秒时间戳 msec struct.unpack_from(I, buf, 28)[0] # 第 37-38 字节方位角原始值需按公式换算 az_raw struct.unpack_from(H, buf, 36)[0] azimuth (az_raw / 8.0) * (180.0 / 4096.0) # 第 55-56 字节反射率库数 n_ref struct.unpack_from(H, buf, 54)[0] # 第 65-66 字节反射率数据指针相对雷达数据信息头 ptr_ref struct.unpack_from(H, buf, 64)[0] # 真实数据起点 头长度 指针 ref_start HEADER_LEN ptr_ref ref_bytes buf[ref_start:ref_start n_ref] return { flag: data_flag, msec: msec, azimuth: azimuth, n_ref: n_ref, ref_raw: list(ref_bytes) }struct.unpack_from(H, ...)里的表示小端字节序这是 CINRAD 基数据的默认约定。az_raw / 8.0 * (180.0 / 4096.0)对应文档里的方位角编码公式先除以 8 再乘角度分辨率。ref_start HEADER_LEN ptr_ref就是前面强调的「指针是相对偏移」的落地写法。如果这里写成ptr_ref直接用读出来的就是头部的保留字节表现为反射率全是乱值。3. 编码公式为什么观测值要经过一次线性变换3.1 反射率的 (数值-2)/2-32 从哪来原始文件里存的不是 dBZ 浮点数而是一个 0-255 的单字节整数。反射率的解码公式是(数值 - 2) / 2.0 - 32 DBZ。这个式子拆开看先减 2是为了把 0 和 1 两个特殊值让出来——0 表示无回波低于信噪比阈值1 表示距离模糊基数据部分。减完之后再除以 2是把整数刻度映射成 0.5 dBZ 的分辨率最后减 32是把零点平移到物理上有意义的区间。为什么是 0.5 dBZ 而不是 1 dBZ因为降水回波的动态范围很大弱回波和强回波可能差几十 dBZ1 dBZ 的量化误差在弱回波区会显得粗糙。0.5 的步长在单字节 256 个刻度里能覆盖大约 127 dBZ 的范围足够用。3.2 速度和谱宽的双分辨率陷阱速度的编码比反射率多一层分支取决于第 71-72 字节的「多普勒速度分辨率」值为 2 表示 0.5 米/秒值为 4 表示 1.0 米/秒。两种情况下公式不同分辨率 0.5 米/秒(数值 - 2) / 2.0 - 63.5 米/秒分辨率 1.0 米/秒(数值 - 2) - 127 米/秒谱宽则固定用(数值 - 2) / 2.0 - 63.5 米/秒。这里最容易踩的坑是解析速度时忘了先读分辨率字段一律按 0.5 的公式算结果在 1.0 分辨率的文件里速度值整体偏大一倍。这种错误不会报异常只会让风场图看起来「风速异常偏高」排查起来很费劲。def decode_velocity(raw, resolution_flag): if raw in (0, 1): return None # 0/1 为特殊标记非有效速度 if resolution_flag 2: # 0.5 m/s 分辨率 return (raw - 2) / 2.0 - 63.5 elif resolution_flag 4: # 1.0 m/s 分辨率 return (raw - 2) - 127.0 else: raise ValueError(未知速度分辨率标志: %d % resolution_flag)resolution_flag来自径向头第 71-72 字节必须在解码每条径向之前读一次。把raw in (0, 1)提前拦掉是因为这两个值参与公式会算出接近 -64 的假速度混进风场里就是明显的坏点。3.3 距离库长与库数S 波段和 C 波段的分水岭SA/SB 属于 S 波段反射率库长 1000 米、最大库数 460速度和谱宽库长 250 米、最大库数 920。CA/CB 属于 C 波段反射率库长 500 米、最大库数 800速度和谱宽库长 125 米、最大库数 1600。这个差异直接决定了程序里数组的维度定义。文档里给了一个很实在的做法在头文件里用常量控制。读 S 波段时RGates 460, VGates 920, WGates 920读 C 波段时改成RGates 800, VGates 1600, WGates 1600。这不是风格问题是内存布局问题——数组第二维、第三维的大小必须和文件里的库数上限对齐否则要么越界要么浪费。参数S 波段SA/SBC 波段CA/CB径向记录长度2432 字节4132 字节反射率库长1000 米500 米反射率最大库数460800速度/谱宽库长250 米125 米速度/谱宽最大库数92016004. 仰角层与体扫为什么 11 次 PPI 只算 9 层4.1 重复仰角的合并逻辑这是整个格式里最反直觉的一处。以 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 扫描。但程序里保存到Elvation[]数组的有效元素只有 9 个0.5、1.5、2.4、3.4、4.3、6.0、9.9、14.6、19.5。原因在于 SA、SB、CB 雷达在低层每个仰角上扫描两次程序在存数组时把这两次记为一个仰角层。为什么低层要扫两次常见的实现思路是低仰角受地物遮挡和波束展宽影响大扫两次可以做时间上的平均或互补提高近地层数据质量。但对上层应用来说这两次属于同一层合并存储更符合「一层一个 PPI」的使用习惯。这个合并逻辑对解析器的要求是不能简单地按「径向状态」逐条累加层数而要按仰角值去重。文档里第 43-44 字节的仰角字段就是去重的依据第 41-42 字节的径向状态0 首条、1 中间、2 末条、3 体扫首条、4 体扫末条则用来判断一条径向在层内的位置。4.2 三维数组的内存模型文档给出的存储结构是三维数组float VolRef[MaxCuts][MaxRads][RGates]; // 反射率单位 DBZ float VolVel[MaxCuts][MaxRads][VGates]; // 速度单位 M/S float VolSpw[MaxCuts][MaxRads][WGates]; // 谱宽单位 M/S float Elvation[MaxCuts]; // 各层仰角单位 度MaxCuts 20是最大层数MaxRads是方位数每度保存一个径向即 360RGates/VGates/WGates是各要素的库数。这个布局的含义是第一维是仰角层第二维是方位第三维是距离。读取时按「层 → 方位 → 距离」三重循环填充正好对应雷达扫描的物理顺序。数组里无效数据标记为-999.0距离折叠标记为999.0。这两个哨兵值的选择有讲究-999 远离任何物理合理的 dBZ 或速度值不会被误判为真实观测999 作为距离折叠标记在速度场上是一个明显异常的正值可视化时一眼能看出来。用哨兵值而不是 NaN是因为早期 C 代码里 NaN 的比较行为在不同编译器下不一致哨兵值更稳。4.3 按方位重采样的必要性MaxRads定义为「每度保存一个径向」但实际雷达扫描的径向数不一定正好是 360 的整数倍方位角也可能不是整度。所以填充数组时需要一个重采样步骤把每条径向按它的实际方位角映射到最近的整度格点上。如果两条径向落在同一度通常取先到的或做平均如果某一度没有径向覆盖就填 -999.0。这一步是很多解析器省略掉的省略的后果是可视化时出现方位向的条纹或空洞。我一般会这么处理先按round(azimuth)取整度索引冲突时保留第一条缺失的格点统一填无效值保证数组结构完整。5. 避坑与排查解析雷达基数据时最常见的五个翻车点5.1 指针当绝对偏移用反射率全是乱值现象读出来的反射率第一个值总是很大或很小和实际天气对不上。原因第 65-66 字节的反射率数据指针是「偏离雷达数据信息头的字节数」不是文件绝对偏移。解决真实位置 128 指针值代码里显式加上头长度并在注释里写清楚这个约定。5.2 忘了读速度分辨率风速整体翻倍现象风场图看起来风速异常偏高但形态合理。原因速度解码公式依赖第 71-72 字节的分辨率标志2 对应 0.5 米/秒、4 对应 1.0 米/秒漏读后一律按 0.5 算1.0 分辨率的文件速度值偏大一倍。解决每条径向解码前先读分辨率字段用分支函数处理遇到非 2 非 4 的值直接抛异常而不是猜。5.3 按径向条数累加层数层数对不上现象程序报告的仰角层数是 11但实际有效层只有 9。原因低层重复仰角被当成两层累加。解决按仰角字段去重而不是按径向状态计数用Elvation[]数组存去重后的仰角值填充时判断当前仰角是否已存在。5.4 字节序搞反时间戳变成天文数字现象毫秒时间戳解出来是几亿甚至几十亿儒略日完全不对。原因CINRAD 基数据默认小端字节序用大端解析会把高低字节颠倒。解决所有struct.unpack统一加前缀或者在读取前用文件头第 15-16 字节的标志位做一次自检——正常值应该是 1如果解出来是 256说明字节序反了。5.5 数组维度按 S 波段写死读 C 波段越界现象读 C 波段文件时程序崩溃或数据错位。原因RGates/VGates/WGates常量按 S 波段定义460/920/920而 C 波段是 800/1600/1600第三维不够大导致越界。解决把库数常量做成可配置读文件前先根据文件长度或波段标识选择常量组不要全局写死。提示排查时优先验证三件事——字节序、指针偏移基准、速度分辨率标志。这三处错了后面所有解码都是错的而且不会报错只会静默产出坏数据。6. 从格式约束反推设计定长、哨兵值与指针偏移的取舍回头看这套格式几个设计选择其实是互相咬合的。定长径向记录让随机访问变成乘法代价是尾部保留区浪费空间指针偏移让三段数据可以不等长地塞进定长记录代价是解析时必须做一次加法哨兵值 -999.0 和 999.0 让无效数据和距离折叠在浮点数组里可区分代价是下游算法要显式过滤这两个值不能直接当数值参与统计。如果让我重新设计一个类似的格式我可能会把指针改成绝对偏移减少一层加法的心智负担也可能把无效标记换成 NaN让浮点运算自然传播。但站在当时的工程约束下定长加相对偏移加哨兵值的组合是在实时写入、随机读取、C 语言数组模型三者之间找到的平衡点。理解这个平衡比记住每个字节的含义更重要——因为字节含义会随波段和版本变而「为什么这么排」的逻辑是稳定的。验证一个解析器是否正确我习惯用两个自检一是把解出的方位角序列按顺序打印应该单调递增并在 360 度处回绕二是把反射率数组的无效值比例统计出来正常体扫里无效值占比应该在一个合理区间如果接近 100% 或 0%基本可以断定偏移或字节序出了问题。这两个检查不需要真实天气做参照纯靠格式自身的约束就能暴露大部分错误。从那以后我每次写新的基数据解析器都会先把「字节序、指针基准、分辨率标志」这三项做成启动时的断言跑不通就不往下走。希望帮到你。本文还有配套的精品资源点击获取