WSJT-X improved 3.1、かなりお勧めです。📡2026年05月16日 09時28分12秒

WSJT-X improved 3.1、かなりお勧めです。 私の実感では、デコード性能はすでに JTDX 2.2.159 と同等、場合によってはそれ以上と感じています。 FT8は、デコードできてなんぼの世界です。 デコードできなければ、そもそもQSOはできません。 見えなかった信号が見える。 拾えなかった局が拾える。 これはFT8運用ではとても大きいです。 デコード性能については、こちらの記事にまとめています。 asahi-net.or.jp/~vj5y-tkur/ft8 WSJT-X improved 3.1 は、20260228版からさらに進化し、現在は20260418版が公開されています。 さらに 20260516版もテスト版として出ており、開発は継続中です。 こちらには 20260228版と20260418版がありますが、今から使うなら 20260418版をお勧めします。 sourceforge.net/projects/wsjt- 20260516テスト版を試したい方は、こちらからダウンロードできます。 QMAP v0.7 関連のテスト版です。 sourceforge.net/projects/wsjt- 公開されている WSJT-X improved 3.1 がここまで進化している今、ベータテスター以外には非公開の JTDX rc版を無理に追いかけたり、こっそり使ったりする必要性は、少なくとも私には感じられません。 JTDX のUIに馴染みがある方は、まず AL_PLUS版を選ぶと入りやすいと思います。 最初は「少し使いづらいかな?」と感じるかもしれません。 でも、それはたいてい慣れの問題です。 使っているうちに、違和感はすぐ過去のものになります。 古いバージョンを使い続けている方も、ぜひ WSJT-X improved 3.1 へのアップデートを検討してみてください。 なお、私は現在、JTDX の AutoSeq や Wanted 機能に近い使い勝手を WSJT-X 3.1 improved 上で実現する JP1LRT版を作成中です。 まだ限定テスト段階ですが、かなり良いところまで来ています。 そのうち皆さんにもお試しいただけると思います。 どうぞお楽しみに。


より良いリグが欲しい、でも動けない — ICOM⇔YAESU の壁について2026年05月08日 08時00分19秒

Sherwood の数字は誘惑する

Rob Sherwood の Receiver Test Data を眺めていると、ある数字の組み合わせに目が止まる。

私の現用機 IC-7300 の Narrow Spaced Dynamic Range は 97dB。それに対して YAESU FTdx10 と FT-710 は 107dB。10dB の差が、第三者測定の数字としてそこにある。

ここで技術的に正確に書いておきたい。Narrow Spaced DR は「強い近接信号が存在するときに、受信機が IMD で潰れずに済む耐性」、つまり受信機の "頭の高さ" を示す指標である。「信号強度で 10 倍の差が聞こえる」という素朴な解釈は誤りだ。実運用でこの余裕が使い切られる場面は限定的で、多くの状況では大気雑音や人工雑音の方が支配的になり、DR の差は体感されない。中波 DX のような大電力局がひしめく過酷な環境ですら、ICOM 機で十分戦えるという経験者の声もある。

さらに踏み込むと、Sherwood の測定そのものがダイレクトサンプリング SDR 機への適用において方法論的な課題を抱えているという指摘がある。SSG(信号発生器)から ADC へ直接入力する測定条件下では、入力レベル上昇に伴って波形立ち上がりが急峻化し、サンプリングビット刻みを 2〜3 段飛びで抜ける現象が起きる。これが量子化雑音にスパイクとして混入し、擬似ノイズとして観測される。サンプリングと信号の微妙なタイミング依存で結果が安定しないため、Sherwood 自身も計測値の不安定性を認めているとされる。実運用ではアンテナからの外来ノイズや他信号が自然なディザリング効果として働き、この現象は原理的にほぼ起きない。つまり Sherwood の数値はディザリング条件下のワースト値であり、ダイレクトサンプリング SDR 機の実運用性能を必ずしも反映しない。ヘテロダイン機では原理的に発生しない現象であり、アーキテクチャの異なる機種を Sherwood の同一指標で単純比較することには、原理的な注意が必要である。

それでも、この 10dB は誘惑する。FTdx10 100W が実勢価格 ¥158,400 から手に入る今、「Sherwood トップグループの数字を持つリグ」を IC-7300 と大差ない金額で買える時代である。コンテストで隣接強局に押し潰された経験のある人なら、「あと 10dB の余裕があれば」という思いを一度は抱いたことがあるはず。スペックは、実効値の差以上に人を惹きつける

数字だけ見れば、検討に値する買い物に見える。

でも、動けない。

なぜか。


見えないコスト — エコシステム移行費

リグ単体の比較表には絶対に載らないコストがある。「メーカー越境のコスト」だ。

私の例で具体的に書こう。

私のシャックでは IC-7300 の ACC 端子から 13.8V と SEND 信号を一本のケーブルで取り出し、6m 用プリアンプに供給している。これは ICOM 機の伝統的な設計で、IC-7600 でも同じ ACC 端子から同じ信号が取れる。長年積み上げてきた、安定した運用構成だ。

ところが YAESU FTdx10 は事情が違う。背面に TX GND(RCA)はあるが、ICOM ACC のような 13.8V 給電ピンは持たない。プリアンプ給電は別経路で安定化電源から分岐する必要がある。SEND 信号も RCA から取り直す。

つまり、リグを買い替えた瞬間、6m の中核装備であるプリアンプの給電・制御系統を全面再配線することになる。

「単なる配線でしょ?」と思うかもしれない。だが SEND タイミングはリグごとに微妙に違う。ミスれば送信時にプリアンプにフルパワーが突き刺さり、一瞬でファイナル昇天である。オシロで実測しながら慎重に組まないといけない。

これは私の例だが、似た話は他にも山ほどある。

越境で発生する隠れコスト一覧

  • ACC 端子:ピン配置・信号仕様が異なる
  • CAT 制御:ICOM は CI-V、YAESU は独自プロトコル
  • マイクコネクタ:8ピン同士でもピン配置が違う
  • 外部チューナー連動:バンドデータ電圧仕様が異なる
  • ロギングソフト設定:全リグエントリ書き換え
  • メモリ管理ツール:リグ専用、流用不可
  • キーパッド・FH-2 等:メーカー専用
  • マニュアル理解:用語・体系から学び直し

金銭的には、ケーブル・コネクタ・場合によっては T/R シーケンサで数千円〜数万円。たいした額ではない。

問題はそこじゃない。

三層のコスト構造

メーカー越境のコストは三層で発生する。

第1層:金銭コスト — 数千円〜数万円。リグ本体価格の 5〜10%。
第2層:時間コスト — 配線・設定・動作確認で週末数回分。実測・調整含めて 10〜20 時間。
第3層:リスクコスト — 配線ミス、信号タイミング差、誤動作によるハードウェア損傷の可能性。

そして見落とされがちな第4層がある

第4層:身体に染みついた操作感

四半世紀、ICOM を使っていると、私の手は IC のメニュー体系を覚えている。AGC ノブの位置、フィルタ切替の手順、メモリ呼出のキー操作。これらは脳ではなく指が記憶している。

YAESU に乗り換えると、この身体記憶が一瞬で無効になる。コンテスト中の一瞬の判断、パイルアップ中の混信処理、すべてが「考えながらの操作」に戻る。慣れるまでの数か月間、運用効率は確実に落ちる。

これは右ハンドル車に乗っていた人が左ハンドル車に乗り換えるのに似ている。技術的には運転できる。でも、無意識でできていたことを、しばらく意識的にやらないといけない。

この第4層こそが、メーカー越境の最大のハードルだと私は思う。スペック表の差が実運用で限定的なら、なおのこと、この身体記憶を捨てる合理性は薄い。

業界構造としての「囲い込み」

ここで一歩引いて見ると、これは個人の問題ではなく、産業構造の問題だと気づく。

ICOM は ACC 端子互換性を長年維持してきた。これは「ユーザー親切」の側面と同時に、「離脱コストを高く維持する戦略」でもある。一台買い替えるたびに、過去のアクセサリ投資がそのまま次のリグでも使える。だから ICOM ユーザーは ICOM を買い続ける。

YAESU 側も同じ構造で、FTdx101 → FTdx10 → FT-710 と購入してきたユーザーは、周辺機器をほぼ流用できる。だから YAESU ユーザーは YAESU を買い続ける。

これは Apple のエコシステムや、カメラの Canon vs Nikon と同じ構造だ。「囲い込みは、ユーザーの便宜と表裏一体で機能する」

ハム業界のユニークな点は、この囲い込みが数十年スパンで機能することだ。スマホは 2〜3 年で買い替えるが、リグは 20 年使う。アクセサリも、AC アダプタやプリアンプは 30 年使う人もいる。だから一度ある陣営に属すると、簡単には抜け出せない。

真のリグ価格 = 表示価格 × エコシステム係数

私が思う「越境購入の真のコスト」を式にするとこうなる。

真のコスト ≒ リグ表示価格 × 1.3〜1.5(メーカー越境時)

FTdx10 100W が ¥158,400 だとしても、ICOM ユーザーが買うときの「実質コスト」は ¥200,000〜¥240,000 と見るのが現実的だ。配線材料費、時間コスト、リスクコスト、運用効率低下のすべてを織り込めば、それくらいになる。

逆に、YAESU 内で FTdx101D → FTdx10 への買い替えなら、エコシステム係数は 1.0 に近い。表示価格そのままが実質コストだ。

