4. 广播消息格式详解
Remote ID 的广播帧并不是一段随意拼接的字节流，而是由 ASTM F3411 定义的一组结构化消息。每条消息都带有固定的消息类型（Message Type）和协议版本，接收端先解析类型，再按对应字段布局读取数据。理解这些消息的字段含义，是开发广播模块、调试接收解析、排查“为什么对方收不到我的 ID”这类问题的基础。
本节聚焦六类最常用的广播消息：Basic ID、Location/Vector、Authentication、Self-ID、System 和 Operator ID。它们各自承担不同的信息职责，组合起来才构成一个完整的“可被识别、可被定位、可被追溯”的无人机身份广播。
核心原理：消息头 + 类型化载荷
所有广播消息共享一个公共消息头，其中最关键的是 Message Type 字段。接收端读取该字段后，才能知道后续字节应按哪种结构解析。例如 Message Type = 0 表示 Basic ID，Message Type = 1 表示 Location/Vector，Message Type = 2 表示 Authentication，Message Type = 3 表示 Self-ID，Message Type = 4 表示 System，Message Type = 5 表示 Operator ID。协议版本字段则用于兼容不同版本的规范差异。
这种“先看类型、再读字段”的设计，使广播帧可以灵活组合不同消息，而不必强制每条帧都携带全部信息。开发者需要特别注意：字段的字节序、有符号/无符号、缩放因子（如纬度乘以 1e-7）都必须严格按规范处理，否则解析出的位置会完全错误。
方法流程：从字节流到可用信息
- 接收广播帧，读取消息头，确认协议版本与消息类型。
- 按消息类型查表，确定该消息的字段布局与长度。
- 逐字段解析：Basic ID 读取 ID Type、UA Type、UAS ID；Location/Vector 读取经纬度、高度、速度、航向、时间戳。
- 对数值字段应用缩放因子，还原为物理量。
- 以 UAS ID 为主键，将同一架无人机的多条消息关联成一条完整记录。
- 若存在 Authentication 消息，验证签名与时间戳，标记该记录的可信等级。
字段速查表
| 消息类型 | 关键字段 | 典型长度 | 工程要点 |
|---|---|---|---|
| Basic ID | ID Type、UA Type、UAS ID | 约 25 字节 | UAS ID 需补零或截断到 20 字节 |
| Location/Vector | 纬度、经度、高度、速度、航向、时间戳 | 约 30 字节 | 纬度/经度缩放 1e-7，注意有符号 |
| Authentication | 认证类型、签名数据、时间戳 | 可变 | 签名长度影响广播帧总长 |
| Self-ID | 描述类型、描述文本 | 约 26 字节 | 文本最长 23 字节，UTF-8 编码 |
| System | 运行位置、区域计数、分类 | 约 20 字节 | 起飞点坐标用于建立空间基准 |
| Operator ID | 运营人 ID 类型、运营人 ID | 约 22 字节 | 与 Basic ID 的 UAS ID 区分开 |
案例场景：一次完整的广播解析
假设一架多旋翼无人机正在执行电力巡检任务。它的广播帧中同时包含以下消息：Basic ID 声明序列号为“1596F3A2B7C8D9E0”，UA Type 为多旋翼；Location/Vector 给出纬度 30.1234567、经度 120.7654321、几何高度 85 米、水平速度 5.2 m/s、航向 270°；Self-ID 描述为“电力巡检”；System 给出起飞点坐标；Operator ID 声明运营人注册号为“OP-2024-00123”；Authentication 携带 UAS ID 签名。
接收端解析后，可以立即知道：这是一架多旋翼无人机，正在以 5.2 m/s 向西飞行，高度 85 米，执行电力巡检任务，运营人是某注册单位，且身份签名有效。如果缺少 Operator ID，接收端只能知道“机器是谁”，却无法追责到运营人；如果缺少 Location/Vector，则只能知道身份，无法判断是否侵入禁飞区。
示例：解析 Location/Vector 的关键代码片段
lat = int.from_bytes(payload[0:4], 'little', signed=True) * 1e-7
lon = int.from_bytes(payload[4:8], 'little', signed=True) * 1e-7
alt = int.from_bytes(payload[8:10], 'little', signed=False) * 0.5 - 1000
speed_h = int.from_bytes(payload[10:12], 'little', signed=False) * 0.25
heading = int.from_bytes(payload[12:14], 'little', signed=False) * 1.0
# 注意：不同协议版本字段偏移可能不同，务必以规范为准常见误区：很多开发者只实现 Basic ID 和 Location/Vector，认为“能识别、能定位就够了”。但在合规场景中，缺少 Operator ID 会导致无法追溯运营人；缺少 Authentication 则无法证明消息未被篡改。另一个高频错误是忽略时间戳字段，导致接收端把过期位置当成实时位置处理。
复盘：消息设计的工程取舍
广播带宽有限，因此每条消息都必须在“信息完整”和“帧长可控”之间取舍。Basic ID 和 Location/Vector 更新频率最高，通常每秒多次广播；Self-ID、System、Operator ID 变化较慢，可以降低广播频率；Authentication 的签名数据较长，若每帧都携带会显著增加带宽占用，因此常采用周期性广播或按需广播策略。
开发广播模块时，建议先确定消息组合策略：哪些消息必须每帧携带，哪些可以低频携带，哪些可以省略。然后再按规范逐字段实现编码与解码，并用真实接收设备做端到端验证。只有把六类消息的字段含义和组合关系都吃透，才能做出既合规又稳定的 Remote ID 广播模块。