四轴飞控DIY集成FPV功能

四轴飞控DIY简明步骤介绍根据需求（能飞），只是安装了基本的四轴模型必须的组件。

1. 飞控：Kakute F7 AIO V1.5
2. 机架：F450
3. 动力：翱云2212电机（正反一对）x 2 + ESC电调（20A） x 4
4. 桨叶：正反自锁桨叶（一对） x 2
5. 接收机：R9DS
6. 电池：3S 2200mAh 25C
7. 遥控：AT9S Pro

鉴于我们目前采用的是BetaFlight穿越机固件，那必不可少的是FPV飞行。因此，本章节准备集成FPV功能。

Holybro Kakute F7 AIO review

1. 功能需求

1. 能够类似FPV FreeRider类似方式进行第一人称飞行
2. 能够实时的保证传输(低延迟)，便于响应控制
3. 最大可能保证视角(期望看的宽来避免碰撞，避免安全问题)
4. 系统角度视场能达到设备最优化

2. 概念介绍

2.1 制式

NTSC和PAL的区别有颜色编码、图像质量、帧数、分辨率线数。

• PAL标准：每秒25帧，扫描线为625线，奇场在前，偶场在后，标准数字化分辨率为720*576, 画面的宽高比为5：4
• NTSC标准：每秒30帧，电视扫描线为525线，偶场在前，奇场在后，标准数字化分辨率为720*486, 画面的宽高比为4：3

优劣对比

1. PAL自带颜色管理，NTSC则需要手动校准；
2. 图像质量方面PAL的画质要好于NTSC；
3. 帧数上NTSC为29/97帧，PAL则只有25帧；
4. 分辨率上，NTSC的DVD分辨率为720x480，PAL则为720x576；

2.2 显示分辨率

• 480p，720x480
• 720p, 1280x960
• 1080p, 1920×1080

2.3 摄像头线数

线数和分辨率的关系：线数x宽高比=高, 分辨率[线数, 高]
TVL(TVLine)实际上主要用于模拟摄像机，而通常情况下模拟600~700TVL就非常不错了。而随着FPV的需要，实际上很多高线数的摄像头不能采用这种常规的计算方法，因此如果一定要考虑分辨率建议700TVL以下的可以采用上述计算公式。高于这个的更多还是看实际情况和厂家提供的分辨率参数。

高于700线

• 1200线是130万像素左右，分辨率：1280*960=1228800
• 1000线是100万像素左右，分辨率：1280*720=921600

低于700线

1. 700线

• 7004/3=933，实际分辨率是700933
• 70016/9=1244，实际分辨率是7001244

2. 600线，

• 6004/3=560，实际分辨率是600800
• 60016/9=746，实际分辨率是6001066

3. 540线，

• 5404/3=560，实际分辨率是540720
• 54016/9=746，实际分辨率是540960

4. 480线，

• 4804/3=560，实际分辨率是480640
• 48016/9=746，实际分辨率是480853

5. 420线

• 4204/3=560，实际分辨率是420560
• 42016/9=746，实际分辨率是420746

3. 需求分析

1. 第一人称角度的需求，目前看来只有在四轴上放摄像头；
2. 户外飞行的角度，手机、平板、眼镜都可以作为显示装置；

• 手机：通过上次碰到公园小伙伴的情况，手机看存在几个问题：a)有点反光；b)高亮背景，对比度不够；c)一般遥控器上要配特殊支架
• 平板：和手机情况类似，关于支架的问题解决就更加困难；如果分开放置，容易受到周边干扰
• 眼镜：【最优解】无需多说

3. 大多数穿越机都是模拟，因为延迟短。数字存在编码，解码过程。(实际模拟器上略有顿挫感的画面是飞不好的原因之一，当然一开始自己的技术本来就比较菜)
4. 视角的问题，通过查阅资料，考虑摄像头的FOV(Field of View)参数，尽量选择大的。
5. 第二点基本上决定了肥鲨眼镜(目前HDO2 显示分辨率是1280 x 960, 4:3)，所以摄像头也选这个比率，就能发挥两者的最大性能。
6. 还要考虑安装孔位的问题，尽量与Kakute F7 AIO 30.5 x 30.5 mm统一尺寸的，方便塔式安装；也要考虑塔式安装是否能够满足F450机架空间要求。

注：视角FOV是指镜头所能覆盖的范围,(物体超过这个角就不会被收在镜头里),一个摄像机镜头能涵盖多大范围的景物,通常以角度来表示,这个角度就叫镜头的视角FOV。

4. 组件选择

根据上面的的分析以及某宝的各种搜索，最终决定采购如下：

1. 摄像头：Caddx Ant 1200TVL 4:3
2. 图传：PandaRC VT5804M L1 (Buzzer/Mic/IRC Protocol) 5.8G
3. 接收机：FOXEER WILDFIRE 5.8G (Long antenna without Panel Antenna)
4. 眼镜：Fatshark HDO2

5. 接线组装

