QSL発行状況

2019/5/6までの交信分は、リプライ分も含め発行し、5/8にビューローに送付しました。

またLotWやeQSLも交信分は、すべてADIFファイルのアップロード済みです。

5/7以降になって、対応するeQSLをお受け取りでない場合や、LotWでcfmになっていない方は、尻切れなどで交信成立と見なさなかったケースがありますのでご確認ください。

そして1点、半分笑い話ですが…

最近はかなり早めにeQSLを送ってくださる方も少なくなく、嬉しい限りです。この発行の仕方もいくつかあると思いますが、私はログアプリ(DX keeper)から直接アップしています。もう3年以上このやり方で特に時刻ずれなどの問題もないのです。

先日、令和の初日の夕方にリジェクトのメッセージが来て相手のカードを確認しました。まず、ログによるとスタートタイムがJSTの5/1 08:59、つまり交信の当日にもらったのですが、そのログをなぜかUCTの5/1 23:59に変換してアップされたようで…

その結果、インボックスでは一致する物がないと表示されますよね。

それであちらは自信満々でリジェクトし、「日時をご確認ください」とわざわざメッセージくれました。

確認したら上記のように5/1 1800JSTころに、「5/1 2359GMT」にしたという交信のeQSLが来たわけで、未来からのeQSLが…

多分ハムログからログ作成したか、ウェブインタフェースから入れたかなのでしょうが、リジェクトする前に、まず自分のデータが間違っていないか確認して欲しかったですね…

結局こちらからあちらのカードをリジェクトしその時のメッセージに上記の日時の指摘を入れておきました。

皆様におかれましても、リジェクトされる前に、まず、自分のデータの誤り(まれに9時間のずれのものを受け取ることがあります)をチェックしてくださいね。

広告

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

DX keeper の導入法(超簡易版)

網羅的なものではありませんが、JTalertと連携させて使うのに便利なので、使い続けるかどうかはおいといて、一度試してみて欲しいのです。なるべく簡単に書いたつもりですが、結構な分量になり、また「超」簡易ではなくなってしまったかもしれません。

ハムログと比べての長所短所を思いつくままに書くとこんな感じです。

  • 日本語を入力できない(QSLで特に不便)
  • eQSL/LoTWへのアップロードやダウンロードが楽
  • JTalertで直接DX keeperのログを検索できるので “QSO B4″や”wanted prefix”などにeQSL/LoTWのコンファーム情報を含めて表示可能
  • 固定した運用地をいったり来たりする人にはQTH切替機能が楽
  • 記述が柔軟、一方で新しいログエントリー(個々のQSOの記録)を入力するのは、ハムログの方が楽かもしれない。JT9/JT65との連携ならほとんど関係ない。
  • 紙カードの印刷は、印刷コマンドそのものがハムログの方が充実しているし、日本語印刷できない時点で負け
  • 検索の柔軟さは、RDB(リレーショナルデータベース)で使われる”SQL”の基本的な書き方(SELECT ~ WHERE)の”where句”が書ければ、色々と検索式を定義できる
  • DXCCやWASなどの海外アワードの進行状況チェックが充実、JCC/WAJA/JCGなども一応あり
  • 英語のヘルプや操作画面でとっつきづらいかもしれない

 

また、以降はすでにeQSLやLoTWの登録を済ませて、使用中であることを前提にしています。

登録の手順などは説明していませんので読み進んでから「できない」と言わないでくださいね。

“DX keeper の導入法(超簡易版)” の続きを読む

検索語から「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」二回目” の続きを読む

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

検索語で掲題のものがありました。

2回に分けて説明します。

ただし、私の環境はちょっと変なので、スクリーンショットの通りに設定して動かすには、色々インストールするものが必要になると思います。

WSJT-Xはすでにインストール済みとして、最低限”JTalert”をインストールし、WSJT-X向けのJTalertが起動するようにしてください。

※WSJT-Xで交信するだけならJTalert(JTalertX)は不要です。eQSLに自動でQSLを送信したり、その他のオンラインのログサービス(LoTWを除く)に自動でログを送信する場合に、WSJT-XではJTalertと連携させる必要があります。

今回の説明ではターボハムログとの連携については説明しません。

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

ドイツからのSWLレポート(eQSL)

ドイツとかイタリアは随分SWLが盛んなようです。これまでもらったSWLカード(eQSL)のほとんどがドイツとイタリアです。

中にはドイツ系イタリア人という方からも受け取っています。

さて、21MHzとか14MHzでヨーロッパからもらってもそれほど不思議もないのですが、今回はびっくりしました。

5Wで7.041でやっていた夕方の国内JT65交信です。

フォーンの混信がないので飛んでいたといえば飛んでいたのかもしれませんが受信レポートは-11dB。まじで?

日本国内に旅行にきていたとかではないことを祈りたいですw

本日の飛び具合は・・・

本日は昼ご飯を近所に食べに行くのも断り、家族がスーパー銭湯に行くのも我慢してリグの前にいたわりにはあまりQSO数が伸びませんでした・・・ログはわずか26です。

国内11, DX25となりました。

JT65/JT9の飛び具合はこんなもの:

飛び具合

南米がフォークランド島だけ、アフリカなし。高さもそれほどないワイヤーバーチカルだからこんなもんでしょう!

夕方、北海道ではEsがでなかったおかげなのでしょうが、ヨーロッパが18MHzで比較的飛んでくれたので(VOACAPを見て狙ってたけど)少しDXが増えました。

去年のGWの方が断然コンディション良かったですよねぇ。