WSJT-X improved ed's Waiting Function2025年10月05日 15時58分06秒

**Understanding WSJT-X Improved Edition’s Waiting Function** WSJT-X offers three distinct "Wait" features: **Wait and Reply**, **Wait and Call**, and **Wait and Pounce**. 1. **Wait and Reply** This feature is enabled by default unless you explicitly disable the waiting functions. When active, the program will automatically send a reply to the station you have entered in your DX Call box — even if “Enable Tx” is not turned on. This is especially useful because you can call once and then just wait (with “Enable Tx” off). If the station replies later, WSJT-X will automatically pick up the QSO and — hopefully — complete it successfully. 2. **Wait and Call** This mode goes further: after you enable it by clicking the ‘DX Call’ button (which then turns red), WSJT-X will call the station in your DX Call box up to three times when that station reappears on the band and sends “CQ,” “RR73,” or “73.” If there is no success after those three calls, the program reverts to **Wait and Reply** mode. 3. **Wait and Pounce** This feature lets you automatically respond to incoming CQ calls from other stations. It becomes particularly powerful when you configure the CQ combo box (e.g., set “CQ: Max Dist”). Additionally, you can use it together with filters for more refined behavior. It’s important to note that **Wait and Reply** and **Wait and Call** are both driven by what’s in the DX Call box, regardless of whether the other station’s number is even or odd. Even if the station’s report changes from even to odd (or vice versa), WSJT-X will still reply as though you double-clicked on the message again. Some may disagree, but I find that putting the station’s call sign in the DX Call box is quite useful — especially when I’m feeling a little drowsy or stepping away briefly. In contrast, in JTDX, the waiting function resets when the station in the DX Call box changes from an even to an odd number (or vice versa). Because of that, I believe WSJT-X’s waiting function in the improved edition is more advanced.



JTDX より進んでいる WSJT-X improved版のwaiting mode2025年10月05日 15時54分05秒

WSJT-X improvedには3種類の「待機(waiting)」機能があります:待機と返信、待機とコール、待機と突撃です。

待機と返信は、待機機能を無効にしない限り常に有効です。これは、送信有効化がオフの場合でも、DXコールボックスに登録した局に対して自動的に返信を送信することを意味します。これは非常に便利です。一度だけ局をコールした後、単に待機する(=「送信有効化」を無効化する)だけで済みます。その後、その局がしばらくして応答してきた場合、WSJT-X Improvedは自動的にQSOを再開し、(うまくいけば)成功裏に終了させます。

「待機とコール」機能はさらに一歩進んだものです。「DXコール」ボタンをクリックして有効化すると(ボタンが赤色に変化)、この機能はDXコールボックスに登録した局がバンド上に再出現し、CQまたはRR73または73を送信した場合、最大3回まで自動的にコールします。その後「待機と返信」モードに移行します。

「待機&突撃」は、他局からのCQコールに自動応答する機能です。特にCQ:コンボボックスで適切なパラメータ(例:CQ:最大距離)を設定すると非常に有効です。フィルタとの併用も可能です。

ご覧の通り、「待機と返信」も「待機とコール」もDXコールボックスの内容を使用します。偶数/奇数などの設定とは無関係です。例えば相手局が偶数から奇数に変わった場合でも、プログラムは引き続き該当メッセージに反応します。これは該当メッセージを再度ダブルクリックした場合と同様の動作です。

意見は分かれるかもしれませんが、少し居眠りしたり、ちょっとした用事で席を外したりする際に、QSOしたい局のコールサインをDXコール欄に設定しておくのは便利な機能です。

JTDXのwaiting機能は、DXコールボックスに入れた局が、セットしたときの偶数/奇数の反対側に出てきた時はリセットされてしまいます。


WSJT-X 3.0.0-rc1 のパラメーター設定2025年10月01日 05時44分00秒

WSJT-X ユーザーの皆さん、今までJTDXのデコード性能にずっと負けてきたWSJT-Xですが、3.0.0-rc1 からJTDXのデコード技術が移植され、遜色ないレベルになっています。

WSJT-X の rc 版はどなたでも使えます。rc版は新機能を試して開発者にフィードバックを提供したいユーザー向けではありますが、とりあえずそのデコード性能を経験してみませんか??? 

きっとその差に驚くことだと思います。 今までの WSJT-Xが《超イモ》に思えるレベルです。

どうせ使うならば、improved版を断然お勧めします。

WSJT-X_IMPROVED は、Uwe Risse(DG2YCB)によって公開されています。これは、Joe Taylor(K1JT)、Steve Franke(K9AN)、Bill Somerville(G4WJS)、彼自身、およびその他の開発者(https://sourceforge.net/projects/wsjt/)による優れたソフトウェア WSJT-X の拡張版であり、いくつかの追加機能と改良、さらに頻繁な更新とバグ修正が提供されています。

ダウンロードは https://sourceforge.net/projects/wsjt-x-improved/ 
から入り


Files をつリックして進み



 WSJT-X_v3.0.0  をクリックして進みます。



赤枠で囲った3つのファイルが該当しています。 どう違うかといえばインストールして起動したときの画面がオリジナルのWSJT-Xに近いのか、JTDX風なのか等です。ダウンロード数が一番多いのは improved_PLUSですね。 各人のお好みでどうぞ。

インストールするだけではだめです。パラメーターの設定をしましょう。

JTDXユーザーにはおなじみの項目です。



左の赤枠を選択するのは必須です。 青は任意です。
スレッド数は今バージョンからCPUのマルチスレッドに対応したので、何スレッドでWSJT-Xを動かすかという選択です。 通常は Auto で問題ありません。 ご自身のPCのCPUのスレッド数より大きな数字は選択しないようにしてください。



デコード回数は2か3を選択しましょう。お使いのPCのCPU性能が低い場合は 3 だと重く感じると思いますので、その際は 2 を選択しましょう。



ここの選択は High で良いと思います。



ここの選択は サブパスを使用 がベストなのですが、CPU性能が低い場合は 低閾値 の選択を試してみてください。



ここの選択は標準で良いかと思いますが、各人の環境によって違うと思います。CU性能の高い方は色々実験してみてください。

今までの WSJT-X であり得なかったデコード性能を手に入れた 3.0.0-rc1 、使わない手はないと思います。

FT8 はデコードしてなんぼの世界です。

Windows ユーザーを前提にして記事を書いているのでもう一つ。 電源の設定についても見直してください。


WSJT-X 3.0.0 improved 版は rc 版ではない というご意見も聞きますが、 《本家》がrc1 として出しているものをベースにしていますので rc  と書いています。使う方はその点については全く気にならないと思いますが。

Parameter settings of WSJT-X 3.0.0-rc12025年09月30日 19時07分14秒

The enhanced decoding capabilities in WSJT-X 3.0.0-rc1 appear to stem from technology transfer from JTDX. While JTDX users are already aware of the optimal settings, I thought it would be helpful to share this information with WSJT-X enthusiasts who might not be familiar with them.



Please configure the section highlighted in red as shown here.


WSJT-X version 3.0.0-rc1 now supports multi-threaded CPUs, and it is generally recommended to set this option to "Auto."



For the decoding cycle, choose either option 2 or 3. If you have a high-performance CPU, option 3 should perform well. However, if your system is less powerful, selecting option 3 may lead to longer decoding times. I recommend experimenting with the settings on your computer to find the best option for your setup.




Make sure to adjust both of the above items to the settings indicated in the red frame. Keep in mind that using subpass may feel sluggish on less powerful CPUs..



The ideal setting can vary depending on CPU performance. Typically, "Normal" is a suitable choice, but it's a good idea to experiment to find the optimal configuration for your system.

By adjusting these parameters, you can achieve decoding capabilities that were previously unattainable with earlier versions of WSJT-X. Please test different settings to find the best configuration for your specific environment.

Thoughts on WSJT-X 3.0.0-rc12025年09月23日 10時53分21秒

My thoughts on WSJT-X 3.0.0-RC1. It seems to incorporate JTDX's features, evolved specifically for FT* decoding, with almost no modifications. This clearly reflects the JTDX development team's intent. I believe the JTDX development team decided not to release a GA version until the war ended, instead providing WSJT-X with JTDX's excellent features. This is purely my personal impression, and I don't know the truth, but it must have been a difficult choice.


Features like multithreaded CPU support and decoding settings are identical to JTDX.


WSJT-X enthusiasts will surely be surprised by the sudden, dramatic improvement in WSJT-X's decoding capabilities.



WSJT-X 3.0.0-rc1 の新機能 New Features2025年09月19日 15時11分03秒

先日リリースされた WSJT-X 3.0.0-rc1 ですが、新機能があります。

JTDXに搭載されていた機能をほぼそのまま移植した感じです。

The recently released WSJT-X 3.0.0-rc1 includes new features.

It feels like they've ported over nearly all the features that were in JTDX.





ようやくCPUのマルチスレッドに対応しました。

デコード数はJTDXとほぼ同じです。

今までデコード能力だけで仕方なくJTDXを使用していた方、JTDXのrc版を不正使用している皆さん、いかがですか?  WSJT-X 3.0.0-rc1 をお試しになられては。

At last, it supports CPU multithreading.

The decoding rate is nearly identical to JTDX.

For those who've been forced to use JTDX solely for its decoding capability, and everyone using JTDX's rc version without authorization—how about it? Why not give WSJT-X 3.0.0-rc1 a try?

WSJT-X 3.0.0-rc1 リリース2025年09月16日 06時52分45秒


タイトルの件リリースされています。



WSJT開発チームは、多くの新機能と能力を提供するメジャーリビジョンであるWSJT-X 3.0.0の準備を完了すべく尽力してきました。新機能の多くは既にWSJT-X Improved 2.8.0でテスト済みであり、同エディションのユーザーには馴染み深いものとなるでしょう。一方で、全く新規の機能も存在します。

変更点の完全な概要については、新しいリリースノート https://wsjt.sourceforge.io/Release_Notes.txt および WSJT-X ユーザーガイド https://wsjt.sourceforge.io/wsjtx-doc/wsjtx-main-3.0.0-rc1.html#NEW_FEATURES のセクション 1.1 を参照してください。


なおご理解いただいているとは思いますが、rc版は新機能を試して開発者にフィードバックを提供したいユーザー向けです。

RIGとVSPE2025年09月05日 15時24分05秒


IC-7300とVSPEというタイトルの記事を書きました。

VSPE の FAQには ICOM では という指定が書いてありました。


このページの下から2つ目の例です。



Data processing mode を Switch にしろと。


またFAQの一番下では YAESU / KENWOOD は Data processing mode を Smart router  にしろとあります。




ICOMは  Switch   、  Yaesu と Kenwood は Smart router をお試しください。

Smart routerを選択すると、Settingsからリグのリストを表示させて選択することができます。


フィールドテーコンテストでびっくりした2025年08月04日 12時27分19秒


2025 FD は仲間との移動運用は台風の影響があるかもしれないと判断し中止しました。結果的にはさほど影響はなかったかもしれませんが、あくまでも結果であり判断は間違っていなかったと思います。そして自宅から2日目の4時半から休み休み参加しました。QSOしていただいた皆さんありがとうございました。

CAで参加しました。 160m とかは出られませんが・・・



さてびっくりしたシーンに出くわしたことを書きます。

JARLのコンテスト周波数で40m CWは 7.010~7.040MHz とされています。






しかしバンドプランでは 7.030MHzより上は狭帯域の全電波形式になっているのです。







なので普段から40mSSBしかやらないようなお方が、コンテスト中のCWの存在を無視して移動ごサービスをしている局がいました。 J クラスターにも載ってました。






これはまずいだろうなーーーと思ってちょっと聞いてました。真剣参加じゃなかったので。
そうしたら気がついたのですが3の方がそこで辛抱強くCQ TEST出していたので呼びました。

また戻って聞いてました。JARL会員局と思われました。調べてみるとそのとおりでした。
JARL会員である局がJARLが主催する催し物を尊重することもせず、他モードに対する配慮をすることもせず、いや『できず』なのかもしれませんが、それを注意する局がいたのですが、その注意に対して逆ギレしてヤクザまがいの言葉遣いをしていたシーンに遭遇したのです。悲しすぎますね。

聞いてた範囲では怒鳴っていたのは移動していた方だけではなく、《とりまき?》と思われる局多数という感じでした。しかし注意している方もちょっと煽る感じで話していたので【おいおい(^_^;)】と感じましたけど。

きっと多くの人が聞いていたと思います。

まあ40m SSBばかりで移動運用をやって、クラブが発行するようなローカルアワードに夢中の方にはコンテストなんて全く興味がないだろうし、コンテスト周波数の設定も知らないだろうし知ろうとも思わないでしょうからね。見下しているわけではありません。なんだか悲しいだけです。私はこのような局には関わりたくないです。

「移動御サービス運用」の局も40m bandが大好きなわけでしょうから、自分が好きなbandの使われ方には興味を持ってもらいたいです。

またコンテスト参加者も他モードに配慮した運用が求められますね。
デジタルの国際標準周波数については知っておくべきだと思います。
コンテスト参加者がFT8の国際標準周波数でCQ TESTを出すシーンがあったと聞きます。

このページ コンテスト使用周波数帯 https://www.jarl.org/Japanese/1_Tanoshimo/1-1_Contest/frequency.html  にはデジタル通信の周波数が書かれていますが、例えば今回のコンテスト規約 フィールドデーコンテスト規約 https://www.jarl.org/Japanese/1_Tanoshimo/1-1_Contest/fd_rules.html
には書かれていないのです。

コンテスト規約だけを見て参加する人も相当数いると思います。周知のためには各コンテストの規約にも明記すべきだと私は思います。

LoTW復旧予定のお知らせが来ました2025年07月02日 08時50分25秒


私は ARRL の会員ですのでメールが届きます
それによりますと

Eastern Daylight Time (EDT) で 7月2日の10時とあるので、日本時間では 本日、7月2日23時に復活ということですね。