QGC 软件配置优化：从源头堵住丢包

上一章我们聊了硬件和链路层面的排查。但说实话，很多时候丢包问题并不在物理层，而是 QGC 自身的软件配置没调对。我见过不少团队，飞控和数传模块都是顶配，结果地面站这边参数还是出厂默认值，那丢包率能好看才怪。

这一章，我们就聚焦 QGC 里的几个关键配置项。你调整好这些参数，往往能立竿见影地降低丢包率。我个人习惯是，拿到一个新项目，第一件事就是检查这四项：串口波特率、流控、Mavlink 协议版本、心跳与超时参数。

核心观点：软件配置是通信链路的“软开关”。硬件再好，参数不对，照样丢包。

先说波特率。很多人觉得波特率越高越好，恨不得直接上 921600。但实际项目中，我吃过这个亏。有一次在山区测试，链路本身就不太稳定，我图省事把波特率设成了 57600，结果丢包率直接飙到 15%。后来降到 38400，问题就解决了。

为什么会这样？因为波特率越高，对链路质量的要求也越苛刻。信号稍微有点衰减，高波特率下的误码率就会急剧上升。你想想看，数据传得快但全是错的，那还不如传得慢一点但保证正确。

再说流控。硬件流控（RTS/CTS）是个好东西，但前提是你的数传模块和飞控都支持。我记得有一次帮客户排查问题，他死活说丢包严重，我一看配置，硬件流控打开了，但飞控那边的对应引脚根本没接线。结果就是数据发不出去，全堵在缓冲区里。

我的建议：如果你不确定硬件是否支持流控，或者线没接全，那就老老实实关掉硬件流控，用软件流控或者干脆不用。别为了追求理论上的完美，反而搞出问题。

Mavlink 协议现在主流是 v2。v2 相比 v1 多了很多好东西，比如签名验证、更大的消息 ID 空间、更灵活的 payload 长度。但问题来了——不是所有设备都支持 v2。

我遇到过最典型的情况：飞控是 Pixhawk 跑了最新固件，支持 v2 没问题。但用户用的一个老款数传模块，固件还是三年前的，只认 v1。结果 QGC 这边默认开了 v2，数传模块收到 v2 的包直接丢弃，丢包率能不高吗？

怎么选？我一般遵循这个原则：

注意：QGC 里切换协议版本后，一定要重启地面站和飞控。我见过有人改了设置不重启，然后跑来问我为什么没生效……

这个参数很多人忽略。QGC 默认的数据链超时时间通常是 5 秒或 10 秒。什么意思？就是如果超过这个时间没收到飞控的任何数据，QGC 就认为链路断了，然后触发一系列重连动作。

但问题来了：如果你的链路延迟本身就比较大（比如卫星中继或者超远距离数传），偶尔一次心跳延迟 6 秒是很正常的事。结果 QGC 以为断了，开始疯狂重连，反而加重了链路负担，造成更多丢包。

我个人的习惯是：先测一下实际链路的 RTT（往返延迟），然后把超时时间设为 RTT 的 3-5 倍。比如 RTT 是 2 秒，那超时时间设 6-10 秒比较合理。

心跳包是维持通信的命脉。飞控默认每秒发一次心跳，QGC 收到后就知道“哦，飞控还活着”。但如果链路不好，心跳包丢了怎么办？

这里有个关键参数：心跳丢失次数阈值。QGC 默认是连续丢失 3 次心跳就判定链路断开。但你想，如果链路偶尔抖动一下，连续丢 3 个包其实挺常见的。结果就是频繁触发重连，用户体验极差。

我建议的做法是：

避坑指南：我曾经在一个项目中，把心跳间隔改成了 5 秒，阈值改成了 10 次。结果飞控真的挂了，QGC 等了 50 秒才发现……所以改参数要适度，别太极端。

最后，给你一个快速检查清单。每次部署新项目，按这个过一遍：