DX keeper他DX lab suiteとJTalertの連携

昨夜、DX lab suiteのうちのロギングソフトである “DX keeper”の導入の話を「超簡易」とかきつつ、インポートまで書いたらかなり分量が増えてしまいました。

そして、肝心のJT alertとの連携を書きませんでした。

JT alertのsettingsから Manage Settings…を選んで設定ダイアログを表示させてください。

設定中でDX lab関係の箇所は2箇所あります。

まずうまく接続できるかどうかのチェックをした方が良いでしょう。DX lab launcherなどからDX keeperを起動してください。

その後で、JT alertの設定のうち、下図の箇所を開いてください。

applications

このDXkeeper関連のところにチェックを入れることになります。

チェックを入れたら、さらに接続テストをしてください。

test

蛍光ペンっぽい色でマーキングした箇所が操作箇所です。[+]をクリックすると下位メニューが展開されるので、DXLab Suiteを開いて、さらにTestに移動してください。そこで右側の[Test]ボタンをクリックです。うまく接続出来ていれば、インストールされるアプリの横に Running とか Connectedが表示されるはずです。

 

そしてロギングそのものをDX keeperに切り替えます。

JTalert logging

多くの方はStandard ADIFを選択されていると思います。HRDやLog4OMなどはDX Keeperと比べてどうかは存じませんのでここでは比較しません。

この状態で”Enable DXLab DXKeeper Logging”にチェックを入れると、以降、JT alert用のQSOログ管理がDX keeperになります。他のログを指定していた場合は、他のログは自動的に「オフ」になります。

JT Linker の連携は、また別のつながり方での連携ですから、この設定を行っても、基本的にはハムログとの連携はそのまま残ります(※ロギング時に動くプログラムが増えるのでメモリーとかCPUパワーの使われ方は若干変わります)。

WSJT-Xなどで[Log QSO]を押したあと、JT alertがログを DX keeperに追加してくれます。

ロギング時のeQSL Uploadは、JT alertから直接行うこともできるのですが、DX keeperを使う場合は、”Instruct DXKeeper to upload each new QSO to eQSL”にして置いた方が後でログ操作が減るので楽です。

(もっとも、一つ一つコメントを入れたいという方はロギング時アップロードではなく、Requestedにしておいてから、QSLメッセージを入力し、アップロードキューに「積んで」、まとめてアップロードした方が良いでしょう)

データをインポートした直後は、操作ミスをしてデータが壊れても失う物が一番少ないので、コンディションが悪い日にでもインポートして、色々試してみると良いと思います。

 

この接続をした状態で、実際にJT alertを動作させた状態で、どこかのバンドをワッチして、デコードされたコールサインの「QSO B4」とか、コール右クリックでの「以前のQSOヒストリーの表示」などが動作することを確認してください。

それが完了したら “Scan Log and Update”を実行してください。これでログの状態がトラッキング込みで反映されるようになっているはずです。

WSJT-XをJTlinkerによってハムログに接続している場合は、これでロギングが2重になります(DX keeperとハムログ)。DX keeperに入力されるQSO時刻は、JTalertのログ入力欄に入っている数値です。Log QSOをクリックした時の時刻とは通常は3~6分程度離れているはずですので、必要に応じLog QSOの時刻をキーボードで訂正してください。パイルになっている局を呼んでいる場合など、十数分~数十分ずれていることもありますから気をつけてください。

また、HB9HQXエディションでは、ロギングそのものをDX Keeperに変えることができるのですが、これはおすすめしません。というのは、HB9HQX版で生成されるログファイルをJT linkerが監視していて、これが更新されるとハムログへデータを転送するようになっているためです。

検索語から「wsjt-65の送信の方法」「wsjt-x e-qsl」二回目

WSJT-XからeQSLの送信についての部分を二回目として記します。

後半は少しだけDX lab suiteのお話つきです。

まず、WSJT-XにはeQSLを送信する機能は内蔵されていませんので、協調して動くJTalertを使います。JTalertは昔から一緒に使われてきているようで、WSJT-Xのオンラインマニュアルにも数カ所で名前が出てきます。たとえば11章や12章です。

JTalertとWSJT-Xを連動させる

今日(2016/05/26)、JTalertのアップデートが出て、2.7.3になりましたが、WSJT-Xの方のとあるオプションがオフになっていると警告が出るようになりました。

JTalert-3

“検索語から「wsjt-65の送信の方法」「wsjt-x e-qsl」二回目” の続きを読む

JTalertXでアラート音が鳴らない場合

いくつか原因が考えられます。

以前は音が出ていたのに出なくなった場合

サウンドカードの指定が正しいかどうかの確認(settings-Sound Card)。希に、個別カードを指定すると音が鳴らず、”Windows default sound card”にしなければ鳴らない場合があるようです。オーディオインタフェースを追加・交換した場合は注意です。

JTalertXのタイトルバーでサウンドオフになっていないか確認。何かのはずみでタイトルバーのサウンドのオンオフ切替をクリックしてしまって音がでなくなっていることがあります。

新しくインストールした場合

上記の「以前は~」の他に、アラートそのものが有効になっているかどうかの確認。

アラート音のWAVファイルが指定されているかどうかの確認。サウンドをインストールしただけではWAVファイルが有効にならなかったことがあります。デフォルトサウンドを指定したら鳴るようになりました。

直れば良いのですが。

JTalertX 2.6.26とカスペルスキー

.25から.26への更新は一部JT65クライアントからのイベントハンドリングの追加だったようですが、なんとカスペルスキーがそれを危険動作認定してデータベース更新された模様。

その結果、デフォルト設定だとオブジェクトが削除されてしまいます。

2.6.25で問題なく動作している人はしばらくアップデートしない方がいいです。