无人机Remote ID Beacon 帧字段详解

Ne0inhk

23 Mar 2026 — 9 min read

 80 00 00 00 FF FF FF FF FF FF 60 60 1F B0 13 D0 60 60 1F B0 13 D0 00 00 10 4F F1 1A 00 00 00 00 A0 00 20 04 00 18 52 49 44 2D 31 35 38 31 46 35 59 48 58 32 33 39 48 30 30 32 34 35 30 41 DD 53 FA 0B BC 0D B0 F1 19 03 01 12 31 35 38 31 46 35 59 48 58 32 33 39 48 30 30 32 34 35 30 41 00 00 00 11 16 B5 00 00 AA 10 8D 12 5E 64 77 3D 3E 08 35 08 D0 07 4B 04 DB 01 0A 00 41 09 98 0F 8D 12 A5 64 77 3D 01 00 00 00 00 00 00 01 1A 08 0F 45 BF 0C 00 00 78 56 AD

以上为抓取无人机Remote ID的原始16进制数据(部分位置数据修改)

802.11 Beacon 帧 + OpenDroneID 协议完整解析（151 字节，0-150 索引）

1. 帧类型与整体结构

十六进制数据为802.11 管理帧（Beacon 帧），承载 OpenDroneID 协议数据（“Remote ID”，协议标准名称为 OpenDroneID）。帧结构符合 IEEE 802.11-2020 规范，通过供应商特定信息元素（VSIE，类型 0xDD） 嵌入无人机标识、位置、操作者信息，总长度 151 字节（0-150 索引），无数据缺失。

2. 帧头部解析（0-35 字节，共 36 字节）

偏移（字节）	长度（字节）	字段	十六进制值	说明
0-1	2	帧控制字段	`80 00`	管理帧（类型 = 0），子类型 = Beacon 帧（0x8000），无加密、无分片，符合信标帧标准。
2-3	2	持续时间	`00 00`	标准填充值，用于避免帧冲突，无特殊业务含义。
4-9	6	目的地址	`FF FF FF FF FF FF`	广播地址，Beacon 帧需向所有设备发送，确保周边接收端能捕获。
10-15	6	源地址	`60 60 1F B0 13 D0`	发送设备 MAC 地址（推测为无人机的无线模块 MAC，或其关联 AP 的 MAC）。
16-21	6	BSSID	`60 60 1F B0 13 D0`	基本服务集标识，与源地址相同→基础设施模式（Beacon 帧由 AP 发送，BSSID=AP MAC，源地址 = AP MAC，非自组织模式）。
22-23	2	序列控制	`00 00`	帧序列号（0）+ 分片号（0），为初始帧，无分片。
24-31	8	时间戳	`10 4F F1 1A 00 00 00 00`	设备内部计时戳（单位：微秒），用于同步接收端时钟，无 UTC 映射意义。
32-33	2	信标间隔	`A0 00`	小端序转换为`0x00A0=160`，单位为 “1024 微秒”，计算为`160×1024=163840微秒=0.16384秒`）。
34-35	2	能力信息	`20 04`	二进制`00100000 00000100`→支持 ESS（基础设施网络）、支持隐私保护（WEP 加密），无其他扩展能力。

3. 信息元素（IE）解析（36-146 字节，共 111 字节）

帧头部后为 IE 字段，包含 SSID 和 OpenDroneID 核心数据，IE 结构遵循 “类型（1 字节）+ 长度（1 字节）+ 数据（长度值字节） ” 规范。

3.1 SSID 信息元素（36-61 字节，共 26 字节）

偏移（字节）	长度（字节）	字段	十六进制值	说明
36	1	IE 类型	`00`	标准 IE 类型，标识后续为 SSID 字段。
37	1	IE 长度	`18`	十六进制`0x18=24`字节，对应 SSID 数据长度（与后续 38-61 字节共 24 字节匹配）。
38-61	24	SSID	`52 49 44 2D 31 35 38 31 46 35 59 48 58 32 33 39 48 30 30 32 34 35 30 41`	ASCII 转换为`RID-1581F5YHX239H002450A`，为无人机的 “远程标识关联 ID”，非直接序列号（序列号在 Basic ID 消息中）。

3.2 OpenDroneID 供应商特定 IE（62-146 字节，共 85 字节）

