OpenIPC开源FPV之Adaptive-Link信号干扰

1. 源由

虽然，OpenIPC作为FPV图传在延时方面使用广播wfb-ng，性能上已经非常棒了。

在权衡一些特殊场景，尤其是FPV穿越机场景，由于RF的特有性质，会被遮挡、干扰等问题困扰。

Adaptie Link是一个比较有意思的实现，尽管从目前使用场景看，仍然存在一些问题。

• The Runcam Wifi Link V2 is better than I initially thought - More testing
• Enhancing Packet Loss Handling in FPV Scenarios with Increased FEC #21

其最为主要的目的，根据现场情况，调整RF方案，最优无线链路传输。本章将结合实际看到的现象，提出一些改善的思路。

注：基于当前v0.58.0版本情况分析，因为v0.60.0有较大的变化，考虑了动态FEC等，实际情况并不理想。

2. 现象

总结下现在发现的两个主要问题：

1. 发射端由于链路检测，直接丢弃通讯报文；
2. 报文虽然发射，但是由于空中无线传输问题，导致丢包；

FPV Interference Scenarios: Bitrate/SNR/RSSI/IDR/Drop/FEC/Link

3. 分析

3.1 冲突弃包

CSMA/CA（Carrier Sense Multiple Access with Collision Avoidance，载波监听多路访问/碰撞避免）机制是一种 无线网络（如 Wi-Fi）常用的 媒体访问控制（MAC）协议，用于避免数据包在共享无线信道上的冲突。

由于无线设备不能像有线网络一样同时发送和接收数据，因此 无法检测到碰撞，所以需要 碰撞避免（Collision Avoidance, CA） 机制来减少冲突。

CSMA/CA 工作原理

1. 监听信道（Carrier Sense）
   设备在发送数据前，先监听无线信道是否空闲：

• 空闲 → 进入下一步
• 忙碌（检测到其他设备正在发送）→ 等待一段时间后重新监听

2. 退避计时（Backoff）
   如果多个设备同时检测到信道空闲，它们可能会同时发送数据，导致碰撞。因此，每个设备会：

• 计算一个随机退避时间（Backoff Timer）
• 在此期间继续监听信道，确保它仍然空闲
• 退避时间到达后才发送数据，以减少多个设备同时发送的概率

3. 数据发送与确认（ACK）

• 设备发送数据包后，接收端返回 ACK（确认帧）
• 如果发送端在一定时间内未收到 ACK，则认为数据丢失，重新发送数据

3.2 传输丢包

由于遮挡、信号强度、底噪、距离、天线位置/方向等综合因素导致的传输丢包，这是一个复杂问题。

可以参考：

• Ardupilot开源代码之ExpressLRS性能实测方法
• ExpressLRS硬件实测性能分析
• ExpressLRS开源代码之功能&性能测试
• ExpressLRS开源之RC链路性能测试

4. 逻辑

自适应传输的主要目的，就是应对现场RF情况，优化传输方案，确保两点：

• 高带宽（视频）：从发送端顺利到达接收端
• 低带宽（控制）：从接收端顺利到达发送端

在《OpenIPC开源FPV之Adaptive-Link关键RF参数》中，可以归纳出以下内容。

4.1 可调整参数

• Bitrate (比特率)
• Bandwidth (带宽)
• GI, Guard Interval (保护间隔)
• MCS, Modulation and Coding Scheme (调制编码方案)
• K/N, Coding Rate (编码率)
• Power (功率)
• GOP, Group of Pictures (图像组)

注：频段也是可调，但是通常飞行过程中不做动态调整。

4.2 可监测参数

• RSSI (Received Signal Strength Indicator)
• SNR (Signal-to-Noise Ratio)
• FEC 恢复包数量（FEC Recovered Packets）
• 发送端丢弃包数量（Dropped Packets at Sender）
• 发送端关键帧请求次数（Keyframe Requests from Air Unit）
• 接收端关键帧请求次数（Keyframe Requests from Ground Unit）

4.3 逻辑思路

1. 正常无干扰环境，决定性能的主要指标应该取决于RSSI/SNR底噪
2. 正常无干扰环境，发生丢包之前，应该有FEC恢复报文场景
3. 正常无干扰环境，频繁FEC恢复报文，且数量增加，随之逐步发生接受丢包（发生不应该放弃发送报文）
4. 底噪干扰环境，会整体上，全时间域影响信号质量，常见于接收端环境
5. 局部干扰环境，会偶发性，影响信号质量，常见于发射端环境
6. 局部干扰环境，常见情况：遮挡、信号占位等
7. 局部干扰情况发生，当接收端发现丢包，为时已晚，从时间顺序上已经发生了一段时间
8. 局部干扰-遮挡，发射端收到的心跳报文会丢失；接收端接受报文会丢失，被动应对，如：增加功率，降低比特率，调整K/N值等
9. 局部干扰-占位，发射端通过CSMA/CA可以侦测到，及时应对处理，如：降低比特率
10. 发现异常，要果断、快速、高效应对，然后根据场景逐步尝试恢复链路质量

*注：以上只是简单拍脑袋，整理的一些逻辑思路，提供参考。方便后续更加量化的解决问题，或者从定性到定量的一个过渡思考阶段。 *

5. 总结

当前 adaptive-link 仅简单考虑了 逻辑思路1。

在阳光状态作为一个思路来说是非常不错的，但仍然存在非线性问题，需要较多的实验验证，并且受到环境因素影响。

为此，必须思考更多关于RF方面的特性，依赖量化的理论逻辑，结合实验做出更好的自适应通讯链路方案，以应对复杂的穿越环境（障碍物、干扰、底噪）。

这里，先抛出这个话题来讨论，后续将会更加深入的看看，如何来思考和量化。

6. 参考资料

【1】OpenIPC开源FPV之Adaptive-Link工程解析
【2】OpenIPC开源FPV之Adaptive-Link天空端代码解析
【3】OpenIPC开源FPV之Adaptive-Link地面站代码解析
【4】OpenIPC开源FPV之Adaptive-Link安装
【5】OpenIPC开源FPV之Adaptive-Link关键RF参数