PCとCPUとGPUとFT82025年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 が中心になるだろう。

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、そして CTESTWINTurbo 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で十分に快適な運用が続けられます。


ご近所に新築物件ができそうなとき2025年12月07日 11時53分46秒

家庭用太陽光発電装置から発せられるノイズは、我々アマチュア無線の通信を妨害する可能性があります。自宅から半径100m以内に新築物件が立つ場合、太陽光発電装置の設置の有無は特に気になります。 半径100m以内の新築物件を発見した際に、調査先への問い合わせのフォームを作ってみました。

含まれている内容 文書タイトル 差出人情報(名前・コールサイン) 半径100m以内の新築物件に伴う確認依頼 アマチュア無線の特性(微弱電波・ノイズ脆弱性) 電波法82条・101条 パワコン(PCS)によるノイズ発生の説明 ご協力依頼(CISPR 11、施工相談可) 計画なしの場合の回答依頼 今後に役立つ知識である旨の一文 総務省 / JPEA / 住宅協議会 / NEDO へのリンク一覧 各人でアレンジしてご活用ください。 https://t.co/8DCsLxXyRm

WSPR ガードバンドについて — すべての FT8/FT4 運用者への注意喚起2025年12月10日 07時15分27秒

近年、FT8/FT4 の利用者が増えたことで、WSPR との周波数衝突が世界中で問題になるケースが増えています。特に、FT8/FT4 の約3kHzの運用帯に WSPR の周波数が入り込むバンドでは、意図せず WSPR を妨害してしまう可能性があります。

WSPR は非常に狭い帯域を使っており、ほんのわずかな干渉でも多数のデコードが失われます。そのため、デジタルモード間の無用な衝突を避けるには、ユーザーの注意が欠かせません。

■ JTDXのWSPR保護機能

JTDX には、WSPRを保護するための仕組みが実装されています。

  • WSPRサブバンドに送信できないよう 送信ブロック

  • ワイドグラフの該当領域を オレンジ色で表示

このため、JTDXでは誤ってWSPR上に送信してしまうリスクが大きく低減されています。

■ 17m FT4の画面は「例」にすぎない

今回掲載したスクリーンショットは 17m FT4 のものですが、これはあくまで一例です。

実際には、すべてのバンドで同じ問題が起こり得ます。

FT8/FT4 の運用帯の中に、バンド割り当て上 WSPR が存在するケースがあるためです。

■ WSJT-Xユーザーは特に注意が必要

WSJT-X には以下の保護機能がありません。

  • WSPRサブバンドへの送信ブロック

  • 視覚的な警告表示(オレンジ帯)

そのため、WSJT-Xではオペレーターが自分で周波数をチェックしなければ、知らないうちに WSPR に被せて送信してしまうことがあります。これは「バンドポリス」ではなく、単なる運用上の注意喚起です。

■ まとめ

FT8/FT4 と WSPR は隣接した周波数帯に存在することが多く、注意して運用しないと互いに干渉してしまいます。

  • JTDXは強力な保護機能を搭載

  • WSJT-Xはユーザーの注意力に依存

  • これらの違いを理解し、特にWSJT-Xユーザーは 送信前に周波数を確認する習慣 を持つことが重要です。

少しの注意で、FT8/FT4もWSPRもより快適に運用できます。

スペクトラムを共有するすべてのユーザーが気持ちよく運用できるよう、ご協力をお願いします。

How to Add a New Station Location in TQSL2025年12月15日 08時02分35秒


Focusing on Correct Grid Locator Registration

To properly confirm QSOs in LoTW, it is essential that your Station Location includes a correctly defined Grid Locator.

This is especially important for:

  • Grid-based awards (VUCC, Grid awards, etc.)

  • Rare grid confirmations

  • Stations operating from multiple locations under the same callsign

In this article, we intentionally step away from mobile operation examples and focus solely on how to add a new Station Location in TQSL, with particular emphasis on Grid Locator accuracy.


Why Grid Locator Matters

LoTW supports many awards that depend on Grid information, such as:

  • VUCC

  • Grid-based endorsements

  • Regional and experimental awards

If your uploaded QSO data does not include Grid information, the other station may:

  • See the QSO in LoTW

  • Fail to receive a confirmation (CFM)

In many cases, “CFM problems” are caused simply by a missing or incorrect Grid Locator in the Station Location.


1. Start TQSL

Launch TQSL.
All LoTW uploads are processed through TQSL.


2. Open the “Station Locations” Tab

Select the Station Locations tab.

This screen shows all Station Locations currently registered in TQSL.


3. Create a New Station Location

Click “Create a New Station Location”.

⚠️ Important rule
Even if the callsign is the same, a different Grid Locator requires a separate Station Location.


4. Enter the Grid Locator (Critical Step)

On the Station Location input screen, enter the Grid Square.

🔴 This is the most important field

  • Grid Square: Mandatory

  • IOTA reference: Optional

IOTA can be left blank if not applicable,
but Grid Square should always be entered.


5. Select Administrative Location

Next, select:

  • Prefecture / State

  • Administrative region

Choose the location that accurately matches the operating site.


6. Assign a Clear Station Location Name

Enter a descriptive Station Location Name.

Recommended format examples:

  • HOME_PM95

  • MIYAKOJIMA_PM74

  • YORON_PQ00

Including the Grid Locator in the name makes future uploads much easier to manage.


7. Finish and Save

Click Finish to save the new Station Location.

The Station Location is now ready for use.


8. Uploading Logs – Important Reminder

When signing and uploading an ADIF file:

  • Always select the correct Station Location

Selecting the wrong location can result in:

  • Incorrect Grid uploaded

  • QSOs confirmed under the wrong location

  • Lost award credit


Summary

  • Create one Station Location per Grid Locator

  • Always enter the Grid Square

  • Use clear, descriptive location names

  • Verify the Station Location before every upload

Following these steps prevents nearly all Grid-related LoTW problems.


Final Note

If you operate from a rare Grid, please take the time to register it correctly and upload your QSOs to LoTW.
Many operators are waiting for those confirmations.


📻 WSJT Log Utility v0.13 公開のお知らせ2025年12月18日 16時48分58秒

今日は休みで時間があったので、あれこれ試しているうちに……
気がついたら WSJT Log Utility v0.13 まで進んでしまいました 😊

このツールは、主に次のような方を想定して作った Windows 用 GUI アプリです。

  • wsjtx_log.adi を失ってしまった

  • 手元に wsjtx.log(WSJT-X / JTDX のテキストログ)しか残っていない

  • 複数のグリッド・ロケーター、移動運用、特別運用などで
    ログを正しく分割・整理したい

主な機能

  • wsjtx.log(CSV形式テキストログ)を ADIF に変換

  • 既存の ADIF ファイルを日時指定で分割

  • バンド指定フィルタ(最大 23cm まで対応)

  • 日付・グリッド・/P /M /MM /AM・POTA / SOTA / IOTA / WWFF などを
    含めた 安全な出力ファイル名生成

  • LoTW 向けとして設計していますが、
    複数アカウントを使う eQSL ユーザーにも十分対応できます

  • 完全ローカル動作(ログのアップロードなし/元ファイルは変更しません)

開発のきっかけ

古い WSJT ログとグリッド移動に関する技術的なやり取りがきっかけでした。
この用途にピッタリ合う「実用的で簡単なツール」は、これまでほとんど無かったため、
思い切って形にしてみました。

ご注意

  • 完全フリーソフトです

  • 無保証・サポートはできない場合があります

  • 実行ファイルには SHA-256 チェックサムを付けています

  • 将来的なアップデートは、時間が許せば行うかもしれません

何年分もの WSJT/JTDX ログを前にして
「もっと楽に整理できたら……」と思ったことがある方には、
きっと役に立つと思います。

🔗 ダウンロード(GitHub Releases)
https://github.com/jp1lrt/wsjt-log-utility/releases

73 & Enjoy!


第41回1エリアAMコンテスト2025年12月22日 16時17分02秒

第41回 1エリアAMコンテストにご参加いただき、誠にありがとうございました。
現在、ログの集計作業を進めております。

規約には

【提出書類】 JARL推奨旧フォーマット R1.0
【提出先】 1am_test(あっとまーく)6mnet.jp
※2023年度より電子メールのみの受付となっております。
添付ファイルではなく、メール本文に貼り付けてお送りください。

と明記しておりますが、今年も R1.0 以外の形式 で提出された方、添付ファイルで送付された方 が数名いらっしゃいました。
また、
「1. 移動局は移動場所・使用電源を明記してください」
という規定についても、記載漏れが見受けられました。
今年については、主催者側で確認のうえ、必要事項を補足・訂正させていただきました。
ただし、スムーズな集計のためにも、来年度以降は規約に沿った形式でのご提出にご協力いただけますと幸いです。
引き続き、結果発表まで今しばらくお待ちください。

また随時ログの受付状況についても公開しています。