没有和笔者一致配套的接线图，不过“皇天不负有心人”，找了一个相对接近的图，用这张Holybro Kakute F7的做解释（也很漂亮！！！）。

上面采购的组件，飞控端需要是以下几个组件：

1. 摄像头：采集视频信息
2. 图传：传输视频信号

5.1 摄像头接线

摄像头(Caddx Ant)出了两路线：

1. 第一路（VI & GND & VCC）视频信号及供电线 ==》接飞控Kakute F7 AIO视频专用输入口
2. 第二路（OSD & GND）5按键板连接线 ==》接飞控Kakute F7 AIO串口（可配置）

第二路线主要用于配置摄像头，有一块模拟按键板可以操作配置，也可以接到FC上用遥控器模拟按键板。不过为了简化，且配置好通常不太调整，这里就没有连接飞控。BetaFlight是支持这个OSD按键模拟的，详见BetaFlight模块设计之十九：摄像头按键控制模拟任务分析。

5.2 图传接线

图传(PandaRC VT5804M L1)是一个四合一的集成板子，内部Buzzer/Mic，这个也是个人比较需要的，因为KakuteF7 AIO没有喇叭(有些报警音听不到)和麦克风（想听听上天后飞机的声音^-）。

注：除了这个其他还有4个LED灯条可以控制，主要通过图传板上的按键调整，感觉用途不大，这里也不介绍了。

图传出的排线可以分为三路：

1. 第一路（VO & GND & RX）==》接飞控Kakute F7 AIO专用视频输出和串口（可配置）
2. 第二路（Buzzer） ==》接飞控Kakute F7 AIO喇叭Buzz-
3. 第三路（VCC & GND） ==》接飞控Kakute F7 AIO分电输出（任何一路均可）

6. 组装位置

在测试组装发现了散热问题，之前没有考虑到。相对来说图传比飞控更烫。

1. 图传模块超级热（模组油票孔贴片发烫）
2. KakuteF7 AIO（STM32F7主芯片发烫）

实际装好后，感觉还可以吧（先看看再说）

1. 图传和飞控发热的位置分别安排在不同层，没有堆叠到一起。
2. 塔式两层之间距离大概是5mm。
3. 飞的时候，桨叶已经周边的风会比较大，容易散热。
4. 且该位置不再长时间爆嗮位置。

另外，400mW图传配置下，实测对整体功耗影响不大（没有显著的分钟级电池耗电减少）。

7. FPV功能调试

笔者是在组装之前进行的调试，毕竟装好了如果有问题受到很多限制。比如：

1. 空间受限

• 无法看到LED指示灯（机架或者控制板视线遮挡）
• 按键触摸不便（机架或者走线遮挡）

2. 接线不便

• 插拔线受空间限制，重新更换端口很麻烦
• 有些接线是焊接的，如果重新焊接那就是大工程了

3. 调试不变（组装好之前，有些部件可以分开上电，测试效果）

这里整理了下调试的主要内容：

1. 摄像头+图传频点（频段+通道）与接收机的通信调试；
2. 摄像头参数调试（通过按键板）；
3. 图传IRC通道协议调试；

7.1 摄像头+图传+接收机的通信调试

注：图传和接收机的物理按键配置具体操作这里就不重复描述，直接看官网就好。

7.1.1 频点调试（频段+通道）

这里发现熊猫图传在频点（频段+通道）上的几个问题：

1. 似乎并非表中所有频点都能用（频点表白色部分）
2. 其中部分频点还会有重复，比如：E-CH3和E-CH4都是5665；E-CH6、E-CH7、E-CH8都是5905

总的来说，这个表格真的很奇怪。反正来自官网，也无法解释详细原因，用的时候注意用能用的，且比较正常的频点（频段+通道）就好。
*
注：通过某宝客服反馈厂家了解两个问题：
1）是否有熊猫图传导入频率，功率的配置文件？厂家反馈：无配置文件
2）红色框框内熊猫图传为什么不同通道（在同一个频段），频率是一样的？厂家反馈：无反馈（大约1个礼拜了吧，放弃沟通！！！）
大家仔细看下去，关于VTX配置文件以及F450+KakuteF7的BetaFlight配置我都会给出。
*
相比而言，野火接收机的频点（频段+通道）就比较正规，不重复。
笔者在实际使用的时候，配置在E-CH1，E-CH2，E-CH3，默认采用E-CH1。

7.1.2 功率调试

测试调试过程先随便配置一个功率（比如：通过按键操作，从LED装态灯确认配置25mW，发热低），确保能通信，也不容易烫手。

注1：详细的可以通过后续BetaFlight IRC协议进行配置。

注2：这里遇到一个小问题，非常烦人！！！因为当IRC接着飞控的时候，图传模块配置功率，频段，通道始终不能成功。后来将图传上的Rx与飞控断开，才配置成功的。

7.2 摄像头参数调试

通常情况下，摄像头正确接线，图像肯定有的。

如果真的遇到图线没有，请检查以下几点：

