无人机Remote ID Beacon 帧字段详解

 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-12帧控制字段80 00管理帧(类型 = 0),子类型 = Beacon 帧(0x8000),无加密、无分片,符合信标帧标准。
2-32持续时间00 00标准填充值,用于避免帧冲突,无特殊业务含义。
4-96目的地址FF FF FF FF FF FF广播地址,Beacon 帧需向所有设备发送,确保周边接收端能捕获。
10-156源地址60 60 1F B0 13 D0发送设备 MAC 地址(推测为无人机的无线模块 MAC,或其关联 AP 的 MAC)。
16-216BSSID60 60 1F B0 13 D0基本服务集标识,与源地址相同→基础设施模式(Beacon 帧由 AP 发送,BSSID=AP MAC,源地址 = AP MAC,非自组织模式)。
22-232序列控制00 00帧序列号(0)+ 分片号(0),为初始帧,无分片。
24-318时间戳10 4F F1 1A 00 00 00 00设备内部计时戳(单位:微秒),用于同步接收端时钟,无 UTC 映射意义。
32-332信标间隔A0 00小端序转换为0x00A0=160,单位为 “1024 微秒”,计算为160×1024=163840微秒=0.16384秒)。
34-352能力信息20 04二进制00100000 00000100→支持 ESS(基础设施网络)、支持隐私保护(WEP 加密),无其他扩展能力。

3. 信息元素(IE)解析(36-146 字节,共 111 字节)

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

3.1 SSID 信息元素(36-61 字节,共 26 字节)

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

3.2 OpenDroneID 供应商特定 IE(62-146 字节,共 85 字节)

偏移(字节)长度(字节)字段十六进制值说明
621IE 类型DD供应商特定 IE(VSIE),标识后续为厂商自定义数据。
631IE 长度53十六进制0x53=83字节,对应后续数据长度(64-146 字节共 83 字节,62+1+83=146,范围正确)。
64-663OUIFA 0B BC供应商标识(ASD-STAN,无人机行业标准组织)
671App Code0DOpenDroneID 应用代码(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 字节)

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

4.2 子消息 1:Basic ID 消息(72-96 字节,类型 0,共 25 字节)

偏移(字节)长度(字节)字段十六进制值说明
721消息类型 + 协议版本01高 4 位0x0=0Basic ID(基本标识消息);低 4 位0x1F3411-20 (1.1)
731ID 类型 + 无人机类型12高 4 位0x1Serial Number (ANSI/CTA-2063-A)(序列号类型);低 4 位0x2Helicopter (or Multirotor)(多旋翼)。
74-9320无人机序列号31 35 38 31 46 35 59 48 58 32 33 39 48 30 30 32 34 35 30 41ASCII 转换为1581F5YHX239H002450A,与 SSID 前缀一致,为无人机唯一序列号。
94-963保留字段00 00 00协议预留,无数据,填充 0。

4.3 子消息 2:Location/Vector 消息(97-121 字节,类型 1,共 25 字节)

偏移(字节)长度(字节)字段十六进制值说明
971消息类型 + 协议版本11高 4 位0x1=1Location/Vector(位置消息);低 4 位0x1F3411-20 (1.1)
981状态 + 标志16高 4 位0x1On Ground(地面状态,未起飞);低 4 位0x6(二进制0110)→bit2=1:高度类型AGL(离地高度);bit1=1:东西方向West(西向);bit0=0:速度乘数0.25
991方向B5原始值0xB5=181°,结合西向标志→181+180=361°361°=Unknown
1001水平速度00原始值0× 乘数0.25=0 m/s(地面静止)。
1011垂直速度00原始值0×0.5 m/s(协议单位)=0 m/s(无升降)。
102-1054无人机纬度AA 10 8D 12小端序重组为12 8D 10 AA0x128D10AA=311230730,协议单位1e-7 °311230730÷1e7=31.123073°(北纬)。
106-1094无人机经度5E 64 77 3D小端序重组为3D 77 64 5E0x3D77645E=10312346541031234654÷1e7=103.1234654°(东经)。
110-1112气压高度3E 08小端序重组为08 3E0x083E=2110,协议公式(值×0.5)-10002110×0.5-1000=55米
112-1132大地高度35 08小端序重组为08 350x0835=21012101×0.5-1000=50.5米
114-1152AGL 高度D0 07小端序重组为07 D00x07D0=20002000×0.5-1000=0米(地面状态)。
1161精度组合4B高 4 位0x4vertAccuracies[4]=<10 m(垂直精度);低 4 位0xBhorizAccuracies[11]=<3 m(水平精度)。
1171气压 / 速度精度04高 4 位0x0vertAccuracies[0]>=150 m(气压高度精度);低 4 位0x4speedAccuracies[4]=<0.3 m/s(速度精度)。
118-1192小时内时间戳DB 01小端序重组为01 DB0x01DB=475,协议单位0.1秒475×0.1=47.5秒
1201时间戳精度0A低 4 位0xA0xA×0.1=1.0秒(时间戳精度);高 4 位保留(0x0)。
1211保留字段00协议预留。

