HB9HQX 3.4リリース

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からの漏れのようです。

これらのせいでプリアンプを入れるとノイズレベル3~4程度となっています・・・

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が監視していて、これが更新されるとハムログへデータを転送するようになっているためです。

化ける JT65-HF-HB9HQX版

この1ヶ月ほど、JT65-HF-HB9HQX 3.2を併用してみました。

このJT65-HFのバリエーションのいいところは、WSJT-X 1.5/1.6と比べた場合に、S/Nが悪いときにデコードの粘りが良いことです。いわゆる感度が良いという状態です。

しかし、最近色々とデコードさせてみて、以下の現象を体験しています。

  1. 特に信号が強めの局のデコードで、本来の信号の数ヘルツ下あたりに「おばけ」をデコードしてしまうことがある。
  2. 信号が重なった場合、多くの場合はWSJT-Xの方がデコード率が良い(一方、まれに、WSJT-Xでは分離できなかった位に近い信号を分離できることがありますが、そのために1の現象が起きているのかも)
  3. 通常コールの前にプリフィックスを付けている場合(たとえばDU/W6XYZとか)に、プリフィックスがデコードされない上、付いていないグリッド情報が再現されてしまう。
  4. 最近希にみかける画像系のユーザが送信する “R+49” が妙なグリッドに変換されてしまう。

ゴーストのデコードがあるのが問題で、JT65-HF-HB9HQX使用局はデコード情報をそのままスポット(HamSpot.net)に上げているとばれますねw

比較的改修ペースが速いのでいずれは直るのかもしれませんが、現時点では上記に注意した方が良さそうです。

JT65-HF HB9HQX edition (3.2)

40mbで同時デコードのテスト中。

WSJT-X向けのオーディオ設定だと HB9HQXではやや信号レベルが低いので、オーディオミキサーで録音デバイスのレベルを少し上げ、WSJT-Xのゲインを下げ。ややWSJT-Xにとっては不利な状況。

その上で比較すると、以前からあった「弱い信号のデコードに強い」は健在。また、多少の被り(100Hz近く)でもHB9HQXでデコードできるケースが増えた模様。ただし、被りがある場合のデコードのS/Nは、まだWSJT-Xの方が一日の長があり、数dBは違う結果が出ている。また、HB9HQXでは「オバケ」が出てきたケースがある。強めの信号とか、あるいは南米からの信号などやや「ゆらいでいる」信号で、実際の信号の数ヘルツ下側でKVASDがオバケをデコードしてしまう傾向があり、PSKRへはちょっと送信しがたい。

これは送信についてもHB9HQXを有効にしたほうがいいかもしれないが、使用法を考える必要あり。

ただし、ロギングでDX keeperを有効にしてしまうとJTlinkerが使えないようなので、ハムログとの連携はちょっと工夫が必要か。あるいはあえてローカルのadifファイルをアクセスするようにして、もう一つJTalertを立ち上げるか?

WSJT-X + HB9HQX edition with Commander

先日、commanderでデフォルトポートが使えなかったためポート番号を変更した旨書きましたが、具体的にどのアプリが悪さをしているのか調査をしてみました。

コマンドプロンプトを立ち上げて

netstat -nao

・・・で、ふさがっているポートとプロセスIDが出てくるのですが、見当たりません。

あれれ?

それでcommanderでポートをデフォルトにもどしてサービスを再起動、その上でWSJT-Xの指定ポートをデフォルトに変更。・・・動くじゃないですか。

ついでに昨日はポート番号の違いのため接続できなかったHB9HQX版でCAT接続のテスト。これも無事動作。

送信を複数のクライアントでやってしまうと変なことになるので、HB9HQXの方はPTTを殺した上で、送信用の信号はモニターに出力するように変更です。

同時起動して、HB9HQXからバンド変更して連動を確認。WSJT-Xからも連動を確認。ひとまずこれで両方モニターできます。(なお、HB9HQXからはPSKRへの送信はなし、eQSLの送信も未設定で、ログだけはDX keeperを参照するようにセット)

HB9HQXの方の最適な入力レベルをまだ調べていません。どんなもんでしょうね。

WSJT-XとHB9HQXのデコード比較

比較

さきほどたまたま、ロシアのヨーロッパ局とのQSOで差が出たのでスクリーンショット。

QRGは18MHzの方が正解です(HB9HQXはCAT連携していないので不正確)

下部右側の方では最初にコールもらった時にもデコードできていますが、WSJT-Xではデコード不可。

次のコールは両方OK,レポートはWSJT-X不可でHB9HQXではデコード可。

ファイナルは両方で可能でした。

それにしても、この 1670あたりを中心としたパルスはなんなんだろう?