偏移（字节）	长度（字节）	字段	十六进制值	说明
62	1	IE 类型	`DD`	供应商特定 IE（VSIE），标识后续为厂商自定义数据。
63	1	IE 长度	`53`	十六进制`0x53=83`字节，对应后续数据长度（64-146 字节共 83 字节，62+1+83=146，范围正确）。
64-66	3	OUI	`FA 0B BC`	供应商标识（ASD-STAN，无人机行业标准组织）
67	1	App Code	`0D`	OpenDroneID 应用代码（0x0D）

4. OpenDroneID 消息解析（68-146 字节，共 79 字节）

64-67 字节为 “OUI（3）+App Code（1）” 共 4 字节，68 字节开始为 OpenDroneID 消息包，总长度146-68+1=79字节（与 IE 长度 83-4=79 匹配）。

4.1 消息包头部（68-71 字节，共 4 字节）

偏移（字节）	长度（字节）	字段	十六进制值	说明
68	1	消息计数器	`B0`	递增计数器（0xB0=176），用于接收端去重或排序，无其他业务含义。
69	1	消息类型 + 协议版本	`F1`	高 4 位`0xF=15`→`Message Pack`（消息包，含多个子消息）；低 4 位`0x1`→`F3411-20 (1.1)`（协议版本）。
70	1	子消息大小	`19`	十六进制`0x19=25`字节，单个子消息固定长度（符合 OpenDroneID 标准，所有子消息均为 25 字节）。
71	1	子消息数量	`03`	共 3 个子消息（类型 0、1、4），无类型 2/3（可选消息，非强制发送）。

4.2 子消息 1：Basic ID 消息（72-96 字节，类型 0，共 25 字节）

偏移（字节）	长度（字节）	字段	十六进制值	说明
72	1	消息类型 + 协议版本	`01`	高 4 位`0x0=0`→`Basic ID`（基本标识消息）；低 4 位`0x1`→`F3411-20 (1.1)`。
73	1	ID 类型 + 无人机类型	`12`	高 4 位`0x1`→`Serial Number (ANSI/CTA-2063-A)`（序列号类型）；低 4 位`0x2`→`Helicopter (or Multirotor)`（多旋翼）。
74-93	20	无人机序列号	`31 35 38 31 46 35 59 48 58 32 33 39 48 30 30 32 34 35 30 41`	ASCII 转换为`1581F5YHX239H002450A`，与 SSID 前缀一致，为无人机唯一序列号。
94-96	3	保留字段	`00 00 00`	协议预留，无数据，填充 0。

4.3 子消息 2：Location/Vector 消息（97-121 字节，类型 1，共 25 字节）

偏移（字节）	长度（字节）	字段	十六进制值	说明
97	1	消息类型 + 协议版本	`11`	高 4 位`0x1=1`→`Location/Vector`（位置消息）；低 4 位`0x1`→`F3411-20 (1.1)`。
98	1	状态 + 标志	`16`	高 4 位`0x1`→`On Ground`（地面状态，未起飞）；低 4 位`0x6`（二进制`0110`）→bit2=1：高度类型`AGL`（离地高度）；bit1=1：东西方向`West`（西向）；bit0=0：速度乘数`0.25`。
99	1	方向	`B5`	原始值`0xB5=181°`，结合西向标志→`181+180=361°`，`361°=Unknown`。
100	1	水平速度	`00`	原始值`0`× 乘数`0.25=0 m/s`（地面静止）。
101	1	垂直速度	`00`	原始值`0`×`0.5 m/s`（协议单位）=0 m/s（无升降）。
102-105	4	无人机纬度	`AA 10 8D 12`	小端序重组为`12 8D 10 AA`→`0x128D10AA=311230730`，协议单位`1e-7 °`→`311230730÷1e7=31.123073°`（北纬）。
106-109	4	无人机经度	`5E 64 77 3D`	小端序重组为`3D 77 64 5E`→`0x3D77645E=1031234654`→`1031234654÷1e7=103.1234654°`（东经）。
110-111	2	气压高度	`3E 08`	小端序重组为`08 3E`→`0x083E=2110`，协议公式`(值×0.5)-1000`→`2110×0.5-1000=55米`。
112-113	2	大地高度	`35 08`	小端序重组为`08 35`→`0x0835=2101`→`2101×0.5-1000=50.5米`。
114-115	2	AGL 高度	`D0 07`	小端序重组为`07 D0`→`0x07D0=2000`→`2000×0.5-1000=0米`（地面状态）。
116	1	精度组合	`4B`	高 4 位`0x4`→`vertAccuracies[4]=<10 m`（垂直精度）；低 4 位`0xB`→`horizAccuracies[11]=<3 m`（水平精度）。
117	1	气压 / 速度精度	`04`	高 4 位`0x0`→`vertAccuracies[0]>=150 m`（气压高度精度）；低 4 位`0x4`→`speedAccuracies[4]=<0.3 m/s`（速度精度）。
118-119	2	小时内时间戳	`DB 01`	小端序重组为`01 DB`→`0x01DB=475`，协议单位`0.1秒`→`475×0.1=47.5秒`。
120	1	时间戳精度	`0A`	低 4 位`0xA`→`0xA×0.1=1.0秒`（时间戳精度）；高 4 位保留（0x0）。
121	1	保留字段	`00`	协议预留。