1. 摄像头是否正确接线 GND & VCC & VI ==》 接飞控Kakute F7 AIO专门用于图线接入的GND & VCC & VI
2. 图传是否正确接线 GND & VI ==》接飞控Kakute F7 AIO的VO以及临近的GND
3. 摄像头GND VCC电压范围和驱动功率是否满足摄像头规格要求
4. BetaFlight飞控OSD配置页面有个视频格式，是否Auto（反正不确定就尽量Auto）

注：也许眼镜里面也有图像格式的配置，我没有看到，不过如果可以也配成Auto吧。

言归正传，关于摄像头的配置取决于场景问题，这个摄像头4:3是固定的，而某宝技术支持反馈NTSC和PAL对于摄像头性能以及分辨率没有影响，国内推荐使用PAL。

注1：对于这个某宝的技术支持反馈的这个说法，我不太认同，但是也说不出个专业道道来。目前，我是按照PAL配的（其他参数默认），后续实际长时候再向大家汇报吧。

注2：关于摄像头拍摄视频的问题，请详细参考：关于穿越机FPV视频果冻效应的讨论

7.3 图传IRC通道协议调试

7.3.1 OSD菜单操作方法

BetaFlight模块设计之二十：CMS菜单模块分析从代码角度给出CMS菜单操作方法：