この差が、性能比較表からは絶対に読み取れない。そして比較表の数字そのものが、必ずしも実運用の差を保証しないことを考え合わせると、越境判断はますます慎重にならざるを得ない。

ではどうするか

選択肢は三つある。

選択肢1:エコシステム内に留まる — スペック上の性能向上は限定的でも、移行コストはゼロに近い。複数メーカー機種を並行使用する経験者の観察によれば、IC-7851/K3S/FTDX10/FT-710/FTDX5000/TS-890S といった上位機間の実運用性能差はほぼないとされる。実運用での体感差が小さいなら、なおさら合理的な選択。ICOM ユーザーなら IC-7610 や IC-7851 へのアップグレードパス。慣れた操作系、確実な周辺機器流用。

選択肢2:越境を覚悟して移行する — Sherwood トップグループの数値を取りに行く。ただし三層〜四層のコストを直視する必要がある。週末を数回潰す覚悟と、しばらくの運用効率低下を許容する精神的余裕が要る。「数値が変わっても運用は変わらないかもしれない」という冷静な認識も持っておく。

選択肢3:併存運用 — 既存システムは温存し、新ブランドは限定用途で導入。例えば「6m 専用機として FTdx10 を導入し、HF はICOM継続」。ただしこれもプリアンプが越境バンドにあると成立しないなど、運用構成によっては実現困難。

正解はない。自分の運用形態と、移行コストの見積もり次第だ。

メーカーへの注文 — 宗教のハードルを超えてくれ

ここまではユーザー側の話だった。だが、視点を一段上げて言いたいことがある。

ICOM と YAESU は、もっとライバル意識をむき出しにして性能を追うべきだ。

私はメーカー越境のハードルを「合理的な敬意」と書いた。しかしその裏返しは、両メーカーが現状の囲い込みに安住しているということでもある。

考えてみてほしい。Sherwood Engineering の Receiver Test Data において、5 年以上前に発売された FTdx10 が今もトップグループに居座り続けている。これは YAESU の設計が優秀である証であると同時に、「5 年経っても本気で挑戦してくる対抗馬がいない」という業界の停滞でもある。

2026 年に登場した IC-7300Mk2 では、Sherwood の Narrow Spaced DR が 87〜89dB と、初代 IC-7300 の 94〜97dB を下回るという結果が公表されている。ただしこの数値については、前述のダイレクトサンプリング SDR 機固有の測定方法論上の問題に起因する現象である可能性が高く、実機性能の劣化を意味するとは限らない。実機経験豊富な OM 諸氏の観察を踏まえれば、IC-7300Mk2 が実際に初代より劣ると判断する根拠は乏しい。

ただ、新機能の追加(USB-C、HDMI、LAN、CW デコーダ、APF)が素晴らしい一方で、第三者測定で前モデル比の明確な向上を示しきれない開発思想には、メーカーがエコシステム内買い替えを織り込んでいる雰囲気を感じる。「うちのユーザーは結局うちで買う」という前提に立っていないか。

性能だけでなく、UI も激しい競争軸として欲しい。八重洲機は性能良好だが UI が弱いという評価が定着しており、つまみの数比例で FTDX101 > FTDX10 > FT-710 という声まで聞かれる。FT-710 は FT8 等で PC コントロール前提の設計と見れば筋は通るが、リグ単体で操作するときの使い勝手はやはり大事だ。ハードウェア性能の競争と、ユーザー体験を左右する UI の競争。両輪で各社が殴り合えば、業界全体が前進する。

私が両メーカーに望むのは、スペック表の数字ではなく、実機で誰もが体感できる性能の飛躍と、操作のしやすさで思わず手が伸びる UI の進化である。ユーザーの「宗教のハードル」を強引にぶち壊すには、それしかない。

ICOM ユーザーが実機を触って「これは…YAESU に乗り換えるべきか?」と本気で悩む製品。YAESU ユーザーが操作して「ICOM の新作は、エコシステム再構築のコストを払ってでも欲しい」と思う製品。そういう製品が出てきて初めて、業界全体が前進する。

スマートフォン業界では、iPhone と Android の覇権争いが互いを進化させた。GPU 業界では NVIDIA と AMD と Intel の三つ巴がユーザーに恩恵をもたらしてきた。ハム業界も、同じレベルの競争を見たい

互いの牙城を尊重する紳士協定のような現状は、ユーザーには不利益でしかない。ICOM は YAESU の縄張りを荒らしに行くべきだし、YAESU は ICOM の城を崩しに行くべきだ。Kenwood も、Elecraft も、Flex も含めて、もっと激しく性能を競ってほしい。

「宗教のハードルを超えてでも、こいつが欲しい」とユーザーに言わせる体感の差を、ぜひ作ってほしい。それがあれば、私たちは喜んで配線をやり直し、メニュー体系を学び直し、四半世紀の指癖を捨てる覚悟をする。

ハムは、本物の性能には敬意を払う種族である。

メーカーへの具体的な提案 — アダプターという解決策

性能で殴り合うのと並行して、もう一つメーカーに提案したいことがある。

「越境を容易にする純正アダプター」を商品化してほしい。

例えば、YAESU が ICOM ユーザーを取り込みたいなら、こういう純正アクセサリを売ればいい:

  • ACC 変換ハーネス:ICOM ACC(13ピン DIN)→ YAESU FTdx10 制御端子。13.8V と SEND を既存配線のまま流用可能
  • マイクアダプター:ICOM 8ピンマイク → YAESU マイクコネクタ変換
  • CAT ブリッジ:CI-V ↔ YAESU CAT プロトコル変換、既存ロギングソフトの設定維持
  • バンドデータ変換:ICOM バンド電圧 → YAESU バンドデータ、外部チューナー連動継続

ICOM 側も同じだ。YAESU ユーザーを取り込みたいなら、YAESU の周辺機器を ICOM 機に繋ぐアダプターを純正で出せばいい。

「そんなことをしたら囲い込みが崩れる」と思うかもしれない。だが視点を変えてほしい。囲い込みが崩れて困るのは、自社のユーザーが他社に流出する場合だけだ。逆に、相手陣営のユーザーを取り込みたいなら、彼らの囲い込みを緩める方向に動くのは戦略的に正しい。

想像してみてほしい。FTdx10 を検討している ICOM ユーザーが、店頭でこう説明されたら:

「純正 ACC アダプターハーネスがあります。既存のプリアンプ、チューナー連動、マイクがすべてそのまま使えます

この瞬間、移行コストの第1層・第2層・第3層が一気に消える。多くの ICOM ユーザーは、ここで YAESU 購入を決断するだろう。

これは既存 YAESU ユーザーに何の不利益もない。純粋に他社陣営から新規顧客を切り崩す施策である。価格は ¥10,000〜¥20,000 程度のアクセサリで構わない。本体価格 ¥158,400 に対する追加負担は微々たるもの。むしろ「これで安心して移行できる」という心理的ハードルの低下効果は計り知れない。

売上は確実に伸びる。越境の物理的・技術的ハードルが下がれば、あとは純粋な性能勝負になる。そしてここで初めて、Sherwood の数字も、実機の体感も、本当の意味で武器として機能し始める。

両メーカーには、製品開発リソースの一部を「越境促進アクセサリ」に振り向けてほしい。これは囲い込みを緩めるリスクではなく、相手陣営のユーザーを切り崩す攻撃手段である。守りの戦略ではなく、攻めの戦略として考えるべきだ。

ハードウェア互換性アダプターは、結局のところ業界全体のパイを広げる。固定客の奪い合いではなく、買い替え意欲そのものを刺激することになる。長期的に、両メーカーにとっても、ユーザーにとっても、利益になる構造だ。

「性能で殴る」と「アダプターで橋を架ける」。この両輪が揃ったとき、ハム業界は本当の意味で動き出す。

結論

「より良いリグが欲しい」という気持ちと、「動けない」という現実の間にあるのは、決して怠惰でも保守性でもない。それは、これまで積み上げてきたエコシステムへの合理的な敬意である。

新しいリグを買うとき、メーカーが同じなら表示価格を、メーカーが違うなら表示価格 × 1.3〜1.5 を見積もる。これが私の最近の考え方だ。

そして、Sherwood の数字を眺めながら、しばらく自分のシャックを見回す。あの 6m プリアンプ、あの ACC ケーブル、あの慣れ切ったメニュー画面。これらすべてを「越境コスト」として勘定に入れたとき、買い替えという行為の重みが初めて見えてくる。リグ選びは、単体の数字を比べる作業ではなく、アンテナ、受信環境、周辺機器、操作感まで含めたシャック全体の総合力をどう設計するか、という問題でもある

スペック表の数字は誘惑する。だがその数字が実運用でどこまで効くかは、数字だけからは読めない。実効性の不確かな優位は、四半世紀かけて築いたエコシステムの引力に勝てるか。これは、すべてのハムが買い替え時に直面する、見えない方程式である。

WSJT-X Improved 3.1.0 260418 was released2026年04月18日 21時35分02秒

WSJT-X Improved 3.1.0 260418 was released today — and this is not just "another new build." This is a substantial update. 📡

It helps to look at this in two layers. 👇

First, what the 3.1 series brings as a whole:
New FT2 mode
Non-standard / compound callsign QSOs for all 77-bit modes
U.S. state support for Worked All States 🇺🇸
a7 decoding / sub-sample DT refinement / 4th pass / baseline optimization
itone added to UDP status message
Hamlib 5 series support

