6/20の日付ですので月曜ですか。JT65-HF HB9HQXの3.4がでたようです。
数日さぼっていたので気づきませんでしたが・・・あまりにリリースサイクルが短い気はします。もう少し落ち着いてもいいのでは？
ロギング周りでDX keeperに直接ロギングする場合の接続法がTCP/IPに変更になったそうです。
追記 2016/06/23 10:29
短時間モニターしてみましたけど、弱い信号のデコードが悪くなっています。
希に、WSJT-XでデコードできているのにHB9HQXではできないという信号があります（QRMがない場合でも）。
文字化けに対して慎重になって、アグレッシブなデコードをしなくなっている感じです。
6mのJT65に出るようになってから不思議な現象があります。
下記のようなウォーターフォールになることがあります。
これは同じ局のCQの送信ですが、真ん中に映っている回だけ、なぜか数十ヘルツ程度下にさらに下に向かって下がって行く信号となっています。
これはWSJT-Xのウォーターフォールなのですが、HB9HQX版でも同様ですし、実際の信号を聞いていてもビートが聞これますので、少なくとも受信段の検波前で起きている現象です。また、上と下では発生していないので、いつも発生するわけではありません。
このウォーターフォールではわかりませんが、他の局の信号も受信しているときには、この症状が起こる局と起こらない局があります。
原因がわかりません。ドップラーシフトの様にも見えますが、通常は下にさがるだけなのでそれだけでも変ですし、ましてや数十ヘルツのシフトを起こすようなドップラーシフトってどれくらいの速度が必要でしょう？
これが出るとたまにデコード不可能になることがあります。
そして上記は50.2764にQRGをセットした状態です。赤く太く見えているのはLANからの漏れのようです。
これらのせいでプリアンプを入れるとノイズレベル３～４程度となっています・・・
昨夜、DX lab suiteのうちのロギングソフトである “DX keeper”の導入の話を「超簡易」とかきつつ、インポートまで書いたらかなり分量が増えてしまいました。
そして、肝心のJT alertとの連携を書きませんでした。
JT alertのsettingsから Manage Settings…を選んで設定ダイアログを表示させてください。
設定中でDX lab関係の箇所は２箇所あります。
まずうまく接続できるかどうかのチェックをした方が良いでしょう。DX lab launcherなどからDX keeperを起動してください。
その後で、JT alertの設定のうち、下図の箇所を開いてください。
このDXkeeper関連のところにチェックを入れることになります。
チェックを入れたら、さらに接続テストをしてください。
蛍光ペンっぽい色でマーキングした箇所が操作箇所です。[+]をクリックすると下位メニューが展開されるので、DXLab Suiteを開いて、さらにTestに移動してください。そこで右側の[Test]ボタンをクリックです。うまく接続出来ていれば、インストールされるアプリの横に Running とか Connectedが表示されるはずです。
そしてロギングそのものをDX keeperに切り替えます。
多くの方は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によってハムログに接続している場合は、これでロギングが２重になります（DX keeperとハムログ)。DX keeperに入力されるQSO時刻は、JTalertのログ入力欄に入っている数値です。Log QSOをクリックした時の時刻とは通常は3～6分程度離れているはずですので、必要に応じLog QSOの時刻をキーボードで訂正してください。パイルになっている局を呼んでいる場合など、十数分～数十分ずれていることもありますから気をつけてください。
また、HB9HQXエディションでは、ロギングそのものをDX Keeperに変えることができるのですが、これはおすすめしません。というのは、HB9HQX版で生成されるログファイルをJT linkerが監視していて、これが更新されるとハムログへデータを転送するようになっているためです。
この１ヶ月ほど、JT65-HF-HB9HQX 3.2を併用してみました。
このJT65-HFのバリエーションのいいところは、WSJT-X 1.5/1.6と比べた場合に、S/Nが悪いときにデコードの粘りが良いことです。いわゆる感度が良いという状態です。
しかし、最近色々とデコードさせてみて、以下の現象を体験しています。
ゴーストのデコードがあるのが問題で、JT65-HF-HB9HQX使用局はデコード情報をそのままスポット(HamSpot.net)に上げているとばれますねｗ
比較的改修ペースが速いのでいずれは直るのかもしれませんが、現時点では上記に注意した方が良さそうです。
40mbで同時デコードのテスト中。
WSJT-X向けのオーディオ設定だと HB9HQXではやや信号レベルが低いので、オーディオミキサーで録音デバイスのレベルを少し上げ、WSJT-Xのゲインを下げ。ややWSJT-Xにとっては不利な状況。
その上で比較すると、以前からあった「弱い信号のデコードに強い」は健在。また、多少の被り(100Hz近く)でもHB9HQXでデコードできるケースが増えた模様。ただし、被りがある場合のデコードのS/Nは、まだWSJT-Xの方が一日の長があり、数dBは違う結果が出ている。また、HB9HQXでは「オバケ」が出てきたケースがある。強めの信号とか、あるいは南米からの信号などやや「ゆらいでいる」信号で、実際の信号の数ヘルツ下側でKVASDがオバケをデコードしてしまう傾向があり、PSKRへはちょっと送信しがたい。
これは送信についてもHB9HQXを有効にしたほうがいいかもしれないが、使用法を考える必要あり。
ただし、ロギングでDX keeperを有効にしてしまうとJTlinkerが使えないようなので、ハムログとの連携はちょっと工夫が必要か。あるいはあえてローカルのadifファイルをアクセスするようにして、もう一つJTalertを立ち上げるか？
先日、commanderでデフォルトポートが使えなかったためポート番号を変更した旨書きましたが、具体的にどのアプリが悪さをしているのか調査をしてみました。
コマンドプロンプトを立ち上げて
netstat -nao
・・・で、ふさがっているポートとプロセスＩＤが出てくるのですが、見当たりません。
あれれ？
それでcommanderでポートをデフォルトにもどしてサービスを再起動、その上でWSJT-Xの指定ポートをデフォルトに変更。・・・動くじゃないですか。
ついでに昨日はポート番号の違いのため接続できなかったHB9HQX版でCAT接続のテスト。これも無事動作。
送信を複数のクライアントでやってしまうと変なことになるので、HB9HQXの方はPTTを殺した上で、送信用の信号はモニターに出力するように変更です。
同時起動して、HB9HQXからバンド変更して連動を確認。WSJT-Xからも連動を確認。ひとまずこれで両方モニターできます。（なお、HB9HQXからはPSKRへの送信はなし、eQSLの送信も未設定で、ログだけはDX keeperを参照するようにセット)
HB9HQXの方の最適な入力レベルをまだ調べていません。どんなもんでしょうね。
さきほどたまたま、ロシアのヨーロッパ局とのＱＳＯで差が出たのでスクリーンショット。
ＱＲＧは18MHzの方が正解です（HB9HQXはCAT連携していないので不正確）
下部右側の方では最初にコールもらった時にもデコードできていますが、WSJT-Xではデコード不可。
次のコールは両方ＯＫ，レポートはWSJT-X不可でHB9HQXではデコード可。
ファイナルは両方で可能でした。
それにしても、この 1670あたりを中心としたパルスはなんなんだろう？
JT65のクライアントアプリですが、先日NEGIさんがアプリ複数起動されているとのことだったので私も試してみました。
純正ともいえるWSJT-XとHB9HQX edition( 0.9.90.0, 確か昨年末に入れるだけ入れてみただけですので、最新版ではないかもしれません)です。
八重洲のリグの場合は、端末ソフトからCATで接続していても、リグ側からは設定変更のデータがＰＣには取り込まれないため、ソフト側から状態取得のpollingを行っています。その関係で、CATの接続は一度に一つだけやるしかありません。(VSPEを使ってもポーリングが衝突するとやっかい。また、オーディオデバイスもそれぞれでサンプリングを設定するようなものは同時起動しない方がトラブル少なそうです）
WSJT-Xではオーディオ表示はQRG周波数からの＋のオフセット表示ですが、JT65-HF系のソフトでは、2.5kHzの帯域の中心からの±オフセット表示です。これがちょっと換算面倒です。
デコード結果ですが・・・次のような感触を得ています。
JT9もやっているのでメインがWSJT-Xというのは揺らぎませんが、将来もし対応することがあればHB9HQXもいいかもしれません。
日々是物書 