理解 WSJT-X 3.1 improved 中的 FT8 解码器设置

JTDX 长期以来一直提供很有帮助的说明，解释其解码器设置如何工作。这些说明一直很有价值，因为它们清楚地强调了一个重要原则：

这就是关键原则。

但是到了 2026 年，如果你关注的是 FT8/FT4 实际操作中的性能，讨论的背景已经发生了变化。

WSJT-X 3.1 improved 已经不再只是“标准 WSJT-X 加上一些附加功能”。大量来自实际操作的解码理念——其中也包括许多 JTDX 用户会感到非常熟悉的思路——已经被有意义地融入其中。到了现在，再随意拿它与 WSJT-X 2.7 或更早版本比较，坦率地说，已经没有太大参考价值。

说得更直接一点：对于一般操作者而言，WSJT-X 3.1 improved 现在完全值得被认真视为首选之一。

当然，等待 JTDX 的下一个 GA 正式版本也是一种选择。但如果你优先考虑的是实际解码性能、现有功能、更新活跃度，以及今天真正能够安装并使用的软件，那么使用已经存在且已经很强的方案，显然更加理性。

这并不意味着 JTDX 没有自己的位置。如果有人非常喜欢 JTDX 的界面，这完全是继续使用它的合理理由。但这与解码能力和实际优化是两个不同的问题。

本文并不是想再列一份“推荐设置清单”。我更想讨论一个更深层的问题：

所谓 FT8 解码器优化到底是什么？更具体地说，WSJT-X 3.1 improved 里的“Decode Start”设置究竟做了什么？

先给出实际结论

先从 Normal 开始。如果 CPU 余量充足，可以尝试 3-Stage。如果时间余量更重要，则使用 Early。

先从实际结论说起。

调整 FT8 解码器时最重要的原则并不是：

“使用最重、最强的所有设置。”

真正的原则是：

“使用你的系统能够在 15 秒周期内稳定完成的、最激进的设置。”

这是完全不同的思考方式。

对许多电台来说，以下设置可以作为合理的起点：

这不一定是最终答案，但它是一个可靠的起点。如果 CPU 还有余量，可以进一步提高激进程度。如果开始出现延迟、过晚完成或不稳定，就应该退回一步。

至于 Decode Start，可以先用下面的方式做实际理解：

以上是实际层面的总结。但这一设置真正有趣的地方，比这个简单总结更深。

Decode Start 并不仅仅是在“更早开始还是更晚开始”之间选择。它与解码器使用多少阶段、这些阶段在时间轴上的位置，以及计算工作如何分布在 FT8 周期内密切相关。

这才是问题的核心。

为什么 WSJT-X 3.1 improved 如今值得认真关注

要理解这一点的重要性，最好先退一步看整个背景。

过去几年中，WSJT-X improved 已经远远超越了一个“带额外选项的分支版本”。它逐步变成了一个用于实践真实解码理念、提高界面灵活性并加入面向实际操作改进的平台。

只要实际使用当前的 improved 版本一段时间，就会发现一件很明显的事：

过去那个“它与标准 WSJT-X 2.7 相比如何？”的问题，已经不是最有意义的问题了。

现在更值得问的是：

• WSJT-X 3.1 improved 作为今天实际使用的 FT8/FT4 工具，到底有多好？
• 其中融入了多少来自真实操作经验的解码思路？
• 操作者又应该如何根据自己的电台、CPU 和操作重点进行调整？

因此，本文的重点并不是制作比较表，而是讨论如何聪明地使用这个软件。

一旦讨论从“有哪些设置？”转向“这些设置应该怎样使用？”，就必须进一步理解这些设置在 15 秒 FT8 周期内部究竟代表什么。

各项设置分别起什么作用

“更激进”并不自动等于“更好”

在集中讨论 Decode Start 之前，有必要先明确应该如何整体理解 FT8 解码器的各项设置。

一个很常见的误解是：

设置越重，性能就一定越好。

听起来似乎有道理，但 FT8 并不是这样工作的。

因为 FT8 以 15 秒为一个周期，真正重要的是下面四件事之间的平衡：