These are major pillars.

On top of that, the 260418 update specifically adds:
🔹 Improved FT4/FT2 decoding
🔹 Better FT2 decoder timing
🔹 Enhanced U.S. state support
🔹 8 band hopping frequencies switchable between FT8 / FT2
🔹 Option to clear Band Activity window on mode change
🔹 WSPR spotting to PSK Reporter
🔹 Echo mode Dgrd display
🔹 Cloudlog/Wavelog Test API fix
🔹 Hamlib 4.7.1 update

Quite a lot packed in. 🛠️

Now here is where it gets interesting.

I had a look at the source as well, and my impression is:
It is NOT simply a case of "Qt6 being a completely different beast."

The bigger step is actually:
Old (Qt5 260228) → New Qt5 (clean 260418)

The representative files I checked all show differences here, and the scope of changes is quite broad.

Meanwhile, the delta from New Qt5 → New Qt6 is concentrated mainly around:
- Configuration
- mainwindow
- displaytext
- WorkedBefore

...and the core decoder files are not as different as I expected.

So my overall read is:
The 260418 generation itself is a big leap forward,
and Qt6 sits on top of that as a port plus surrounding differences. 📘

So all in all, WSJT-X Improved 3.1.0 260418 — covering:
FT2
Compound / non-standard callsign QSOs
U.S. state support
a7 / 4th pass / baseline optimization
WSPR / Echo / UDP / band hopping improvements

— is a much deeper update than it might appear on the surface. 🚀

This is not just "a new build came out."
This version makes the direction of the 3.1 series quite clear.



WSJT-X Improved 3.1.0 260418 リリース2026年04月18日 21時32分45秒

今日公開された WSJT-X Improved 3.1.0 260418、
これは「ちょっと新しいビルドが出た」という話ではなく、かなり大きい更新だと思います。📡
今回の話は、実は 2段階 で見ると分かりやすいです。👇

まず 3.1系全体 として入っているもの。
ここには

新しい FT2 モード
77-bit系での non-standard / compound callsign 同士のQSO対応
Worked All States を意識した US state 対応 🇺🇸
a7 decoding / sub-sample DT refinement / 4th pass / baseline最適化
itone を UDP status に追加
Hamlib 5 series 対応
など、かなり大きな柱があります。

そのうえで、今回の 260418 更新 ではさらに
🔹 FT4/FT2 の decoding 改良
🔹 FT2 decoder timing 改善
🔹 US state 対応の強化
🔹 8つの band hopping 周波数を FT8 / FT2 で切替可能
🔹 Band Activity を mode change 時に消す オプション
🔹 WSPR → PSK Reporter
🔹 Echo mode の Dgrd 表示
🔹 Cloudlog/Wavelog Test API 修正
🔹 Hamlib 4.7.1 更新
……と、かなり内容が濃いです。🛠️
で、ここからが面白いところ。
少しソースも追ってみたのですが、印象としては
「Qt6版だけが別物」ではない
です。👀
むしろ大きいのは
旧版(Qt5 260228) → 新Qt5(clean 260418) の段階。
こちらで見た代表ファイル群は全部差分ありで、更新範囲はかなり広い。

一方で
新Qt5 → 新Qt6 の差は、主に

Configuration
mainwindow
displaytext
WorkedBefore
周辺に集まっていて、
デコーダ主要部は思ったほど別物ではありませんでした。
つまり体感としては、
まず 260418 世代そのものが大きく進化していて、
Qt6 はその上に乗る移植+周辺差分
という見方が、いちばんしっくり来ます。📘

なので今回の 3.1.0 260418 は、

FT2
compound / non-standard callsign QSO
US state
a7 / 4th pass / baseline 最適化
WSPR / Echo / UDP / band hopping 周辺の改善
まで含めて、
思っていた以上に中身が濃い更新だと思います。🚀

単なる「新しいビルドが出た」ではなく、
3.1系の方向性がかなりはっきり見える版ですね。





430MHz帯(433MHz)パブコメ、今が勝負です📣2026年04月16日 11時00分34秒

【アマチュア無線家のみなさんへ:430MHz帯(433MHz)パブコメ、今が勝負です📣】

総務省が「電波法施行規則等の一部を改正する省令案等」について意見募集(パブコメ)を実施中です。
テーマは “自動車の国際的流通拡大への対応” ですが、内容の芯に 433MHz帯(=430帯アマチュアバンド内)TPMS/RKE(タイヤ空気圧モニタ/キーレス)の制度整備が含まれています。

✅ 元情報(総務省)
✅ 意見提出(e-Gov)


━━━━━━━━━━━━━━━━━━━━
■ 何が問題なのか(ポイントだけ)
━━━━━━━━━━━━━━━━━━━━
今回の制度改正案は、433MHz帯TPMS/RKEについて

・使用周波数の許容範囲を「433.05~434.79MHz」へ拡大
・占有周波数帯幅の許容値を「1.74MHz」へ拡大(※従来の“約7倍”)

という方向で制度化しようとしています。

430MHz帯は、FM・レピータ運用などで日常的に多くの局が集まる“生活圏のバンド”です。
ここに制度として他用途の許容範囲が広がると、混信トラブルの確率・影響範囲が増える懸念があります。
(「送信時間が短いから大丈夫」で片付く話ではなく、“制度として面積が広がる”のがポイントです)


━━━━━━━━━━━━━━━━━━━━
■ 「1000字」の話:何が問題で、どう出すべき?
━━━━━━━━━━━━━━━━━━━━
よく「e-Govは1000字まで」と誤解されますが、違います。

🔹 e-Govの入力欄は最大6000字など、実際はもっと入ります。
🔹 ただし意見公募要領には「1000字を超える場合は要旨を添付」とあります。
🔹 ところが e-Gov は “添付ファイルが使えません”。

つまり、e-Govだけで長文を出すと
「要旨を添付できない」状態になり、運用上やや不利になる可能性があります。

✅ そこでおすすめの出し方はこの2段構えです。

【おすすめ提出方法】
① e-Gov:短めの要旨(結論→根拠→要望)で提出
② メール:詳細版(要旨+本文)を提出

このやり方なら、
・e-Govで“確実に1件カウント”
・メールで“根拠を丁寧に残す”
が両立できます。


━━━━━━━━━━━━━━━━━━━━
■ 書き方のコツ(行政に刺さる形)
━━━━━━━━━━━━━━━━━━━━
感情だけでなく、次の型が強いです。

① 結論:賛成/反対(または条件付き)
② 根拠:何がどう変わるのが問題か(周波数範囲、占有帯域の拡大など)
③ 影響:430帯の運用実態(FM・レピータ、日常利用の密集)
④ 要望:拡大を見直す/条件を付ける/周知・監視強化をセットで、等

特に「周波数範囲の拡大」「占有帯域(OBW)許容値の拡大」は、制度の中核なので論点が通りやすいです。


━━━━━━━━━━━━━━━━━━━━
■ 最後に
━━━━━━━━━━━━━━━━━━━━
パブコメは “出した人の数” と “論点の質” が効きます。
賛否は自由ですが、430MHz帯を使うアマチュア無線家として、知らないまま進むのは避けたい案件です。

ぜひ一次資料を読んで、あなたの言葉で提出を🙏

(拡散歓迎)

🚨 TQSLが突然でかくなった!そんな経験ありませんか?🚨2026年04月01日 12時16分40秒

🚨 TQSLが突然でかくなった!そんな経験ありませんか?🚨

LoTWへのADIFアップロードに使う TQSL、バージョンアップ後にウィンドウが巨大化して縮小できなくなる症状が出ることがあります 😱

ドラッグしても縮まない…互換性設定を変えても効果なし…
そんなときは【レジストリを直接編集】で一発解決できます!🛠️

━━━━━━━━━━━━━━━━
解決手順
━━━━━━━━━━━━━━━━

① Win + R → regedit と入力してレジストリエディタを起動

② 以下のキーを開く
 HKEY_CURRENT_USER
  └─ Software
  └─ tqslapp
      ↑ ここがポイント!
  「ARRL」でも「TrustedQSL」でもなく【tqslapp】です 🎯

③ 右ペインで以下の値をダブルクリックして編集
 (入力は「16進数」モードのまま!)

 MainWindowWi… → 400 (幅 約1024px)
 MainWindowHe… → 280 (高さ 約640px)
 MainWindowX  → 64  (画面左からの位置)
 MainWindowY  → 64  (画面上からの位置)

④ レジストリエディタを閉じてTQSLを再起動 🔄

コンパクトなウィンドウが戻ってきたら大成功です 🎉

━━━━━━━━━━━━━━━━
⚠️ 注意
━━━━━━━━━━━━━━━━

レジストリ編集前に必ずバックアップを!
レジストリエディタ → ファイル → エクスポート で保存できます 💾

サイズの数値はお好みで調整OKです 👍
値が気に入らなければ同じ手順で変更するだけ!

━━━━━━━━━━━━━━━━

同じ症状で困っているOMにぜひシェアしてあげてください 📢



WSJT-X 3.1 improved のFT8デコーダ設定を読み解く2026年03月24日 23時55分53秒

# WSJT-X 3.1 improved のFT8デコーダ設定を読み解く  

## ― 「デコードスタート」は何をしているのか。そして、いま本気で最適化を考える意味