• 打开/ 进入菜单：IS_MID(THROTTLE) && IS_LO(YAW) && IS_HI(PITCH)
• 向上翻页: IS_HI(PITCH)
• 向下翻页：IS_LO(PITCH)
• 向左翻页：IS_LO(ROLL)
• 向右翻页：IS_HI(ROLL)
• 退出选项：IS_LO(YAW)
• 保存菜单：IS_HI(YAW）

7.3.2 图传VTX表格配置

由于OSD菜单选择的是图传的功率，频段，通道，从而向图传模块发送配置命令。而每个图传模块的VTX表格并不严格一致，因此需要我们先配置VTX表格。

关于VTX表格有两种配置方法：

1. 直接从配置文件导入；
2. 手工输入；

注：笔者根据官网提供的规格参数制作了一份VTX配置文件，如有需要可以下载BTFL_vtxtable_PandaRC_VT5804ML1。

无论哪种方法，以下是配置好的VTX表格（0表示不支持的频点）：

7.4 RSSI信号叠加

为了在OSD上显示RSSI信号强度，根据radiolink给出了官方的指南进行了相应的配置。

7.4.1 实测第一次

实测情况：
1）人站在中间A位置（飞机也在中间位置地面近距离62左右，空中大概40）；
2）RSSI大概到C位置，降为25左右；
3）RSSI大概到B位置，降为35左右；
4）B到C位置总长120米左右；
5）飞行高度在5~10米；

目前怀疑问题：（排除遥控接收机天线折断或者有折痕等情况）
1）接收机天线放置不合理，建议垂直朝下或者45度摆放，匹配天线苹果图效果；
2）接收机内部RF放大电路损坏（不过这个买来也没有多少次，怎么会坏？？？？）

注：据反馈应该在目视距离450米的样子，而实际目前使用100米都够呛。至于官方提供的4000米，貌似没有这么理想。

7.4.2 官方推荐测试方法

根据官方测试方法：如何检测AT9S Pro/AT9S/AT9的信号强度（如何检测AT9S Pro/AT9S/AT9的RSSI值）

实际测试结果：-10dB，满足0到-18dB要求。

7.5 实测第二次

BetaFlight Kakute F7 AIO F450试飞示例

BetaFlight Kakute F7 AIO F450试飞

7.5.1 预设条件

• 图传E2，功率100mW
• 遥控接收机（R9DS），天线绑在前支架上
• 公园最长长度120米，宽度大约40~50米
• 人站在中间靠边（保证飞机能在可视距离范围内）
• 飞行高度4~10米
• 检查遥控接收机天线：无弯折损坏情况
• 检查图传天线：未发现天线接触不良（mmcx天线卡扣正常）

7.5.2 测试情况

1. 接收机RSSI（%）

• 地面近距离70-80
• 空中路过头顶50左右
• 公园两端信号20左右

2. 图传信号 （%）

• 地面近距离99
• 空中路过头顶99
• 稍远点（距离人30-40米），70-80
• 公园两端信号偶尔不显示，雪花点增加如图所示（感觉信号丢失前兆）；

3. 接收机SMA位置，工作10分钟，类似图传一样烫（据反馈不应该）
   
   

7.5.3 测试总结

1. 怀疑遥控接收机与遥控器之间存在通信问题 ==》待替换遥控接收机再做测试验证
2. 怀疑图传与接收机之间存在通信问题 ==》怀疑接收机问题，待进一步验证

7.6 实测第三次

7.6.1 R12DSM接收机

为排除第二次测试问题1：替换遥控接收机再做测试验证。

7.6.2 测试情况

1. 在112米左右的位置，信号百分比显示31；
2. 静态起飞前，遥控器靠近10cm左右，信号显示80左右；
3. 静态起飞前，人站直，大约2米左右，信号显示55左右；
4. 飞机飞过头顶附近50左右；
5. 上述情况都在可视直线范围；

7.6.3 测试总结

R9DS接收机更换R12DSM后，未见明显效果改善。

7.6.4 分析数据

从BetaFlight更新数据代码分析显示

1. rssi值是通过辅助通道获得，该值来源于遥控器。
2. 原始值rawPwmRssi范围 [1000;2000]
3. 经过scaleRange范围[0;1023]
4. 通过飞控OSD数据更新到屏幕上以百分比显示osdRssi = getRssi() * 100 / 1024;

从而可以理解：

• 屏幕上显示20（百分比）的时候，相当于原始值rawPwmRssi=1200左右。
• 靠近接收机Aux6（配置辅助RSSI通道），可以看到rawPwmRssi=1885，如果显示到OSD上应该是88（百分比）。

\src\main\rx\rx.c
void updateRSSI(timeUs_t currentTimeUs)
{
    switch (rssiSource) {
    case RSSI_SOURCE_RX_CHANNEL:
        updateRSSIPWM();
        break;
    case RSSI_SOURCE_ADC:
        updateRSSIADC(currentTimeUs);
        break;
    case RSSI_SOURCE_MSP:
        if (cmpTimeUs(micros(), lastMspRssiUpdateUs) > DELAY_1500_MS) {  // 1.5s
            rssi = 0;
        }
        break;
    default:
        break;
    }
}

static void updateRSSIPWM(void)
{
    // Read value of AUX channel as rssi
    int16_t pwmRssi = rcData[rxConfig()->rssi_channel - 1];

    // Range of rawPwmRssi is [1000;2000]. rssi should be in [0;1023];
    setRssiDirect(scaleRange(constrain(pwmRssi, PWM_RANGE_MIN, PWM_RANGE_MAX), PWM_RANGE_MIN, PWM_RANGE_MAX, 0, RSSI_MAX_VALUE), RSSI_SOURCE_RX_CHANNEL);
}

void setRssiDirect(uint16_t newRssi, rssiSource_e source)
{
    if (source != rssiSource) {
        return;
    }

    rssi = newRssi;
}

\src\main\osd\osd_elements.c
static void osdElementRssi(osdElementParms_t *element)
{
    uint16_t osdRssi = getRssi() * 100 / 1024; // change range
    if (osdRssi >= 100) {
        osdRssi = 99;
    }

    tfp_sprintf(element->buff, "%c%2d", SYM_RSSI, osdRssi);
}

7.7 遥控器检测分析

7.7.1 乐迪检测结果

2022.06.24 乐迪售后反馈：遥控器检测正常

7.7.2 乐迪售后建议

1. 怀疑AUX6信号通道设置方向问题：建议相位反向设置（就是说信号增强的时候百分比降低，信号减弱百分比增加）
2. 不要采用AUX6信号通道设置，该值仅仅是一种参考，要以遥控器自身RSSI为准（乐迪自身遥控器，接收机，飞控，图传等整套航模未见上述问题，且OSD显示很准。）
3. 采用遥控器设置振动提示信号告警，比如：-95db

注：60米可视距离反馈OSD百分比信号只有20%的情况，首次接到上述用户反馈。

7.7.3 针对上面的建议分析

1. 飞机放置地面，近距离（30cm），OSD信号百分比80左右；人站直（1.5左右高度遥控器），OSD信号百分比70左右；飞机飞过头顶OSD信号50%左右；60-80米左右飞机高度5米左右，OSD信号20%； ==》信号强度与遥控器通道相位反向可能性可以排除
2. AUX6信号通道反馈数据来自遥控器，该通道遥控器提供数值RSSI Value是什么单位需要明确定义；从BetaFlight源代码角度是1000-2000之间的数据，以百分比方式展示在OSD上。从30cm的AUX6 1800+ 对应80% 到信号弱 1200+ 对应20%的角度来看，比较符合百分比的概念。==》乐迪官网链接：如何检测AT9S Pro/AT9S/AT9的信号强度（如何检测AT9S Pro/AT9S/AT9的RSSI值）看似有对应的联调测试动作，实际情况60-80米可是距离就显示20%的信号强度应用价值不高。
3. 如果遥控器自身的RSSI dbm数告警能够准确反应距离和通信情况（完美解决信号强度告警问题）；那么理论上遥控器通过AUX6通道的RSSI Value也能准确。

从实际应用角度，尤其是穿越的角度，能够在OSD上显示动态RSSI变化，更具有应用价值。能让飞控操作人员更好的了解当前场景的RSSI强度情况，尤其在穿越时提前判断是否会导致失联。

总结：针对上面三个乐迪反馈的建议，个人感觉既然官网已经考虑到对BetaFlight的 OSD显示RSSI Value做了支持，就应该做好充分的测试，以满足并确保对开源的支持（尤其是自身不开源的情况）。

7.7.4 关于乐迪遥控通过AUX6通道反馈RSSI Value的问题

7.7.4.1 从实测视频数据上看

基于动态视频，估算数据，基本稳定（不出现遮挡信号20-70这种大幅度变动）：

可视距离	信号百分比强度
0	70
10	55
20	50
30	40
40	25
60	20

7.7.4.2 从信号强度与距离趋势上看

从其他实验RSSI曲线拟合趋势看。实际我们遥控器或者接收机灵敏度可能在-110dbm（猜测），RF芯片，天线，PCB设计，天气等对于这个曲线都有影响。我们这里只是给出一个拟合例子看趋势。

7.7.4.3 应用角度分析

根据拟合趋势以及实际测试数据的情况看，遥控器在AUX6提供的RSSI Value在非常近的距离就快速下降到了20%（60-80米）。

如果按照乐迪官网规格书上R9DS 4000米可视距离，后面的3920米 RSSI Value从百分比的角度只有20%的下降空间。

从应用的角度，人感受信号变差，最终导致信号丢失的角度来说，80米的80%信号百分比下降，对比3920的20%信号百分比下降，差距太大，体验太差。

从使用者的角度来说，我们可能更期望如下效果：

1. 4000米的距离能够线性的信号百分比下降；
2. 当接近4000 x (100% - 20%) = 3600米的时候，信号百分比20%，提示用户信号已经变差，可以返航；
3. 前面1）2）是考虑可视距离，当遇到遮挡，信号可能极具减弱，表示信号即将丢失；比如：70% 突然下降到50%，可能由于穿越过门框、树林，导致信号变差，提示飞控人员能够根据实际信号强度进行飞行策略调整；

而上述乐迪遥控器提供的RSSI Value无法提供上述飞行体验，无法及时及早提供信息给飞控操作人员，导致丢机、炸机等风险。

鉴于乐迪遥控器检测硬件正常且某宝商家反馈乐迪自身全套飞控，图传，遥控，接收机，OSD显示及遥控器反馈信号强度都非常准确。怀疑遥控器固件在处理RSSI Value时与BetaFlight OSD RSSIValue 百分比映射关系出现不匹配，无法满足上述要求，导致体验差。

注1：鉴于上述情况，经乐迪售后沟通：乐迪尚无上述BetaFlight支持计划。只能考虑退货。

注2：关于到底RSSI Value的关系定义可以参考：BetaFlight模块设计之三十五：RSSI信号强度&链路稳定性分析。

7.8 AT9SPro + R12DSM可视拉距测试

测试视频：BetaFlight Kakute F7 AIO F450 + AT9SPro + R12DSM可视通信测距

BetaFlight Kakute F7 AIO F450 + AT9SPro + R12DSM可视通信测距

7.8.1 信号丢失前视频

7.8.2 信号丢失时视频

7.8.3 实测情况分析

实际测试情况，大于300米直接信号丢失，导致失控坠机。

注：遥控器根据乐迪售后建议设置-95dBm，实际情况没有任何振动预警，还是摔了。

==》结论：用于穿越机飞行，非常危险，不建议使用该遥控器和接收机。

不敢挂狗等其他设备，飞的尽量底，只要可视就好。防止摔得太厉害，结果还是挂了。

7.9 TX12 + ELRS Transmitters/Receiver + 50mW

鉴于前面的问题，期望通过调整以下参数，得到较优的效果：

1. 高频头增加发射功率：1000mW（可选）
2. 调整更好的天线：T型天线
3. 绕射性更好的频率： 915Mhz（相对于2.4G）

注：从通信速率的角度915Mhz 200Hz，2.4Ghz 500Hz角度考虑，其实200Hz相当于5ms左右的响应时间。从人的反应时间看，在20ms以内基本上没有太多延时的问题。

7.9.1 50mW测试条件

• BetaFlight Kakute F7 AIO F450
• TX12 (OpenTx)
• ELRS Nano Transmitter 915Mhz with 50mW (ESP32 + ESX1276)
• ELRS Receiver 915Mhz (ESP01f + SX1276)
• 发射&接收，均采用T型天线

7.9.2 50mW测试视频

120米长公园测试视频

BetaFlight Kakute F7 AIO F450 + TX12 + ELRS(915Mhz)

注：这里OSD显示的飞行时间和dbm有冲突，所以dBm没有四位数，实际是2位数（关注数据的朋友请注意下，是我OSD配置没有配好）。

公园及测试人员位置情况

7.9.3 50mW测试结果

1. 地面近距离30cm左右，70%左右信号强度【这个没有太多实际意义，仅考虑一个对比】
2. 飞过头顶 50%以上信号强度
3. 最远110-120米距离，近地面（3-4米）空中信号强度35%
4. 最远110-120米距离，高空（10米）空中信号强度40%

注：估计120米左右近地时由于中间两颗树的阻挡，信号略有损失。

7.10 ELRS Transmitters/Receiver信号百分比强度分析

关于CRSF协议 BetaFlight模块设计之三十五：RSSI信号强度&链路稳定性分析有一些初步描述。我们本次购买的设备究竟如何来给出或者定义这个信号强度百分比的？

这也是为什么我们感觉AT9S Pro 60-80米左右就只有20%信号强度，但是厂家反馈“没事，继续可以飞。”，非常困扰我们的问题。

从下面7.10.1ExpressLRS代码和7.10.2BetaFlight代码：
我们可以看到双方主要通过“CRSF_FRAMETYPE_LINK_STATISTICS = 0x14”这帧报文来提供相关信号强度的数据。

BetaFlight通过线性映射[-130dBm, 0]映射到信号强度[0,100]：

当dBm值对应如下强度时，信号百分比强度与OSD显示一致：

1. -63dBm：百分比信号强度：(130-63)/130 x 100% = 51%
2. -70dBm：百分比信号强度：(130-70)/130 x 100% = 46%
3. -82dBm：百分比信号强度：(130-82)/130 x 100% = 36%

在50mW发射功率情况下：120米空旷可是距离，最远处大约35%信号百分比强度。

TODO：后续需要拉远测试下更高发射功率，更远距离的情况。

7.10.1 ExpressLRS代码

ExpressLRS\src\lib\CRSF\CRSF.cpp
void CRSF::sendLinkStatisticsToFC()
{
#if !defined(DEBUG_CRSF_NO_OUTPUT)
    if (!OPT_CRSF_RCVR_NO_SERIAL)
    {
        constexpr uint8_t outBuffer[] = {
            LinkStatisticsFrameLength + 4,
            CRSF_ADDRESS_FLIGHT_CONTROLLER,
            LinkStatisticsFrameLength + 2,
            CRSF_FRAMETYPE_LINK_STATISTICS
        };

        uint8_t crc = crsf_crc.calc(outBuffer[3]);
        crc = crsf_crc.calc((byte *)&LinkStatistics, LinkStatisticsFrameLength, crc);

        if (SerialOutFIFO.ensure(outBuffer[0] + 1))
        {
            SerialOutFIFO.pushBytes(outBuffer, sizeof(outBuffer));
            SerialOutFIFO.pushBytes((byte *)&LinkStatistics, LinkStatisticsFrameLength);
            SerialOutFIFO.push(crc);
        }
    }
#endif // DEBUG_CRSF_NO_OUTPUT
}

ExpressLRS\src\lib\CrsfProtocol\crsf_protocol.h
typedef enum
{
    CRSF_FRAMETYPE_GPS = 0x02,
    CRSF_FRAMETYPE_VARIO = 0x07,
    CRSF_FRAMETYPE_BATTERY_SENSOR = 0x08,
    CRSF_FRAMETYPE_BARO_ALTITUDE = 0x09,
    CRSF_FRAMETYPE_LINK_STATISTICS = 0x14,
    CRSF_FRAMETYPE_OPENTX_SYNC = 0x10,
    CRSF_FRAMETYPE_RADIO_ID = 0x3A,
    CRSF_FRAMETYPE_RC_CHANNELS_PACKED = 0x16,
    CRSF_FRAMETYPE_ATTITUDE = 0x1E,
    CRSF_FRAMETYPE_FLIGHT_MODE = 0x21,
    // Extended Header Frames, range: 0x28 to 0x96
    CRSF_FRAMETYPE_DEVICE_PING = 0x28,
    CRSF_FRAMETYPE_DEVICE_INFO = 0x29,
    CRSF_FRAMETYPE_PARAMETER_SETTINGS_ENTRY = 0x2B,
    CRSF_FRAMETYPE_PARAMETER_READ = 0x2C,
    CRSF_FRAMETYPE_PARAMETER_WRITE = 0x2D,

    //CRSF_FRAMETYPE_ELRS_STATUS = 0x2E, ELRS good/bad packet count and status flags

    CRSF_FRAMETYPE_COMMAND = 0x32,
    // KISS frames
    CRSF_FRAMETYPE_KISS_REQ  = 0x78,
    CRSF_FRAMETYPE_KISS_RESP = 0x79,
    // MSP commands
    CRSF_FRAMETYPE_MSP_REQ = 0x7A,   // response request using msp sequence as command
    CRSF_FRAMETYPE_MSP_RESP = 0x7B,  // reply with 58 byte chunked binary
    CRSF_FRAMETYPE_MSP_WRITE = 0x7C, // write with 8 byte chunked binary (OpenTX outbound telemetry buffer limit)
    // Ardupilot frames
    CRSF_FRAMETYPE_ARDUPILOT_RESP = 0x80,
} crsf_frame_type_e;

7.10.2 BetaFlight代码

betaflight\src\main\rx\crsf_protocol.h
typedef enum {
    CRSF_FRAMETYPE_GPS = 0x02,
    CRSF_FRAMETYPE_BATTERY_SENSOR = 0x08,
    CRSF_FRAMETYPE_HEARTBEAT = 0x0B,
    CRSF_FRAMETYPE_LINK_STATISTICS = 0x14,
    CRSF_FRAMETYPE_RC_CHANNELS_PACKED = 0x16,
    CRSF_FRAMETYPE_SUBSET_RC_CHANNELS_PACKED = 0x17,
    CRSF_FRAMETYPE_LINK_STATISTICS_RX = 0x1C,
    CRSF_FRAMETYPE_LINK_STATISTICS_TX = 0x1D,
    CRSF_FRAMETYPE_ATTITUDE = 0x1E,
    CRSF_FRAMETYPE_FLIGHT_MODE = 0x21,
    // Extended Header Frames, range: 0x28 to 0x96
    CRSF_FRAMETYPE_DEVICE_PING = 0x28,
    CRSF_FRAMETYPE_DEVICE_INFO = 0x29,
    CRSF_FRAMETYPE_PARAMETER_SETTINGS_ENTRY = 0x2B,
    CRSF_FRAMETYPE_PARAMETER_READ = 0x2C,
    CRSF_FRAMETYPE_PARAMETER_WRITE = 0x2D,
    CRSF_FRAMETYPE_COMMAND = 0x32,
    // MSP commands
    CRSF_FRAMETYPE_MSP_REQ = 0x7A,   // response request using msp sequence as command
    CRSF_FRAMETYPE_MSP_RESP = 0x7B,  // reply with 58 byte chunked binary
    CRSF_FRAMETYPE_MSP_WRITE = 0x7C,  // write with 8 byte chunked binary (OpenTX outbound telemetry buffer limit)
    CRSF_FRAMETYPE_DISPLAYPORT_CMD = 0x7D, // displayport control command
} crsfFrameType_e;

betaflight\src\main\rx\crsf.c
static void handleCrsfLinkStatisticsFrame(const crsfLinkStatistics_t* statsPtr, timeUs_t currentTimeUs)
{
    const crsfLinkStatistics_t stats = *statsPtr;
    lastLinkStatisticsFrameUs = currentTimeUs;
    int16_t rssiDbm = -1 * (stats.active_antenna ? stats.uplink_RSSI_2 : stats.uplink_RSSI_1);
    if (rssiSource == RSSI_SOURCE_RX_PROTOCOL_CRSF) {
        if (rxConfig()->crsf_use_rx_snr) {
            // -10dB of SNR mapped to 0 RSSI (fail safe is likely to happen at this measure)
            //   0dB of SNR mapped to 20 RSSI (default alarm)
            //  41dB of SNR mapped to 99 RSSI (SNR can climb to around 60, but showing that is not very meaningful)
            const uint16_t rsnrPercentScaled = constrain((stats.uplink_SNR + 10) * 20, 0, RSSI_MAX_VALUE);
            setRssi(rsnrPercentScaled, RSSI_SOURCE_RX_PROTOCOL_CRSF);
#ifdef USE_RX_RSSI_DBM
            rssiDbm = stats.uplink_SNR;
#endif
        } else {
            const uint16_t rssiPercentScaled = scaleRange(rssiDbm, CRSF_RSSI_MIN, 0, 0, RSSI_MAX_VALUE);
            setRssi(rssiPercentScaled, RSSI_SOURCE_RX_PROTOCOL_CRSF);
        }
    }
#ifdef USE_RX_RSSI_DBM
    setRssiDbm(rssiDbm, RSSI_SOURCE_RX_PROTOCOL_CRSF);
#endif

#ifdef USE_RX_LINK_QUALITY_INFO
    if (linkQualitySource == LQ_SOURCE_RX_PROTOCOL_CRSF) {
        setLinkQualityDirect(stats.uplink_Link_quality);
        rxSetRfMode(stats.rf_Mode);
    }
#endif

#ifdef USE_RX_LINK_UPLINK_POWER
    const uint8_t crsfUplinkPowerStatesItemIndex = (stats.uplink_TX_Power < CRSF_UPLINK_POWER_LEVEL_MW_ITEMS_COUNT) ? stats.uplink_TX_Power : 0;
    rxSetUplinkTxPwrMw(uplinkTXPowerStatesMw[crsfUplinkPowerStatesItemIndex]);
#endif

    DEBUG_SET(DEBUG_CRSF_LINK_STATISTICS_UPLINK, 0, stats.uplink_RSSI_1);
    DEBUG_SET(DEBUG_CRSF_LINK_STATISTICS_UPLINK, 1, stats.uplink_RSSI_2);
    DEBUG_SET(DEBUG_CRSF_LINK_STATISTICS_UPLINK, 2, stats.uplink_Link_quality);
    DEBUG_SET(DEBUG_CRSF_LINK_STATISTICS_UPLINK, 3, stats.rf_Mode);

    DEBUG_SET(DEBUG_CRSF_LINK_STATISTICS_PWR, 0, stats.active_antenna);
    DEBUG_SET(DEBUG_CRSF_LINK_STATISTICS_PWR, 1, stats.uplink_SNR);
    DEBUG_SET(DEBUG_CRSF_LINK_STATISTICS_PWR, 2, stats.uplink_TX_Power);

    DEBUG_SET(DEBUG_CRSF_LINK_STATISTICS_DOWN, 0, stats.downlink_RSSI);
    DEBUG_SET(DEBUG_CRSF_LINK_STATISTICS_DOWN, 1, stats.downlink_Link_quality);
    DEBUG_SET(DEBUG_CRSF_LINK_STATISTICS_DOWN, 2, stats.downlink_SNR);
}

7.11 TX12 + ELRS Transmitters/Receiver + 500mW

7.11.1 500mW测试条件

• BetaFlight Kakute F7 AIO F450
• TX12 (OpenTx)
• ELRS Nano Transmitter 915Mhz with 500mW (ESP32 + ESX1276)
• ELRS Receiver 915Mhz (ESP01f + SX1276)
• 发射&接收，均采用T型天线

7.11.2 500mW测试视频

400米长公园测试视频

BetaFlight Kakute F7 AIO F450 +ELRS(915Mhz)+500mW

注：估计200米左右有一段跨过一排大树，所以升高高度信号会好一点。

7.11.3 500mW测试结果

这里因为担心山里丢机找不到，所以没有继续飞过去。

在大约400m处，信号百分比强度39%，-77dBm，信号质量100。相信更远一点500米不会是问题。

更远距离待后续测试，详见：四轴飞控DIY Mark4 - RTH/GPS Rescure。

8. 整体FPV效果

• BTFL_backup_KakuteF7_20220615配置文件
• BTFL_backup_KakuteF7_20220704配置文件
• BTFL_vtxtable_PandaRC_VT5804ML1 VTX配置文件
  目前，这个ESC（Electronic Speed Control）没有开源BLHeliSuite支持，因此与电机相关的振动都无法很好的做过滤，整体上感觉不是很好。

下面给个干净点的照片，这个是经常试飞的公园^_

补充1：血的教训

这里补充一个血的教训，也是一个插曲，导致整个FPV功能集成出了一个大的波折。

SBUS误插到PWM3个地的位置，导致5V对GND短路，飞控的贴片一体成型0402封装大电流电感(18uh)直接烧掉（徐徐青烟！！！徐徐青烟！！！徐徐青烟！！！），重要的事情说三遍。

为了修复这个电感花了大力气，因为左右都是贴片电阻。除此之外，这个规格180（18uh）的电感，没有对应的规格，0402通常最大只有100（10uh），最后和商家对接了，才搞了一个220（22uh）的【本着选大不选小的原则】。2天的路程+1天的焊接修复，心疼啊！！！

这个小插曲也请大家注意接线，一定要仔细检查。

刚开始有问题的时候其实我是笔记本电脑usb供电，飞控不亮灯，笔记本提示usb功耗过大（因为短路了）。没有引起我的重视，直接上了电池，结果把降压DC2DC的电感给当保险丝烧断了，好大的一阵青烟(smoke！！！smoke！！！smoke！！！)

当时如果在笔记提示usb功耗过大，飞控灯不亮的时候，引起重视，着重检查那就不会出现这个问题了。

所以，一定要仔细，仔细仔细再仔细！！！

补充2：试飞小插曲

试飞没注意，结果不小心飞到树上去了，啃爹啊！还好这种云杉树分支很多而且均匀，可以当梯子，自己没费太多力，总算是爬上去，把四轴给拿了下来^_。

树上挂住以后就是这个场景，貌似还很安逸的位置啊。

补充3：TX12 + ExpressLRS 915MHz 硬件异常

详见：【TX12 + ExpressLRS 915MHz RC控制链路配置及问题汇总】

补充4：摄像头OSD菜单控制方法(不推荐)

1. 映射端口（飞控固件内已默认映射）

resource camera_control B00

2. 设置为硬件PWM模式(有软件PWM、硬件PWM、DAC三种，设置为硬件PWM即可)

set camera_control_mode = hardware_pwm

3. 设置遥杆操作时的延时过滤，避免连击，根据个人操作体验设定，单位是毫秒，范围是100-500ms

set camera_control_key_delay = 180

4. 设置摄像头内部电阻，470即47K，根据实际所使用的摄像头而定

set camera_control_internal_resistance = 470

5. 设置摄像头的的OSD引脚在悬空状态时的电压，单位是mv，330即3300mv=3.3v

set camera_control_ref_voltage = 330

• 以上3-4步骤需要根据实际使用的摄像头的硬件信息来输入参数，可咨询具体的摄像头厂家是否支持并获取相关参数。
• 以上CLI命令设置并且每条都能得到响应的时候，最后输入save保存并自动重启即可正常使用。
• 摄像头OSD菜单触发方式：油门中位，俯仰向上，即可进入摄像头的调参界面(OSD显示)。

注：有的摄像头可能还需要外接电阻之类的硬操作，所以请提前与硬件厂家确认。