简介本资源是面向Windows平台的ADS-B航空信号接收与解析工具包专为无线电爱好者、航空监测初学者及嵌入式/SDR实践者设计解决在Windows环境下快速部署RTL-SDR飞行追踪系统的实际需求。压缩包共18个文件含2个核心可执行程序dump1090.exe用于数据解码view1090.exe提供图形化显示、4个关键DLL动态库rtlsdr.dll驱动硬件libusb-1.0.dll与pthreadVC2.dll支撑USB通信与多线程处理msvcr100.dll保障运行环境、8个前端JS脚本及HTML/CSS文件构成轻量Web界面public_html目录支持本地浏览器实时查看航班轨迹另有配置脚本、启动批处理和说明文档。资源大小仅602KB结构紧凑、开箱即用。目前已有835人学习下载用户可直接获得完整可运行的dump1090-win 1.10.3010.14版本eastixg优化分支包含全部依赖项与Web可视化模块无需额外编译或环境配置适合从零搭建个人ADS-B接收站。1. dump1090-win 是什么一个 Windows 下能跑通 ADS-B 接收的轻量级解码器不是“免配置神器”但能让你在 30 分钟内看到飞机飞过你家上空dump1090-win.1.10.3010.14_dump1090win_dump1090_eastixg_这个看似杂乱的文件名实际指向一个在 Windows 平台持续演进的dump1090移植版本——它不是官方dump1090-mutability或dump1090-fa的直接打包而是由社区开发者eastixg基于dump1090主干commit 级别对应 v1.10针对 Windows 环境深度适配的构建产物。核心价值非常具体不用 Linux 虚拟机、不装 WSL、不编译源码插上 RTL-SDR如 RTL8232U/RTL-SDR Blog V3双击就能启动 Web 界面实时显示附近 100km 内民航客机的航班号、高度、速度、航向和位置。它解决的是真实场景里的“最后一公里”问题——很多飞友买了 USB 接收棒却卡在“Windows 下怎么让 dump1090 工作”这一步。这个版本绕过了 MinGW/MSYS2 编译链的玄学依赖用预编译的libusbpthreadVC2.dll 静态链接的rtl-sdr库把整个运行时压缩到不到 5MB。适合硬件入门者、教育演示场景、应急航空监视节点部署也适合想快速验证天线架设效果的实测工程师。注意它不提供自动增益调优、不内置 MLAT 多站协同定位、不支持原始 IQ 数据导出——如果你需要这些它不是终点而是起点。2. 从零启动用 dump1090-win.1.10.3010.14 在 Windows 10/11 上跑通 ADS-B 接收的最小闭环2.1 准备硬件与驱动RTL-SDR 接收棒必须“认得出来”否则后续全是空谈dump1090-win本质是rtl_sdr工具链的上层封装它不自带 USB 驱动。第一步永远是确认 Windows 能识别你的 RTL-SDR 设备。常见型号有 RTL-SDR Blog V3、Nooelec NESDR Nano 3、Airspy R2需额外驱动。操作路径如下插入 RTL-SDR 设备打开「设备管理器」→ 展开「通用串行总线控制器」或「网络适配器」查看是否有带黄色感叹号的未知设备若无右键「扫描检测硬件改动」若仍无法识别必须手动安装 Zadig 驱动下载 Zadig 2.7 → 启动后点击Options→ 勾选List All Devices→ 在下拉菜单中选择你的 RTL-SDR 设备通常显示为RTL2832UHC或RTL2832U→ 顶部选择WinUSB→ 点击Replace Driver提示不要选libusb-win32或USB SerialWinUSB是dump1090-win唯一兼容的底层驱动类型。替换后设备管理器中应显示为WinUSB Device且无感叹号。验证是否成功打开命令提示符管理员权限执行rtl_test -t如果返回类似Found 1 device(s)Supported gain values (29): 0.0 0.9 1.4 ... 49.6说明驱动就位。这是后续所有步骤的前提——没过这关dump1090-win 启动时会静默失败连错误日志都不输出。2.2 解压即用理解 dump1090-win.1.10.3010.14 的目录结构与关键文件你下载的压缩包文件名含_eastixg_解压后典型结构如下dump1090-win/ ├── dump1090.exe ← 主程序32/64 位已静态链接无需 VC 运行库 ├── rtl_sdr.exe ← 用于校准与诊断的底层工具非必须但强烈建议保留 ├── pthreadVC2.dll ← POSIX 线程库dump1090-win 依赖它实现多线程解码 ├── libusb-1.0.dll ← USB 通信库版本必须为 1.0.26本包已内置 ├── config/ ← 配置目录首次运行会自动生成 │ └── dump1090.conf ← JSON 格式配置可手动编辑见 2.3 节 ├── web/ ← 内置 Web 服务器静态资源HTML/CSS/JS └── logs/ ← 日志目录默认关闭需配置启用注意dump1090.exe是单文件可执行体不依赖 .NET Framework、不依赖 Visual C Redistributable、不写注册表。只要pthreadVC2.dll和libusb-1.0.dll在同一目录它就能工作。这也是eastixg版本区别于其他 Windows 移植版的关键设计——去环境依赖保移植性。2.3 启动与基础配置用命令行参数快速验证再用 config 文件固化设置首次运行推荐用命令行启动以捕获实时输出便于排查dump1090.exe --interactive --net --net-http-port 8080 --gain 49.6 --fix --no-fix-check参数含义逐条说明--interactive启用控制台交互模式显示实时解码帧数、信号强度、误码率BER--net启用网络服务TCP/UDP 数据广播 HTTP 服务--net-http-port 8080Web 界面监听端口避免与 IIS/Apache 冲突默认 8080 安全--gain 49.6RTL-SDR 增益值49.6是 V3 棒最大增益新手建议从此值起步过高会饱和--fix启用 GPS 时间戳修正需外接 GPS 模块无则忽略--no-fix-check跳过 GPS 有效性检查避免无 GPS 时卡住启动启动后观察控制台输出若出现Reading data from RTL-SDR device...→Gain reported as 49.6 dB→Starting SDR thread...→Started 2 threads说明接收链路已通打开浏览器访问http://localhost:8080应看到动态地图界面左上角显示Receiving: YES下方有Messages: XXXX/sec实时计数若需长期运行将上述参数写入config/dump1090.confJSON 格式{ interactive: true, net: true, net-http-port: 8080, gain: 49.6, fix: false, no-fix-check: true, net-beast-receiver: 127.0.0.1:30005, net-sbs-port: 30003 }之后双击dump1090.exe即可自动加载配置——这是生产环境的标准做法避免每次输命令。3. 参数调优实战为什么你的 dump1090-win 解码率只有 30%而别人能到 95%3.1 增益Gain不是越高越好用 rtl_test 定量评估信噪比拐点--gain是影响解码率最敏感的参数。V3 棒标称增益范围0.0–49.6 dB但实际最优值因天线、环境、频段干扰而异。盲目设49.6反而会导致 ADC 过载产生大量误码。正确做法是用rtl_test扫描增益曲线# 在 dump1090-win 目录下执行需先确保驱动正常 rtl_test -s 2000000 -g 0观察输出中的PPM和Samples per second行重点看Correlation值相关性。然后逐步提高增益for /l %i in (0,5,49) do echo Gain%i rtl_test -s 2000000 -g %i -n 1000000 | findstr Correlation记录每个增益下的Correlation值越高越好找到峰值点。实测经验城市环境最优增益常在35–42 dB郊区可达45–49 dB。超过拐点后 Correlation 急剧下降dump1090-win 的Messages/sec会同步腰斩。3.2 频率偏移PPM校准为什么你看到的飞机位置总偏 5kmRTL-SDR 晶振存在固有偏差PPM导致接收频率漂移。ADS-B 使用 1090 MHz哪怕1 ppm偏差也会造成1.09 kHz频偏足以让 dump1090-win 无法锁定信号。校准方法分两步粗校准用rtl_test -p测量当前 PPM需稳定信号源如本地 FM 广播台精校准启动 dump1090-win 后观察 Web 界面右下角PPM: X.XX值来自解码帧时间戳推算若持续 ±10需手动补偿在dump1090.conf中添加ppm: -12.5负值表示晶振偏快需减频补偿。eastixg版本支持运行时热更新 PPM修改 conf 后 CtrlC 退出再启动即可无需重编译。3.3 天线与馈线一根 3 米 RG-58 馈线可能吃掉你 6dB 信号dump1090-win 的解码能力上限由射频链路决定而非 CPU。实测数据配置典型解码率市区有效距离无源鞭状天线 1m USB 线12–18 msg/sec≤ 25 km四臂 GP 天线 3m RG-5845–65 msg/sec≤ 60 km四臂 GP 低噪放LNA4ALL 1m LMR-40085–110 msg/sec≥ 120 km关键结论馈线损耗比天线增益更重要。RG-58 在 1090 MHz 下衰减约1.2 dB/m3 米就是3.6 dB损失信号减半。升级馈线LMR-400 衰减仅0.22 dB/m带来的提升远超更换天线型号。dump1090-win自身不提供 LNA 控制接口需外置放大器并确保其供电稳定USB 供电 LNA 易受噪声干扰。4. 避坑指南dump1090-win 运行中 5 个高频翻车点与血泪解决方案4.1 现象dump1090.exe 启动后立即退出控制台无任何输出原因pthreadVC2.dll或libusb-1.0.dll版本不匹配或被 Windows Defender 误杀尤其pthreadVC2.dll常被标记为可疑解决用Dependency Walkerx64 版打开dump1090.exe检查pthreadVC2.dll是否报ERROR_DEPENDENCY_NOT_FOUND从 pthreads-win32 官方存档 下载pthreads-w32-2-9-1-release.exe提取pthreadVC2.dll替换将dump1090-win目录加入 Windows Defender 排除列表设置 → 病毒威胁防护 → 管理设置 → 添加或删除排除项4.2 现象Web 界面显示Receiving: NO但rtl_test -t正常原因dump1090-win默认使用rtl_sdr的direct sampling模式Q-branch而部分 RTL-SDR 固件不支持该模式解决在dump1090.conf中强制指定offset_tuning模式enable-agc: false, offset-tuning: true, rtlsdr-device-index: 0或启动时加参数--offset-tuning禁用 direct sampling4.3 现象解码率忽高忽低如 50→5→80 msg/sec 波动CPU 占用率 100%原因Windows 电源计划设为节能模式导致 USB 控制器间歇性休眠RTL-SDR 数据流中断解决控制面板 → 电源选项 → 更改计划设置 → 更改高级电源设置 → USB 设置 → USB 选择性暂停设置 → 设为已禁用同时关闭快速启动系统设置 → 电源和睡眠 → 其他电源设置 → 选择电源按钮的功能 → 更改当前不可用的设置 → 取消勾选启用快速启动4.4 现象飞机图标显示但位置严重偏移如北京起飞的航班显示在天津上空原因dump1090-win默认使用--lat/--lon参数未设置或配置文件中receiver-location为空导致解码器用(0,0)作为参考点计算相对位置解决在dump1090.conf中明确填写你的经纬度小数格式精度到 0.0001°lat: 39.9042, lon: 116.4074, alt: 50alt单位为米海拔误差 ±10m 对水平定位影响可忽略4.5 现象dump1090.exe运行数小时后内存泄漏占用从 30MB 涨到 2GB原因eastixg1.10.3010.14 版本存在webserver模块的内存释放缺陷未回收 HTTP 连接缓冲区解决启动时添加--net-ri-port 0禁用 raw input 端口减少连接数用 Windows 任务计划程序每 4 小时自动重启!-- 任务 XML 片段 -- Actions Exec CommandC:\path\to\dump1090-win\dump1090.exe/Command Arguments--interactive --net --net-http-port 8080 --gain 42/Arguments /Exec /Actions或改用--net-only模式关闭 Web 界面仅输出数据流给外部软件如 VirtualRadarServer5. 进阶用法把 dump1090-win 的原始数据喂给 Python 做二次分析绕过 Web 界面瓶颈5.1 理解 dump1090-win 的网络协议栈BEAST、SBS-1、Raw 三种输出格式差异dump1090-win默认启用--net后会同时广播三种格式数据到不同端口可配置协议端口数据特点适用场景BEAST30005二进制编码含信号强度、CRC 校验、时间戳解析开销最小实时流处理、嵌入式设备接入SBS-130003ASCII 文本CSV 格式MSG,5,XX,...人眼可读Excel 导入、简单脚本解析Raw30002未解码的 24-bit I/Q 样本流需自行 FFT研究信号特征、开发新解码算法注意eastixg版本对 BEAST 协议做了优化--net-beast-receiver参数可指定转发目标如127.0.0.1:30005但不支持 UDP 组播仅 TCP 单播。5.2 用 Python 实时消费 BEAST 数据50 行代码构建自己的航班统计看板以下脚本连接localhost:30005解析 BEAST 流统计每分钟航班数并打印import socket import struct import time from collections import defaultdict def parse_beast_message(data): if len(data) 2: return None if data[0] 0x1a and data[1] 0x1a: # BEAST sync word # Skip sync length byte, extract payload payload data[3:] if len(payload) 28: # Minimum ADS-B DF17 frame icao payload[1:4].hex().upper() return icao return None def main(): sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect((127.0.0.1, 30005)) sock.settimeout(1.0) counter defaultdict(int) last_min int(time.time() // 60) while True: try: data sock.recv(4096) icao parse_beast_message(data) if icao: now_min int(time.time() // 60) if now_min ! last_min: print(f[{time.strftime(%H:%M)}] {sum(counter.values())} flights/min) counter.clear() last_min now_min counter[icao] 1 except socket.timeout: continue except ConnectionResetError: print(BEAST connection lost, reconnecting...) sock.close() time.sleep(2) sock socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect((127.0.0.1, 30005)) if __name__ __main__: main()逻辑说明parse_beast_message()识别 BEAST 帧头0x1a 0x1a跳过长度字节提取 ICAO 地址3 字节counter按 ICAO 去重计数避免同一航班重复统计settimeout(1.0)防止 recv 阻塞ConnectionResetError捕获 dump1090-win 重启时的断连此方案优势绕过 Web 界面的 JavaScript 渲染瓶颈CPU 占用低于 5%且可无缝对接 Pandas 做历史趋势分析、Matplotlib 画航线图、或接入 MQTT 推送至 Home Assistant。5.3 用 Wireshark 抓包定位丢帧当解码率异常时先看网络层是否丢包dump1090-win的 BEAST 流是 TCP 协议Wireshark 过滤规则如下tcp.port 30005 tcp.len 0关键观察点Sequence Number 是否连续若出现TCP Previous segment not captured说明 dump1090-win 发送端丢包通常是 USB 数据溢出Window Size 是否归零若Window size: 0持续出现说明 Python 客户端未及时 recv导致 TCP 缓冲区满dump1090-win 被迫丢弃新帧Retransmission 次数 3 次重传表明网络不稳定但本地回环127.0.0.1极少发生实测经验当dump1090-win控制台显示Dropped frames: XXX时Wireshark 中必能看到对应的TCP Dup ACK—— 这说明问题不在网络而在接收端处理不过来。此时应降低--net-ri-port速率或升级接收端代码逻辑。我坚持用--net-beast-receiver Python 脚本替代 Web 界面三年没遇到一次定位失效。因为 Web 界面是黑匣子而 TCP 流是透明管道。每次怀疑 dump1090-win 有问题我第一反应不是重装而是 Wireshark 抓包——90% 的“玄学故障”都能在 3 分钟内定位到是 USB 线质量、Windows 电源策略或 Python recv 缓冲区大小的问题。希望帮到你。本文还有配套的精品资源点击获取