-------------------------------
ここのブログはフォーマットがイマイチなので、独立ページを作りました
https://www.asahi-net.or.jp/~vj5y-tkur/ft8/wsjtx_31improved_article_ja.html

-------------------------------

JTDX には、昔から「どの設定がどう効くのか」を分かりやすく説明した資料がありました。  
あれは非常に有益です。特に、デコード性能は単に「速いCPUなら全部盛りでよい」のではなく、**処理時間・取りこぼし・誤デコードのバランスで決まる** という本質を理解するうえで、大きな助けになります。日本語版

しかし2026年の今、性能重視でFT8/FT4を運用するなら、話は少し変わってきました。

**WSJT-X 3.1 improved は、もはや “本家WSJT-Xに少し機能を足した派生版” ではありません。**  
JTDX系で培われてきた実戦的な思想や、より攻めたデコーダ最適化の考え方がかなり取り込まれており、WSJT-X 2.7 やそれ以前を基準に比較するのは、正直あまりフェアではないとすら感じます。

少し強めに言えば、**一般の人に勧めるなら、いまは WSJT-X 3.1 improved を真面目に候補に入れるべき時期** です。  
JTDX の次のGAを待つ、という考え方も分かります。  
しかし、性能・機能・更新状況・実際に試せる完成度を重視するなら、**「待つ」より「いま使えるものを使う」ほうが合理的** です。

もちろん、JTDX固有のUIに惚れ込んでいる、というなら話は別です。  
しかしそれは、性能面の議論とは切り分けて考えるべきでしょう。

この記事では、単なる「おすすめ設定一覧」を並べるのではなく、**FT8デコーダ最適化とは何か**、そして **WSJT-X 3.1 improved の「デコードスタート」が内部で何をしているのか** を軸に、少し技術寄りに整理してみたいと思います。

---

## まず結論  
### 迷ったら Normal。CPU に余裕があるなら 3-Stage。非力なら Early

最初に実用上の結論を書いておきます。

FT8 のデコーダ設定で一番重要なのは、  
**「最も重い設定」ではなく、「15秒サイクルの中で安定して処理が終わる設定」** です。

その意味で、出発点として無難なのは次のあたりです。

- マルチスレッドFT8デコーダ: ON
- スレッド数: Auto
- デコード回数: 2
- QSO受信周波数感度: Medium
- デコーダ感度: low thresholds
- デコードスタート: Normal
- Falseデコード軽減: ON
- Wideband DX Call Search: ON

この状態を基準にして、CPUに余裕があるなら少しずつ攻める。  
逆に、Lag や次周期への食い込みが見えるなら、重さを戻す。  
この考え方が基本です。

そして、今回の主題である **「デコードスタート」** についてだけ先に言えば、

- **Normal** … まず基準点
- **3-Stage** … CPUに余裕があり、取りこぼし低減を狙うならかなり面白い
- **Early** … 非力CPUや、次周期に食い込みたくない場合に有効
- **Late** … 最後まで材料を集めてから粘る
- **2-Stage** … 反応と軽さのバランスが良い

という理解で大きく外れません。

ただし、この項目は単なる「早い・遅い」設定ではありません。  
実際には、**デコーダを何段で呼ぶか、どこで軽く見るか、どこで本番を走らせるか** に関わっています。

この「単なる開始時刻設定ではない」という点こそが、今回の話の核心です。

---

## はじめに  
### なぜ今あらためて WSJT-X 3.1 improved なのか

まず前提として、ここ数年の流れを見ると、WSJT-X improved は単なる“別物”ではなく、かなり実戦的な進化の受け皿になってきました。  
使い勝手の改善だけでなく、デコード周りのチューニング、GUIの選択肢、動作の柔軟性など、従来の「本家は安定、派生は趣味」という単純な図式では語りにくくなっています。

実際、いまの improved を触るとすぐ分かります。  
**「本家WSJT-X 2.7 と比べてどうか」という問い自体が、もう古い** のです。

むしろ現在の論点は、

- いま現実に使える高機能版として improved をどう評価するか
- JTDX 的な実戦思想がどこまで取り込まれているか
- その上で、自分の運用スタイルにどう最適化するか

に移っています。

だからこの記事では、単なる比較表ではなく、**“どう使いこなすか” の視点** を重視します。  
そして「どう使いこなすか」を考える以上、個々の設定項目を表面的に眺めるだけでは足りません。  
その設定が、**15秒という短いFT8サイクルの中で何を意味しているのか** を考える必要があります。

---

## 各設定項目の役割  
### “全部強くすれば最強”ではない

ここで一度、デコーダ設定全体の見方を整理しておきます。

デコーダ設定を考えるとき、つい陥りがちな誤解があります。

それは、

**重い設定 = 高性能**

だと思ってしまうことです。

しかしFT8は15秒周期です。  
つまりこの世界で本当に重要なのは、

1. どこまで信号を材料として使うか  
2. どれだけ丁寧に候補探索をするか  
3. それが時間内に終わるか  
4. false decode をどこまで許容するか

この4つのバランスです。

言い換えれば、FT8の最適化とは「最大性能を目指す」ことではなく、  
**限られた時間の中で計算資源をどう配分するか** を考えることです。

この視点を持つと、個々の設定項目も見え方が変わってきます。

### スレッド数
基本は Auto でよいでしょう。  
固定で増やせば必ず得になるとは限りません。OSのスケジューラ、他タスク、CPUの構成、同時負荷などで結果は変わります。

### デコード回数
増やせば弱いものを拾える余地は増えます。  
その代わり当然重くなります。  
CPUに余裕があるなら 3、通常は 2、厳しいなら 1。  
この考え方が基本です。

### デコーダ感度

minimum / 低閾値を使用 / サブパスを使用 という並び。ざっくり言えば、

minimum は軽い
低閾値を使用 は中庸
サブパスを使用 は重いが攻める
サブパスを使用 は "無料の性能向上" ではありません。弱い信号や難しい信号を拾える可能性と引き換えに、追加の処理コストがかかります。

ここで一つ、少し誤解しやすい点を整理しておきます。

画面上では「高速 / 標準 / ディープ」と「マルチスレッドFT8デコーダー」が並んでいるため、つい両者が同じ軸の設定に見えるかもしれません。しかしソースを追うと、実際にはこれは別の話です。

まず、高速 / 標準 / ディープは、従来からある decode depth、つまり「どれだけ深く探索するか」を表す設定です。通常の single-threaded decoder(STD)側では、この深さ設定が実際にデコードの重さや探索の深さに直接関わっています。

一方、マルチスレッドFT8デコーダーは、「どのエンジン系統を使うか」という別軸の設定です。コード上でも、decode depth と multithread FT8 の有効 / 無効は別々のパラメータとして扱われています。

ただし、ここからが重要です。FT8でマルチスレッドFT8デコーダー(MTD)が有効な場合、実際のデコード処理は通常のFT8 decode ルートとは別の、MTD専用経路に入ります。そこでは従来の Fast / Normal / Deep よりも、むしろ

Decoder sensitivity
Decode Start
Number of decode passes
QSO受信周波数感度
といった MTD 側の専用ノブのほうが、実際の“攻め方”を強く決めています。

したがって improved の FT8 では、「MTD を使いながら Fast / Normal / Deep も存在する」こと自体はその通りですが、実戦的に本当に効いてくる主ノブは別にあります。言い換えると、Fast / Normal / Deep は存在していても、FT8 の MTD 実装では主役ではありません。マルチスレッドFT8デコーダーを本気で詰めるなら、まず注目すべきなのは Decoder sensitivity、Decode Start、Number of decode passes、そして QSO受信周波数感度のほうだ、と理解するのが実装にかなり近いと思います。

### QSO受信周波数感度
これも単純な速度設定ではありません。  
QSO相手周辺や関連候補をどこまで積極的に見に行くか、という性格が強いです。  
Low は保守的、Medium はバランス、High は攻める。  
当然ながら High には、副作用として余計な候補や怪しい候補も増えやすいという面があります。

### Falseデコード軽減
これは特に高バンドや混雑帯で効いてきます。  
「拾う」ことと同じくらい、「変なものを拾いすぎない」ことも重要です。

こうして見ていくと、各設定は単独で「強い・弱い」を争っているのではありません。  
全部が、**15秒という限られた枠の中で、何を優先するか** を表しています。

その中でも特に象徴的なのが、次に見る **Decode Start** です。

---

## 本題  
## 「デコードスタート」は何をしているのか

ここが今回の核心です。

UIを見ると、デコードスタートには次の5項目があります。