4.4 子消息 3:System 消息(122-146 字节,类型 4,共 25 字节)

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

5. 帧尾部:填充位与 FCS(147-150 字节,共 4 字节)

此部分为 802.11 帧强制字段:

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

Read more

前端打工人速通:用JavaScript玩转GIS地图开发(附避坑指南+实战技巧)

前端打工人速通:用JavaScript玩转GIS地图开发(附避坑指南+实战技巧)

前端打工人速通:用JavaScript玩转GIS地图开发(附避坑指南+实战技巧) * 前端打工人速通:用JavaScript玩转GIS地图开发(附避坑指南+实战技巧) * 地图这玩意儿,早就不是大厂的专利了 * 选库如选对象,合适最重要 * 坐标系:前端GIS的终极噩梦 * GeoJSON:地图界的JSON,但别乱用 * 那些常见的地图需求,到底怎么实现? * 性能翻车现场:从3帧到60帧的救赎 * 调试地图:一场玄学的修行 * 骚操作:让老板直呼高级的玩法 * 写在最后:地图开发不是体力活,是技术活 前端打工人速通:用JavaScript玩转GIS地图开发(附避坑指南+实战技巧) 说实话,我第一次接到地图需求的时候,内心是崩溃的。老板拍着我的肩膀说:"小王啊,这个需求很简单,就是在页面上加个地图,然后显示几个标记点。"我当时天真地以为,这不就是引入个<script>标签,调个API的事儿吗?结果三天后,

别再手动切图!用 ClaudeCode+Figma-MCP 实现 UI 设计 1:1 前端还原

使用 Figma-MCP 实现设计还原 Figma-MCP(Measure Copy Paste)是 Figma 的插件,能够快速提取设计稿中的间距、颜色、尺寸等参数,避免手动测量。安装后选中元素即可查看属性,按 Alt 键复制数值,直接粘贴到代码中。 配置 ClaudeCode 生成代码 ClaudeCode 是 Claude 的代码生成功能,支持根据设计参数输出前端代码。在对话中描述需求并附上 Figma-MCP 提取的数据,例如: 生成一个 React 按钮组件,参数如下: - 宽度:120px - 高度:40px - 背景色:#3B82F6 - 圆角:8px - 文字:"

前端动画:别再用 jQuery animate 了

前端动画:别再用 jQuery animate 了 毒舌时刻 这动画效果做得跟幻灯片似的,一点都不流畅。 各位前端同行,咱们今天聊聊前端动画。别告诉我你还在使用 jQuery animate,那感觉就像在没有减震器的情况下开车——能开,但颠簸得要命。 为什么你需要现代前端动画 最近看到一个项目,动画效果卡顿,代码复杂难以维护。我就想问:你是在做动画还是在做卡顿展示? 反面教材 // 反面教材:使用 jQuery animate // index.html <!DOCTYPE html> <html> <head> <title>jQuery Animation</title> <script src=

把 Core Web Vitals 变成可控变量:理解它与 Google 搜索结果的关系,并把体验优化落到工程细节里

把 Core Web Vitals 变成可控变量:理解它与 Google 搜索结果的关系,并把体验优化落到工程细节里

Core Web Vitals 是一组面向真实用户体验的指标体系,用来衡量页面在加载性能、交互响应、视觉稳定性这三件事上做得好不好。它并不是一套只在实验室里跑分的理论指标,而是尽量贴近真实用户在真实设备、真实网络、真实使用路径下的体感数据。Google 也明确提到:Core Web Vitals 会被其排名系统使用,站点想在搜索里长期稳定表现、同时让用户体验更好,应该把这些指标做到 Good 水平,不过分数好并不等价于一定排名第一,因为页面体验之外还有很多更核心的排序因素。(Google for Developers) 这篇文章会把 LCP、INP、CLS 三个指标拆开讲清楚:它们分别在衡量什么、阈值如何定义、为什么同一个站点在不同工具里看见的数会不一样;同时给出足够工程化的落地路径:从观测、定位、验证,到把优化写进交付流程里,做到每次发布都在向 Good 靠拢。 一条主线:Core Web Vitals 衡量的是体感,不是某个单点性能数据 很多团队做性能优化会掉进两个常见坑: