カテゴリー: JTDX

bookmark_border[385] JTDXログ不具合？

ログを「eQSL.cc」にアップロードした後inboxを見たところ、1局だけ相手側のeQSLにエラーが出ていました。早速TurboHAMLOGで検索すると確かにQSO自体は記録されていますが交信時刻が違っています。当局のログでは時刻が9:00（JST）となっており、eQSLにアップロードし記録された時刻も0:00（UTC）です。しかし相手局からのeQSLの交信時刻が全く違います。

そこで、JTDXのログを調べてみると交信開始時刻が0:00となっていました。他方、交信終了時刻はきちんと正常に記録されています。どうもJTDXのエラーのようです。
当局は、通常JTDXからJT_Linkerを介して一旦TurboHAMLOGにログを記録してADIFファイルを作り、そのファイルをeQSL、CLUBLOG、LoTWにアップロードし、QRZ.ccにはLoTWからインポートするようにしています。今回はTurboHAMLOGのログ記録をマニュアル修正してADIFファイルを作り、再度eQSL.cc、CLUBLOG、LoTWにアップロードしました。
その後、改めてeQSLを確認するとエラーが消えていました。

少し気になってログを見ると他に3局が0:00（UTC）として記録されていましたので、JTDXログの交信終了時刻を参考にしてマニュアルで修正しアップロードし直しました。
1日で4件も間違いが出るということは、以前も同じ様なことがあったのかも知れません。しかし全く気付きませんでした。
今後は気をつけたいと思います。

bookmark_border[362] JTDXの「-26dB」現象

この週末は天気が不安定だったため、ベランダ内のアンテナを使って少しの時間ではありましたがFT8を運用しました。

その中で、またJTDXの「-26dB」現象が現れました。バンドは430です。0エリアの局が受信できたため呼んでみると、早速応答していただけました。

その後、こちらからのレポートの具合が悪かったのか、相手局から再びレポートが送られてきたと思ったら同じタイミングで「RR73」が送られてきました。おそらく相手局は途中でこちらのレポートに気がついてマニュアルで「RR73」を送っていただいたのだと思いますが、ここで当局のJTDXのHint機能が働いたのでしょうか、「-26dB」でデコードした部分に反応して「R-26」のレポートを送ってしまいました。

カーソルを合わせるのに手間取り、4秒遅れで相手局の「RR73」をダブルクリックして「73」を返信し事なきを得ましたが、少し慌てました。

当局は「-26dB」を表示したときのJTDXの挙動はあまり信用できないというのが実感としてあり、Hint機能はOFFにしたいのですが、ボタンを押してもOFFできないようですね。ただDXなど本当に弱い信号の場合は、結構この機能に救われていることもあるのかも知れません。

bookmark_border[340] FT8設定状況の確認

CQ誌9月号には、8月号に続き別冊付録として「FT8マニュアル」がついており、8月号が「入門」編であったのに対し今回は「活用」編です。

早速、当局のFT8設定状況を確認しました。まず基本的な見直しポイントとして挙げられている次の7点です。

①PCの時計合わせ

「iネット時計」をインストールしており、運用の都度、そのアプリを立ち上げて時計を合わせています。精度は±0.2秒ですが、記事によると「JTDXの場合、0.18秒以上遅れるとデコーダーの感度が約6～8dB低下するといわれている」とのことですので、何か別の方法を考えた方が良いかも知れません。

②PC処理能力の向上

先日書いたように、当局では何世代も前のプロセッサを使っており、これも「処理能力によってデコードに大きな差が出る」とのことです。特にJTDXはデコード時の負荷が重いそうですので、記事にはプロセッサの状態やCPUクロック周波数を常に100％にすることが推奨されています。当局ではこの設定にしていますが、常にファンが動いた状態で、少しでも排熱がうまくいかなくなるとスロットリングによりクロック周波数が急激に落ちるおそれがありますので、バランスが重要かと思います。

③綺麗な電波の発射

第1はALCレベルメータでの確認が重要ですね。またFT-991AMでは送出信号のオーディオモニタができるためそれで確認したり、相手局から送られるSNRレポートを参考にしたりしています。ちなみに、以前使っていたFT-450DMでは送出信号のモニタができなかったため（自分がモニタ方法を気付かなかっただけかも知れませんが）、不安はありました。

④スプリット設定

「Rig 」設定をしています。スプリット設定をしないと2,800Hz以上のDFでは送信できないこと、初めて知りました。

⑤受信帯域フィルタの拡張

リグ上ではフィルタの幅を最大に設定しています。JTDXやWSJT-Xではワイドグラフの表示範囲しかデコードしないとのことで、設定を確認したところ「Bins/Pixel 2」になっていたため「Bins/Pixel 3」に変更しました。

⑥受信能力改善

受信を妨げるほどのノイズは受けていないように思いますので、特に何もしていません。アンテナやカウンターポイズの調整により、結果的に受信ノイズを低減しているのかも知れません。

⑦ソフトウェア最新化

使っているJTDXは「v.2.2.156」ですが、JTDXのサイトを見たらこれが最新の様ですのでOKです。

別冊記事の内容は盛りだくさんで情報も多く載っていますので、JTDX中心に書かれていることもあり、これから落ち着いて一つ一つ学んでいきたいと思います。

ちなみに、以前「同一局が同じタイミングで複数の信号を出している」のを怪現象として不思議に思っていましたが、これは記事にある「DX petition mode」か「MSHV」と思われます。 勉強になります。

bookmark_border[325] 15m不思議な現象

結局、12mは当面諦めて17m、15mなどを中心に運用していきたいと思います。そこで、15m FT8でインドネシア局がCQを出していましたので呼んでみました。

その局は他のJA局に応答したので、当局は次の呼び出しに備えてTXボタンを押して待っていたら・・・

何とJA局に「73」を送出するのと同じタイミングで、当局に「-13」のレポートが送られてきました。当局（のJTDX）は「-26」を返していますが、ぎりぎりで相手局の信号がデコードできたということでしょうか。

WSJT-XやJTDXに、複数局へ同時に信号を送る機能があるのかどうかはわかりませんが、不思議な体験をしました。

bookmark_border[277] 6m活況

これは昨日午後の6m FT8の様子です。欧州方面が開けていたようです。あいにく天気が悪かったのでアンテナはベランダ内のHFV5で、全く逆方向のため残念ながら欧州局は受信できませんでした。

まるで40mの様相を呈しており、それも特定局に集中したパイルではありません。皆さん欧州DX狙いで当局は大人しくしていた方が良さそうな状況だったため、すぐに2mにQSYしました。

更に驚くべきことに、この時55局のデコードに成功していました。当局のデコード環境では最高記録です。FT8は一信号あたり50Hzの幅があり、それが3KHzの帯域に収まる訳ですから、理論上は最大60局分しか収容できません。55局というとそのうちのいくつかはDFが重なっているでしょうが、90％を超える密度です。

JTDXを「156」にアップデートしてからデコード性能が上がったような気がしていましたが、まさかここまでとは思いませんでした。