1. 开始解码之前等待并收集多少信号
2. 搜索候选消息时要搜索多深
3. 所有这些处理能否及时完成
4. 愿意容忍多少错误解码

从这个角度看，FT8 优化并不是追求“最大功率”，而是如何分配有限的处理时间。

这种视角会改变我们对每一项设置的理解。

解码线程数量

对大多数操作者来说，Auto 仍然是最好的起点。单纯强制使用更多线程并不能保证结果更好。操作系统调度、后台负载、核心拓扑以及系统整体行为都会产生影响。

解码轮次

更多解码轮次可以提高恢复弱信号或模糊信号的机会，但也会消耗更多 CPU 时间。系统性能强时，3 次可能值得尝试；对很多电台来说，2 次是最合理的默认值；在性能受限的硬件上，1 次可能更安全。

Decoder Sensitivity

实际理解起来很直接：

• Minimum 更轻
• Low thresholds 较为均衡
• Subpass 更激进，但也更重

Subpass 并不是“免费的性能”。它意味着投入更多计算工作，以换取恢复更弱或更困难信号的机会。

关于 Fast / Normal / Deep 与 Multithreaded FT8 Decoder

这一部分特别容易被误解。因为 Fast / Normal / Deep 与 Multithreaded FT8 decoder 出现在同一个设置页面上，很自然会让人认为它们只是同一控制项的不同版本。但源代码显示，它们实际上不是同一种设置。

首先，Fast / Normal / Deep 是传统的解码深度设置，也就是告诉解码器搜索到多深。在传统的单线程 FT8 解码路径中，这一深度与解码需要多少计算量、搜索有多激进直接相关。

而 Multithreaded FT8 decoder 则是完全不同的一个维度。它本质上决定使用哪一类解码引擎。在代码中，解码深度和多线程 FT8 是两个独立参数，并不是同一个功能的两个名称。

接下来还有一个重要细节。当 FT8 真正以多线程解码器运行时，程序进入专用的 MTD 路径，而不是旧的传统 FT8 解码路径。在这个路径中，真正决定解码行为的是 MTD 专用设置，而不是旧的 Fast / Normal / Deep 等级：

• Decoder Sensitivity
• Decode Start
• Number of decode passes
• QSO Rx Frequency Sensitivity

因此，最准确的理解方式是：Fast / Normal / Deep 仍然存在，也仍然属于程序整体的“解码深度”逻辑；但是在 FT8 的 MTD 工作模式中，它已经不是决定解码器激进程度的主要旋钮。实际调整时，更重要的是面向 MTD 的设置——尤其是 Decoder Sensitivity、Decode Start、Number of decode passes 和 QSO Rx Frequency Sensitivity。

换句话说，如果你要认真调整启用了多线程解码器的 WSJT-X 3.1 improved FT8 性能，更应该围绕 MTD 专用行为控制来思考，而不要再假设 Fast / Normal / Deep 仍然是决定解码器特性的首要因素。旧的深度设置依然存在于设计中，只是在进入 FT8 MTD 路径之后，它已经不再是最重要的实际调节手段。

QSO Rx Frequency Sensitivity

这并不仅仅是速度设置。它会影响解码器在当前 QSO 相关频率区域以及附近候选信号上进行搜索时有多激进。

• Low 较保守
• Medium 较均衡
• High 较激进

同样可以预期的是，越激进也可能带来越多可疑候选以及更多解码噪声。

Reduce False Decodes

这一设置值得比通常更多的重视。如果新增的结果越来越不可靠，那么“找到更多”并不自动等于“更好”。在拥挤频段和容易产生歧义的情况下，控制错误解码非常重要。

综合来看，这些设置并不是彼此孤立地竞争“谁最强”。它们其实都在回答同一个根本问题，只是答案不同：

在非常有限的 15 秒窗口内，解码器应该把什么放在最优先的位置？

而在这些设置中，Decode Start 是最清楚、最能体现这种思想的例子之一。

核心问题

“Decode Start”究竟做了什么？

从这里开始，问题真正变得有意思。

在用户界面中，Decode Start 提供五个选项：

• 2-Stage
• 3-Stage
• Early
• Normal
• Late