4.4 子消息 3：System 消息（122-146 字节，类型 4，共 25 字节）

偏移（字节）	长度（字节）	字段	十六进制值	说明
122	1	消息类型 + 协议版本	`41`	高 4 位`0x4=4`→`System`（系统消息）；低 4 位`0x1`→`F3411-20 (1.1)`
123	1	系统标志	`09`	二进制`00001001`→高 4 位`0x0`（系统状态：正常运行）；低 4 位`0x9`（保留，非原 “系统状态 + 保留”，协议无低 4 位定义）。
124-127	4	操作者纬度	`98 0F 8D 12`	小端序重组为`12 8D 0F 98`→`0x128D0F98=311234456`→`311234456÷1e7=31.1234456°`（北纬）。
128-131	4	操作者经度	`A5 64 77 3D`	小端序重组为`3D 77 64 A5`→`0x3D7764A5=1031234725`→`1031234725÷1e7=103.1234725°`（东经）。
132	1	操作者高度类型	`01`	`OperatorLocTypes[1]=Dynamic`（动态位置，非原 “大地水准面”）。
133-134	2	操作者高度	`00 00`	小端序`0x0000=0`，协议单位`0.5米`→`0×0.5=0米`（相对大地水准面）。
135-138	4	系统时间戳	`00 01 1A 08`	小端序重组为`08 1A 01 00`→`0x081A0100=135921920`。OpenDroneID 协议系统时间戳 epoch 为`2019-01-01 00:00:00`（Unix 时间戳 1546272000），计算为1546272000`+135921920=1,682,193,920`。
139	1	无人机分类	`0F`	此处为分类字段，非类型字段。
140-145	6	保留字段	`45 0F 8D 12 A5 64`	协议预留，含厂商自定义数据（如硬件版本）。
146	1	保留字段	`45`	协议预留，填充 0x45，非原 “校验位”（校验位在帧尾部 FCS 中）。

5. 帧尾部：填充位与 FCS（147-150 字节，共 4 字节）

此部分为 802.11 帧强制字段：

偏移（字节）	长度（字节）	字段	十六进制值	说明
147-148	2	填充位	`00 00`	802.11 帧要求总长度≥2346 字节（无线传输最小帧长），此处为凑足长度的填充值，无业务含义。
149-150	2	FCS（帧校验序列）	`56 AD`	循环冗余校验（CRC-16），确保数据完整性（非原 “消息包校验位”）。

Flutter 组件 sw 的适配鸿蒙Harmony 实战 - 驾驭高性能微服务路由架构、实现鸿蒙端 HTTP 流量语义分发与逻辑守卫方案

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 sw 的适配鸿蒙Harmony 实战 - 驾驭高性能微服务路由架构、实现鸿蒙端 HTTP 流量语义分发与逻辑守卫方案前言在鸿蒙（OpenHarmony）生态的分布式业务网关、多端协同数据中转站以及需要实现极端细粒度接口管控的各种后端闭环应用开发中，“请求路由的执行效率与逻辑灵活性”是决定系统能否支撑起高并发访问请求的命门所在。面对包含上百个动态参数的 RESTful API 契约、需要针对鸿蒙手机、自研设备等不同终端执行差异化鉴权的复杂路由逻辑。如果仅仅依靠原始的 if-else 显式判定或性能低下的线性字符串匹配。不仅会导致路由分发的延迟随着接口数量增加而呈指数级上升，更会因为缺乏一套工业级的“语义化（Semantic）”路由映射规范。引发严重的服务逻辑归属混乱与权限越界风险。我们需要一种“语义分发、匹配自洽”的路由艺术。 sw（在 Shelf 生态中常指高效的 Switch/Router 增强件）是一套专注于实现极致性能与

