各社トランシーバーの機器ID
2020.06 ICT-Kuwa/JA4BUA
トランシーバーをCAT/CI-VでControlするには、機種別に設定されている機器IDを見ての対応が必須だ。
ＩＣＯＭのＣＩ－Ｖは、十分に拡張性を意識してフレームフォーマットが設計されているので評価できる。
１．Kenwoodの機器ID
001：TS-711 002：TS-811 003：TS-940 004：未指定 005：R-5000
006：TS-680 007：TS-790 008：TS-950 009～16：未指定
017：Elecraft
018：TS-570 019：TS-2000 020：TS-480 021：TS-590 022：TS-990
023：TS-590G 024：TS-890
２．Yaesuの機器ID
0101～0103：FT-9000 0241：FT-450 0244～0246：FT-450D 0251,0252：FT-2000
0310：FT-950 0362：FT-5000 0462：FT3000 0570：＊FT-991 0582,583：FT-1200
0650：＊FT-891 0670:＊FT-991A 0681,682：＊FTDX-101
＊は、周波数のフレームが1バイト長い（100MHzの桁がある）。他は、最上位が10MHzの桁です。
３．同一メーカーで機種による大きな違い
KenwoodのCAT
周波数は、機種に係わらず、11Bytes＝Hz～10GHｚの桁
Mode は、OMコマンドとMDコマンドで機種により異なる
周波数とMode情報の読出しは、旧機種ではIF;コマンドが使えるが、Ts-890,990ではなくなった。
YaesuのCAT
周波数が、機種によって変わる。FT-9000以前の物は8Bytes＝Hz～10MHｚの桁
FT-991,891,101は、9Bytes＝Hz～100MHｚの桁
Yaesuの設計者は、何でこんなにアホなの？？ 次に1.2GHz対応の機種を出すときは、また1Byte増やすの？？
FT-101を出したときに、全機種をFirmwareのUpdateで、せめて1GHzの桁までの対応にするべきですよね。
CATのBaudrateも4800Bps 8N2 これは、40年あまり前のアナログ電話でModem通信の初期の時代だよね。
Modeは、MDで機種毎のでの違いはない。
周波数とMode情報の読出しは、全機種で、IF;コマンドが使える。
４．ＹａｅｓｕのＣＡＴとＫｅｎｗｏｏｄのＰＣコントロール
YaesuとKenwoodの最近の機種は、非常に似た通信フレームを使っています。要求しないと
何も通信ポートには信号が出てきません。ただし、最近の機種は、「AI;」コマンドを１回送って
おけば、状態変化があった時にICOMと同様に情報を自律的に放送します。
（Logger32、SteppIRのSDA-100等は［IF;］コマンドを使っています）
Kenwood（AI2;）：TS-590、TS-480、TS-2000、TS-570、TS-890、TS-990
（AI1;）：TS-870、TS-950
Yaesu(AI1;)：FT-950、FT2000、FT5000、FT9000など
［注意］YaesuのFTDX5000でのデバッグ結果
AI1;コマンドを送って放送される周波数情報で、VFOを早く動かした時に送られてくる
周波数情報は、VFOが止まった最終の周波数ではないことが判明しました。
高速でVFO周波数を動かし、連続的に情報を多数送る場合に、情報を送ってくるが
VFOが止まった最終の周波数を正しく送ってくれないのです。
バンド切替等の時は問題ないのですが、正しいその時の周波数が必要なときは使え
ません。kenwoodはこんな事はありません。
Yaesuの場合は、状態変化時に取り出す情報抽出のアルゴリズムが貧弱のようです。
FT-3000の展示会場でYaeseの技術屋さんに話したらアッサリ認めていました。
（１） YaesuとKenwoodのシリアル通信
通信の相手方を特定するアドレス等が全くありません。１：１の通信しか考えていません。
この事から、1台のトランシーバ対他の機器の通信しかできません。この辺の発想はICOMと
比べると際めて貧弱ですね。物理インタフェースは、いわゆるRS232cです。
電圧は、＋－3~12vです。つまり、このままではＢＵＳ的に複数を接続できません。
机上での検討です。スペース時に＋の電位にはならないはずです。
もし、私の勘違いがあれば指摘願います。
トランシーバー１：機器Ｎ個の接続をするには、ＴＴＬレベルに変換してからＩＣＯＭの所で
書いたようにDIODEーORまたはオープンコレクタにして接続する必要があります。
ただし、このような対策をしてもＮ：Ｎの通信はできません。
もちろん、コリジョン対応など全く考えられていないです。
接続する機器は、トランシーバーの送信データーを受け、トランシーバーに向けて送信する
だけです。お粗末！！
（２） 複数の機器を接続する
① 物理的な接続
トランシーバーに情報を要求する機器を１台だけに限定して、他の機器は情報を受信するだけの場合。
・情報を要求する代表機器１台の送信データとTRXのシリアル入力を接続します。
・他のすべての機器の受信端子とTRXのシリアル出力を接続します。
複数の機器からTRXに情報要求が必要な場合は、全ての機器の232ｃをＴＴＬにレベル
変換して、送信データにDIODE経由で接続します。
② 周辺機器からTRXに送るデーターのコリジョン（衝突）対策
避ける方法がありません。どうしてもやるとすれば、受信データで送信のインヒビットを
掛けるぐらいでしょう。後は、期待する返事が無かったら、しばらく待って再送するしか
方法はなさそうです。
以上の事から、YaesuとKenwoodのTRXで、手の込んだことを確実な動作でやらせる
のは、無理と思った方が良さそうです。
過去に、ＴＲＩＯ、ＹＡＳＥＵの機器も複数使って来ただけに残念です。
５．コリジョンなしの完全なものにするには
ここまでで、述べてきた内容は物理的に接続する方法だけで、送信データーのコリジョンを避ける
方法は含んでいません。
コリジョンが起こらないようにするには、
ICOMの場合、
ICOMの機器は簡易なコリジョン検出と再送の対応を行っているので、ICOM製機器以外
［ＰＣの複数PORT、ＳｔｅｐｐＩＲ、私が頒布中のアンテナ自動切替インタフェース等］がICOMと
同じ方法をとれば良いわけですね。
私が思っているのは、中間に必要なシリアルポート数を持つインターフェース装置を追加し、
各Portにアドレスを振って、ICOMの機器と同様のコリジョン監視と再送制御を行う方法ですが、
プログラムを書くのも実機環境でデバックするのも大変ダロウナーと思い手をつけていません。
（今の所、友人等からの強い要求がないので）
Yaesu,Kenwoodの場合
同様に中間に交通整理の巡査（インタフェース装置）を置いて、各機器から送られてくる情報要求
コマンドを受け付けて、TRXに情報要求を行い、応答情報を要求してきた機器に中継すれば良い
訳ですがかなり複雑なアルゴリズムになりそうです。
ボケ防止と遊びのテーマとしては面白そうですがかなり大変だろうと思っています。
VSPE(Virtual Serial Ports Emulator)は、ソフト内でのコリジョン対応に問題があるようです。
TXDのコリジョン対応がありません。
６．Yaesu機器で注意
FT-991Aで確認したら
RS-232CのＣＡＴは、AI;コマンドが使えない。USBは、OK
７．思うこと
過去に仕事で電気通信の標準化に関わり、如何に標準化がメーカーとユーザーにとって、大切かを
身に染みている、私にとってはメーカーの悪趣味で振り回されるのは残念でたまりません。
本来なら、遅くともWindows98の時代に業界団体で標準化委員会を作って、ＰＣ等周辺機器と
アマチュア無線機の物理Interface、フレームフォーマットの標準化を行い、一部の未定義部分を
各メーカーの特色用にすることができたはずだ。
また、ユーザーを代表する唯一の団体？のJARLがメーカーに対して、要求・勧告を行う事も
できるはずだが事務屋さん集団？では無理なのかなーー。本当の会員サービスとは？？
せめて、今からでも速やかにやるべきと思うのは私だけか？