3、通信链路分析：数传/图传信号丢失、延时过高、链路拥塞的排查方法
通信链路，说白了就是无人机和地面站之间的“生命线”。数传负责传指令和状态数据，图传负责传视频画面。哪条线断了，任务都得完蛋。我见过太多新手一上来就调PID、改航线，结果问题根本不在那儿——是链路本身就不靠谱。
这一章，咱们就聚焦三个核心问题：信号丢失、延时过高、链路拥塞。我会把排查思路和参数调整方法掰开揉碎了讲。
核心原则： 先排查物理层，再分析协议层，最后调整参数。别一上来就动地面站的配置，先看看天线是不是没拧紧。
3.1 信号丢失：别急着怪硬件
信号丢失，最直观的表现就是地面站上显示“RC Loss”或者“Telemetry Lost”。很多人第一反应是“数传坏了”，其实不然。
我个人的排查顺序是这样的：
- 看RSSI值——地面站上一般都有信号强度指示。如果RSSI低于-90dBm，基本就是临界区了。
- 检查天线——天线有没有拧紧？极化方向对不对？我遇到过好几次，飞手把天线对着飞机屁股，信号直接被机身遮挡。
- 看距离和遮挡——城市里飞，一栋楼就能把信号切得干干净净。别指望2.4G能穿墙。
- 检查频率干扰——机场附近、高压线塔旁边、WiFi密集区，这些地方干扰源多。
我的习惯： 每次起飞前，我都会在地面站上看一眼“链路质量”这个参数。如果低于60%，我绝对不会起飞。宁可花10分钟换个位置，也别在空中赌运气。
如果确认是信号丢失，参数调整方向如下：
| 参数项 | 调整方向 | 说明 |
|---|---|---|
| 发射功率 | 增大（如20dBm→27dBm） | 注意法规限制，部分频段有上限 |
| 跳频模式 | 开启自适应跳频 | 避开干扰频点，但会增加延时 |
| 数据率 | 降低（如250kbps→64kbps） | 低数据率有更好的穿透性 |
| 重传次数 | 增加（如3次→5次） | 提高可靠性，但会加重拥塞 |
注意： 增大发射功率不是万能的。我曾经在一个项目里把功率调到最大，结果图传和数传互相干扰，两个都挂了。功率不是越大越好，够用就行。
3.2 延时过高：到底是谁在拖后腿？
延时高，飞手会感觉“打舵之后飞机慢半拍”。图传延时高，画面卡顿，FPV根本没法飞。
延时分为几个环节：
- 上行延时：地面站→飞机。遥控指令的延迟。
- 下行延时：飞机→地面站。状态数据和视频的延迟。
- 处理延时：飞机飞控和地面站软件的处理时间。
怎么测？我一般用两种方法：
方法一：Ping测试。 如果数传链路支持，直接在地面站上ping飞机的IP地址。RTT（往返时间）超过100ms，基本就属于高延时了。
方法二：秒表法。 飞控上接一个LED，地面站发指令让它亮，同时用手机慢动作录像，数帧数。这个方法土，但准。
延时过高的常见原因和调整：
| 原因 | 现象 | 调整方案 |
|---|---|---|
| 数据率过低 | RTT > 200ms | 适当提高数据率（如64kbps→250kbps） |
| 重传次数过多 | 丢包率低但延时高 | 降低重传次数，允许少量丢包 |
| 地面站处理瓶颈 | CPU占用率 > 80% | 关闭不必要的日志记录或视频解码 |
| 链路距离过远 | RSSI < -85dBm | 缩短距离或使用高增益天线 |
避坑指南： 我曾经遇到一个案例，延时一直很高，查了半天发现是地面站的USB转串口线质量太差，数据包频繁出错导致重传。换了一根带屏蔽的线，延时直接降了60%。别小看这些细节。
3.3 链路拥塞：数据太多，路太窄
链路拥塞，说白了就是“堵车”。数传链路带宽有限，如果同时传输大量数据——比如高清图传、高频率的遥测数据、日志下载——链路就会堵死。
拥塞的表现：
- 地面站上遥测数据更新卡顿，几秒才刷新一次。
- 图传画面马赛克严重，甚至黑屏。
- 指令发送后，飞机要过好几秒才响应。
排查方法：
- 看带宽占用率。 有些地面站（比如Mission Planner）会显示链路利用率。超过70%就要警惕了。
- 检查数据流。 是不是开了太多不必要的MAVLink消息？比如每秒50次的姿态数据，其实10次就够了。
- 看图传码率。 1080p 30fps的图传，码率动辄4-8Mbps。而数传链路通常只有几百kbps。两者共用同一信道时，图传会把数传挤死。
参数调整方案：
| 调整项 | 具体操作 | 效果 |
|---|---|---|
| 降低遥测频率 | 将SR0/SR1参数中的姿态、GPS频率减半 | 减少数传带宽占用 |
| 降低图传码率 | 从8Mbps降到4Mbps，或降低分辨率 | 释放信道带宽 |
| 启用QoS | 设置数传数据优先级高于图传 | 保证控制指令优先传输 |
| 分频段传输 | 数传用433MHz，图传用2.4GHz | 彻底避免互相干扰 |
我的经验： 在复杂电磁环境下，我习惯把遥测数据中的“无用消息”全部关掉。比如电池详细信息、传感器原始值，这些在航点任务中根本用不上。省下来的带宽，留给图传和关键指令，效果立竿见影。
3.4 综合排查流程：一张表搞定
如果你在现场遇到通信问题，别慌。按这个流程走一遍，90%的问题都能定位：
| 步骤 | 操作 | 判断依据 |
|---|---|---|
| 1 | 检查RSSI和链路质量 | RSSI > -80dBm 且 链路质量 > 70% 为正常 |
| 2 | 执行Ping测试 | RTT < 50ms 为优秀，< 100ms 可接受 |
| 3 | 查看带宽占用率 | 占用率 < 50% 为安全 |
| 4 | 检查丢包率 | 丢包率 < 1% 为正常 |
| 5 | 观察图传画面 | 无马赛克、无卡顿为正常 |
如果以上任何一项不达标，就回到对应的小节里找调整方案。嗯，这套流程我用了好几年，基本没翻过车。
最后提醒一句： 通信链路的问题，很多时候不是参数能解决的。如果换了天线、调了功率、降了码率还是不行，那就换个地方飞。环境不行，参数再调也没用。别死磕。