Flutter 组件 mock_client 的适配鸿蒙Harmony 实战 - 驾驭 HTTP 协议级测试模拟、实现鸿蒙端离线环境下的接口断言与质量门禁方案

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.ZEEKLOG.net Flutter 组件 mock_client 的适配鸿蒙Harmony 实战 - 驾驭 HTTP 协议级测试模拟、实现鸿蒙端离线环境下的接口断言与质量门禁方案前言在鸿蒙（OpenHarmony）生态的大型分布式政务办公系统、极繁金融交易内核以及对交互逻辑边界有极致审计要求的各种工业级应用开发中，“测试的确定性”是架构设计的定海神针。面对包含多级鉴权、动态速率限制（Rate Limiting）且环境依赖极重的后端 API。如果仅仅依靠真实的沙箱网络环境进行逻辑验收。那么不仅会导致测试套件由于网络波动引发由于非预期超时导致的频繁“假失败（Flaky Tests）”，更会因为无法模拟极端错误分位（如：服务器 500 时特定的 Payload 反馈）产生严重的代码覆盖率黑洞。我们需要一种“契约自洽、逻辑伪造”的协议审计艺术。 mock_client（通常作为

Flutter 三方库 encrypter_plus 的鸿蒙化适配指南 - 打造工业级多重加密隔离、安全存储实战、鸿蒙级数据隐私专家

欢迎加入开源鸿蒙跨平台社区：https://openharmonycrossplatform.ZEEKLOG.net Flutter 三方库 encrypter_plus 的鸿蒙化适配指南 - 打造工业级多重加密隔离、安全存储实战、鸿蒙级数据隐私专家在鸿蒙跨平台应用处理用户核心资产、敏感通讯或离线隐私数据库时，单一的加密手段往往难以应对复杂的逆向工程攻击。我们需要一套功能全面、算法严谨且易于在鸿蒙端进行多层加固的方案。今天我们要深度解析的 encrypter_plus——一个集成了 AES、RSA、Salsa20 等多种主流算法的增强型加密工具集，正是帮你构建“数据保险柜”的核心组件。前言 encrypter_plus 是对经典 encrypt 库的功能增强与性能优化版。它提供了更直观的操作符抽象和更健壮的填充（Padding）机制。在鸿蒙端项目中，利用它你可以轻松实现前端文件加密、服务端通讯非对称握手以及本地敏感配置的字段级混淆，确保即使用户设备的物理文件被导出，数据依然处于不可读的“致密状态”。一、原理解析 / 概念介绍 1.1

ARM Linux 驱动开发篇--- pinctrl 子系统详解-- Ubuntu20.04

🎬 渡水无言：个人主页渡水无言 ❄专栏传送门：《linux专栏》《嵌入式linux驱动开发》《freertos专栏》 ⭐️流水不争先，争的是滔滔不绝 📚博主简介：第二十届中国研究生电子设计竞赛全国二等奖 |国家奖学金 | 省级三好学生 | 省级优秀毕业生获得者 | ZEEKLOG新星杯TOP18 | 半导纵横专栏博主 | 211在读研究生在这里主要分享自己学习的linux嵌入式领域知识；有分享错误或者不足的地方欢迎大佬指导，也欢迎各位大佬互相三连文章目录 * 前言 * 一、pandas是什么？ * 二、使用步骤 * 1.引入库 * 2.读入数据 * 总结前言在上一期的实战中，我们完成了基于设备树的 LED 驱动开发，但从底层逻辑来看，核心依旧是直接配置 LED 对应的 GPIO 寄存器 —— 这种开发方式，本质上和裸机驱动开发并无二致。 Linux 作为一套成熟、庞大的操作系统，其驱动框架的设计核心就是复用与简化。对于 GPIO 这类最基础、