第41回1エリアAMコンテスト 現在までのログ受付状況



1エリアAMコンテスト(1AM)】開催日アンケート(2026年)2025年12月29日 09時36分05秒


【1エリアAMコンテスト(1AM)】開催日アンケート(2026年) — 2026年の開催日、どちらが参加しやすいですか? — ※アンケート締切:2026/1/3(土)23:59(JST) 1エリアAMコンテスト(1AM)は、皆さんのおかげで 41回連続で開催できています。本当にありがとうございます。 そして 2023年から私が主催を引き継いで以降、ありがたいことに「結果発表が劇的に早くなった!」という評価も多くいただいています。 ※なお 2025年分は、まだ結果発表前ですが、並行して「来年以降さらに良くする」ための改善も進めたいと思っています。 主催者として次に目指したいのは、 さらに参加しやすく、皆が楽しめるコンテストにすること。 そして「年内最後にこれに出て締めくくる」――そんな印象を持ってもらえる恒例行事に育てたいと思っています。 その第一歩として、2026年の開催日について皆さんの実感を教えてください。 第4日曜(12/27)に寄せると「年末で忙しくて出られない」方が増えるかもしれません。 一方で「年末休みに入っていて、逆に参加しやすい」という方もいるはずで、主催者の想像だけでは決めきれません。 さらに運営面では、来年以降 ログ提出期限を少し早めることも検討しています(集計〜結果発表をよりスムーズにするため)。この点についてもご意見があればぜひお寄せください。 投票だけでも大歓迎ですし、理由や事情は この投稿へのコメントでも、または コンテストログ提出先メール(1am_test(あっとまーく)6mnet.jp)宛に送っていただいてもOKです(短文でも大丈夫です) ※メールの場合、件名に「開催日アンケート」と入れていただけると助かります。 【投票】2026年、参加しやすい開催日は? A:12/20(第3日曜・年末前) B:12/27(第4日曜・年末寄り) C:どちらでもOK D:年によって調整が良い(例:年末に近い年は前倒し 等) 最後にひとこと: ぜひ“年末の挨拶代わり”に、1局でも交信したら参加してみてください!

📣【コンテスト勢のみなさんへ】2025年12月29日 22時45分56秒

CTESTWIN / zLog を使ってる方、**スーパーチェック(パーシャルチェック)**使ってますか?
これ、地味だけど めちゃ効く仕込み です

既に使ってる方には耳タコですからごめんなさい
■ スーパーチェックって何?
 事前に用意した「局リスト(常連局・最近QSOした局など)」を
CTESTWIN / zLog に読み込ませておく機能です。
 コールを打ってる途中から
「候補局がズラッと出てくる」あれです!
■ 実戦メリット(これが効く)
 誤記・呼び間違いが減る
似たコールが多い時間帯ほど効果大!
「それじゃない!」に早めに気づけます
 S&P が速くなる=拾いが増える
数文字で候補が出るので、判断が早い
結果的に取りこぼしが減ってスコアが伸びやすい
 テンポが崩れにくい(レート維持)
確認・迷い・打ち直しが減る=運用がスムーズ
長時間運用ほど差が出ます
 “出てきそうな局”が見える
常連局・復活局・最近交信した局が候補に出ると
「今いるかも?」が見えて探しやすい
 後処理もラク
誤記が減る=ログ修正が減る
提出前の整理も楽になります
■ 国内コンテストだとどうする?
国内向けは、基本的に
 自分で作る or  友人からもらう
って感じになりがち(JCC/JCG と相性◎)ですよね。
 ちなみに海外コンテストなら…
 supercheckpartial.com から
Super Check Partial Database Files が入手できます!
 https://www.supercheckpartial.com/
 そこで配布されている master.scp などの “.scp系” は、配布側の説明では Win-Test / N1MM+ 向け とされていることが多いです。CTESTWINでは読み込めて使用できました。きっとzLogでも?
■ 今回:国内向けを作るのが面倒だったのでツール作りました(笑)
Turbo HAMLOGから出力させる CSV から
 国内局(JCC/JCG が入ってる行)だけ拾って
 既存リストとマージ → ソート → 重複削除
して、チェックリストを作れる簡易ツールです
補足:
 .spc で出力したものは拡張子を .pck に変えるだけで CTESTWIN で使えます(逆も同様に運用可)
■ まとめ
スーパーチェックは派手じゃないけど
 ミス減
 拾い増
 テンポ維持
に直結するので、コンテストではかなり効きます
まだ使ってない方は、一度入れてみると体感できると思います