Windows下用RTL-SDR搭建ADS-B飞机雷达：dump1090-win实战指南

简介dump1090-win 1.10.3010.14 是面向 Windows 平台的 ADS-B 信号接收与解析工具配合 RTL-SDR 软件无线电硬件使用适合航空爱好者、业余无线电玩家及飞行数据研究者。它整合了启动脚本、核心可执行程序、RTL-SDR 驱动及运行所需 DLL并在 public_html 中内置基于网页的实时地图展示模块可直观查看周边飞机的实时位置、高度、速度与航向等动态信息。压缩包共 18 个文件以 JavaScript、DLL、EXE 为主涵盖主程序、配套可视化界面、驱动库、批处理启动脚本、网页资源及说明文档整体大小仅 602KB轻量易部署。目前已有 832 人学习下载按 readme 指引配置后即可在 Windows 上搭建个人 ADS-B 监测站实时追踪空域飞行态势是了解 RTL-SDR 应用、ADS-B 协议与飞机数据可视化的实用入门工具。1. 花几十块买个电视棒让 Windows 变成飞机雷达站如果你第一次接触 dump1090-win多半和我当年一样手里有一根 RTL-SDR 电视棒想知道天上飞过的是哪架飞机结果在 Linux 教程里翻了半天发现 Windows 上根本没几条能照着敲的路径。dump1090-win 就是这个问题的答案——它是 ADS-B 解码器 dump1090 的 Windows 打包版专门接收民航飞机在 1090MHz 频率上持续广播的位置、高度、速度、航班号信息把一根几十块的 USB 接收器变成一套本地飞机雷达。这个方案能解决两件事一是让你在本机浏览器里看到实时航迹图二是把解码后的数据以 TCP 流、JSON 文件等形式输出给其他程序用。适合无线电爱好者、航空数据二次开发者以及想低成本搭建本地 ADS-B 数据源的从业者。需要注意这个版本在国内中文社区流传较广属于 dump1090-mutability 这条分支的 Windows 编译版老而稳定但发布较早后面我会专门讲它和现代版本在用法上的差异与坑。2. 从 1090MHz 到屏幕上的航迹解码链路与选型逻辑2.1 1090MHz 信号特征为什么天线位置比解码器更先决定成败ADS-B 信号使用 1090MHz 频段飞机上的应答机每秒约广播 6 到 10 条消息每条 112 比特包含 ICAO 地址、经纬度、高度、速度、航班号等字段。这个频率的特点是视距传播信号直线到达接收天线地球曲率和障碍物会直接挡住它。所以决定你能不能收到飞机的第一因素不是软件而是天线能不能「看见」天空。实际体验中在室内窗边用原厂小天线通常只能收到 30 到 80 公里内的飞机把天线放到屋顶或阳台外能稳定收到 200 公里以上。这不是玄学是 1090MHz 的物理特性。另外机场附近消息密度极高每秒可能超过 500 条消息解码器必须在下一个脉冲到来之前处理完当前消息这对解码算法的实时性提出了硬要求。2.2 解码链路从射频采样到航迹跟踪的四个环节dump1090-win 内部做的事情可以拆成四步。第一步是射频采样。RTL-SDR 接收器内置的 RTL2832U 芯片以 2.4MHz 采样率、8 位精度采集 1090MHz 附近的信号把射频模拟信号变成数字 IQ 数据。第二步是脉冲检测解码器在 IQ 数据流中寻找符合 Mode-S 脉冲特征的能量变化常用下降沿或幅度阈值方式触发。第三步是 PPM 解调Mode-S 使用脉冲位置编码1 微秒的短脉冲和 2 微秒的长脉冲分别代表 0 和 1解码器按脉冲位置还原 112 比特报文再用 24 位 CRC 做校验校验失败的消息直接丢弃。这三步都属于硬实时任务需要在微秒级完成。CPU 占用率高不是 bug恰恰说明它在满负荷干活。最后一步是报文解析与航迹跟踪把通过校验的报文按 DF 格式拆字段属于同一 ICAO 地址的消息会被合并成一条航迹持续推进位置、高度、速度的更新。2.3 为什么是 dump1090-win 而不是别的解码器当年 Windows 上可选的 ADS-B 解码工具主要有三类rtl1090、GNU Radio 搭配 gr-air-modes、以及 dump1090 的 Windows 移植版。rtl1090 是比较早的 Windows 专用解码器功能简单但多年不更新界面老旧数据输出能力弱。gr-air-modes 功能强但需要先搭一套 GNU Radio 环境学习成本和安装成本都高得不划算。dump1090-win 的优势在于单二进制文件即可运行不需要安装运行时环境解压后直接执行。它内置了 Web 服务器浏览器打开就能看到飞机列表和地图同时也监听多个 TCP 端口把解码后的数据以多种格式输出给后续二次开发留了很舒服的接口。对于大多数想在 Windows 上快速搭一套 ADS-B 接收站的用户这是最务实的选型。硬件端配合 RTL-SDR整套成本可以压在几十块钱和专业 Mode-S 接收器相比几乎可以忽略。3. 在 Windows 上跑通 dump1090-win驱动、启动命令与参数3.1 RTL-SDR 驱动为什么第一步不是运行程序而是换驱动RTL-SDR 原本是电视接收棒Windows 默认给它装的是 DVB-T 电视驱动。dump1090-win 通过 RTL-SDR 的 USB 接口直接访问设备必须先把驱动换成 WinUSB 或 libusb 兼容驱动这一步通常用 Zadig 工具的 WinUSB 驱动替换功能完成。操作步骤比较固定打开 Zadig在菜单里选择列出所有设备找到名为 Bulk-In, Interface (Interface 0) 的设备项右侧目标驱动选择 WinUSB点击 Replace Driver。需要注意的是这个设备项的名字与电视棒品牌无关认准 Bulk-In 字样即可。换驱动时先不要把电视棒拔掉替换完成后重新插拔一次再打开设备管理器确认设备名称已经变为 WinUSB 设备。提示如果你之前用其他 SDR 软件给电视棒装过专用驱动这里需要先卸载干净再替换否则 dump1090-win 会报找不到设备。3.2 最小启动命令与参数表把 dump1090-win 解压后放到C:\adsb目录这是为了避免中文或带空格路径带来的兼容性问题。打开 PowerShell 或命令提示符进入目录后最小可用命令是cd C:\adsb dump1090.exe --interactive --net --net-http-port 8080 --gain 42这个命令拆开来说--interactive打开文本交互界面屏幕上会有一张不断刷新的飞机数据表格方便确认解码是否正常--net开启网络输出功能这是后续从其他程序读取数据的前提--net-http-port 8080让内置 Web 服务器监听 8080 端口--gain 42把接收器增益固定在 42 附近这是我比较习惯的起点值具体合法值因接收棒型号而异可以在运行状态下用rtl_test -t查看。如果你不想让文本界面占据一个窗口或者打算把它作为后台服务跑改用dump1090.exe --net --net-http-port 8080 --quiet--quiet关闭标准输出日志进程在后台静默维持解码与网络服务。这时你依然可以通过http://127.0.0.1:8080访问前端页面确认状态。3.3 三个端口的用途与验证方法dump1090-win 开启--net后默认监听三个 TCP 端口各自承担的职责完全不同很多帖子把这三个端口混为一谈导致下游程序收到数据却解析不出来。用表格区分清楚端口协议内容适合下游30002AVR 原始文本每行一条十六进制消息如*8D3C6A2A...;自定义解析程序、调试30003SBS BaseStation 文本逗号分隔的规范化字段含航班号、经纬度、速度等Virtual Radar Server、自写脚本30005Beast 二进制紧凑二进制格式节省带宽tar1090、readsb 等生态工具验证方式很简单在另一终端执行telnet 127.0.0.1 30003如果能看到类似MSG,3,111,11111,3C6A2A,...的行在持续输出说明解码和网络链路都正常。看到*8D开头、以分号结尾的十六进制行则说明 30002 端口在正常工作。3.4 从临时运行到常驻服务Windows 上的常见习惯临时跑几天用命令行没问题但如果你想长期开着接收站常见做法是把它做成开机自启任务。Windows 上最省事的方式不是注册系统服务而是写一个批处理文件放进启动目录配合start命令让它在独立窗口中运行echo off cd /d C:\adsb start dump1090 dump1090.exe --net --net-http-port 8080 --gain 42start后面的dump1090是这个新窗口的标题必须写上否则批处理会卡在等待进程退出的状态。这个批处理文件放到%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup目录即可实现登录后自动启动。如果你需要更强的管理能力比如开机不登录也运行、崩溃自动重启可以用任务计划程序配置触发器为「计算机启动时」。3.5 参数调优三个值得为长期运行调整的选项除了上面的最小参数有三个选项在使用中值得关注。--ppm用于校正接收器晶振的频率偏差如果 RTL-SDR 的晶振实际频率与标称值偏移较大解码成功率会受影响。常见做法是先默认 0 运行一段时间如果发现同一架飞机反复出现解码中断、或者消息 CRC 通过率明显偏低再用--ppm 20这类值逐步尝试。--aggressive开启更激进的消息聚合策略适合信号密集的机场附近但会显著增加 CPU 占用老机器上慎用。--write-json C:\adsb\json --write-json-every 1让程序每隔 1 秒把当前航迹快照写成 JSON 文件包含 aircraft.json、receiver.json 等这个特性对后续做数据归档非常有用。注意写盘频率太高会增加磁盘压力不是做秒级分析的话设--write-json-every 5更稳妥。4. 让数据流动起来前端、TCP 流与离线调试方案4.1 内置前端地图瓦片加载是隐性依赖启动后访问http://127.0.0.1:8080页面分两个主要区域左侧是飞机表格列有 ICAO 地址、航班号、高度、速度、航向等字段右侧是地图视图飞机位置以标记形式叠加在 OpenStreetMap 瓦片上。这里有一个容易误判的问题如果表格里有飞机在更新但地图一直空白很多人会以为是解码出了问题。实际上大多是地图瓦片源无法访问因为页面加载 OSM 瓦片需要联网。如果你部署在内网环境表格数据仍然有效地图显示空白属于正常现象直接把表格或 TCP 数据拿去做业务即可不需要解决瓦片问题。4.2 解析 30003 端口的 SBS 文本30003 端口输出的是 SBS BaseStation 格式每行一条消息字段用逗号分隔开头以MSG标识。典型的一行是这个样子MSG,3,111,11111,3C6A2A,1,2025/06/01,12:00:00,2025/06/01,12:00:01,CXA123,10250,420,274,22.345,-114.567,0,0,0,0,0,0字段的意义按顺序拆解前三个分别是消息类型3 表示空中位置、传输类型和会话 ID航空公司内部 IDICAO 地址3C6A2A接下来两组生成日期与时间、记录日期与时间然后依次是航班号CXA123、高度英尺、地速节、航向度、纬度、经度、垂直速率、应答机编码、紧急状态等。字段数量固定为 22 个这对写解析器非常友好按逗号切分后索引取值即可。4.3 用 Python 消费 30003 数据的最小脚本如果你想把数据接到自己的程序里最直接的切入点是写一个 TCP 客户端连接 30003 端口。我用 Python 搭过多次这类数据管道最小可跑的版本如下import socket import json def consume_sbs(host, port, duration60): sock socket.create_connection((host, port), timeout10) sock.settimeout(5) start time.time() seen {} while time.time() - start duration: try: data sock.recv(4096).decode(utf-8, errorsignore) except socket.timeout: continue for line in data.splitlines(): parts line.split(,) if len(parts) 22 and parts[0] MSG: icao parts[4] seen[icao] { flight: parts[14].strip(), altitude: parts[11], lat: parts[15], lon: parts[16], } print(json.dumps(seen, indent2)) import time consume_sbs(127.0.0.1, 30003, duration30)逻辑不复杂循环读取端口数据按行拆分过滤出MSG行按 ICAO 地址去重维护最新状态。recv(4096)一次可能读到半行或多行所以必须在splitlines后逐行校验字段数。这个脚本跑 30 秒后会把看到的飞机快照输出为 JSON是验证数据链路和做二次开发的好起点。4.4 离线调试把 30003 数据录下来重放不是所有开发场景都有条件对着真实电台调试尤其是写解析器、调算法的阶段。常见做法是把 30003 的实时流录制成文件之后在任意时间重放给本地程序等于把开发环境和射频环境解耦。录制只需一个简单的 TCP 转存脚本import socket sock socket.create_connection((127.0.0.1, 30003), timeout10) with open(sbs_capture.txt, a) as f: while True: data sock.recv(4096) if not data: break f.write(data.decode(utf-8, errorsignore))录制文件每行就是一条 SBS 消息重放时只需要按行读取原样发送到本地任意端口供你的解析程序连接。这个方式的优点是不依赖 dump1090-win 的特定参数录制的文件也能分享给同行联调。5. Windows 下跑 dump1090-win 的五个常见坑现象、原因、解决5.1 启动即报找不到设备但设备管理器里明明有接收器现象双击运行后立刻提示找不到 RTL-SDR 设备或者显示No supported devices found。原因通常是驱动没有替换成 WinUSB也可能之前装过其他 SDR 驱动Windows 记住了旧驱动信息。解决先卸载设备管理器里该 USB 设备的现有驱动再打开 Zadig确认左侧列表选择的是 Bulk-In, Interface (Interface 0)重新执行 WinUSB 替换替换完成后务必拔插一次让驱动重新加载。5.2 进程活着但 Web 页面始终打不开现象dump1090.exe在任务管理器里有但浏览器访问http://127.0.0.1:8080一直拒绝连接或超时。原因大概率是防火墙拦截Windows 首次监听端口时会弹防火墙授权框如果点了取消后续不会再弹。解决打开 Windows 防火墙高级设置在入站规则里为 dump1090.exe 新建允许规则允许 TCP 8080、30002、30003、30005 四个端口。临时测试也可以先关闭防火墙确认但长期运行请用白名单而不是关防火墙。5.3 运行一段时间后数据停止更新程序却没有退出现象前几十分钟显示正常之后表格和端口数据都凝固了。原因最常见的是 USB 控制器进入选择性暂停或 USB 供电不足导致接收器间歇性掉线。解决在 Windows 电源选项里关闭 USB 选择性暂停设置把接收器从前置 USB 口或 USB Hub 换到主板后置 USB 2.0 口如果必须用 Hub选带独立供电的。这个问题在笔记本上更容易出现很多笔记本会在电池模式下主动节电。5.4 解压后双击闪退命令窗口一闪而过现象直接双击 exe 文件窗口一闪就没。原因不是程序坏了而是它本就不是设计为双击运行的命令行程序日志打印完就关闭。解决在 PowerShell 或命令提示符中运行并加上--interactive参数保持前台界面。如果加了参数仍然闪退检查解压路径是否含中文或空格C:\adsb这种纯英文路径最稳。5.5 高密度信号区解码率异常同一架飞机航迹断裂现象飞机飞过机场上空时消息密度剧增航迹开始频繁中断表格中同一 ICAO 地址的消息间隙忽大忽小。原因通常是自动增益被强信号压制弱信号淹没在底噪里或者 CPU 不足以支持--aggressive模式。解决先去掉--aggressive再把增益从自动改为固定值在 30 到 50 之间多试几个点观察哪个值下航迹最连续。老机器上还可以尝试降低采样率相关开销但 dump1090-win 对采样率参数支持有限优先检查 CPU 占用是否为满。6. 进阶用法开机自启、频率校正与历史数据归档对长期跑的接收站我有三个已经固化成习惯的做法。第一个是开机自启加日志落盘批处理里除了启动命令再挂一段 C:\adsb\logs\dump.log 21保留输出日志出问题时有迹可循这是最便宜的后悔药。第二个是频率校正。晶振频偏会长期影响解码率但不需要专业仪器也能粗调把天线架好固定增益运行一两天统计解码消息总量然后用--ppm 10跑同样时长做对比选用量更高的 ppm 档。没有统计脚本的话前端页面上的消息计数就是参照指标。我自己的接收器稳定在--ppm 20附近不同批次芯片差别很大必须实测。第三个是 JSON 归档。开启--write-json后程序会持续把航迹快照写入指定目录我用一个定时任务把 aircraft.json 按小时归档到数据仓库。这个文件的格式很简单名字字段直接对应 ICAO 地址和经纬度拿来做覆盖分析、去重统计都方便。配合前文的重放方案你可以完全脱离射频环境去验证算法这套组合拳是我目前觉得 Windows 上最省心的 ADS-B 落地路径。提示定期回去看一眼归档数据里同一航班号的连续航迹是否平滑这比盯着实时画面更容易发现接收机性能的缓慢退化。折腾 ADS-B 接收这件事七分在天线和供电三分在软件。dump1090-win 虽然老但它把解码、展示、输出都做在了一个进程里是这个方向上投入产出比相当高的起点。我从看到第一架飞机在自己屏幕上亮起到现在用归档数据做航迹热区分析这套方案一直没有换。希望帮到你。本文还有配套的精品资源点击获取