諸般の事情で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に比べると見える信号がはるかに少ないですネ。
スポンサーサイト
私もJTDXを使ってます。
実際はJTDX+Jtalertという組み合わせです。
先日のTCPサーバー機能追加については非常に安定してLOG転送はできるのですが、JTDXの場合名前とQTHは手打ちをしなくてはならないので、あえてTCPサーバーをOFFにして毎回JtalertのADIFをインポートしております。
どうぞ楽しまれてください
今後ともよろしくです
今日は
ClubLogへのuploadもできるようにしたので、しばらくこれで遊ぶことにします。
聞こえていたら(見えていたら?)、どうぞ呼んでください。
こんにちは。
いつも Logger32 の情報提供して頂きありがとうございます。
こちらのシステムは ノート PC , Win10 64bit , VSPE 64bit版 Splitter モード , Logger32 最新版 , JTDX v17.9 , TS-990 です。
PC環境の違いと思われますが JTDX と Logger32 の COM ポートは同時にオープンしても問題なく動作しています。
JTDX の周波数一覧から選択するとリグ、Logger32 の周波数表示が変化します。
リグの VFO ダイヤルを回すと Logger32 の周波数表示、JTDX の周波数表示も連動し変化します。
JTDX で QSO したデータは Logger32 の TCP サーバー Enable , JTDX の Enable data transfer to external log を有効にしているため JTDX で RRR/RR73 或いは 73 をクリックし、 OK だったか?をクリックすると Logger32 で自動取り込みしてくれます。
CLUBLOG には N2AMG Rick さんが作成された LOTW_EQSL_Utility からリアルタイムアップロードしていて LoTW は同じユーティリティを使用し UPLOAD / DOWNLOAD しています。
eQSL にはアップロードのみ、データダウンロードはしていません。
今後ともよろしくお願いいたします。
今日は
情報有難うございました。こちらはWindows 10 64bit、VSPEも64bit版、Splitterモードです。
これでLogger32とNaP3を同時に動かしても問題はありませんが、JTDXの場合はcomポートに問題ありとのエラーとなります。エラーを発生しているのはJTDXでLogger32は問題ありません。もう少し調べてみる必要がありそうですネ
こんにちは いつもお世話になります
Logger32のPolling intervalは100msとなっていましたが、これを250ms以上にするとJTDXのエラー、Rig Control Errorが回避できる
→とありました。Logger32でのポーリング時間変更は設定から可能でしょうか?
スミマセン、見つけました
350msになっていますが、それでもエラーになりますね
組み合わせは
Logger32+WSJT-X V1.8 + VPSE 32bit
Radio1のCOMポートを開放する必要があります。
JT65HF HB9HQXバージョンではポーリングエラーは発生しておりません。
はじめまして。
先ほどはQSOありがとうございました。
JT9/JT65での重複チェックについてはJTAreatが便利です。
http://hamapps.com/
今日は
先ほどはありがとうございました。
私はまだ始めたばかりで、今のところはJTDXのチェックだけで十分ですが、研究してみたいと思います。
コメントの投稿
≪ 前ページ | HOME |
次ページ ≫