乍看之下，它像是一个很简单的时序控制：

更早开始解码，或者更晚开始解码。

但这并不是全部。

查看 WSJT-X 3.1 improved 的实际实现，可以看到这些模式在内部被处理为：

• 0 = 2-Stage
• 1 = 3-Stage
• 2 = Early
• 3 = Normal
• 4 = Late

在 FT8 工作过程中，程序会使用 m_hsymStop、m_earlyDecode 和 m_earlyDecode2 等值来决定各个解码阶段何时触发。

这立刻告诉我们：

为了更容易理解，我们先从比较简单的三个模式——Early、Normal、Late——开始，然后再进入更能体现设计思想的 2-Stage 和 3-Stage。

Early / Normal / Late

先看三个较简单的模式

先从最直观的选项开始。

启用多线程 FT8 解码器时，内部停止点大致为：

• Early → 48
• Normal → 49
• Late → 50

粗略换算成时间，大约对应：

• Early → 约 13.8 秒
• Normal → 约 14.1 秒
• Late → 约 14.4 秒

它们最基本的含义很直观：

• Early 少收集一点信号，以换取更多 CPU 时间余量
• Late 等待更久，先收集稍多一些信息再开始解码
• Normal 位于二者中间

如果 Decode Start 只有这三个模式，它仍然会是一个有用的设置，但并没有特别特殊。

真正让这个功能更有意思的是接下来的两个模式：

2-Stage 和 3-Stage。

补充技术说明

2-Stage 与 3-Stage 的真正含义

它们不只是“更早”或“更晚”，而是把 STD 与 MTD 结合起来的分阶段解码策略

WSJT-X improved 的更新日志把 2-stage 和 3-stage 描述为能够“智能地组合两个解码器”的模式，并称其由此实现了迄今为止最好的 FT8 解码性能。

也就是说，软件明确把它们设计为传统 STD 解码器（单线程）与较新的 MTD 解码器（多线程）相结合的方式。

更新日志没有解释两者确切的执行顺序，也没有说明它们之间的时序关系。只有查看实际实现后，这一点才会清楚。

而一旦看过实现就会发现，2-Stage 和 3-Stage 并不只是不同的开始时间。它们是多阶段解码策略，而且每个阶段承担的角色并不相同。

STD 与 MTD 之间的分工

这里的 STD 指传统的单线程 FT8 解码器；MTD 指 improved 系列中引入的多线程 FT8 解码器。

从实现来看，分阶段模式大致按下面的方式工作：

• 较早阶段使用 STD
• 最终阶段使用 MTD

这就是最关键的设计思想。

换句话说，最好把它理解为有意识地分成两种工作：

• 更早、更轻、更快的一次查看
• 以及更晚、更完整的一次解码

这是一个非常重要的区别。

更简单的设计可能会一直等到接收时段结束，然后只执行一次很重的解码。WSJT-X improved 并不是这样做。它会在最终阶段之前执行中间候选搜索，然后在稍后再完成更深入的解码。

这说明这个设计非常重视一个核心问题：

开发者视角：STD 预解码究竟是为了什么

根据 Uwe Risse / DG2YCB 的说明，STD 预解码并不仅仅是“多做一次预先解码”。它的重要作用，是把传统 STD 解码器所具备的早期解码优势带入 MTD 工作流程。

开发过程中测试了多种 STD 与 MTD 的组合，也测试了不同的 nzhsym 参数。最终，目前这种“STD 负责预解码、MTD 负责主要最终解码”的方式取得了最好的实际效果。

这是非常关键的一点。2-Stage 和 3-Stage 并不是简单地“把解码器运行多次”。它们是为了把 STD 的轻量早期解码能力与 MTD 更完整的最终解码能力结合起来，从而更有效地利用 15 秒 FT8 周期内有限的 CPU 时间。

Uwe 还指出，2-Stage 可以达到 3-Stage 大约 99.5% 的解码收益，但所需计算能力明显更低。这也解释了为什么 2-Stage 对大多数用户而言是非常有力的实际推荐，而 3-Stage 则保留为高速电脑上的最高性能选项。

2-Stage 真正意味着什么

