3. Remote ID 广播协议基础
Remote ID 广播模块的本质，是把无人机的身份、位置、速度、起飞点、操控者位置等运行数据，按标准格式周期性地“喊”出去，让地面接收设备无需联网即可解析。理解这一过程，必须同时掌握三层内容：标准层（ASTM F3411 定义消息语义）、协议栈层（Open Drone ID 提供跨平台实现）、承载层（蓝牙 4/5 广播与 Wi-Fi NAN 提供无线传输通道）。三者缺一不可，任何一层理解偏差都会导致“发得出、收不到”或“收得到、解不开”。
一、ASTM F3411：消息语义与帧结构
ASTM F3411 是 Remote ID 的核心标准，它规定了广播式 Remote ID 的消息类型、字段布局和编码方式。广播帧采用紧凑的二进制结构，核心是 Message Pack：一个 25 字节的固定头部加上若干条消息体。每条消息以 1 字节的 Message Type 开头，常见类型包括：
- 0x0 Basic ID：无人机唯一标识，含 ID 类型（序列号、CAA 注册号、UTM UUID 等）和 ID 值。
- 0x1 Location/Vector：纬度、经度、高度、速度、航向、水平/垂直精度、时间戳。
- 0x2 Authentication：认证数据，用于防篡改和身份核验。
- 0x3 Self-ID：自由文本描述，如“航拍作业”“应急搜救”。
- 0x4 System：起飞点位置、操控者位置、区域计数、紧急状态。
- 0x5 Operator ID：操控者注册标识。
所有多字节字段采用小端序（Little-Endian），经纬度以 1e-7 度为单位的有符号整数存储，高度以 0.5 米为单位偏移编码。这意味着解析时必须严格按位偏移读取，不能依赖字符串分割。
二、Open Drone ID 协议栈：从标准到可运行代码
Open Drone ID 是 ASTM F3411 的开源参考实现，通常以 C 语言库形式提供，向上暴露编码/解码 API，向下对接蓝牙或 Wi-Fi 驱动。其典型数据流为：
应用层：填充 odid_UAS_Data 结构体
↓
编码层：encodeBasicIDMessage() / encodeLocationMessage()
↓
打包层：odid_message_pack() 生成 25 字节 Message Pack
↓
传输层：蓝牙广播 / Wi-Fi NAN 服务发现帧
↓
接收端：扫描 → 解包 → decode → 校验 → 展示开发中最容易出错的是结构体字段单位与标准单位不一致。例如 Open Drone ID 内部可能用 float 表示纬度，而编码时必须转换为 1e-7 度的 int32。若直接强转，会出现位置漂移数百米的问题。
三、蓝牙 4/5 广播机制：低功耗下的周期“喊话”
蓝牙 4/5 的广播（Advertising）是 Remote ID 最常用的承载方式。蓝牙 4.0 引入低功耗广播，蓝牙 5.0 将广播载荷从 31 字节扩展到 255 字节（LE Extended Advertising），使单帧可容纳更多 Remote ID 消息。
广播流程如下：
- 设备进入广播态，按 Advertising Interval（通常 100ms～1s）周期性发送广播包。
- 广播包包含 AD Structure：长度 + 类型 + 数据。Remote ID 使用 Manufacturer Specific Data（0xFF）或 Service Data（0x16）承载。
- 接收端处于扫描态，收到广播后按 ASTM F3411 解析 Message Pack。
- 蓝牙 5 的扩展广播支持 Primary + Secondary Channel，可传输更大载荷，但接收端必须支持 LE Extended Advertising 才能解析。
关键参数：广播间隔越短，实时性越好，但功耗越高；广播间隔越长，接收端越容易漏包。工程上常取 200ms～500ms 作为平衡点。
四、Wi-Fi NAN：另一种广播通道
Wi-Fi Neighbor Awareness Networking（NAN，又称 Wi-Fi Aware）是 Wi-Fi 联盟推出的邻近发现协议。它通过 Discovery Window 和 Service Discovery Frame 广播服务信息，天然适合承载 Remote ID。
与蓝牙广播相比，Wi-Fi NAN 的优势是传输距离更远、载荷更大，但功耗和硬件支持要求也更高。NAN 的工作机制是：设备在 Discovery Window 内同步唤醒，交换 Service Discovery Frame，帧内可携带 Remote ID 的 Message Pack。接收端无需连接 AP，即可直接解析。
| 对比项 | 蓝牙 4/5 广播 | Wi-Fi NAN |
|---|---|---|
| 典型载荷 | 31 字节（BT4）/ 255 字节（BT5） | 更大，适合多消息打包 |
| 广播间隔 | 100ms～1s 可调 | Discovery Window 周期同步 |
| 功耗 | 低 | 较高 |
| 接收端要求 | 支持 BLE 扫描 | 支持 Wi-Fi Aware |
| 适用场景 | 小型无人机、低功耗模块 | 远距离、大载荷场景 |
五、案例与误区复盘
案例：某开发板使用蓝牙 4.0 广播 Remote ID，接收端能扫描到设备名，却无法解析位置。排查发现：广播包被拆成两条 AD Structure，第二条被接收端丢弃。原因是蓝牙 4.0 单包仅 31 字节，而 Basic ID + Location 已超过 31 字节。解决方案是改用蓝牙 5 扩展广播，或分时发送不同消息类型。
常见误区：
- 误区一：认为“广播出去就一定有人收到”。实际接收端必须处于扫描态，且广播间隔与扫描窗口需匹配。
- 误区二：忽略字节序。ASTM F3411 规定小端序，若按大端序解析，经纬度会完全错误。
- 误区三：把 Open Drone ID 的结构体直接 memcpy 到广播包。结构体存在对齐填充，必须使用官方编码函数逐字段序列化。
- 误区四：蓝牙 5 扩展广播与蓝牙 4 兼容性混淆。旧接收端无法解析扩展广播，需做降级策略。
总结来看，Remote ID 广播模块开发的核心是“标准语义 + 协议栈实现 + 无线承载”三者的对齐。ASTM F3411 决定“说什么”，Open Drone ID 决定“怎么编解码”，蓝牙与 Wi-Fi NAN 决定“怎么发出去”。只有把这三层打通，才能让广播帧在真实空中被正确接收和解析。