6m FT8 DXシーズン到来 — 皆で幸せになるための運用作法(2026年版)2026年05月22日 11時20分33秒

## 6m FT8 DXシーズン到来 — 皆で幸せになるための運用作法(2026年版)

毎年この時期になると書いている話ですが、今年も改めて。

2020年・2023年にも同様の記事を書きました。


繰り返し書くのには理由があります。毎年FT8を始める方が一定数いて、この慣習を知らないまま運用されるケースが続くからです。決して責める話ではありません。知らなければ当然そうなります。だからこそ書き続けています。

---

### 今年(2026年)の状況


Solar Cycle Sunspot Number Progression(出典:NOAA/NWS Space Weather Prediction Center、2026年5月2日更新)

上のグラフをご覧ください。太陽活動サイクル25は2024年末頃にSSN 200超でピークを打ち、2026年現在は明確な下降局面に入っています。それでも平滑化SSNはまだ100前後と高水準にあり、F2伝搬は引き続き活発です。

そしてこの時期、50MHzにはもう一つの伝搬が加わります。マルチホップEsのシーズン(5月〜8月上旬)です。F2とEsが重なるこの時期は、50MHzのFT8バンドに多くの局が集まります。だからこそ、バンドの使い方を改めて確認しておく価値があります。

---
### なぜ「JAは奇数秒(2nd / 15:45)」なのか

FT8は15秒を1ピリオドとして、偶数秒スタート(00秒・30秒)と奇数秒スタート(15秒・45秒)の2系統が交互に動いています。

マルチホップEsでヨーロッパ・中東・北米が入感するとき、相手のDX局は多くの場合偶数秒(00/30)でTXしています。DX局が送信している間、こちらは受信する。そして奇数秒(15/45)でこちらが送信し、DX局が受信する——これが理想の流れです。

ところがJAの局が偶数秒(00/30)でCQを出していると何が起きるか。DX局が送信しているタイミングと完全に被ります。自局の強いローカル信号が周囲のJA局の受信機でDXの微弱な信号を覆い隠してしまい、せっかくのDXを誰も受信できません。

逆に言えば、JAが一斉に奇数秒(15/45)でTXする習慣を守れば、偶数秒(00/30)の受信タイムを全員で共有できる。限られたチャンスを最大多数で活かせる、極めて合理的な取り決めです。

義務でも規則でもありません。しかし欧米の6mコミュニティでは広く認知されており、「JAは2nd」は国際的に通用するコンセンサスです。

---

### 6m bandのDXを守る意味

誤解のないように言っておくと、私はDX至上主義ではありません。国内QSOにも同じだけの価値があります。ただ、6m bandの特性を考えれば、マルチホップEsで入感する超遠距離のDXは保護してしかるべきだと思っています。

理由は単純で、そのチャンスは突然やってきて、あっという間に消えるからです。国内向けの1ホップEsは比較的機会が多く、コンディションさえ上がれば楽しめます。北海道〜沖縄のような長距離パスは2ホップEs的な伝搬が関与することもありますが、それでも国内での交信機会は海外DXに比べれば圧倒的に多い。一方、マルチホップEsによるEU・中東・北米との交信チャンスは年に数回あるかどうか。コンディションが特別に恵まれれば、アフリカや中米まで届くこともあります。その数分間を皆で守ることが、結果として全員の楽しみを最大化します。

---

### 具体的な設定

WSJT-X(標準版 / Improved版 共通)

「Tx even/1st」のチェックを外す。



JTDX

「15/45」を選択する。



---

### 周波数の使い分け

50.313 MHz FT8標準周波数(国内・DX共用)
50.323 MHz 大陸間DX専用 — 国内・近隣諸国との交信には使用しない
50.303 MHz 国内通信用サブ周波数(標準周波数が混雑した場合)

50.323MHzは「最初からあった」周波数ではありません。数年かけて国際的に合意形成し、WSJT-X開発者のK1JT Joe氏をはじめEU各国の6m関連団体・著名DXerと連携して定着させたものです。大陸間の微弱な信号を守るために確保された専用スロットです。

標準周波数がDXをコールするJAで混雑してきたら、国内向けQSOは50.303MHzへ移動することで、お互いのチャンスを守ることができます。

---

### 例外と現実——柔軟性も大切

「JAは2nd/奇数秒」は原則であり、絶対ルールではありません。実際の伝搬は複雑で、例外が発生することがあります。

米国内でも東海岸と西海岸で送信タイミングが分かれて運用されています。そこへ突然JAやAsiaとのパスがオープンした場合、それまでの流れのまま、Asia側が偶数になることがあります。

さらに複雑な状況もあります。米国とEUが同時にオープンしている場合、EUは常に偶数(1st)で送信しています。この場合、米国は奇数(2nd)を使う。そこへ同時に米国からAsiaへのパスがオープンすると、Asiaも偶数になる——EUと同じタイミングです。

こういう状況で原則を頑なに守ろうとすると、かえって混乱します。その時はもうどうしようもない。 流れに乗って臨機応変に対応するしかありません。

大切なのは「原則を知った上で、状況を読む」ことです。原則を知らずに偶数で出し続けることと、状況を判断した上で偶数を選ぶことは、まったく意味が違います。

---

### まとめ

- CQは原則 2nd / ODD(奇数秒)/ 15:45 で出す
- 50.323MHz は大陸間DX専用、国内QSOには使わない
- 50.313MHzが混雑したら国内QSOは 50.303MHz へ

一人ひとりの小さな協力が、超遠距離DXとのQSOを日本全体で最大化します。今シーズンも皆さんが素晴らしいDXと繋がれることを願っています。

追記 もちろん奇数でCQを出している局をコールする時に自分が偶数側になるのは言うまでもありません。CQを出す時にご注意くださいというお話でした

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

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

是非上記独立ページをご覧ください。

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.