在实际空中解码中，2-Stage 由一次 nzhsym=41 的 STD 预解码组成，随后在 nzhsym=49 执行最终 MTD 解码。

实际顺序是：

• STD 预解码 @ nzhsym=41 — 约 11.8 秒
• 最终 MTD @ nzhsym=49 — 约 14.1 秒

关键点在于：实际解码时，nzhsym=46 的第二次 STD 预解码并不属于 2-Stage。这个额外预解码只属于 3-Stage。

也就是说，2-Stage 是一个平衡得很好的模式：先做一次早期侦察式预解码，然后在 nzhsym=49 用主要 MTD 解码完成最终处理。

由于解码收益与 CPU 成本之间的平衡非常好，2-Stage 是我最先推荐给大多数用户的模式。根据 Uwe Risse / DG2YCB 的说法，它能达到 3-Stage 约 99.5% 的解码收益，却需要明显更少的计算资源。这是非常强的实际折中方案。

3-Stage 真正意味着什么

3-Stage 会在最终 MTD 解码之前，于 nzhsym=46 增加第二次 STD 预解码。

实际空中解码时，顺序为：

• STD 预解码 @ nzhsym=41 — 约 11.8 秒
• STD 预解码 @ nzhsym=46 — 约 13.2 秒
• 最终 MTD @ nzhsym=50 — 约 14.4 秒

因此，3-Stage 先在 41 做一次早期侦察，再在 46 做一次额外 STD 预解码，最后在 50 执行主要的 MTD 解码。

这使 3-Stage 成为 WSJT-X 3.1 improved 中可用的最高性能 FT8 解码模式。

但是这里必须加入一个重要的实际警告：3-Stage 增加的解码收益，并不与增加的 CPU 使用量成比例。Uwe Risse / DG2YCB 指出，2-Stage 已经可以获得大约 99.5% 的 3-Stage 解码收益，因此剩下的那一点收益，与额外需要的计算能力相比其实很小。

在较弱的电脑上，nzhsym=46 的额外 STD 预解码可能占用过多时间，最坏情况下甚至会影响至关重要的 nzhsym=50 最终 MTD 解码。因此，3-Stage 应该被视为一种高端模式：它是强大硬件用户追求极限性能的选项，但并不自动等于适合所有人的最佳建议。

应该理解成“先 STD，最后 MTD”，而不是“先 MTD，再用 STD 补充”

这一点非常容易被误解。

因为更新日志说 2-Stage 和 3-Stage 会组合 STD 与 MTD，有些读者可能会想象成下面这种模型：

• 先运行 MTD
• 然后用 STD 补上 MTD 漏掉的内容

但实际空中解码的行为并不是这样。

更准确的解释恰好相反：

• STD 负责较早、较轻的侦察式预解码
• MTD 负责最后、更完整、更严肃的解码

在实际工作中，区别是：

• 2-Stage：STD @41 → 最终 MTD @49
• 3-Stage：STD @41 → STD @46 → 最终 MTD @50

这个区别非常重要。3-Stage 提供最高的解码性能，但对大多数用户来说 2-Stage 更实用，因为它避免了 nzhsym=46 第二次 STD 预解码所带来的额外 CPU 成本。

为什么较早阶段要使用 STD？

这一点同样很能说明问题。

如果目标只是“让解码器多运行几次”，那么很自然会认为程序应该在每个阶段都重复运行 MTD。但实际并非如此。

一个很直接的原因可能是：

较早阶段应该轻量而快速。

在这些较早时刻，接收尚未完成，可用信息量仍然少于最终阶段。每一次都以最大强度运行最重的解码逻辑，并不一定是利用有限 CPU 时间的最高效方式。

因此，软件在较早时刻使用 STD 快速而经济地进行检查，把 MTD 留给最后、更关键的解码过程。

这不只是实现细节。它体现了一种非常适合 FT8 的解码理念，因为 FT8 本身就是一种短时间、脉冲式、对时序敏感的计算负载。

代码还表明，与最终阶段相比，较早阶段使用的处理受到一定限制。这进一步说明这些模式并不是简单的重复解码，而是一个分阶段推进的过程，每个阶段承担不同角色。

