タグ: DX keeper

DX keeperのOQRSのダウンロードボタン

紙QSLのリクエスト対策にOQRSをenableにしているのですが（ＪＡみたいな雑魚エンティティにわざわざリクエストが来ることも無かろうとたかをくくっている）、たまーにリクエストが来ます。年に１，２件。

DX keeperの方でinbound OQRSの処理ができますが、カード発行をDX keeperではやっておらず、ハムログで印刷になるので、来たOQRSは、手動でハムログにマークをつけています。年に１，２件ですから作業としてはこの程度で十分。

さっき、JH8JNF/2のコールをClublogに追加したときに、１～２ヶ月ぶりにOQRSを確認したら１件増えてました。（ギリシャから、17mb/JT9)

さて、これをどうやってDX keeperに取り込めたっけ、と久々なので忘れていて、思い出すのに２０分。

手順はこんな感じ。

  1. 複数のコールをClublogに登録している人は、DX keeperのQSL configのClublogのところで、対象のコールにセット。たとえば私の場合は関東のPCではJH8JNF/1のコールをセットしてあることが多いのですが、JH8JNF宛ての場合にはClublogのコールをJH8JNF/1からJH8JNFに変更する必要があります。
  2. そして次にOQRSの確認ボタンをクリックするのですけれど、このボタンはQSLのタブではなく、Progressのタブにあります。他のQSL管理はeQSL/LoTWやQSLそのものの印刷を含めてQSLタブにあるのですが、inbound OQRSだけはProgressにあるのです。これが分かりづらい。
  3. もしログにマッチするOQRSリクエストがあれば、DX keeperのQSLカードのステータスが “R” (requested)に変わります。いちいち検索するのは面倒なので、ステータスが変わった物は、QSLタブで”Add Requested”をクリックして「発行のキュー」に積んでやれば確認ができます。
  4. DX keeperで印刷もしている方は、そのまま印刷すればＯＫです。送付方法もB(uro)とD(irect)がステータスに入りますから確認してください。
  5. ハムログなどで印刷管理している方は、手動でハムログの方にJマークを入れるなりして対応を。その場合、ハムログにQSLの印刷情報を写したら、DX keeperのログエントリーでは「発行済み」の”Y”に変えておくと良いと思います。次にOQRSでinboundのものがあった時に、同じように印刷キューに追加してみるとリクエストの有無がわかりますので。

DX局のカードでよく見る、シールを貼る形式のカードにするなり対策すれば良さそうなのですが、まぁ枚数が増えてから考えればよしとします。年間１～２件じゃあんまり時間かけて自動化しても、ね。

JTalert-XとDX keeperの連携 vs. WSJT-XとJTlinker/ハムログの連携の違いで気をつける事

今朝１つはまったので備忘録。

今朝、南米がオープンしてる時間帯にコールしてもなかなかQSOが成立しなかった局がありました。最初にコールをダブルクリックしてからQSO成立してロギングするまで20分くらいかかりました。

その後eQSL/LoTWでコンファーム出来たのですが、その状況をDX keeperで同期しようとしたら、マッチするログエントリーがないというエラー。

ロギングして登録されている時刻とeQSLで受け取った内容が15分以上違うからです。
その南米局をコールしてる時、S/Nがほとんど変わらなかったので、毎回送信周波数だけ修正してコールしました。最終的にはオフセットをつけてコールしてやっとQSO、レポート交換が終わってロギングしたら、最初のコールからかなり時間が経っていました。

その状態でLog QSOをクリックすると、ハムログとの連携の方は、WSJT-Xのロギング用のウインドウを経由して、JTlinker、ハムログと転送されていきますが、このロギングウインドウが曲者で、開いた時に入力されている時刻は、ボタンをクリックした時の時刻です。そのままロギングを進めると、ハムログには、QSOの途中、または終了後のタイムスタンプが入ります。
仮に、Log QSOを押したのが01:19に出たCQに応答し、01:20にコール、01:21にレポートもらい、01:22にRつきレポートを送信、01:23にRRRか73をもらってLog QSOをクリックすると、ハムログの方は、手動で時刻訂正しない限りは01:23がQSO時刻として記録されます。これがちょっと気になってはいました。
一方でDX keeperとの連携は、JTalert-Xにコールを転送した時に入るタイムスタンプがログには開始時刻として記録されます。ですので、ダブルクリックしたのが01:19とか01:20ならそれが記録されていきますが、今回はそのずいぶん前にダブルクリックしてJTalertに転送していたので、この例なら01:01とか、それくらいの時刻がJTalertのログ入力欄には入っていました。

eQSLはそのまま発行してしまいましたので、送ったeQSLはQSOに入るずいぶん前のものとなっしまっていました。
QSOのマッチングの時間ウインドウが±15分程度だと、この例ではマッチするQSOがない事になってしまいます。こういう場合はロギング前に対処する場合は、手動で時刻を訂正しておくか、再度ダブルクリックでJTalert-Xにコールと時刻を転送するしかないようです。

今は結局乗り換えはできず、両方のロギングをやっている状態です。
DX keeperを入れて改善したのは、JTalertで表示されるポップアップなどに、ロギングソフト上のeQSL/LoTWでのコンファーム状況が反映されるようになった事です。

日本語の使用には制約が付きますが、それを除けばメリットは大きいようです。

カードの印刷についてはこれからDX keeperの方でできる事の詳細を調べます。(JARLの転送枠のための両面印刷できるのかな)

DX keeperへターボハムログからデータを移す

例によってADIFで移したいデータを作成して、QSOのインポートを実行するだけです。

ただし、ハマりましたので備忘録。

書き出すデータに日本語を含めない


ひょっとしたらエンコードをUTF-8にでもすれば良いのかもしれませんが、日本語でQTHや名前が入っているログレコードを書き出すと、書き出したそのままのデータでは該当レコードを認識してくれません。

ハムログで書き出した件数とインポートした件数がかみ合わず悩みましたが、日本語が悪さをするようです。

わたしはエディタで開いて日本語をローマ字に書き直しました。

わたしの件数程度(インポートしたのは1年分、1000件程度)で、しかもJT65/9中心ならその後でDX keeperでデータを直しても大した数では無いと思いますが、長年お使いの方は海外交信のみに限定し、JAは申請に使うものだけにするとか、WPX程度とする事にするのが良いかも。

あと、インポートの時は重複レコード削除するように設定した方が良いです。

グリッドはコンファームするまで入らない


みたいです…もちろん、手動で入れたり、オンラインコールブックを参照して入れる方法はありそうです。

WASの自動トラッキングには計上するmyQTHの設定が必要


…それに気づくのに丸一日かかりました。
結局今はハムログとDX keeperの両方を起動して、両方にロギングしてます。

中国の地域名略称でハマる

LoTWと同期すると中国のディストリクト名がアルファベット2文字の略称で入るのですが、DX keeperでは、数字2桁のコード管理なので、データ集計でエラーが出て気分が悪いです。入力ツールにもバグが多いようです。日本のJCCコードなどはきちんと動くのですが、テストしたり利用してる人が少ないという事なのかも。