PATHpilotのブログ

久しぶりにCQを出してみた。応答なし。ところが、、、

Free Textで”PSE QSY DF”と30秒後に信号があった。シグナルレベルから察すると結構近所からみたい。

おそらく”Please QSY Down Frequencty”と伝えているのかと思われる。前後のBand Activityから察するに私に対して送ってきたと推測される。

混信を与えてしまっているかと心配になり暫くWatchすれども、少なくとも私のアンテナにはその近辺の入電なし。それどころか、私がCQを出した前には1036HzでJA1局を呼ぶJK1局のみ。私がCQを出した後にはしばらくActivityはなし。1200Hzって何か特別な周波数なんだろうか？なんだったんだろう？？？

経験が浅いというのは不安なもの。

ぼーっとしていると（気を付けていても）同じ局をCallしてしまう。特に私のように軒下ダイポールだと耳が悪いし飛びも悪いので、近所（？）の局しかQSOできず、同じ局のCQに何度も反応する恐れが高く。

で、OBの皆さんのお知恵をWebで見ていたらLogger32にはPrevious QSOをチェックする機能があるという情報にたどり着いた。早速それを試してみた。

BandMapでコールサインを左クリックすると、Previous QSOがチェックできる。Previouos QSOはViewメニューにある。

まずはPrevious QSO画面を表示しておいて、Band Mapでコールサインを左クリック。そうするとOperatorダイアログ画面が立ち上がって、今クリックしたコールサインが自動的にセットされてる。このOperatorダイアログにセットしたコールサインでデータベースを引いて、Previous QSOをチェックするみたい。その局がLogbookにログがあれば、それをPrevious QSO画面にリスト表示してくれる。

気持ちとしては、Band MapでPrevious QSOがあるコールサインは色分け表示してもらえるととてもうれしい。

いずれにせよ、まずはこれで重複チェックができるようになった。

ちなみにBand Mapでコールサインを右クリックすると、そのコールサインに関する直近のActivityが表示される。

コールサインに/Pを付けて移動局であることを明示してみようと思った。

File -> Setting -> GeneralでCall signの後ろに/Pを追記。

とりあえず、QSOは成立してるみたい。

エアコンから水が垂れるとの事で朝からエアコンの点検。

まずはカバー外しから。

カバーは前面にあるネジで固定されているだけ。これを外せば取れます。

その前にルーバーを外します。というか、カバーがルーバーに引っかかるので外さないと作業が進まない。ルーバーは右にずらす（ルーバーを反らして）事で外れます。

ドレンに水は溜まってなくて、いろいろ調べたらルーバー上のプラスチックケースが冷えてそこで結露して滴った模様。梅雨時にこれは仕方がないと判断。

しかし、内部の汚れがひどい。特にファンのカビ。これはなんとかせねば、と言うことで早速ホームセンターへ。近所のホームピックは朝７時に開店。

購入したのは２本セットのクリーナー。

45リットルのゴミ袋を2枚、割り箸で開口部を確保してエアコンの下にガムテープで固定。

全体を見るとこんな感じ。床にはタオルを引いてタレ対策。

ムース缶で内部にムースを散布。歯ブラシでファンを下からゴシゴシ。

そもそも買ってきたクリーナーは冷却フィン洗浄用だったので（買ったときは気が付かなかった）これを洗浄するだけの容量がリンス缶にはないので、スプレー容器を空にして水を充填。まずは、この水で洗浄。

その後リンス缶で洗浄して、汚れを拭き取り、エアコンスイッチONでファンの汚れた水を吹き飛ばし、それを拭き取って、掃除完了宣言。

再びケースをはめて、ルーバーを取り付けて。

ワンポイントアドバイス：エアコンスイッチオンでファンが回転すると、汚れが飛び散るので、吹き出し口にタオルを当てておくべし。

とりあえずファンの汚れは取れて、清潔感復活。１時間20分ほどの作業でした。

QSOしてみました。

QSOが完了するとWSJT-XでLog QSOダイアログがポップアップする。そこでOKを押すとLogger32のLogbookに反映された。WSJT-XのLogファイルパス情報は設定していないのUDPで情報取得しているのだと思う。

WSJT-XのLogをFileメニューからLogger32にインポート。

ユーザーフォルダーの自分のフォルダーのAppData￥Local￥wsjt-xフォルダーにあるADIファイルをインポートすると（いろんなオプション指定ダイアログがでるけれども、とりあえず何も指定しないでOKボタンクリック）、先ほどLogger32に登録されたものも含めてインポート完了。

それにしてもDefaultのカラム構成は使いづらい。カラムタイトルを右クリックすると、カラムのプロパティが表示される。一番したにカラムを左または右に移動させるボタンがある。これで移動。

とりあえず以下に構成変更してみた。一見使えそう。

Logger32ってなんだか便利そうというか、超多機能であることは間違いなし。多機能ゆえにつかみ難い。

今日はWSJT-XとLogger32のUDP通信を設定してみた。

WSJT-XはFile -> Setting でReportingタブを選択。

ここでUDP Serverを活性化しておく（チェックボックスにチェックをいれる）。IPアドレスとポート番号はDefaultのまま。

次にLogger32のMain画面のステータスバーのUDPをクリックする。

初期状態（今まで何も設定していない状態）では、UDPは赤色表示。ここでOpen WSJT/JTDX UDP Socketをクリックする。するとUDPが赤字から青字に変わって、UDP通信が始まったことを示す。ここでOpen WSJT/JTDX UPD BandMapをクリックする。

すると、ここの表示が以下になる。

以下のBandMapが表示される。これはWSJTから得た情報を可視化したもの。

次はこれにLog情報が加われば、もっと使える情報が得られるはず。

今日はここまで。

新しいThinkPadが届きました。WSJT環境をちゃんと整えたかったのが最大の理由。

で、WSJT-Xを設定しました。ダウンロードしたのはWSJT-X v2.0.1.
パラメータは今まで使っていたPCからコピーで、こちらは早々に完了。

WSJT環境を整えるというのは、Loggingも含めて必要なソフトを入れて、それなりにインテグレートしたかったという意味。

今日はLOG環境のセットアップをしました。とりあえず、Turbo HAMLOGがよさそう。
こちらはJH4VAJ氏の記事を参考にセットアップ。

JT_Linkerをダウンロードして設定。設定するのは、自分のコールサインとGrid、それにWSJT-Xのログが保存されているパス。

JT_Linkerは新しくQSOが記録されるとそれを拾ってくれる。WSJT上でLog QSOをクリックすると、JT_Linkerがそれを拾い、ログ登録準備をしてくれる。ここでOKを押せば登録完了。

Log QSOを押すと、さっきQSOしたログの登録ができるけれども時間はクリックした時間になるので、その部分はマニュアル修正。

これでしばらく使ってみる。

Logger32とかJTAlertとか、余りに機能がありすぎでどうやって使いこなすのか、これから探検開始。