2-Stage 与 3-Stage 的本质是时间分配

归根结底，2-Stage 和 3-Stage 真正讨论的是一件事：

如何在 15 秒周期内分配计算工作。

• 解码器是否应该更早看一次？
• 是否应该在中间再看一次？
• 还是应该一直等到最后，再做最完整的最终尝试？

分阶段模式实际上就是在做这样的选择。

因此，不应该把 2-Stage 和 3-Stage 理解成简单的时间微调。更准确地说，它们是把 FT8 解码器沿时间轴展开的不同方式。

在实际操作中应该怎样理解它们？

把这些差异翻译成实际操作语言后，就会非常直观。

2-Stage

• 能够较好地保持响应速度
• 增加一次较早的检查
• 最终阶段保持在接近 Normal 的时间位置
• 提高候选恢复能力，同时不会把 CPU 负载推到极端

换句话说，它是一种很均衡的分阶段策略。

3-Stage

• 很早先看一次
• 中间再看一次
• 最后仍保留一次大约在 Late 时刻的 MTD 解码
• 更加努力地减少漏解码
• 但也相应提高 CPU 负载

因此，3-Stage 是当前最有野心、也最激进的分阶段模式。

如果 CPU 有足够余量，它非常有吸引力。如果 CPU 已经接近时间极限，那么理论上的额外优势，就不如保证每个周期都能干净、稳定地完成来得重要。

到这里，这些模式真正代表什么就清楚得多了：

还有一个重要点

分阶段模式并不只是“多次解码”，而是给不同阶段分配不同角色

从更宽的角度看，2-Stage 和 3-Stage 有意思的地方，并不只是它们会触发多次解码。

更深层的关键在于，每个阶段承担的作用不同。

• 较早阶段更轻、更快
• 最终阶段更完整
• CPU 计算工作沿整个周期分布，而不是一次性全部消耗

这与 FT8 的特点非常契合。

理论上，当然可以一直等到最后，再做一次最终判断。但更早寻找可以恢复的候选信号有实际价值，然后在之后拥有更多信息时，再用更深入的处理重新检查这些候选。

因此，理解分阶段模式并不仅仅是在理解一个设置。实际上，它是在理解“FT8 优化本身到底是什么”。

实际解读

实际操作中应该如何使用各个模式？

在讨论了这么多技术细节之后，有必要重新回到实际操作的语言。

2-Stage

非常实用。它保持良好响应，同时仍然提前进行一次检查。最终阶段不像 Late 那样晚，因此不会不必要地增加处理压力。

3-Stage

这是最有野心的模式——这里是褒义。

它先早看一次，稍后再看一次，同时还保留强力的最终解码。如果 CPU 余量足够，而且减少漏解码是优先目标，那么这是整个设置面板中最有意思的选项之一。

Early

不要把它简单地当成“弱 CPU 的备用模式”。它同样是一种非常理性的稳定性策略。如果避免处理拖到下一周期比榨取最后一点信号更重要，那么 Early 完全可能是正确选择。

Normal

参考基准。对大多数用户来说，测试应该从这里开始。这样最容易与其他模式进行比较。

Late

等待更久、稍后解码，并利用稍多一些信息做最终判断。理论上这可能有帮助；实际是否有价值，取决于系统是否仍能可靠地按时完成。

综合来看，不应该把 Decode Start 各模式理解为“个人口味”。更准确地说，它们代表不同的时序策略。

那么，我们真正优化的到底是什么？

不是平均性能，而是 15 秒周期内 CPU 时间的使用方式

到这里，整体原则应该已经很清楚。

FT8 优化并不是简单地让所有东西“更强”。

真正要决定的是：

• 等待多久
• 多频繁地检查
• 在哪些时刻进行较轻的解码
• 在哪里执行较重的最终解码
• 以及整个过程能否在一个又一个周期中保持稳定

换句话说，问题真正关心的是 CPU 性能如何被使用，而不仅仅是有多少 CPU 性能。

从这个角度看，Decode Start 是整个解码器设置面板中最重要的设置之一。看似只是一个很小的界面选项，实际上直接体现了时间策略。

