2. 断连场景分析：信号丢失、硬件故障、链路拥塞、飞控重启

地面站跟飞控之间的连接，说白了就是一根看不见的「数据绳子」。这根绳子什么时候会断？我做了这么多年地面站开发，总结下来无非四种情况。每种我都踩过坑，今天一个一个说清楚。

2.1 信号丢失——最常见的「假死」

信号丢失，说白了就是无线电波传不过来了。无人机飞远了、飞到大楼后面、或者天线角度不对，都会这样。

我记得有一次在山区测试，飞机刚翻过山头，数传信号直接从 100% 掉到 0%。地面站这边看着最后一条消息是「心跳包」，然后就卡住了。嗯，这种情况最让人头疼——你不知道飞机是炸了，还是只是信号被挡住了。

信号丢失的几个典型特征：

• 心跳包先断——MAVLink 的心跳是 1Hz 发的，它一停，基本就是链路断了
• RSSI 逐渐下降——不是瞬间归零，而是从 -70dBm 慢慢掉到 -100dBm 以下
• 数据包不完整——有时候能收到半条消息，校验和过不去

2.2 硬件故障——最让人抓狂的「断连」

硬件故障，嗯，这个我吃过不少亏。数传模块烧了、USB 口松了、飞控的 UART 口虚焊了……什么奇葩情况都有。

我曾经遇到过一架飞机，飞着飞着突然断连。换了两套数传都没用，最后发现是飞控上的排针有一根断了，刚好是 TX 脚。你说气不气人？

硬件故障的典型表现：

• 完全无响应——心跳包、数据包全都没有，连个噪声都收不到
• 端口打不开——地面站报「无法打开串口」或「设备不存在」
• 异常数据——偶尔收到几个字节，全是乱码，校验和永远不对

2.3 链路拥塞——数据太多，把路堵死了

链路拥塞，说白了就是数据量太大，数传模块忙不过来了。这种情况在调试阶段特别常见。

你想想看，地面站开了日志下载、视频回传、遥测数据全开，再加上几个 MAVLink 命令在排队……数传模块就那么点带宽，能不堵吗？

链路拥塞的几个信号：

• 心跳包延迟——正常 1Hz 的心跳，变成了 3 秒、5 秒才来一次
• 命令超时——发出去的 MAV_CMD 指令，飞控半天没回应
• 数据包乱序——sequence number 跳得厉害，比如收到 seq=10，下一个是 seq=15

场景	典型带宽占用	建议措施
普通遥测	~2 KB/s	正常，无需干预
日志下载	~50 KB/s	暂停遥测，优先下载
视频回传	~200 KB/s	降低画质或关闭
多命令并发	~10 KB/s	排队发送，加延迟

2.4 飞控重启——最「假」的断连

飞控重启，嗯，这个情况最迷惑人。飞控因为某些原因重启了，地面站这边看到的是「连接断了」，但实际上飞控还在天上飞，只是重新初始化了。

我记得有一次做自动航线测试，飞控突然重启了。地面站显示「连接丢失」，我差点就点了「紧急降落」。后来发现飞控重启后自动恢复了航线，继续执行任务。好险。

飞控重启的典型特征：

• 心跳包中断后恢复——断了几秒到几十秒，然后心跳又回来了
• 系统 ID 不变——重启后飞控的 MAVLink 系统 ID 还是原来的
• 启动消息出现——收到飞控的 BOOT 消息或 AUTOPILOT_VERSION 消息
• 时间戳重置——飞控的 time_boot_ms 从 0 开始

2.5 四种场景对比总结

四种场景，各有各的脾气。我画了一张图，帮你快速区分：

这张图是我在实际项目中总结出来的诊断流程。你照着走一遍，基本能定位问题出在哪。