雷达基数据二进制解析：字节序、信息头与定点编码避坑

简介《雷达基数据格式说明》面向气象数据处理、雷达产品开发及遥感教学场景系统梳理CINRAD SA/SB与CA/CB雷达基数据的字节级组织规则帮助读者建立二进制文件的读取依据。文档围绕雷达信息头、径向数据收集时间、儒略日、不模糊距离、方位角、径向状态、仰角、体扫模式及各数据指针展开说明反射率、速度、谱宽数据的编码方式、距离库长与库数差异以及SA/SB和CA/CB在库数上限上的区别。资源包共1个doc文件约92KB内容紧凑适合作为解析程序开发、格式核对与教学备课的查阅材料。已有2807人学习下载读者可据此掌握固定2432字节径向记录、扇区与体扫排列逻辑并为后续质量控制、可视化或格式转换提供字段依据。1. 一份二进制格式说明里最容易翻车的往往不是逻辑读 S 波段雷达基数据程序不报错、偏移也没算错但反射率整场都是 -32.5 dBZ。查了半天解析流程问题出在编码公式(数值-2)/2.-32里的那个“2”——有人觉得它像个手滑多打的字符顺手抹掉了。这 2 个刻度不是冗余它是给两个特殊值让位0 表示无回波1 表示距离模糊。抹掉它物理量整体偏移 1 dBZ两个哨兵值也被当成正常回波解出来图上一片假回波。这就是雷达基数据格式说明这类文档的价值所在它不讲算法只把一个字节一个字节的约定写清楚。2432 和 4132 这两个径向长度不是随手定的它们由信息头 128 字节、三组距离库和 4 字节保留位加出来的。搞懂这些数字怎么来的比会调一个解析库重要得多。2. 字节序与信息头128 字节里到底塞了什么2.1 双字节顺序为什么是第一道坎雷达基数据的多字节字段一律按大端存放这是网络传输和早期雷达处理机的历史约定。x86 机器天生小端直接拿struct.unpack(H, ...)解得到的是一个完全不同的数。方位角字段原始两字节如果是0x0A 0x00大端读出来是 2560小端读出来是 10换算成角度差了 256 倍画出来的径向会像被拧过的扇子。先用一小段代码把这件事钉死后面所有字段都靠它兜底。import struct with open(radar_scan.bin, rb) as f: head f.read(2432) # 先整条径向读进来 # 方位角在 1 基的 37-38 字节换成 0 基切片就是 [36:38] az_raw struct.unpack(H, head[36:38])[0] # 强制大端 az_deg (az_raw / 8.0) * (180.0 / 4096.0) print(fraw{az_raw} az{az_deg:.3f} deg) # 同一段字节按小端再解一次看看会错成什么样 az_wrong struct.unpack(H, head[36:38])[0] print(fwrong{az_wrong})和这两个格式字符就是全部的秘密但漏写的代价很大程序不会崩只会安静地给你一份错的方位角序列。判断字节序还有个土办法看方位角是否单调递增且落在 0 到 360 之间——小端解出来的值通常会剧烈跳变甚至超出量程这比逐字段对文档快得多。方位角的编码方式[数值/8.]*[180./4096.]值得单独说一句。16 位无符号整数满量程 65536除以 8 得到 8192 个刻度再乘 180/4096 恰好是 360 度。也就是说这个公式把 8192 个刻度均匀铺满一整圈分辨率约 0.0439 度。仰角用的是完全相同的编码这不是偷懒是让解析代码只需要一个换算函数。2.2 从 1 基偏移到 0 基索引字段逐个对文档里的偏移是 1 基的字节序号代码里是 0 基切片两者差 1。这种差一错误在逐字段手写解析时几乎必然出现一次最稳妥的做法是把偏移表写成数据结构让代码自己去减。1 基偏移字节数字段编码或单位1-1414保留—15-162数据类型标识1 表示雷达数据17-2812保留—29-324径向收集时间毫秒自 00:00 起33-342儒略日自 1970-01-01 起35-362不模糊距离数值/10 千米37-382方位角[数值/8.]*[180./4096.] 度39-402当前仰角内径向序号整数41-422径向数据状态0~4见第 4 章43-442仰角同方位角编码45-462体扫内仰角数整数47-482反射率第一库距离米49-502多普勒第一库距离米51-522反射率库长米53-542多普勒库长米55-562反射率库数整数57-582多普勒库数整数59-602扇区号整数61-644系统订正常数定点65-662反射率数据指针偏离头的字节数67-682速度数据指针同上69-702谱宽数据指针同上71-722多普勒速度分辨率20.5 m/s41.0 m/s73-742体扫模式 VCP11/21/31/3275-828保留—83-842回放反射率指针同 65-6685-862回放速度指针同 67-6887-882回放谱宽指针同 69-7089-902Nyquist 速度数值/100 米/秒91-12838保留—信息头到 128 字节结束数据区从 129 字节1 基开始也就是代码里的buf[128:]。这个 128 是硬边界S 波段和 C 波段都一样变的是后面的数据区。三个指针字段65-66、67-68、69-70是整张表里最容易被忽视、又最能救命的部分。它们记录的是各自数据块相对于文件头的字节偏移意味着你不必死记“反射率从 129 开始”只要读指针就知道真实位置。写解析器时我一般会做一次交叉校验用指针算出的偏移和按库数累加算出的偏移两者必须相等不相等就说明文档读错了或者文件不是这个型号的。2.3 定点编码公式的推导所有物理量都是定点整数存储没有浮点。反射率(数值-2)/2.-32速度在 0.5 米/秒分辨率下是(数值-2)/2.-63.51.0 米/秒分辨率下是(数值-2)-127谱宽与速度的 0.5 分辨率公式一致。Nyquist 速度更简单数值/100就是米/秒。拿反射率验算一遍能看清设计意图数值 2 对应 -32 dBZ数值 255 对应 94.5 dBZ刻度步长 0.5 dBZ。0.5 的步长刚好是雷达接收机量化精度的量级再细没有物理意义再粗会丢掉弱回波细节。速度公式同理0.5 米/秒分辨率下数值 255 对应 63 米/秒覆盖了绝大多数天气目标的径向速度范围一旦切换到 1.0 米/秒分辨率同一字节能表示到 126 米/秒代价是精度腰斩。提示速度的换算分支由信息头 71-72 字节决定不是由文件大小或者文件名推断。忘了读这个字段整场速度会差一倍或者偏 0.5而且看起来“还挺像那么回事”很难第一时间发现。3. 数据区排布2432 和 4132 是怎么加出来的3.1 S 波段的串联布局S 波段SA/SB 型单条径向固定 2432 字节减去 128 字节信息头剩 2304 字节装三组数据。反射率 460 库速度和谱宽各 920 库460 920 920 2300再加末尾 4 字节保留正好 2304。这不是巧合是先把距离库数定死再反推径向长度。按 1 基偏移排下来是反射率 129 至 588速度 589 至 1508谱宽 1509 至 24282429 至 2432 保留。三块首尾相接像三节车厢串在一根轨道上所以只要知道第一块的起点和长度后面两块的位置就都确定了。为什么速度和谱宽的库数是反射率的两倍因为反射率的库长是 1000 米、最大 460 库覆盖 460 公里速度和谱宽的库长是 250 米、920 库覆盖 230 公里。距离分辨率提高了四倍探测距离相应缩短这是脉冲多普勒雷达的固有权衡——要更细的速度估计就得接受更短的的不模糊距离。文档里“不模糊距离”字段对应的就是这个物理约束。3.2 C 波段的并列布局与表格笔误C 波段CA/CB 型径向长度 4132 字节减去 128 字节头、再减 4 字节保留数据区 4000 字节。反射率 800 库、速度 1600 库、谱宽 1600 库加起来正好 4000。这里有个必须点出来的坑。原始文档的表格里三块数据的偏移写成了129-928、129-2528、129-4128起始全是 129。照字面理解三块区域互相重叠物理上不可能。稍微算一下就知道真实起点应是首尾相接反射率 129 至 928速度 929 至 2528谱宽 2529 至 4128。800 1600 1600 4000 这个等式是唯一的仲裁者。这类排版笔误在二进制格式文档里不罕见靠的不是猜而是用总量去反推。更稳的做法还是读那三个指针字段指针说在哪就在哪文档的绝对偏移只作参考。我见过有人照着笔误的偏移去切片切出来的速度场里混进了反射率的尾部图像上表现为一条条横贯的条纹查了两天才发现是文档的问题。S 波段和 C 波段的差异本质上是一个“库长换库数”的取舍C 波段波长更短同样天线尺寸下波束更窄距离分辨率可以做到 500 米反射率和 125 米多普勒代价是库数翻倍、单径向体积从 2432 涨到 4132一个体扫文件的体积也跟着涨。3.3 逐字节解码与向量化单库解码逻辑很短但写错一个常数就全盘皆输def decode_ref(b): if b 0: return -999.0 # 低于信噪比阈值无回波 if b 1: return 999.0 # 距离模糊 return (b - 2) / 2.0 - 32.0 # dBZ def decode_vel(b, dop_res): if b 0: return -999.0 if b 1: return 999.0 if dop_res 2: # 枚举 2 0.5 m/s 分辨率 return (b - 2) / 2.0 - 63.5 return (b - 2) - 127.0 # 枚举 4 1.0 m/s 分辨率两个参数要分清b是原始字节值0 到 255dop_res是信息头里那个枚举值2 或 4不是分辨率本身。把 4 当成 1.0 直接拿去乘速度场会偏成负数。逐字节 Python 循环处理一个体扫要几十秒实际工程里都用 numpy 向量化一次算完一整条径向import numpy as np raw np.frombuffer(buf[128:128 460], dtypenp.uint8).astype(np.float32) ref (raw - 2) / 2.0 - 32.0 ref[raw 0] -999.0 # 先整体换算再把哨兵值盖回去 ref[raw 1] 999.0顺序很重要必须整体换算完再覆盖哨兵值。反过来先覆盖再换算-999 会被公式再减一次 32最后变成 -1031下游做统计时这些值会被当成极端强回波。注意-999.0和999.0这两个哨兵值是从程序侧约定来的不是文件里的原始值。文件里只有 0 和 1映射到浮点数组时才变成这两个数。4. 径向、仰角与体扫11 个 PPI 为什么只剩 9 层4.1 径向状态码的语义每条径向的信息头里有个 2 字节的状态字段取值 0 到 40 是该仰角第一条径向1 是中间径向2 是该仰角最后一条3 是体扫第一条4 是体扫最后一条。这套编码把“层”的边界信息直接写进了数据本身解析时不需要靠方位角回绕去猜。状态 1 是最常见的值一整条径向里绝大部分都是它。真正有用的是 0、2、3、40 和 2 标出一个仰角的起止3 和 4 标出整个体扫的起止。体扫第一条径向的状态既是 3 又是该仰角的第一条这种语义重叠在实现上要注意判断层边界时优先看 0/2判断文件边界时看 3/4。用状态码切层比用方位角判断可靠得多。方位角在正北附近会从 359 跳回 0靠“角度变小”来判断层结束遇到噪声或者个别径向缺角就会误切。4.2 重复仰角合并0.5 度扫两次算一层这是整份文档里最反直觉的一条。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 各只记一层所以Elvation[]数组里只有 9 个有效元素。低层扫两遍是有物理原因的低仰角受地物遮挡和波束展宽影响最大重复采样能提高近地面的数据完整性也给后续的杂波抑制留出冗余。但对上层应用来说同一仰角的两轮数据没必要分成两层合并成一层更符合“一个体扫若干仰角层”的直觉模型。合并的实现要点是不能简单按角度去重然后丢掉后一份得决定保留哪一份。常见做法是保留第一次出现的先到先得后面的覆盖或者丢弃也有做法按信噪比择优但这需要额外判据文档里没给。我一般按先到先得处理逻辑最简单也最容易和别人的结果对上。# 按 0.1 度量化后去重保留首次出现的顺序 seen {} for rad in radial_list: # 体扫自低仰角到高仰角排列 key round(rad[elevation], 1) if key not in seen: seen[key] len(seen) Elvation[seen[key]] rad[elevation] # VCP21 下 seen 的长度是 9不是 11round(..., 1)这一步不能省。仰角是定点编码换算出来的浮点同一次扫描的两条径向算出来可能有 1e-6 级别的差异直接拿浮点做字典键会得到 11 个“不同”的仰角。量化到 0.1 度既吸收了浮点误差又不会把 0.5 和 1.5 误并成一层。4.3 每度一个径向的重采样原始径向的方位间隔并不均匀受天线转速和触发时序影响可能在 0.9 到 1.1 度之间浮动。程序侧约定“每度保存一个径向”也就是把方位轴固定成 360 格MaxRads取 360。这是一次降采样把不均匀的原始径向映射到均匀网格上。映射方式默认是就近取值——哪条原始径向的方位角最接近当前整度就用哪条填进去。更讲究的做法是线性插值或者按波束宽度加权但文档给的数组结构VolRef[MaxCuts][MaxRads][RGates]是规整的三维数组说明它默认用就近取值。重采样带来的直接后果是分辨率损失。原始方位采样可能比 1 度更密压到 360 格之后细节被抹掉了一部分但换来的是数组规整、索引简单、绘图时不需要额外的坐标变换。这是典型的“用精度换工程便利”在体扫数据这种体量下是划算的。4.4 数组落地与波段切换程序侧给的数组定义是理解整个格式的钥匙float VolRef[20][360][460]; // 反射率dBZ float VolVel[20][360][920]; // 径向速度m/s float VolSpw[20][360][920]; // 谱宽m/s float Elvation[20]; // 各层仰角度第一维 20 是最大层数MaxCuts第二维 360 是方位数每度一个第三维是距离库数。无效数据填 -999.0距离折叠填 999.0。切到 C 波段只需要改头文件里的三个常量反射率 460 改 800速度 920 改 1600谱宽 920 改 1600。这个设计把波段差异压缩成了三个数字解析逻辑一行都不用动——因为 S 波段和 C 波段的字段布局、编码公式完全一致只有库数不同。// S 波段 const int RGates 460; const int VGates 920; const int WGates 920; // C 波段只改这三行 // const int RGates 800; // const int VGates 1600; // const int WGates 1600;但改常量之前必须先确认文件真的是 C 波段。库数字段55-56、57-58就在信息头里读出来对一下比靠文件名猜靠谱得多。混用会切出长度不对的数组短了会越界长了会读进保留位。5. 常见问题与排查五个真实踩过的坑5.1 字节序与偏移类问题现象方位角序列杂乱无章画出来的径向像随机散开的扇形但程序没有任何异常。原因多字节字段按小端解析。struct.unpack(H, ...)默认用本机字节序在 x86 上就是小端而基数据是大端。解决所有多字节解包强制加前缀并在解析入口做一次量程断言——方位角和仰角换算后必须落在 0 到 360 之间超出就立即报错别让它悄悄流到下游。现象反射率数据整体偏移了 1 个库图上的强回波位置比实际近了 1 公里。原因把 1 基偏移直接当 0 基切片用buf[129:589]实际取到的是从第 130 字节开始的数据少读一个字节、多读一个保留位。解决把偏移表写成常量并在代码里统一减 1或者干脆全部改用三个数据指针来定位从根上绕开 1 基和 0 基的手工换算。5.2 量化与哨兵值类问题现象整场速度值恰好是真值的一半或者整体偏了 0.5 米/秒但空间分布看起来完全正常。原因忽略了信息头 71-72 字节的多普勒速度分辨率枚举一律按 0.5 米/秒的公式解而实际文件是 1.0 米/秒分辨率。解决解析速度之前先读dop_res等于 2 走(b-2)/2-63.5等于 4 走(b-2)-127。这个字段是每条径向都带的别嫌重复逐条读。现象统计反射率均值时得到 -1031 这样的荒谬数字或者强回波识别把大片区域标成极强回波。原因哨兵值覆盖和公式换算的顺序反了。先把 0 和 1 写成 -999 和 999再做(x-2)/2-32哨兵值被二次换算。解决永远先整体向量化换算再用布尔掩码把 0 和 1 对应的位置盖成 -999.0 和 999.0。做完之后断言数组里不存在小于 -100 或大于 100 的值。5.3 仰角与库数类问题现象VCP21 模式的文件只解出 9 层和文档里写的“16 层仰角”对不上怀疑漏读。原因把 VCP 模式编号当成仰角层数。11 是降水模式 16 层、21 是降水模式 14 层、31 是晴空模式 8 层、32 是晴空模式 7 层——这些数字是扫描模式的编号不是层数。而且低层重复扫描会合并21 模式的 11 次 PPI 实际只有 9 个有效仰角。解决层数以Elvation[]数组里实际去重后的元素个数为准别信 VCP 编号。校验方法是拿信息头里的“体扫内仰角数”字段对一遍虽然那个字段记的也可能是重复扫描前的数量两边不一致是正常的。现象C 波段文件用 S 波段的库数解析程序不崩但图像上出现规则横条纹。原因S 波段反射率 460 库、C 波段 800 库用 460 去切 800 库的数据只读了前 57%剩下 43% 被当成了速度区的开头三块数据整体错位。解决从信息头 55-56、57-58 字节读出实际库数用它去切片而不是用常量。常量只用来开数组切片长度必须来自文件本身。这一条是所有踩坑记录里最容易反复犯的因为错位后的图像“看起来还行”。6. 设计取舍为什么是定点整数和哨兵值这套格式处处透着一股“省”的味道。一个 S 波段体扫9 层、360 个方位、每方位 2300 个库全用浮点存要接近 30 MB用字节存不到 8 MB。上世纪九十年代的链路带宽和处理内存这 4 倍的差距是能不能实时传输的问题不是优化问题。所以反射率用 0.5 dBZ 的刻度、速度用 0.5 米/秒的刻度都是先把物理精度定在接收机噪声水平附近再用最少字节数把它表达出来。哨兵值的选择也是同一个思路的延伸。用 -999 和 999 而不是 NaN表面看是土办法实际上是有意为之NaN 在比较运算里恒为假data threshold这种筛选会静默丢掉所有 NaN 位置排查时非常隐蔽而 -999 就是个普通浮点数能在数组里被直接看见、被断言拦住这在没有成熟调试工具的年代是保命的特性。代价是 -999 有可能和真实数据撞车——虽然现实中不会出现 -999 dBZ但这个约定要求下游所有统计都必须先过滤一旦漏掉就是错一个量级的均值。每条径向都带一份完整的 128 字节信息头也是同样的取舍。9 层 360 方位就是 3240 条径向多存 400 多 KB占比不到 6%。换来的是每条径向自描述任意跳到一个位置读 128 字节就知道自己在哪一层、哪个方位、用什么分辨率不需要先扫全文件建索引。这种“冗余换随机访问”的设计在流式处理和断点续读场景下价值很大。如果要验证自己的解析器对不对我一般会做一个往返测试把解出来的浮点值按公式反向编码回字节和原始字节逐位比对。反射率和谱宽的公式是双射的能完全还原速度因为有两个哨兵值占位还原时要跳过 0 和 1。往返一致说明偏移、字节序、量化公式、库数四项全部对齐比对着文档逐行检查快得多。也是从那次把减 2 当成笔误改掉、结果整场反射率偏移 1 dBZ 之后我每次接手一个新的二进制格式都强制先跑一遍往返测试再写业务逻辑。看着傻但它能把“看起来对”和“真的对”分开。希望帮到你。本文还有配套的精品资源点击获取