JT9、JT65を運用するための仕組み

諸般の事情でJT9、JT65を運用するこことになりました。きっかけはLogger32にJTDXからQSOデータを受け取るTCPサーバのテストでした。
これらのモードを運用するために必要なプログラムとしてWSJT-Xが有名です。更にこれをベースび独自の「味付け」がされたプログラムがあります。当初Logger32のテストでインストールしたのがJTDX、更にWSJT-X、JT65 HFもテストしてみました。
ルーツがあってそこから派生したプログラムがたくさんある状況はNaP3と同じで、若干混乱します。

1.　プログラム
(a)　JTDX
・　TCPクライアント機能がありLogger32のQSOデータを送り込める
・　CATをサポートする機種が豊富でK3を使う場合も簡単、リストからK3を選択するだけ
・　ユーザーインターフェースが自分の好みにあう
(b)　WSJT-X
・　TCPクライアント機能がない　
・　K3を使う場合は簡単
(c)　JT65HF
・　K3を使うのが難しい

しばらくはJTDXを使うことにします。

2.　Logger32と組み合わせて便利に使う
(a)　Logger32とJTDXでK3が接続されたcomポートを共用
このためにVSPEで実在のcomポートの下に仮想comポートを作ります。(Splitter機能)　Logger32、JTDX側ではこの仮想comポ－トを指定します。
但し、JTDXを運用する際はLogger32側でこのcomポ－トをクローズする必要があります。そうしないとJTDXはエラーになります。

追記：
その後のテストで次のようなことが分かりました。VSPEでcomポートを共用すると、Logger32からのPollingに対するK3からのReplyデータもJTDXが受信することになります。もちろんJTDXからのPollingに対するReplyデータもLogger32が受信します。
今までLogger32のPolling intervalは100msとなっていましたが、これを250ms以上にするとJTDXのエラー、Rig Control Errorが回避できる、できそうだということが分かりました。多分JTDXは想定外のReplyデータを頻繁に受信してしまって「お手上げ」になるのかも知れません。しばらくLogger32のPolling intervalを250msとして様子をみることにします。

追記：
テストしてきましたが、JTDXを使う時にはLogger32側でCOMポートをクローズする必要がありそうです。
試しにK3ではなくTS480を接続してテストしてみました。こちらは全く問題なさそうです。JTDXを起動するとすぐにTS480の周波数が表示されます。K3では数秒かかります。どうもこのCATは機種を選ぶみたい、、、

(b)　JTDX側でQSOをログすると同時にLogger32側でもこのQSOをログ
このためには、Logger32側でTCPサーバーを開いておきます。JTDX側では"Enable data transfer to external log"のオプションを有効にします。
(c)　全体のログはLogger32で一括して行う
QSOがログされてしまえばCW、RTTY等の他のモードと同じで、一括管理することができます。LoTWへのupload、lotwreport.adiによるLogbookの更新も問題ありません。

3.　重複QSOはしない、DXCC Newかどうかはチェックしたい
これらのチェックについては、事前にLogger32でチェックすることはできないことはありませんが面倒です。JTDX側で色付け等の工夫が必要です。


4.　ClubLogへのupload
現在QSOをログすると同時にそのQSOをClubLogにuploadしています。このために自作のプログラムを使っていますが、これがJT9、JT65には対応できません。然るべきタイミングでJTDX側のLogbookをuploadするか、Logger32のLogbook全体をuploadすればいいのですが、イマイチ、、、残念

追記：　自作のプログラムを少しいじってこれもOK

5.　JTDXでのミスオペ
TX Odd/TX EvenとEnable TXの関係で誤って送信してしまうことがよくあります。いろいろな解説を見たりしていますがいい解決策が見当たりません。

6.　QRP？
5W、或は10Wでの運用にします。これでもやっとEUとQSO出来ました。自分の好みとしては帯域の狭いJT9ですが、JT65に比べると見える信号がはるかに少ないですネ。