因此，理解 Decode Start 不只是理解一个设置。它也是理解 FT8 中计算资源分配理念的一种方式。

再谈一点个人观点

我为什么要写这篇文章

到目前为止，我一直尽量把讨论保持在一般性和技术层面。不过为了说明背景，我也应该明确自己的立场。

这并不是因为 JTDX 没有价值，而是因为软件也应该根据它现在是否实际可用、是否已经成熟到足以测试、以及是否当下真正有帮助来评价。

如果有人继续使用 JTDX，是因为真心喜欢它的界面，这完全可以理解。但如果讨论的是今天的解码能力与实际操作价值，那么 WSJT-X 3.1 improved 值得认真关注。

我自己的操作理念

到这里为止，我主要讨论的是一般原则。但也许有必要说明，这些原则在我自己的实际操作中最终变成了什么样的选择。

我的主要操作电脑使用 Core i9-9900K。这个细节很重要，但并不仅仅因为它是一颗相对强的 CPU。

同样重要的是这台电脑如何配置。

在 Windows 电源设置中，我把“最小处理器状态”设为 100%。也就是说，我不会等到解码负载出现后，再让 CPU 提升频率。我更希望 CPU 事先就已经以高频运行，随时准备工作。在我的系统上，它实际上基本保持在 4.7 GHz。

原因很简单。

FT8 解码不像长时间的视频渲染，那种任务会持续维持稳定负载。它更像是短时间、集中的计算爆发，而且会以可预测的间隔不断重复。

面对这种负载，平均跑分并不能说明全部问题。最初的响应速度很重要。

如果 CPU 正处在较低功耗状态，系统需要：

• 检测负载
• 切换性能状态
• 提高时钟频率
• 调整电压
• 并让调度器作出响应

在长时间持续负载中，这些延迟可能几乎无关紧要。但在短暂、对时序敏感的计算爆发中，它们的影响可能比很多人想象的更大。

因此，我的看法是：

当然，这种选择也有代价。

• 更高的功耗
• 更多的发热
• 更低的能效
• 从节能角度看没有那么“优雅”

但对电台用电脑来说，我认为解码响应速度和稳定性比极致节能更重要。

为什么我的设置刻意偏向激进

因为 50 MHz 对我非常重要

我的设置很明显地反映了这种理念。

• Decoder Sensitivity: Subpass
• QSO Rx Frequency Sensitivity: High
• CPU 预先保持在高时钟频率等待

这不是保守的设置，我也不会假装它很保守。

但这样做有明确的理由：

50 MHz 对我非常重要。

在 6 米波段：

• 传播条件可能很快变化
• 活动可能突然增加
• 弱信号和强信号经常同时存在
• 而短暂开通一旦错过机会，会尤其令人遗憾

因此，我愿意使用更多 CPU 资源，以减少漏解码。

这就是为什么我使用：

• Subpass，以进行更深入的搜索
• High 灵敏度，以更积极地恢复候选信号
• 以及让 CPU 在突发计算负载到来之前就保持就绪的电源配置

这并不是简单地“把所有东西都开到最大，因为越多一定越好”。

它是一种有意识的操作策略，建立在以下前提上：

• 重视 50 MHz
• CPU 有足够余量
• 重视响应速度
• 并愿意用能效换取更多机会

最后的思考

真正的问题不是“哪一个软件才是正确的？”，而是“哪一种调整理念更适合你的电台？”

如果必须把全文压缩成一句话，那就是：

从这个角度看，WSJT-X 3.1 improved 是非常有意思的软件。并不仅仅因为它提供更多选项，而是因为它让操作者能够真正控制解码器的时序策略。

而 Decode Start 就是最清楚的例子之一。

2-Stage、3-Stage、Early、Normal 和 Late 并不只是几个表面标签。它们代表了在 FT8 周期内分配解码工作的不同方式。

如果进一步观察分阶段模式，还能看到其中一个尤其漂亮的思想：

最后，作为一个真正重视 JTDX 的人，我想这样说：

如果你坚持 JTDX 的原因是喜欢它的界面，那是一回事。但如果你关心的是今天实际工作条件下的解码能力，那么几乎没有理由犹豫。