一个舵机，一只可变电容。
端馈半波天线挂起来极简单，调起来极烦。这台天调就是来终结这件事的：ESP32-S3 转一只舵机，把驻波压下去——而驻波桥根本不装在天调里。
端馈半波天线（EFHW）挂起来简单得让人愉快，调起来烦得让人恼火。在同一个波段里挪一挪频率，馈点阻抗就远远跑开 50 欧；要是跨三个波段换着用，你会在那儿拧半天旋钮、反复读驻波表。EFHW Fuchs ATU V3.0 就是为了终结这件事造的：ESP32-S3 转一只舵机带动的空气可变电容，把驻波压下来——而驻波桥完全不在天调里。
这篇走一遍硬件、匹配网络和调谐算法，讲清一台约 430 元的设备为什么能覆盖 40 米到 10 米，还包括全部 WARC 波段。
硬件平台
一颗 ESP32-S3、一个舵机、一只空气可变电容，没有 Arduino 层。
核心是 ESP32-S3-WROOM-1：双核 Xtensa LX7 跑到 240 MHz，512 KB SRAM，16 MB flash，跑 ESP-IDF v5.x 的原生 C 加 FreeRTOS。没有 Arduino 层，也没有 Linux：只有一个实时内核，和三个职责定义得非常清楚的任务。
| 部件 | 规格 |
|---|---|
| 主控 | ESP32-S3-WROOM-1，LX7 双核 240 MHz，512 KB SRAM，16 MB flash |
| 舵机 | MG996R，6 伏，10 kg·cm，0.17 秒/60° |
| 舵机 PWM | GPIO1 上的 LEDC，50 Hz，500–2500 微秒 ↔ 0–180° |
| 舵机供电 | GPIO2 → 2N2222A → IRF9540 P 沟道 MOS，用来开关 6 伏那一路 |
| bias-T 监视 | GPIO5，ADC1_CH4，12 位，47 k + 10 k 分压（5.7:1） |
| 状态灯 / 蜂鸣器 | GPIO6 / GPIO7 |
供电链路值得从上到下看一遍，因为它解决的是远程天线的一个经典问题：从同轴电缆上取电。bias-T 把 13.8 伏直流注到馈线上；天调把它分成三路：LM2940CT-12 出 12 伏，DC-DC 降压出舵机要的 6 伏，AMS1117-3.3 给 ESP32。一根同轴电缆，不用第二块电池，不用太阳能板——那只盒子除了天线和馈线，什么也不用接。
舵机供电由 MOS 管门控，理由是：通电但闲置的舵机，在无人值守的天线端是白白的 300 毫安消耗。一次调谐结束，固件把 6 伏整条切断；电容靠机械结构停在原位，所以天线保持匹配，而舵机静态电流为零。
匹配网络
舵机驱动的 L 型网络，以及为什么一只可变电容就够了。
天调用一只 T200-6 羰基铁粉环做阻抗变换，再加一只舵机带动的空气可变电容：
| 参数 | 取值 |
|---|---|
| 磁环 | T200-6（μ=8），外径 50.8 mm，内径 31.8 mm，高 14 mm，AL ≈ 10.5 nH/N² |
| 匝数 | 初级 2 匝 : 次级 14 匝 |
| 阻抗比 | (14/2)² = 49:1 → 输入 50 欧，输出约 2450 欧 |
| 电容 | 发射机级空气可变，10–500 pF，耐压 ≥5 kV（片距 ≥1.5 mm） |
| 舵机耦合 | MG996R 经 3:1–6:1 减速 |
| 调谐范围 | 10 pF 时最高 35.1 MHz → 500 pF 时最低 4.96 MHz |
这里有两个工程细节值得说。第一，空气可变电容是唯一的调谐元件：没有切换电感组，没有继电器噼啪响。这是物料能压到 430 元、故障模式能收敛到「只有一个运动部件」的原因。第二，磁环被大幅低于额定值使用：7.1 MHz、100 瓦时峰值磁通约 12.7 mT，而饱和极限是 600 mT，余量 47 倍，所以就算比赛日下午连续工作，磁芯也不会明显发热。
驻波检测到底在哪
有意思的地方，是这只桥不在哪儿。
让这个设计有意思的决定是：天调里没有驻波桥。没有串联匹配检波器，没有 BAT41 二极管对，没有 FT37-43 磁环，也没有校准电位器。驻波由一台完全独立的仪表测量，再经 WebSocket 送过来：
ATR-1000 → MRRC 服务器 → WebSocket（JSON）→ ESP32-S3 → tune_engine_feed_swr()
这是 SDD 里明确记下的一条架构决策（AD-003）：把桥从天调的物料表里删掉，等于把一整类校准与元件公差问题，从一台挂在天线杆上的设备里删掉。代价也是诚实的，而且必须说清楚：网络断开时这只天调无法调谐。对一台常设台站、MRRC 服务器常年在线的场景，这笔交换很划算；对便携架台，这是一条你该提前知道的约束。
调谐算法
四个阶段：查缓存、粗扫、细扫、锁定。
调谐引擎（tune_engine.c）是一台四阶段状态机：
- 阶段一 · 查缓存（不到 1 秒）：每次调谐成功，把胜出的电容位置写进 NVS flash，按频率作键（
"f" + 频率 kHz，例如 7.040 MHz 记作f7040）。模糊查找接受目标频率 ±50 kHz 内的存档位置。命中率很高，因为 40 米到 10 米按 50 kHz 步进，大约 2000 条就能覆盖，只占 24 KB 分区。 - 阶段二 · 粗扫：以较大的角度步进扫过电容行程，先找出驻波下降的大致区间。粗扫只求方向对，不求精确。
- 阶段三 · 细扫（仅在粗扫没命中时）：在最有希望的角度附近小步进收窄，直到驻波到阈值以内。
- 阶段四 · 锁定并保存：停舵机、断 6 伏舵机供电、把最终角度写回缓存。整个过程有超时保护：扫完一圈仍不达标就停下来报告，而不是一直转下去。
安全与故障检测
驻波压不下去的时候，会发生什么。
远程天线调谐器的失败方式必须被预先设计，否则它会在你不在场的时候把功放烧掉。几条基本规则：调谐期间发射功率受到限制；bias-T 电压由 ADC 持续监视，异常时停止动作；舵机有动作时间上限，避免堵转；任何阶段只要驻波不降反升，就回退到上一个已知良好的位置。天调不做「猜」，它做的是：停在一个已知安全的位置，并把这次失败如实报告上去。
FreeRTOS 架构
三个任务，各干各的活。
固件里只有三个任务，职责边界划得很清楚：一个负责网络与协议（WebSocket 连接、JSON 收发），一个负责舵机与调谐状态机，一个负责监视与看门狗（bias-T 电压、超时、异常上报）。这样划分的好处是：网络卡住不会让舵机停在半路，调谐中的长动作也不会把心跳饿死。
JSON 协议
一次调谐一条消息，带一个用于比较候选位置的分数。
服务器与天调之间是一条很薄的 JSON 契约：天调上报状态与当前驻波，服务器下发调谐指令与功率许可。每次尝试都会带一个分数回传，于是服务器能比较不同候选位置的优劣，而不只是看「过没过阈值」。协议保持薄的另一个好处是：它可以在没有天线、没有射频的环境里被完整测试。