FT-991Aを使ったFT8の運用(Omini-Rig経由)


最近はパソコンでログを扱うだけでは飽き足らず、何やらアプリケーションやハードウェアが、いろいろと複雑に結びついて来ているので、どんどん面倒くさい事になっています。
私もFT8を始めた頃は、WSJT-Xが自動生成するログファイル(wsjtx_log.adi)から、手動で本来のQSOログソフトウェアにインポートしていたのですが、やっぱりこれも面倒な訳で、とうとうと云うか、やっぱりと云うか、QSOログソフトとの連動になるんです(しちゃうんです)よね。
この記事を読んでくださっている方には、今更「Omini-Rigって何?」って方は少ないと思うのですが、話の端緒として(ホントは自分のために)整理するところから始めます。

念のためですが、トランシーバー(ここではFT-991A)とWSJT-XやJTDXは、きっちり1体1でつながり、快適に動作します。
Omni-Rigが必須な訳ではないので、どうかご注意ください。


■Omini-Rig

Omni-Rig

ソフトウェアの現物はここ Afreet Software, Inc
何も詳しい説明はありませんけど、肝心のダウンロードもここから行います。

■何でOmni-Rig?
昔から機器同士の通信(正確なデーターの流れ)って大きな問題なんですが、何と云ってもRS-232Cに代表されるシリアル通信が簡単で、市場に溢れる構成部品などのハードウェアはもちろん、ドライバーソフトなどのソフトウェアもこなれているから、多分アマチュア無線機のメーカーや設計者の思想なんでしょうが、トランシーバーに外部制御端子が用意された頃からずっと、シリアル通信が採用されているんです。

シリアル通信って、1対1の通信でチャッチャカチャッチャカと、これ自体はきちんと約束事が出来ていて、しっかりした通信が確保されます、遅いけど。
しかしながら、この1体1ってのが、実はくせ者で、現代のアマチュア無線の世界では、いろいろなハードウェアやソフトウェアが、それぞれトランシーバーの情報を使う場面が増えて、トランシーバーの通信先が1つに限定されてしまうと、当然ほかのソフトウェアが止まってしまう(使えない)のです。
余談ですが、その昔(MS-DOS時代)も、CTとかTR-logとかって伝説のログソフトは、シリアルポートに「Yケーブル」なるもので、シリアルデーターを横取りしてましたね。

つまり、1体1の通信をなんとか複数の通信でShare出来ないか、と考える人が出てくるのは当然で、特に、トランシーバー(以下リグと記載)の送受信を制御するソフトウェアと、その結果(ログ)を扱うソフトウェアを共存させられたらオペレーターはアプリケーションの違いを乗り越えるだけでなく、正確な通信の結果(CALLSIGN、DATE、TIME、BAND、REPORT等々)を残せる上に、オペレーターの省力化が格段に進む訳です。
DXペディションやコンテストで、「24時間戦えますか?」状態なら、絶対に欲しい機能ですよね。



Omni-Rigの実際の設定
簡単なのでここでは起動方法などは端折りますが、この画面が表示されたら真似てください。
なお、後述のFT-991Aメニューモード一覧とも照らし合わせて確認をお願いします。

私はRIG1にKENWOODのTS-890Sが接続されていて、FT-991AはRIG2で使用しています。
ここで設定するパラメーターは、もちろんFT-991Aをパソコンと直接接続する値がベースになります。

本来、1体1接続であるWSJT-Xとリグの間に、Omni-Rigが入る事で、WSJT-Xのリグコントロール情報(周波数やモード情報など)がログソフトにも送られ、QSOの結果としてログに書き込まれます。


■FT-991Aのメニュー

設定値(出荷時値と異なるもののみ)

#028 = RS232C
#029 = 38400bps
#031 = 38400bps
#059 = DIRECT FREQ
#060 = RTS
#062 = OTHERS
#064 = 1000Hz
#065 = 1000Hz
#066 = OFF
#071 = RTS
#072 = USB
#084 = OFF
#085 = ON


WSJT-Xの設定

設定をしたら画面下の「Test CAT」ボタンを押し、リグと正しく通信できているか確認してください。
うまく通信が出来ればボタンが緑色に変化し、隣の「Test PTT」ボタンも現在のグレーアウトから、ボタンが押せる状態になりますので、こちらも押下してリグが送信状態になる事を確認してください。
もしうまく切り替わらないなどの場合は、Omni-Rigの設定をもう一度確認し、再試行してみてください。
特にPTTが変化しない場合は、RTSやDTRの設定を変えてみてください。
また、RTSやDTRを変更すると、不用意に送信になったりする事があるので、その場合は落ち着いて設定を元に戻せば送信停止になります。
リグの強制電源断などは、なるべく控えた方がよいでしょう。


私の場合は、音源が複数あるのでわかりやすくするために、リグの名前を付して管理しています。
実際のインストールされたドライバーの名前は、「USB Audio CODEC」と云うものです。
余談ながら、TS-890Sを接続時にインストールされるドライバー名は、「USB AUDIO CODEC」と云う名称のもので、極めて紛らわしいもので、その区別のために名前を変えています。


ログソフトウェアとの連動(参考)

ここで云うログソフトウェアとの連動とは、以下のようなものを指しています。

・WSJT-Xの一連の操作で、QSOが成立した場合に自動的にログインされること。
・WSJT-Xの動作を支援するアプリケーションソフトウェアの動作を阻害しない動きをすること。

参考例に過ぎないが、私のシャックでは以下のような構成で各アプリケーションソフトウェアがシームレスに動作しています。

・WSJT-XはOmni-RIg経由のCATでリグと相互情報の交換を行っており、同時にCAT経由でログソフトウェア自体にも周波数やバンド、モード情報が送られている。

・FT-991で受信した信号はWSJT-Xで解読され、画面上に表示されオペレーターに必要な、コールサイン、信号強度などの情報が提供されます。

・WSJT-Xからは、予め設定されたUDPプロトコル(クラスDのプライベートスコープが一般的)とポートで、JTAlertとGridTrackeに情報がマルチキャストされている。

・WSJT-Xから送られた情報を元に、JTalertはログソフトからB4やQRA、QTH、GLなどの情報を取得し、JTalert自体で表示すると共に、WSJT-XにB4やWantedリストに登録されて局が現れればその情報を送り返す。

・GridTrackerも同様に得た情報から、GridTracker自体の地図上やポップアップウインドウで当該局の情報を表示する。

この図のような構成は、WSJT-X系のモダンシステムでは必須の構成ではないか、と私は考えています。
また実際、JTalertやGridTracker自体も、そのように使う事を想定して作られたアプリケーションで、また実際に使ってみると大変有用であることが実感できています。
一見、複雑そうに見える構成ではありますが、もちろん理屈に基づいている訳ですから、判ってしまえばなんていう事もなく設定出来るものと思います。
最後に、このシステム構成の肝は、ログソフトウェアのインターフェース次第だと思います。
日本国内で沢山のユーザーがいるTurbo HAM LOGの事を私は存じないので判りませんが、世界のハム界に浸透したADIFでのデーター交換が簡単に出来れば、この構成も比較的簡単に構築出来ると思います。

Posted by JF1OCQ_blog