理解 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 的原因是喜歡它的介面，那是一回事。但如果你關心的是今天實際工作條件下的解碼能力，那麼幾乎沒有理由猶豫。