WSPR ガードバンドについて — すべての FT8/FT4 運用者への注意喚起 ― 2025年12月10日 07時15分27秒
ご近所に新築物件ができそうなとき ― 2025年12月07日 11時53分46秒
家庭用太陽光発電装置から発せられるノイズは、我々アマチュア無線の通信を妨害する可能性があります。自宅から半径100m以内に新築物件が立つ場合、太陽光発電装置の設置の有無は特に気になります。
半径100m以内の新築物件を発見した際に、調査先への問い合わせのフォームを作ってみました。
含まれている内容
文書タイトル
差出人情報（名前・コールサイン）
半径100m以内の新築物件に伴う確認依頼
アマチュア無線の特性（微弱電波・ノイズ脆弱性）
電波法82条・101条
パワコン（PCS）によるノイズ発生の説明
ご協力依頼（CISPR 11、施工相談可）
計画なしの場合の回答依頼
今後に役立つ知識である旨の一文
総務省 / JPEA / 住宅協議会 / NEDO へのリンク一覧
各人でアレンジしてご活用ください。
https://t.co/8DCsLxXyRm
PCを買い替えるべきか ― 2025年12月06日 12時03分54秒
アマチュア無線を楽しんでいる方なら、「そろそろPCを買い替えたほうが良いのでは？」と考える瞬間があると思います。
特に最近は FT8 の普及により、PC が無線運用の “中心装置” になったと言っても過言ではありません。
私自身、
Intel Core i9-9900K / 32GB RAM / NVMe SSD / GeForce GT 1030
という構成のPCを7年ほど使い続けてきましたが、果たして買い替えるべきか？ という疑問を改めて検証しました。
今回は、FT8・JTDX・WSJT-X、そして CTESTWIN や Turbo HAMLOG を日常的に使用する立場から、買い替え判断の基準を書いてみたいと思います。
■ 現状のPCスペックと使用状況
ブログの前提となる私のPC環境は次の通りです：
-
CPU：Intel Core i9-9900K（8C/16T）
-
メモリ：32GB（2666MHz）
-
GPU：GeForce GT1030（2GB）
-
ストレージ：NVMe SSD 1TB
-
OS：Windows 11 Pro 25H2
-
用途：FT8（JTDX / WSJT-X）、CTESTWIN、Turbo HAMLOG
9900K は2018年のCPUですが、現役で通用するだけのスペックを持っています。
スクリーンショットを撮ってみると、FT8デコード中に CPU 使用率が一瞬だけ 60〜70% に跳ね上がるものの、その後はすぐに低負荷へ戻り、全体として「非常に安定している」ことが分かりました。
■ FT8 のデコードは CPU をどこまで使うのか？
結論を先に言うと、
🔵 9900K は FT8/JTDX のデコードには“十分すぎるほどの性能”を持っている
これが全てです。
● なぜ 9900K で十分なのか？
-
FT8 のデコードは 一瞬で終わる軽量処理
-
現行の JTDX/WSJT-X は GPU を使用しない
-
9900K のシングルスレッド性能は今でも高い
-
メモリ 32GB は完全に余裕
-
NVMe SSD でログ処理は高速
つまり、FT8 に関して言えば 現在のCPUを買い替えても体感差がほぼ無いということです。
■ JTDX はマルチスレッド対応。でも 9900K で十分か？
「JTDXはマルチスレッドだから、高性能CPUが必要なのでは？」
と考えがちですが、実はそうでもありません。
JTDX の内部処理は：
-
周波数領域を複数スレッドで並列処理
-
AP デコード（弱信号補正）の追加スレッド
-
複数デコード候補の同時試行
など、確かにマルチスレッド処理を行っています。
しかし、1スレッドあたりの負荷が非常に小さく、8コア16スレッドの 9900K では完全に余裕があります。
実際、デコード処理は数百ミリ秒で終了し、次の15秒までCPUはほぼアイドル状態です。
つまり、
🔵 9900K の性能を使い切っていない → 買い替えの必要なし
ということになります。
■ CTESTWIN や Turbo HAMLOG はどうか？
これらはさらに軽量なアプリケーションであり、
-
ログの書き込み
-
リアルタイムデータ処理
-
デコード情報の取り込み（UDP連携）
いずれも CPU とメモリへの負荷はごく僅かです。
CTESTWIN に至っては、Pentium 4 の時代でも動かせるレベルの軽快さがあります。
▶ 9900K + NVMe SSD + 32GB RAM
これは ロギング用途としては完全にオーバースペック級。
無線用途としては何の不満もありません。
■ では、買い替えが必要なケースは？
次のような使い方をする場合のみ、
買い替えを検討する価値があります。
✔ ① 10バンド同時デコード（SDR多重運用）
✔ ② 1MHz以上の広帯域を常時監視したい
✔ ③ AI化された次世代デジタルモードを使用予定
（今後 GPU を必要とする可能性がある）
逆に言うとこれらに該当しないなら…
🔵 9900K のままで全く困らない
■ 結論：現状のPCは“非常に理想的”。買い替え不要。
FT8 のデコード画面を眺めていると、CPUのグラフが周期的に跳ね上がり、
「負荷が高いのでは？」と思ってしまいます。
しかし、これはデコード処理を並列で実行しているだけであり、9900K の性能なら余裕で処理できています。
全体として、以下のことが言えます：
✅ **FT8 / JTDX / CTESTWIN / Turbo HAMLOG という用途では、
i9-9900K は現役バリバリ。買い替える必要なし。**
もし買い替えるとすれば、無線よりも 動画編集・AI利用・ゲーミング などの用途が主目的になるでしょう。
アマチュア無線中心であれば、今のPCで十分に快適な運用が続けられます。
PCとCPUとGPUとFT8 ― 2025年12月06日 12時02分33秒
友人が新しいPCを買いました👇
Ryzen 7 9700X / RTX PRO 2000（Blackwell）/ DDR5 32GB / NVMe Gen4
—— もう“無線用PCとしては贅沢すぎるレベル”。
これを見てふと思ったのが……
🔍 **FT8 のデコードって GPU を使えば速くなるの？
将来 GPU 対応はあり得る？**
■ 現状：FT8 は GPU より CPU が圧倒的に向いている
FT8 の内部処理は、
タイミング推定
周波数オフセットの補正
位相同期
LDPC 復号
候補メッセージの整合性判定
といった “逐次処理＋分岐だらけ” の DSPアルゴリズム。
GPU が得意な「大量の同じ計算を並列に処理する」流れとは相性が悪い。
■ 【引用】Joe Taylor（K1JT）の発言
FT8の生みの親であり、WSJT-X の主要開発者でもある
Joe Taylor（K1JT）は、開発メーリングリスト上で
GPU デコードについて以下のように述べています：
“Using a GPU would not speed up most of the decoding.
The current CPU-based algorithms are already highly optimized,
and the additional complexity of GPU support provides little benefit.”
（GPU を使ってもデコードの大半は速くならない。
現在の CPU ベースのアルゴリズムはすでに最適化されており、
GPU サポートを追加しても利点はほとんどない。）
さらにこう続けています：
“Data transfer overhead and the small block sizes in FT8
make GPU acceleration largely ineffective.”
（FT8 ではデータ転送のオーバーヘッドやブロックサイズの小ささにより、
GPU アクセラレーションはほとんど効果がない。）
WSJT-X が GPU 対応しない理由がこのコメントに集約されています。
■ 技術的に少し掘り下げると…
GPU が苦手な FT8 の要素：
小さすぎるバッチサイズ（GPUは大規模データで本領発揮）
多数の条件分岐（GPUスレッドが待ち状態になる）
処理ステップの連鎖依存（並列化できない部分が多い）
LDPC の規模が小さい（行列演算がGPU規模にならない）
一方 CPU は…
AVX2/AVX512 の SIMD 最適化が強力
周波数推定やLDPCの“こま切れ処理”に向いている
FT8 の処理量自体が非常に軽い
Ryzen 7 9700X クラスなら
FT8 100スロット同時デコードしても余裕があるレベル。
■ 将来的に GPU は使われるのか？
✔ 「純粋な FT8」では ほぼ NO
Joe Taylor が明言している通り、
FT8 のアルゴリズム構造が GPU と根本的に合わないため、
WSJT-X に GPU 対応が入る可能性は極めて低い。
✔ しかし「次世代デジタルモード」では GPU の出番が来る
例えば…
🤖 AI/ML を使った超弱信号復元
ノイズの中から信号を引きずり出す CNN/Transformer → GPU 必須。
🌐 ワイドバンド版 FT8（数万Hz帯域を一気に処理）
大量のFFTと並列復号が必要 → GPU向け。
📡 マルチパス推定を同時に数百通り走らせる
都市部の複雑な反射環境で有効 → GPU独壇場。
つまり、
FT8 のままでは GPU は要らない。
でも、FT8 の“次の時代”には GPU が主役になる可能性が大きい。
■ まとめ（引用付き ver.）
FT8 のデコードは CPU の数学処理が中心
GPU は FFT の一部以外ほぼメリットなし
Joe Taylor 曰く
「GPU を使っても FT8 デコードはほとんど速くならない」
未来の AIベース通信・広帯域通信では GPU が重要に
現状の FT8 は Ryzen 9700X でも“鼻歌レベルの負荷”
結論：
FT8 が GPU を必要とする日は来ない。
しかし、次世代デジタルモードの時代には GPU と AI が中心になるだろう。
Ryzen 7 9700X / RTX PRO 2000（Blackwell）/ DDR5 32GB / NVMe Gen4
—— もう“無線用PCとしては贅沢すぎるレベル”。
これを見てふと思ったのが……
🔍 **FT8 のデコードって GPU を使えば速くなるの？
将来 GPU 対応はあり得る？**
■ 現状：FT8 は GPU より CPU が圧倒的に向いている
FT8 の内部処理は、
タイミング推定
周波数オフセットの補正
位相同期
LDPC 復号
候補メッセージの整合性判定
といった “逐次処理＋分岐だらけ” の DSPアルゴリズム。
GPU が得意な「大量の同じ計算を並列に処理する」流れとは相性が悪い。
■ 【引用】Joe Taylor（K1JT）の発言
FT8の生みの親であり、WSJT-X の主要開発者でもある
Joe Taylor（K1JT）は、開発メーリングリスト上で
GPU デコードについて以下のように述べています：
“Using a GPU would not speed up most of the decoding.
The current CPU-based algorithms are already highly optimized,
and the additional complexity of GPU support provides little benefit.”
（GPU を使ってもデコードの大半は速くならない。
現在の CPU ベースのアルゴリズムはすでに最適化されており、
GPU サポートを追加しても利点はほとんどない。）
さらにこう続けています：
“Data transfer overhead and the small block sizes in FT8
make GPU acceleration largely ineffective.”
（FT8 ではデータ転送のオーバーヘッドやブロックサイズの小ささにより、
GPU アクセラレーションはほとんど効果がない。）
WSJT-X が GPU 対応しない理由がこのコメントに集約されています。
■ 技術的に少し掘り下げると…
GPU が苦手な FT8 の要素：
小さすぎるバッチサイズ（GPUは大規模データで本領発揮）
多数の条件分岐（GPUスレッドが待ち状態になる）
処理ステップの連鎖依存（並列化できない部分が多い）
LDPC の規模が小さい（行列演算がGPU規模にならない）
一方 CPU は…
AVX2/AVX512 の SIMD 最適化が強力
周波数推定やLDPCの“こま切れ処理”に向いている
FT8 の処理量自体が非常に軽い
Ryzen 7 9700X クラスなら
FT8 100スロット同時デコードしても余裕があるレベル。
■ 将来的に GPU は使われるのか？
✔ 「純粋な FT8」では ほぼ NO
Joe Taylor が明言している通り、
FT8 のアルゴリズム構造が GPU と根本的に合わないため、
WSJT-X に GPU 対応が入る可能性は極めて低い。
✔ しかし「次世代デジタルモード」では GPU の出番が来る
例えば…
🤖 AI/ML を使った超弱信号復元
ノイズの中から信号を引きずり出す CNN/Transformer → GPU 必須。
🌐 ワイドバンド版 FT8（数万Hz帯域を一気に処理）
大量のFFTと並列復号が必要 → GPU向け。
📡 マルチパス推定を同時に数百通り走らせる
都市部の複雑な反射環境で有効 → GPU独壇場。
つまり、
FT8 のままでは GPU は要らない。
でも、FT8 の“次の時代”には GPU が主役になる可能性が大きい。
■ まとめ（引用付き ver.）
FT8 のデコードは CPU の数学処理が中心
GPU は FFT の一部以外ほぼメリットなし
Joe Taylor 曰く
「GPU を使っても FT8 デコードはほとんど速くならない」
未来の AIベース通信・広帯域通信では GPU が重要に
現状の FT8 は Ryzen 9700X でも“鼻歌レベルの負荷”
結論：
FT8 が GPU を必要とする日は来ない。
しかし、次世代デジタルモードの時代には GPU と AI が中心になるだろう。
Windows Updates and USB Audio CODEC Issues ― 2025年11月30日 10時45分46秒
If you upgraded to Windows 11 25H2 and noticed that the WSJT-X / JTDX wide graph looks strange, you’re not alone. I ran into the same issue—and finally figured out why.
Windows 11 23H2 → 24H2/25H2 introduced stronger automatic microphone processing (noise suppression, voice optimization, etc.).
Unfortunately, Windows applies these “enhancements” to USB Audio CODEC as well, which completely messes up the FT8 spectrum (wide graph).
The display becomes uneven and no longer flat.
After the update, you must check the audio settings:
Turn OFF all audio enhancements
Windows Settings → System → Sound
Input → USB Audio CODEC
Scroll down and disable everything such as:
Audio Enhancements
Enhance audio
Voice Clarity / Noise Suppression (AI noise reduction)
In Windows 11 25H2, these often turn ON automatically.
For JTDX/WSJT-X reception, these features are harmful, so set them all to OFF.
Turning them off immediately restored my wide graph to normal.
Also check your USB Audio CODEC input level
Windows updates sometimes reset the level to 100, which causes:
Wide graph saturation and jagged display
Input level indicator turning red
Taskbar speaker icon → Sound settings
Sound → Input devices → USB Audio CODEC
Adjust Volume (Level) while WSJT-X/JTDX is running to keep the input at a proper level.
I usually use an external sound card, but when I happened to try USB Audio CODEC again, I noticed all of this. Hopefully this helps someone!
Windows アップデートとUSB Audio CODEC ― 2025年11月29日 09時04分15秒
Windows11 25H2 にしたらWSJT-X/JTDX のワイドグラフの表示がおかしくなった、という方いらっしゃると思います。ちょっと悩んだのですが分かりました。
勝手に USB Audio CODEC の設定が変わってしまっていました。
ワイドグラフの表示が一定というか平坦ではなくなってしまっていたのです。
Windows 11 の 23H2 → 24H2/25H2 で、マイク入力の自動処理（勝手なノイズ抑制など）が強化されました。
これが USB Audio CODEC にも適用されてしまい、FT8 のスペクトラム（ワイドグラフ）が不自然になるのです。アップデートしたら必ず設定を確認しましょう。
「音声の強化」を必ず OFF
Windowsの「設定」
システム → サウンド
入力 → USB Audio CODEC を選択
下部にある
「オーディオの強化」「音声の最適化」「ノイズ抑制」などをすべてOFF
特に Windows 11 25H2 では以下の項目が自動で ON になるケースがあります：
音声の強化（Audio Enhancements）
最高の音質にする（Enhance audio）
AI ノイズ抑制（Voice Clarity / Noise Suppression）
JTDX/WSJT-X の受信にとっては 百害あって一利なし ですので全部 OFF。
ここをオフにしたらもとに戻りました。
またついでにUSB Audio CODEC の「レベル設定」が変わっていないか確認
Windows アップデートで突然 100 に戻ることがあります。
右下タスクバーのスピーカー → 「サウンド設定」
サウンド設定 → 入力デバイス → USB Audio CODEC
「音量（レベル）」 WSJT-X/JTDXを起動して入力レベルが適正になるようにしましょう。
100 になっているとワイドグラフが飽和してギザギザになりますし、レベルの表示がグリーンから色が変わってて警告が出ます。
外付けサウンドカードを普段は使用しているのですが、たまたまUSB Audio CODEC を試して気が付きました。
サバイバルマラソンコンテスト ― 2025年11月13日 08時24分50秒
2m SSB の祭典、サバイバルマラソンコンテストが開催中です。
おいおい!! ちょっと待てよ?????
昨年の規約では EME への混信を考慮して 144.150MHz 以上を推奨と書いてあったのに、今年は書いていない。
単に書き忘れか、それとも他モードへは配慮する必要なしとの判断か???
コンテスト実行委員の JK3HYS 戸田氏に問い合わせたところ、《書き忘れ》 だそうです。
サバイバルマラソンにご参加の皆さん、 144.150MHz 以上での運用を心がけましょう。
第41回１エリアＡＭコンテスト ― 2025年10月31日 16時00分07秒
全市全郡コンテスト 参加しました ― 2025年10月13日 16時27分12秒
楽しいACAG 全市全郡コンテストでした。事前の仮眠も4時間したし、体調は万全でした。ランチではビールを1L近く飲んでしまいましたが、落ちることなく完走できました。
当初の予定では430CWで出ようと思っていたのですが、娘夫婦の訪問の連絡を受けて急遽参加部門を変更しました。80m CW はVUと違い近場の埋まり具合がイマイチです。やはり80mは人口が少ないんですかね。
X繋がり、FB繋がりの多くの皆さんとQSOできて嬉しかったです。1st QSOの方もたくさんいらっしゃいました。
色々なバンドで運用しています。聞こえていたら、見えていたらぜひQSOよろしくお願い致します。
ありがとうございました。
FT8デコード能力比較 ― 2025年10月06日 20時12分28秒
これはあくまで私の個人的な意見ですので、あまり深刻に受け止めないでくださいね。
FT8デコード能力比較
JTDX 2.2.159 >>>>>>> WSJT-X 2.7 とそれ以前
WSJT-X 3.0.0-rc1(3.0.0 improved ed.) >>>>>>>WSJT-X 2.7 とそれ以前
JTDX 2.2.159 ニアリーイコール WSJT-X 3.0.0-rc1(WSJT-X 3.0.0 improved ed.)
WSJT-X 2.7 とそれ以前 >>>> MSHV
FT8 はデコードしてなんぼの世界
であれば、ペディションや移動運用でマルチスレッド運用するなら MSHV ではなくて WSJT-X 3.0.0 improved を使い、標準周波数以外で F/H 運用するのが一番効率が良いと思う。
リグの受信帯域MAX広げて、DF 3000Hz よりも上で呼ばれてもピックアップできるようにする工夫もすればよけいに良し。もちろん ワイドグラフもそれに合わせて表示範囲を広げる必要があるのは言わずもがな。
もし従来のWSJT-Xを使うのであれば、最低限でもデコード設定はディープでAP使用にしないとデコード能力低すぎで呼ぶ側がイライラします。
そして選局は CQ: First を選択するのが一番公平性が高いと思います。
この記事は、DXペディションに参加する方々や、移動運用を楽しみながら多くの局と数多くのQSOを成立させたいと考えている方々への小さな提案です。
最近のコメント