トランシーバーのID一覧

     各社トランシーバーの機器ID
                              2020.06 ICT-Kuwa/JA4BUA

 トランシーバーをCAT/CI-VでControlするには、機種別に設定されている機器IDを見ての対応が必須だ。
 ICOMのCI-Vは、十分に拡張性を意識してフレームフォーマットが設計されているので評価できる。

1.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
2.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/A  0582,583:FT-1200
  0650:*FT-891  0681,682:*FTDX-101
   *は、周波数のフレームが1バイト長い(100MHzの桁がある)。他は、最上位が10MHzの桁です。


3.YaesuのCATとKenwoodのPCコントロール
   YaesuとKenwoodの最近の機種は、非常に似た通信フレームを使っています。要求しないと
   何も通信ポートには信号が出てきません。ただし、最近の機種は、「AI;」コマンドを1回送って
   おけば、状態変化があった時に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の技術屋さんに話したらアッサリ認めていました。
  (1) YaesuとKenwoodのシリアル通信
     通信の相手方を特定するアドレス等が全くありません。1:1の通信しか考えていません。
     この事から、1台のトランシーバ対他の機器の通信しかできません。この辺の発想はICOMと
     比べると際めて貧弱ですね。物理インタフェースは、いわゆるRS232cです。
     電圧は、+-3~12vです。つまり、このままではBUS的に複数を接続できません。
     机上での検討です。スペース時に+の電位にはならないはずです。
      もし、私の勘違いがあれば指摘願います。
     トランシーバー1:機器N個の接続をするには、TTLレベルに変換してからICOMの所で
     書いたようにDIODEーORまたはオープンコレクタにして接続する必要があります。
     ただし、このような対策をしてもN:Nの通信はできません。
     もちろん、コリジョン対応など全く考えられていないです。
     接続する機器は、トランシーバーの送信データーを受け、トランシーバーに向けて送信する
     だけです。お粗末!!
  (2) 複数の機器を接続する
    ① 物理的な接続
      トランシーバーに情報を要求する機器を1台だけに限定して、他の機器は情報を受信するだけの場合。
      ・情報を要求する代表機器1台の送信データとTRXのシリアル入力を接続します。
      ・他のすべての機器の受信端子とTRXのシリアル出力を接続します。
        複数の機器からTRXに情報要求が必要な場合は、全ての機器の232cをTTLにレベル
        変換して、送信データにDIODE経由で接続します。
    ② 周辺機器からTRXに送るデーターのコリジョン(衝突)対策
        避ける方法がありません。どうしてもやるとすれば、受信データで送信のインヒビットを
        掛けるぐらいでしょう。後は、期待する返事が無かったら、しばらく待って再送するしか
        方法はなさそうです。
        以上の事から、YaesuとKenwoodのTRXで、手の込んだことを確実な動作でやらせる
        のは、無理と思った方が良さそうです。
      過去に、TRIO、YASEUの機器も複数使って来ただけに残念です。

3.コリジョンなしの完全なものにするには
  ここまでで、述べてきた内容は物理的に接続する方法だけで、送信データーのコリジョンを避ける
  方法は含んでいません。
  コリジョンが起こらないようにするには、
  ICOMの場合、
    ICOMの機器は簡易なコリジョン検出と再送の対応を行っているので、ICOM製機器以外
    [PCの複数PORT、SteppIR、私が頒布中のアンテナ自動切替インタフェース等]がICOMと
    同じ方法をとれば良いわけですね。
    私が思っているのは、中間に必要なシリアルポート数を持つインターフェース装置を追加し、
    各Portにアドレスを振って、ICOMの機器と同様のコリジョン監視と再送制御を行う方法ですが、
    プログラムを書くのも実機環境でデバックするのも大変ダロウナーと思い手をつけていません。
     (今の所、友人等からの強い要求がないので)
  Yaesu,Kenwoodの場合
    同様に中間に交通整理の巡査(インタフェース装置)を置いて、各機器から送られてくる情報要求
   コマンドを受け付けて、TRXに情報要求を行い、応答情報を要求してきた機器に中継すれば良い
   訳ですがかなり複雑なアルゴリズムになりそうです。
   ボケ防止と遊びのテーマとしては面白そうですがかなり大変だろうと思っています。

   VSPE(Virtual Serial Ports Emulator)は、ソフト内でのコリジョン対応に問題があるようです。
   TXDのコリジョン対応がありません。

4.思うこと
   過去に仕事で電気通信の標準化に関わり、如何に標準化がメーカーとユーザーにとって、大切かを
   身に染みている、私にとってはメーカーの悪趣味で振り回されるのは残念でたまりません。
   本来なら、遅くともWindows98の時代に業界団体で標準化委員会を作って、PC等周辺機器と
   アマチュア無線機の物理Interface、フレームフォーマットの標準化を行い、一部の未定義部分を
   各メーカーの特色用にすることができたはずだ。
   また、ユーザーを代表する唯一の団体?のJARLがメーカーに対して、要求・勧告を行う事も
   できるはずだが事務屋さん集団?では無理なのかなーー。本当の会員サービスとは??
   せめて、今からでも速やかにやるべきと思うのは私だけか?