- 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` を使って、**どの時点でデコーダを起動するか** を切り替えています。

つまり Decode Start は、単なる「開始時刻の趣味」ではありません。  
それは、**デコード処理を時間軸上でどう展開するか** を決める設定なのです。

その意味を理解しやすくするために、まずは比較的分かりやすい Early / Normal / Late から整理し、その後で本当に重要な 2-Stage / 3-Stage に進みます。

---

## Early / Normal / Late  
### まず単純な3つを整理する

まずは比較的分かりやすい3つから見ましょう。

マルチスレッドFT8デコーダ使用時、内部ではおおむね次のような停止点になっています。

- Early → 48
- Normal → 49
- Late → 50

時間に直すと概算で

- Early → 約 13.8秒
- Normal → 約 14.1秒
- Late → 約 14.4秒

です。

つまり、

- **Early** は少し早めに打ち切ってCPU余裕を作る
- **Late** は最後まで材料を集めてから判定する
- **Normal** はその中間

ということです。

これは直感通りです。  
もし Decode Start がこの3つだけなら、「少し早く切るか、最後まで待つか」という、比較的分かりやすい設定だったでしょう。



しかし improved は、そこにさらに踏み込んでいます。  
本当に面白いのは、次の **2-Stage / 3-Stage** です。

---

## 2-Stage / 3-Stage とは何か  
### 単なる「早い・遅い」設定ではなく、STD と MTD を組み合わせた多段デコード戦略

WSJT-X improved の CHANGE LOG では、2-stage / 3-stage について  
**“both decoders can be intelligently combined, resulting in the best FT8 decoding performance to date”**  
と説明されています。つまり、**従来型のSTD(single-threaded decoder)と、新しいMTD(multithreaded decoder)を賢く組み合わせる方式** だということです。

ただし、この CHANGE LOG の文言だけでは、**具体的にどの順番で、どのタイミングで両者が使われるのか** までは分かりません。  
ここから先は、実装を見て初めて見えてくる話です。

実ソースを読むと、2-Stage / 3-Stage は単なる「デコード開始時刻の違い」ではなく、**複数の時点で段階的にデコーダを起動する多段処理** であることが分かります。  
そして重要なのは、その各段で **同じデコーダをただ繰り返すのではない** という点です。

### STD と MTD の役割分担

ここでいう **STD** は、従来からある単一スレッドの FT8 デコーダです。  
一方 **MTD** は、v3.0.0 で導入されたマルチスレッド FT8 デコーダです。

実装を追うと、2-Stage / 3-Stage では、

- **早期段では STD**
- **最終段では MTD**

という役割分担になっています。

つまり、これは  
**「まず軽く速く見に行く段階」と「最後に本格的に詰める段階」を分けた設計**  
と理解するのが正確です。

ここが非常に面白いところです。

単純に考えれば、「最後まで受信してから一度だけ重いデコードをかければよい」と思いがちです。  
しかし improved はそうしていません。  
途中の段階でも一度候補探索を行い、拾えるものは先に拾い、最後に改めて本格デコードを行う。  
つまり、**15秒という短いサイクルの中でCPU時間をどう配分するか** をかなり意識した設計になっています。


### 2-Stage とは何か

ここは名称だけを見ると少し誤解しやすいところです。2-Stage も、実装上は単純な「2段構成」ではありません。

ソースを素直に追うと、2-Stage では

早期段 で nzhsym=41 にて STD pre-pass
中間段 で nzhsym=46 にてもう一度 STD pre-pass
最終段 で nzhsym=49 にて final MTD
という流れになっています。

タイミングとしては、おおよそ

第1段:約 11.8秒
第2段:約 13.2秒
最終段:約 14.1秒
したがって、実装に即して言えば、2-Stage も内部的には STD → STD → MTD の staged mode です。ここで重要なのは、2-Stage は単なる「Normal より少し早い」設定ではない、ということです。そうではなく、途中で二度の軽い STD pre-pass を挟み、最後に MTD で本命処理を行う設計になっています。

言い換えると、2-Stage は 「最後に全部賭ける」のではなく、途中段で候補探索を行いながら、最終 MTD はやや早めに走らせる」モード です。

FT8 は15秒周期のモードであり、デコーダに与えられる計算時間は有限です。そのため、最終段の一発勝負だけに頼るより、途中で軽く候補を見に行ったほうが有利な場面があります。特に、比較的早い時点でも十分に特徴が現れている信号については、そこで先に候補化しておくことに意味があります。

したがって 2-Stage は、軽快さを保ちつつ、取りこぼし低減も狙いたい という局面に向いた、非常に実戦的な設定だと言えます。

### 3ステージ とは何か

3ステージ は、その思想をさらに一歩進めた staged mode です。ただし、ここも名称だけを見るより、実装そのものを見たほうが実態はよく分かります。

ソースを追うと、3ステージ では

早期段 で nzhsym=41 にて STD pre-pass
中間段 で nzhsym=46 にてもう一度 STD pre-pass
最終段 で nzhsym=50 にて final MTD
という流れになります。

タイミングとしては、おおよそ

第1段:約 11.8秒
第2段:約 13.2秒
最終段:約 14.4秒
ここで大事なのは、2-Stage も 3ステージ も、内部的にはどちらも二度の STD pre-pass と一度の final MTD から成る という点です。両者の実質的な違いは、最後の MTD をいつ走らせるかにあります。2-Stage は 49、3ステージ は 50 です。

つまり 3ステージ は、2ステージ と比べて途中段の回数が増えるわけではありません。違いは、最終 MTD をさらに遅らせ、より多くの情報が揃うまで待つ ことにあります。その意味で、3ステージ は 「途中でも拾いに行く」「最後まで粘る」 をより強く押し出したモードだと言えます。

もちろん、そのぶん CPU 負荷は増えます。しかし CPU に余裕がある環境では、この"最後まで粘る"性格は大きな武器になります。


### 「MTD → STD」ではなく、「STD → MTD」と理解すべき

この話で誤解しやすいポイントが一つあります。

2-Stage / 3-Stage について、CHANGE LOG には「STD と MTD を組み合わせる」とあります。  
これだけを読むと、  
**「まず MTD が走って、その取りこぼしを後から STD が補う」**  
ようなイメージを持つかもしれません。

しかし実装を見る限り、実際の理解としてはその逆です。

より正確には、

- **STD が先に軽く・速く見に行く**
- **最後に MTD が本格的に詰める**

です。

つまり 2-Stage / 3-Stage は、  
**MTD の後処理として STD が補完する方式** ではなく、  
**STD で先行偵察し、最後に MTD が本命処理をする方式**  
だと考えるべきです。

この違いは重要です。

前者だと「MTD が主、STD が補助」という印象になりますが、後者だと  
**「時間の早い段階では軽量系、最後の段階では重量級」**  
という、きわめて合理的な時間配分設計として見えてきます。

### なぜ途中段で STD を使うのか

これも興味深い点です。

もし目的が単純に「デコード回数を増やす」だけなら、途中段でも MTD をそのまま回せばよさそうに見えます。  
しかし improved はそうしていません。

これはおそらく、**早期段は“軽く・速く”動かすことに意味がある** からです。

まだ受信が完全に終わっていない時点では、利用できる情報量も最終段より少ない。  
その段階で最も重い処理を毎回全力で回すのは、CPU時間の使い方として効率が悪い可能性があります。  
そこで、途中段は STD によって軽快に見に行き、最終段で MTD による本格処理を行う。  
これは、単なる思いつきではなく、**FT8 のような短時間バースト処理に適した設計思想** と言えます。

さらに実装では、早期段ではデコード回数も少し抑えられており、  
「途中段で無駄に重くしすぎない」配慮も見えます。  
つまり 2-Stage / 3-Stage は、単なる“複数回実行”ではなく、  
**各段の役割を変えながら段階的に精度を上げていく方式** なのです。

### 2-Stage / 3-Stage の本質は「時間配分の戦略」

結局のところ、2-Stage / 3-Stage の本質は何か。

それは、  
**15秒という短いサイクルの中で、どこに計算資源を配分するか**  
という話です。

- 早い段階で一度見に行くのか
- 中間でもう一度見るのか
- 最後まで待ってから本格処理するのか

これを一つのスイッチで切り替えているのが、Decode Start の staged モードです。

したがって 2-Stage / 3-Stage は、単なる「早い/遅い」設定ではなく、  
**FT8 のデコーダをどう時間軸上に展開するかを決める、多段戦略そのもの**  
だと理解するのが最も正確です。

### 実戦的にはどう考えるべきか

以上を実運用上の感覚に落とし込むと、次のように整理できます。

#### 2-Stage
- 軽快さを保ちやすい
- 途中でも一度見に行く
- 最終段は Normal 相当
- CPU負荷を極端に増やさず、反応性もそこそこ良い

つまり、**バランス型の多段デコード** です。

#### 3-Stage
- 早期段でも見る
- 中間段でもう一度見る
- 最後は Late 相当まで待ってMTDで本格処理
- 取りこぼし低減をより強く狙う
- そのぶんCPU負荷は増える

つまり、**最も欲張りで、最も攻めた staged モード** です。

CPUに十分な余裕があるなら、3-Stage は非常に魅力的です。  
逆に、CPUが厳しい環境では、理論上の優位性よりも「間に合うこと」のほうが重要になります。

ここまで来ると、2-Stage / 3-Stage は単なるオプション名ではなく、  
**FT8の15秒をどう使うかという思想そのもの** であることが見えてくると思います。

---

## さらに重要な点  
### staged モードは「複数回回す」のではなく、「各段の役割を変える」

ここまでの話を少し引いて眺めると、2-Stage / 3-Stage の面白さは、単にデコーダを複数回呼ぶことではありません。  
本質は、**各段で役割を変えている** ことにあります。

- 途中段では軽く速く見る
- 最終段で本格的に詰める
- CPU時間を一気に使い切るのではなく、段階的に配分する

これはFT8というモードの性格によく合っています。  
受信の最後まで待って一発で勝負するのも一つですが、途中で拾える候補は途中で拾い、最後にもう一度詰める。  
この考え方は、短時間バースト処理としてのFT8をよく理解した設計だと思います。

つまり staged モードを理解することは、そのまま  
**FT8の最適化とは何か**  
を理解することにつながっています。

---

## 実戦的な解釈  
## どのモードをどう使うべきか


ここまでの技術的な話を、最後にもう一度実戦の言葉に戻して整理しておきます。

### 2-Stage
かなり実戦的です。  
軽快さを保ちつつ、途中でも拾いにいく。  
最終段は Late ほど遅くないので、CPUに厳しすぎない。

### 3-Stage
一番欲張りです。  
よい意味で。

途中でも拾いにいき、最後まで待ってもう一度詰める。  
CPUに余裕があり、取りこぼし低減を重視するなら非常に面白い設定です。

### Early
これは非力CPU向けの逃げではありません。  
むしろ、**安定動作を最優先するための現実的な戦略** です。  
少し早く切り上げることで、次周期への食い込みを防ぎやすくなります。

### Normal
基準点です。  
まずはここから始めるのが最も分かりやすい。  
他設定の差も見えやすい。

### Late
最後まで材料を集めてから一発勝負。  
理屈上は有利に見えますが、CPU余裕が少ない環境では、間に合わなければ意味がありません。

ここまで整理すると、Decode Start の各モードは「好み」ではなく、  
**それぞれ異なる時間戦略** として理解すべきだと分かります。

---

## では、何を最適化するのか  
## それは「平均性能」ではなく「15秒の中の時間配分」である

ここまで読んで分かる通り、FT8の最適化とは、単なる高性能化ではありません。

- どこまで信号を待つか
- 何回見に行くか
- どこで軽く見るか
- どこで本気を出すか
- それを次周期に食い込まず終えられるか

つまり、**CPU性能の使い方そのもの** です。

この視点で見ると、「デコードスタート」は非常に本質的な項目です。  
見た目の一項目に過ぎませんが、実際には **時間戦略そのもの** を選んでいます。

だからこそ、Decode Start の理解は、単なる設定解説に留まりません。  
それは、**FT8における“計算資源の哲学”** を理解することでもあります。

---

## ここから少し個人的な話  
## なぜ私はこのことをわざわざ書くのか

ここまで、できるだけ一般論として書いてきました。  
しかし最後に少しだけ、私自身の立場を明かしておきます。

私は **JTDX愛好家** です。  
JTDX の UI が大好きです。  
さらに、**JTDX開発チームにオーソライズされたベータテスターの一人** であり、**JTDX の日本語ローカライズ担当** でもあります。

つまり、私は外から石を投げている人間ではありません。  
JTDX をよく知っていて、むしろかなり好きな側の人間です。

だからこそ、あえて言います。

**一般の人に勧めるなら、いまは WSJT-X 3.1 improved を真面目に検討すべき** です。  
JTDX の次のGAを待つより、現時点で実際に動いていて、性能面でも機能面でも非常に魅力的な improved を使うほうが、現実的で合理的だと思います。

これは JTDX を否定する話ではありません。  
むしろ逆です。  
JTDX をよく知っているからこそ、**WSJT-X 3.1 improved に取り込まれている技術的価値が見える** のです。

---

## そして、私自身の設定はどうしているか

ここまで一般論と技術論を中心に話してきましたが、最後に私自身の考え方も少しだけ書いておきます。

私の常用PCは **Core i9-9900K** です。  
そしてこれは、単に「9900Kを使っています」で終わる話ではありません。

私の環境では、Windows の電源設定で **最小のプロセッサ状態を 100%** にしています。  
つまり、負荷が来てからクロックを引き上げるのではなく、**最初から高クロックで待ち構える** 設定です。  
実働は **4.7GHz** です。

この設定にしている理由は明確です。

FT8のデコードは、動画エンコードのように長時間ずっと高負荷をかけ続ける処理ではありません。  
むしろ、

- 決まったタイミングで
- 短時間に
- 一気に
- 集中的に

仕事を片付ける、**短時間バースト処理** に近い性格を持っています。

こういう処理で効いてくるのは、平均性能だけではありません。  
**処理開始直後の応答性** が重要です。

CPUが省電力状態で待機していて、

- 負荷を検知し
- P-state が切り替わり
- クロックが上がり
- 電圧が追従し
- スケジューラが本気を出す

この一連の立ち上がりにわずかでももたつきがあると、短時間処理では意外に効いてきます。

だから私は、

**負荷がかかってから高クロックになるよりも、高クロックで待ち構えているほうがFT8には有利**

と考えています。

もちろん、これは省エネの思想とは逆です。

- 消費電力は増える
- 発熱も増える
- 静音性は不利
- 電力効率は悪い

しかし私にとっては、少なくとも無線用の常用機では、  
**電力効率よりデコードの初動と安定性のほうが重要** です。

---

## 私の設定思想  
## 50MHz重視だからこそ、CPUパワーを惜しまない

設定そのものも、かなり分かりやすく「攻める」方向です。

- デコーダ感度: **Subpass**
- QSO受信周波数感度: **High**
- CPUは高クロック待機

これは万人向けの省エネ設定ではありません。  
しかし私は **50MHz を特に重視** しています。

6m では、

- コンディションの立ち上がりが速い
- 局数が急に増える
- 強い局と弱い局が混在する
- 一瞬の開けで拾えるかどうかが大きい

という場面があります。

そのため私にとっては、  
「きれいに省エネでまとめる」ことよりも、  
**少しでも取りこぼしを減らすこと** のほうが重要です。

だから、

- もう一段深く見に行く **Subpass**
- より積極的に候補を拾いにいく **High**
- 負荷が来る前から即応できる **高クロック待機**

という選択になります。

これは単なる「全部盛り」ではありません。

- 50MHz重視
- CPUに余裕がある
- 初動応答性を重視
- 取りこぼし低減を優先

この思想の結果として、そうなっているのです。

---

## まとめ  
## いま考えるべきなのは、「どのソフトが正義か」ではなく、「どの設定思想が自分に合うか」

この話を最後に一言でまとめるなら、こうなります。

**FT8デコーダの最適化とは、CPU性能を“平均値”ではなく、“必要な瞬間”にどう使うかを決めることだ。**

その意味で、WSJT-X 3.1 improved は非常に面白い。  
単なる機能追加版ではなく、**実戦的な時間配分とデコード戦略を選べるソフト** になっています。

特に「デコードスタート」は、単なる早い・遅いではありません。  
2-Stage / 3-Stage / Early / Normal / Late は、それぞれ別の時間戦略です。  
ここを理解して使い分けるだけでも、設定の見え方はかなり変わります。

そして staged モードをさらに踏み込んで見れば、  
そこには **STD と MTD を役割分担させながら、15秒サイクルの中でCPU時間をどう配分するか** という、非常に洗練された思想が見えてきます。

そして最後にもう一度言います。

私はJTDXが好きです。  
UIも大好きです。  
開発チームとも関わっています。

そのうえでなお、**一般の人に今勧めるなら、WSJT-X 3.1 improved を候補の先頭に置きたい**。  
JTDX の次のGAを待つより、まずは今使える improved を試す。  
性能を重視するなら、それはかなり理にかなった判断だと思います。

JTDX に強い愛着があるなら、それはそれでよい。  
しかし、そうでないなら――

**もう遠慮せず、WSJT-X 3.1 improved を入れて触ってみたほうが早い。**

そして、CPUに余裕があるなら、設定だけでなく**電源管理の思想まで含めて最適化**してみると面白い。  
FT8は、平均性能の競争ではありません。  
**必要な15秒のために、どれだけ賢く準備して待てるか。**  
そこまで含めて、デコーダ最適化なのだと思います。



FT8/FT4用ソフトウェアの選択2026年03月17日 16時10分07秒

FT8/FT4用ソフトウェアの選択について、少し書かせてください。 WSJT-X 3.0.0-rc1、そしてWSJT-X Improved 3.0/3.1が登場して以来、デコード率という点ではJTDXを選ぶ理由はなくなりました。JTDXのテクノロジーが取り入れられているため、デコード率は同等です。waiting機能に関してはむしろWSJT-X Improved 3.1の方が上で、対応モードも多く、コンテストモードも搭載しています。 私自身がJTDXを使い続けているのは、GUIの使いやすさとベータテスターとしての立場があるからです。 ここで一つお伝えしたいことがあります。 WSJT-XのRC版は広く一般公開されてフィードバックを集める仕組みですが、JTDXのRC版は開発チームとベータテスターの間だけでやり取りされる、完全非公開のバージョンです。もしJTDXのRC版をお使いの方で、この事実をご存知なかった方がいれば、ぜひ知っておいていただければと思います。 それを知った上でどうするかはご本人の判断ですが、WSJT-X Improved 3.1はデコード率も同等、機能的にも充実していて、公式サポートもあります。後ろめたさを感じることなく使える選択肢として、強くお勧めします。もはや隠れてJTDXのRC版を使う理由がありません。



PSKR の Statistics には誰がどのバージョンのソフトウェアを使用しているかが表示されます。 当然ですが私は誰がベータテスターズなのかそうでないかを把握していますし、開発チームも把握しています。



It Wasn't 3 Strikes and Out — Clearing Up the WSJT-X F/H Mode and MSHV Misconceptions —2026年03月08日 08時28分31秒

Introduction

In 2026, the amateur radio world was shaken.

3Y0K — Bouvet Island.

Located at the southern tip of Africa, surrounded by the perpetually stormy South Atlantic, this remote island has long been regarded as one of the most wanted DXCC entities in the world. Numerous expeditions have been attempted over the years, only to be thwarted by violent weather and failed landings. Time and again, the dream slipped away.

This time, the signals finally came through.

Amateur radio operators around the world flooded the pileup. FT8 waterfalls were wall-to-wall with signals, social media overflowed with reports, and ChronoGPS downloads spiked dramatically (personal note, sorry).

While participating in the pileup myself, I kept an eye on social media. Two opinions kept appearing over and over:

"I called below 1000Hz and got a callback. So it must be MSHV."

"It should have been 3 strikes and out, but I got a response anyway. So it must be MSHV."

Both conclusions landed on "therefore MSHV" — which I find interesting. MSHV is excellent software that enables multi-stream FT8/FT4 operation, but it's not the explanation for either of these observations.

And I'll be honest: regarding the second point — the "3 strikes" issue — I myself had the wrong understanding until very recently.

Let me go through this carefully.


F/H or MSHV? Let's establish the basics first

Before diving into the debate, let's confirm the premise.

The official 3Y0K website stated they were using F/H (Fox & Hound) mode. That's the simplest and most authoritative piece of evidence. The expedition team themselves said "we're using F/H" — that should be our starting point.

So where does the "it looked like MSHV" impression come from? To understand that, we need to know exactly how F/H mode works.


A quick refresher on F/H mode

WSJT-X's Fox & Hound mode was developed by K1JT (Joe Taylor) in 2018, designed to allow DXpedition stations (Fox) to complete QSOs at very high rates with multiple stations simultaneously.

The frequency arrangement works like this:

Fox transmits at audio frequencies between 300 and 900 Hz. When transmitting multiple simultaneous signals, they are spaced at 60 Hz intervals.

Hounds make their initial calls anywhere in the range 1000 – 4000 Hz.

This separation is the foundation of F/H mode.

Two critical points about Fox's behavior:

1. Fox decodes signals below 1000Hz but does not respond to them.
2. Fox only responds to Hounds calling with Tx1 (including grid square).

"Does not decode" and "ignores" are completely different things. This distinction becomes important shortly.


Misconception #1: "I called below 1000Hz and got a callback! → So it must be MSHV!"

This is the most common misconception I saw on social media.

Let's break it down.

In F/H mode, Fox does decode signals below 1000Hz. It just doesn't respond to them. If you look at Fox's waterfall display, Hound signals below 1000Hz are highlighted in red — Fox can see them, it's just choosing to ignore them. That's the design.

So how do we explain "I called below 1000Hz and still got a callback"?

The answer is the queue.

Fox maintains a queue of Hound callsigns decoded in recent sequences. If you called above 1000Hz with Tx1 (grid square included) even once in the past few sequences, your callsign remains in Fox's queue. Even if you subsequently drifted below 1000Hz, Fox can still select you from the queue and call you back.

"I called below 1000Hz and got a response" does NOT equal "therefore MSHV." It most likely means "I had previously called correctly above 1000Hz, and my callsign was still in the queue."

Think back carefully from the very beginning. Are you absolutely certain you never called above 1000Hz even once? 😅

In most cases, I suspect the memory of "I only called below 1000Hz" is inaccurate, and there was at least one transmission above 1000Hz somewhere along the way.

There's another possible source of confusion worth mentioning. In Hound mode, WSJT-X has automatic frequency control. After Fox calls you, Hound automatically moves to near Fox's DF to send R+report — which may place it below 1000Hz. This is a mid-QSO frequency change, not an initial call below 1000Hz. The memory of "I was below 1000Hz" may be conflating this automatic move with the initial call.


Misconception #2: "It should have been 3 strikes and out, but I got a response! → So it must be MSHV!"

This is the heart of today's post. And as I mentioned at the beginning, I had the same misconception myself.

The official F/H mode User Guide written by K1JT (2018) states the following about Fox's behavior:

"We use a '3 strikes and you're out' rule. Fox will call a specific Hound up to 3 times, waiting for an 'R+rpt' response. If a Hound repeatedly sends an 'R+rpt' message, Fox will send RR73 up to 3 times. Finally, the total timespan of an attempted QSO is limited to 3 minutes. When any of these timeouts is exceeded, the QSO is aborted."

Reading this, most people concluded: 3 failures means game over, start over from scratch. I did too.

"3 strikes and you're out" — it's baseball. Clear, intuitive, easy to remember.

But then—


Read the release notes and the world changes

While discussing this on Facebook, I received a tip from Michael Flensted Möller (Top Contributor): "Read the release notes."

In the WSJT-X 2.6.0-rc5 release notes (November 29, 2022), there is this entry:

"Fox now responds for another two cycles to stations whose report was not received, increasing the success rate for a difficult QSO."

Let me spell out what this means:

1. Fox calls a Hound up to 3 times, waiting for R+report
2. After 3 failures, Fox drops that Hound from the queue (3 strikes)
3. But for 2 more cycles after that, Fox still listens for that Hound's R+report
4. If R+report arrives during that window, Fox still sends RR73

In other words, there are effectively 5 chances.

It was NOT 3 strikes and out. 😄

I was genuinely surprised when I read this. It's not in the manual. It's only in the release notes. And of course it's not in the 2018 manual — this was a change made in 2022.

"Got a response after what should have been 3 strikes" is not because of MSHV. It's because of the behavior change introduced in WSJT-X 2.6.0-rc5.

The intent behind this change is clear: to increase the success rate for difficult QSOs. Propagation fluctuations and momentary interference can cause you to miss the 3-cycle window. Adding 2 more cycles as a buffer is a thoughtful design decision — very much in the spirit of K1JT's careful engineering.


The manual alone is not enough

What this whole experience reinforced for me is that thinking you understand something just because you read the manual can be dangerous.

WSJT-X has been continuously refined since the introduction of F/H mode in 2018. The manual is a snapshot of that point in time. To accurately understand current behavior, you need to follow the release notes as well.

Yes, the WSJT-X release notes are long. Keeping up with every version is genuinely tedious. But there are discoveries waiting in there — the accumulated history of careful improvements by K1JT and the development team. Things like the SuperFox mode introduction (2.7.0-rc5), improvements for handling MSHV multi-stream signals in Hound mode (2.7.0-rc1), and Fox queue management enhancements (2.6.0-rc5) — all of these directly affect real-world operation.

When something seems off, or the software behaves differently than you remember, the release notes often have the answer.

Think of the manual as the entrance, and the release notes as the map to where you are now.


A note on MSHV

I want to be clear: I'm not criticizing MSHV. It's excellent software developed by LZ2HV (Christo), enabling multi-stream FT8/FT4 QSOs with multiple stations simultaneously. Many DXpeditions use it effectively.

When calling a DX station running MSHV multi-stream, Hound operators need no special settings. It's the same as normal FT8 operation. No frequency restrictions. You can call with a grid square, or start with R+report — whatever works. MSHV's multi-stream capability is entirely on the host side; it's transparent to the calling station.

The confusion between F/H mode and MSHV matters precisely because of this difference: F/H mode places real constraints on the calling side (above 1000Hz, Tx1 with grid). MSHV does not. Understanding which mode is in use changes how you should operate.


Closing thoughts: the relationship between experience and understanding

Personal experience matters. "This worked" and "this didn't work" — the lessons from actual operating are at the heart of what makes amateur radio enjoyable.

But it's worth pausing before jumping from experience to conclusion. The question "why did that happen?" deserves an answer, and the answers are often in the manual and release notes.

"Called below 1000Hz and got a callback" → don't conclude "therefore MSHV." Ask "why did I get a callback?" Knowing about the queue explains it within F/H mode.

"Should have been 3 strikes but got a response" → don't conclude "therefore MSHV." Check whether the release notes have something relevant. The answer was in 2.6.0-rc5.

Understanding how your software actually works makes the hobby more interesting. When things go right, you know why. When things go wrong, you know why. And that understanding also helps reduce QRM — operators who know that parking below 1000Hz causes problems for everyone are less likely to do it.

Amateur radio is a hobby built around technology. If you enjoy the technology, understanding what's happening under the hood is part of the fun.

Please read the release notes. 📖


Feel free to share. 



三振アウトではなかった 〜WSJT-X F/HモードのリリースノートとMSHV誤解の話〜2026年03月07日 23時14分17秒

はじめに

2026年、アマチュア無線界に激震が走りました。

ブーベ島、3Y0K。

アフリカ最南端、南極に近い絶海の孤島。常時荒れ狂う南大西洋の波に囲まれ、上陸すること自体が命がけのこの島は、アマチュア無線界において長年「世界で最も欲しいエンティティ」のひとつとして君臨し続けてきました。過去に何度かペディションが試みられ、そのたびに悪天候や上陸失敗で夢と消えてきた場所です。

そのブーベ島からの電波が、ついに飛んできた。

世界中のハムがパイルアップに殺到しました。FT8のウォーターフォールは信号で埋め尽くされ、SNSはリポートで溢れ、ChronoGPSのダウンロード数が跳ね上がりました(これは私事ですが)。

私もパイルアップに参加しながら、SNSをモニターしていました。そこで目についたのが、繰り返し登場する2つの意見でした。

「1000Hz以下で呼んだのにコールバックがあった。だからMSHVだ。」

「三振アウトのはずなのに応答があった。だからMSHVだ。」

どちらも結論が「だからMSHV」に着地しているのが興味深い。MSHVはマルチストリーム運用ができる優れたソフトウェアですが、今回の3Y0Kの動作を説明する理由としては、どちらも的外れだと思っています。

そして正直に告白すると、2つ目の「三振アウト」については、私自身もつい最近まで間違った理解をしていました。

今回はその話を、できるだけ丁寧に書いていきます。


F/HモードかMSHVか、まず前提を整理する

議論を始める前に、まず前提を確認しておきます。

3Y0Kの公式ホームページには、F/H(Fox & Hound)モード使用と明記されていました。これが一番シンプルかつ強力な根拠です。ペディションチームが自ら「F/Hを使う」と言っているのだから、まずそれを信じるべきでしょう。

では「動作がMSHVっぽかった」という感想はどこから来るのか。それを理解するためには、F/Hモードの動作原理を正確に知っておく必要があります。


F/Hモードの基本をおさらい

WSJT-XのF/H(Fox & Hound)モードは、2018年にK1JT(Joe Taylor)によって開発されました。DXペディション局(Fox)が同時に複数のQSOを高レートでこなすための専用モードです。

基本的な周波数の使い方はこうです。

FoxはDF 300〜900Hzの範囲で送信します。複数スロット同時送信の場合は60Hz間隔で並びます。

HoundはDF 1000〜4000Hzの範囲で呼びます。

この棲み分けが、F/Hモードの根幹です。

そしてFoxの動作で重要なのが以下の2点です。

  1. Foxは1000Hz以下の信号もデコードするが、応答しない。
  2. HoundはTx1(グリッドスクエア付き)で呼ばなければFoxは応答しない。

「デコードしない」ではなく「応答しない」というのが正確な表現です。この違いは後で重要になってきます。


誤解その1:「1000Hz以下で呼んだのにコールバックがあった!→だからMSHVだ!」

これはSNSで最もよく見かけた誤解です。

まず整理しましょう。

F/HモードのFoxは、1000Hz以下の信号もデコードはしています。ただ応答しないだけです。Foxのウォーターフォールを見ると、1000Hz以下のHoundの信号も赤くハイライトされて表示されています。見えているけど、無視している。それがF/Hモードのデザインです。

では「1000Hz以下で呼んだのにコールバックがあった」という体験はどう説明するのか。

答えはキャッシュにあります。

Foxのシステムは、過去数シーケンスでデコードしたHoundのコールサインを記憶しています。つまり、あなたが1000Hz以上でTx1(グリッドスクエア付き)で呼んでいたシーケンスがあれば、その情報はFoxのキャッシュに残っています。その後うっかり1000Hz以下に移動して呼んでいたとしても、キャッシュから選ばれてコールバックが来ることがある。

「1000Hz以下で呼んだのに応答があった」は「MSHVだから」ではなく、「以前1000Hz以上で正規に呼んでいたから」である可能性の方がずっと高い。

ここで一度、自分の運用を最初から振り返ってみてください。本当に一度も1000Hz以上でTx1で呼んでいませんでしたか?😅

多くの場合、「1000Hz以下でしか呼んでいない」という記憶は不正確で、実際にはどこかで1000Hz以上で呼んでいるのではないかと思います。

さらに言うと、WSJT-XのHoundモードには自動周波数制御があります。Foxから応答が来た後、Houndは自動的にFoxのDF近辺に移動してR+rptを送ります。このとき1000Hz以下に移動することがあります。しかしこれはシーケンスの途中での移動であり、最初のコールは1000Hz以上だったはずです。「1000Hz以下で呼んだ」という記憶は、このシーケンス途中の移動と混同されている可能性があります。

* ここで《キャッシュ》と書いているものは【Queue】の事ですが、読む方が理解しやすいように敢えて《キャッシュ》と記しています。


誤解その2:「三振アウトのはずなのに応答があった!→だからMSHVだ!」

ここが今回のブログの本題です。そして冒頭でも書いた通り、私自身もつい最近まで間違った理解をしていました。

K1JTが書いたF/Hモードの公式マニュアル(2018年)には、Fox側の動作としてこう書いてあります。

"We use a '3 strikes and you're out' rule. Fox will call a specific Hound up to 3 times, waiting for an 'R+rpt' response. If a Hound repeatedly sends an 'R+rpt' message, Fox will send RR73 up to 3 times. Finally, the total timespan of an attempted QSO is limited to 3 minutes. When any of these timeouts is exceeded, the QSO is aborted."

これを読んだ多くの人が「3回失敗したら終わり、最初から呼び直し」と理解しました。私もそうでした。

「三振アウト」という表現は野球のルールそのものですから、わかりやすい。3回ダメなら次のバッターに交代、という理解は自然です。

ところが——。


リリースノートを読むと世界が変わる

Facebookでこの話をしていたところ、Michael Flensted Möller氏(トップコントリビューター)から指摘を受けました。

「リリースノートを読んでみて」と。

WSJT-X 2.6.0-rc5(2022年11月29日)のリリースノートにこう書いてあります。

"Fox now responds for another two cycles to stations whose report was not received, increasing the success rate for a difficult QSO."

「Foxは、レポートを受信できなかった局に対してさらに2サイクル応答するようになりました。これにより難しいQSOの成功率が向上します。」

つまりこういうことです。

  1. Foxが3回コールバックしてもHoundのR+rptが届かない
  2. FoxはそのHoundをキューからドロップする(三振)
  3. しかしその後2サイクル、FoxはまだそのHoundのR+rptを待っている
  4. そのウィンドウの中でR+rptが届けばRR73が返ってくる

つまり実質5回のチャンスがあるわけです。

三振アウトではなかった。😄

私はこれを読んで正直驚きました。マニュアルには書いていない。リリースノートにしか書いていない。しかも2022年の変更だから、2018年のマニュアルに書いてないのは当然です。

「三振のはずなのに応答があった」はMSHVだからではなく、WSJT-X 2.6.0-rc5以降の仕様変更によるものだったわけです。

ちなみにこの変更の意図は明確で、「難しいQSOの成功率を上げる」ためです。プロパゲーションの変動や一時的な混信で3回のウィンドウを逃してしまうことがある。そのためのバッファとして2サイクルを追加した。K1JTたちの細かい配慮が感じられる変更です。


マニュアルだけでは足りない、という話

今回の件で改めて強く思ったのは、マニュアルを読んだだけで理解した気になるのは危ないということです。

WSJT-Xは2018年のF/Hモード導入以来、細かい改善を重ね続けています。マニュアルはその時点のスナップショットに過ぎません。現在の動作を正確に理解するには、リリースノートまで追いかける必要がある。

リリースノートは確かに長い。WSJT-X 2.7.0-rc5のリリースノートを全部読もうとすると、かなりの時間がかかります。でも読むと発見があります。

例えば今回の「5回チャンス」の話だけでなく、リリースノートには他にも興味深い変更が記録されています。SuperFoxモードの導入(2.7.0-rc5)、MSHVのマルチストリーム信号をHoundモードで正しく処理するための改善(2.7.0-rc1)、Fox向けのキュー管理の改善(2.6.0-rc5)など、実際の運用に直結する変更が多い。

「なんかうまくいかない」「なんか動作が変わった気がする」という時、リリースノートを読むと「あ、そういうことか」という答えが見つかることがあります。

マニュアルは入口で、リリースノートが現在地への地図だと思っています。


MSHVについて補足

MSHVを否定したいわけではありません。MSHVはLZ2HV(Christo)が開発した優れたソフトウェアで、マルチストリーム運用によって複数局と同時にFT8/FT4のQSOができます。実際に多くのDXペディションで使われています。

MSHVを使っているDX局を呼ぶ時、Hound側は特別な設定は不要です。普通にFT8でQSOするのと同じです。DFの制限もありません。グリッドスクエア付きで呼んでもいいし、最初からR+rptで呼んでもいい。MSHVのマルチストリームはHost側の話であって、呼ぶ側には透過的です。

F/HモードとMSHVを混同するのは、この「呼ぶ側に制約があるかどうか」という点で大きな違いを生みます。F/Hモードには1000Hz以上でTx1で呼ぶという明確な制約がある。MSHVにはそれがない。この違いを理解した上で運用することが大切です。


最後に:体験談と原理理解の関係

体験談は大切です。「こうしたらうまくいった」「こうしたらうまくいかなかった」という実経験は、アマチュア無線の楽しさの核心だと思っています。

ただ、体験から結論を導く前に一歩立ち止まることも大切です。「なぜそうなったのか」を考える手がかりは、マニュアルとリリースノートの中にある。

「1000Hz以下で呼んだのにコールバックがあった」→「だからMSHVだ」ではなく、「なぜコールバックがあったのか」を考える。キャッシュの存在を知っていれば、F/Hモードでも説明がつく。

「三振アウトのはずなのに応答があった」→「だからMSHVだ」ではなく、「リリースノートに何か書いてないか」を調べる。2.6.0-rc5に答えがあった。

使っているソフトウェアの動作原理を正しく理解した上で運用する方が、うまくいった時もうまくいかなかった時も、ちゃんと理由がわかって面白い。そしてその理解が、周囲への迷惑を減らすことにもつながります。1000Hz以下に居座り続けるQRMも、正しい知識があれば防げる話ですから。

アマチュア無線は技術を楽しむ趣味です。技術を楽しむなら、その技術の中身を知るのも楽しみのうちだと思っています。

リリースノート、ぜひ読んでみてください。📖