WW DX Contestにおけるマルチ探しの実験と考察

1.　はじめに

　私の所属するJA1YDU（千葉工業大学電気研究部）では、ここ数年、 WWのSSB、CW両部門にマルチOP・マルチTX（M/M）で参加しています が、国内トップクラスのM/M局に比べ、マルチ数が少ないのが悩み の種でした。「電波が弱い分、局数ではかなわないだろうが、マル チ数はがんばれば何とかトップクラスに近づけるはずだ！？」とい う信念のもと、どうしたらうまくマルチ数を増やすことができるか、 と、毎年色々と試行錯誤しています．

　昨年のWW CWでも、いくつか新しい試みをしてみました。言って みれば単なる「悪あがき」に過ぎないかも知れませんが、そのいく つかを報告したいと思います。

2.　マルチ探しの方法

1. ランニング局内で探す方法
   施設の中に受信専用の設備を設けて、そこでマルチ探しを行う。マ ルチ探し用の別のアンテナやリグを準備する方法、一本のアンテナ をランニング用／マルチ用の2台のリグで共有する方法などが考え られる。

2. パケットクラスタを利用する方法
   CTなどの、パケットクラスタノードに接続可能なロギングソフトを 使用し、クラスタに流れる情報を各バンドのサイトで直接利用する 方法。Wでは一般的に行われているらしい。

3. マルチステーションが探す方法
   マルチ探しを専門的に行うマルチステーションを特別に設け、そこ からマルチ情報を流してもらってニューマルチをゲットする方法。 あまり一般的でない？
   

　(2)に頼るためには、パケットクラスタでコンテストに有効な情 報が多く流れて来なくては意味がありません。そのためにはクラス タに参加している多数の局との協力関係がないと出来ないでしょう。 もちろん、情報を流して貰うだけでなく、クラブ局側からも有効な 情報を流すのは当然の事です。しかし、現在のDXer中心のJAのクラ スタをコンテストで使うと、迷惑になってしまいそうであること （VKやUA0などの情報も流さないとならないので、怒られそう）、 また同じクラスタに同程度の実力を持ったライバルクラブ局がぶら 下がっている可能性があるという点で、現状では難しいのではない かと思われます。

　(3)の方法では、もう一局分余計に準備しなければならないこと、 マルチ探し用の人足が余計に必要になること、2局間での連絡を密 に行う必要がある事など、システム全体の規模が大きくなってしま います。これは準備が大変になるという点以外でも、システムの安 定性の観点からも問題が多くなります。

　YDUでは、ご近所のJA1YFGと協力して、(1)と(3)のハイブリッド 方法でのマルチ探しをここ数年検討してきています。

3.　マルチ探しのためのポイント

1. マルチを探すための優秀な耳を持つ。

2. マルチを探す人が、ランニング局（以下run局と省略）のマル チ獲得情報を常に正確に把握する。

3. 新しいマルチが発見されてから、run局が呼び始めるまでの時 間を可能な限り短縮する（ほとんどF1のタイヤ交換のノリで）。

4. システムが大規模化することによって発生する操作性、安定性 の低下を極力抑える。

3.1 システム面

• (a)を実現するために、マルチステーション（以下multi局と省 略）ではrun局と同程度の耳を持つ受信設備が必要。できれば同じ バンドを複数人で同時に受信できるシステムが望ましい（受信に特 化できるため、技術的には比較的容易にできる）。これは、run局 内でのマルチ探し用システム（以下、サブシステムと省略）につい ても同様の事が言える。

• (b)のために、run局のマルチ獲得情報を、何らかの手段を用い て定期的にmulti局に送ってやるシステムが必要である。情報の正 確さはマルチ探しの効率に影響する。

• (c)のために、multi局のニューマルチ情報を、何らかの手段を 用いて迅速にrun局側の該当バンドのオペレーティングディスクま で転送するシステムが必要である。数回CQを出しただけでQSYして しまうニューマルチ局も存在するので、タイムラグを秒単位で縮め る必要あり。

• (d)の操作性と安定性はトレードオフの関係にある場合が多い ので、どのあたりにその妥協点を置くかがポイント。あまり複雑で 見通しの悪いシステムはエラーが起こり易く、復旧も難しいのでな るべく避けた方が無難。またあらゆるエラーを想定したバックアッ プ方法も検討する必要あり。

3.2 ソフト面（人的要因）

• (a)のために、マルチ探しのための耳を日頃から鍛えておくの は当然必要。またサブシステムでのマルチ探しではコールサインの 一部から全体を推測する能力も必要。

• (a),(b),(c)を効果的に行うためには、人員の配置を慎重に行 うことが重要。マルチ探しは、オペレータの技量がモロに結果とし て現われやすいので、上手な人を配置する必要がある。

• マルチ探しはオマケ的な捉え方をされて手が抜かれがちだが、 クラブ全体でその重要性を認識する必要がある。どちらかというと ランニングをする方が好きだというオペレータの方が多いと思われ るが、マルチ探し要員の士気を高めるような環境を作ることが重要。

• 人間が関与すると必ずうっかりミスをおかしてしまう。なるべ く人的要因が絡まないように、システム化できる部分は可能な限り システム化することが必要。

• システムの操作が複雑になるため、事前にバンド担当者が操作 法を理解し、ある程度練習しておく必要がある。

4.　1994年WWでのマルチ探し

1. multi局の設備
   　JA1YFGの設備をそのままお借りして、multi局を作った。ローバ ンド以外では、ほぼrun局と同程度の耳を持つmulti局となった。一 つのバンドで複数のリグを接続して受信できるようにした。multi 局だけで最高3つの耳で聞いていたことになる。

2. サブシステム
   　21,28MHzで2アンテナ、2リグシステムを採用した。人員が足りな くて、サブシステムに人がついていない時間が多かったこと、事前 の打ち合わせ不足でサブシステムの有効的な活用法が理解されてい なかったこと、その操作性が悪かったことが反省点として上がった。

3. run局からmulti局への情報転送
   　ロギングはCTを用いて行っていたので、その各バンドのデータを マージし、まずCTのマルチ情報ファイル出力を得る。そのファイル 出力をフィルタを使って冗長な部分を削ってから、パケット通信に よってそのデータをYFG側に送信する。 　YFG側ではその情報をもとにチェックシートを付けて、それを使 いながらマルチ探しを行う。反省点として、この作業がNZNの担当 であったため、NZNのbusyさによって情報転送が不定期になってし まって最新の情報がすぐにYFGに届かなかった点、YFG側で、転送さ れてきた情報をもとにしてチェックシートを付ける作業に時間がか かった点などが挙がった。

4. multi局からrun局への情報転送
   　93年までは、YDU内にYFGとのパケット通信を担当する端末を一台 用意し、そこにパケット担当のオペレータをつかせ、YFGから送ら れてくるマルチ情報を小さな紙に書いて各バンド担当者に手渡しす る方法を採ってきた。しかし小さな紙の処理が繁雑になる点、新マ ルチを探してからrun局が呼び始めるまでのタイムラグが大きい点、 人足不足でパケット担当者がいなくなる場合があって、せっかく探 したマルチ情報が届かなくなるなどの問題があった。
   　そこで94年は、CTのネットワークにTNCを接続し、それとYFGを直 接つなぐ方式を採った。これにより、YFG側である決まったフォー マットにより入力した新マルチ情報は、直接各バンドのCT端末まで 瞬時に届く「はず」だった。しかし、RS-232Cのディジーチェーン 接続でのCTネットワークが不安定で、大切なマルチ情報がネットワー クの途中で消えてしまうという問題が発生し、途中から93年方式に 切り替えた。

5. ソフト面
   　JH0LFEがmulti局側のイニシアティブを採り、5名程度のDXコンテ ストを良く知っているメンバーをmulti局担当としてYFG側に送り込 んだ。LFEクラスの実力者をマルチ探しに回すことの重要さを改め て認識した。

5.　1995年WW CW

1. multi局の設備
   　YFGのクランクアップタワーが一基使用不可になったことにより、 94年よりもmulti局のアンテナ設備は弱くなった。7MHz以下はワイ ヤー系のアンテナのみとなった。28MHzはなし。YDUとの連絡用回線 は430MHzおよび50MHz FMで確保。

2. サブシステム
   　昨年までの反省を生かし、14-28MHzにて、2アンテナ、2リグによ る新しいサブシステムの方式を採用した(図1)。
   　アンテナは14MHz以上ではそれぞれ2系統ビームアンテナを準備し、 それぞれが独立して回転出来るようにした。リグは各バンドともメ インリグ（送受信が可能）とサブリグ（受信のみ）を準備し、通常 はそれぞれ別系統のアンテナに接続し、メインリグでランニング、 サブリグでマルチ探しを行う。アンテナもメインとサブで独立して いるため、マルチ探しの自由度が増す。また、同軸切り替え器を用 いてサブリグ用のアンテナをメインリグ側に切り替えることが出来 るようにした。これにより、ランニングからマルチ呼びにすぐに移 れるようになった。
   　また、14-28MHzにて、サブリグからメインリグに周波数情報の転 送を行えるようにした。14,21MHzではTS850x2で行ったため、サブ リグからメインリグのメモリに直接転送することが可能であった。 28MHzではTS830x2で行い、こちらは外部VFO接続端子を利用して、 サブリグのVFOをメインリグのVFOに一時的に切り替えるシステムを 作った。
   　サブシステムの主な使い方としては、以下の2通りが考えられる。
   
   • メインリグでランニング中に、サブリグでサブアンテナを回し てマルチを探す。ニューマルチが見つかった場合には、サブリグか らメインリグのメモリにその周波数の情報を転送する。転送したら、 その局のコールサインと転送した旨の報告をメインリグのオペレー タに知らせる。メインリグのオペレータはメモリから周波数を呼び 出してQSYし、サブアンテナに切り替えてニューマルチ局を呼ぶ。 サブアンテナへの切り替えは、メインアンテナの向いている方向と ニューマルチ局の方向が違うときに有効。

   • YFGからニューマルチ情報が来た場合に、サブリグでまずその 局を探す。探している間、run局はそのままrunningを継続する。見 つかったら前述と同じ方法でメインリグ側に周波数情報を転送し、 アンテナを切り替えて呼ぶ。

3. run局からmulti局への情報転送
   　94年までの方法とほぼ同様の方法を採用。各バンドのCTデータを マージし、WRITEMULTIで得られるマルチ情報ファイルをawkスクリ プトで処理し、低速のパケット通信に適した形式に変換する。
   　このawkスクリプトは、全バンドの獲得マルチ情報の他に、前回 送ったものからの差分のみの情報も出力するので、通常は差分（つ まり前回から増えた分）のみを送ることになる。昨年からの進歩と しては、コマンドをバッチ化およびスクリプト化して、操作を簡単 にしたことが挙げられる。

4. multi局からrun局への情報転送
   　昨年CTネットワーク上に重要なマルチ情報を流してはまったので、 今年はロギングデータ転送用の従来のRS-232CでのCTネットワーク とは別に、マルチ情報転送用のネットワークをEthernetおよび TCP/IPを利用して構築した(図2)。つまり、ロギングを行うコンピュータ と別に、各バンドのサイトにマルチ情報モニタを置いて、そこに YFGからのニューマルチ情報を表示した。
   　これにより、YFGからの新マルチ情報を直接CTに取り込む事はで きなくなったが、その代わり間違いなく各バンドのサイトまでマル チ情報が来ることになった。
   　また、CTネットワーク側のトラフィックをちょっとだけ軽減させ ることができた。YFGからの情報は、パケット通信によりTNCの接続 されたUnixマシン（FreeBSD）に送られ、そこからTCP/IP上のアプ リケーションによって各マルチ情報表示用マシンに配送される。マ ルチ情報表示用マシンとしてはTCP/IPが喋れさえすればよく、実際 にはUnixマシン、Macintosh、OS/2などのマシンを使用した。
   　また、実験的にOS/2マシンを用いて両方のネットワークに接続す る実験を試みた。このOS/2マシン上では、一つのウインドウでCTが 走り、ロギングが行え、また別のウインドウからはYFGからのマル チ情報が表示される。
   　マルチ情報モニタは、通常サブリグのオペレータが監視しており、 マルチ情報が流れてきたらサブリグを用いてその局を探し、発見し たら(2)で述べた方法でメインリグに周波数を転送し、サブアンテ ナをメイン側に切り替える。

5. ソフト面
   　今回は他大学の協力なども得て、総勢約15名程で臨んだ。マルチ 局にはJA9VDAを中心として約5名程を送った。昨年の反省を生かし、 各バンド担当者とコンテスト前に打ち合わせを行い、システムの動 作の説明や操作方法の説明などを入念に行った。

6.　評価と考察

1. multi局の設備
   　トラブルにより昨年よりもYFG側の設備が弱くなってしまったが、ローバンドのコンディションに助けられたこともあり、multi局として十分に機能していた。これで更にローバンドの耳が良くなれば、multi局としては十分であろう。

2. サブシステム
   　アンテナ切り替えのための操作性がまだ若干悪いが、安定性という面では昨年に比べだいぶ向上した。これは、サブリグでは送信をしない制約を付け、送信はメインに集中させたために、スタンバイ関連の複雑な制御が不必要になったことが大きい。サブリグですぐにニューマルチを呼べないという欠点を周波数転送機能で補った形となった。
   　14MHzでのサブシステムは、特に夕方のヨーロッパ／アフリカで、ショートパスでランニング、ロングパスでマルチ探しをする際に大いに役立った。その他のバンドでも、WやEUをメインでランニングしながら、サブで東南アジアやオセアニアのマルチ探しが十分できた。
   　周波数転送機能は、概ねオペレータに評判が良かった。これはTS850の操作性の良さにも起因するものであろう。
   　メインのオペレータとサブのオペレータの息が合っていることがサブシステムの成功の重要な要素である。これについては後述する。
   　サブシステムについては、今までいろいろな形態を実験してきたが、まだまだ改良の余地はあるものの、安定性、操作性、投資に対する見返りなど総合的に評価して、今回の形は一つの結論になりそう。

3. run局からmulti局への情報転送
   　awkによるマルチ情報のフィルタにバグがあり、一部不正確な情報がmulti局側に流れ、混乱を起こしていた。コンテスト中にプログラムのデバッグを行っていた。これは明らかに自分の準備不足で、周りに迷惑をかけてしまって反省している。またマルチ転送処理がNZNの仕事であり、昨年同様不定期にまとめて送られていたので、情報の更新がスムーズに出来ていなかった。
   　これについては、この形態での情報転送、つまり不定期にYDU側の情報をまとめてYFGに流すという方法に限界を感じている。出来れば、常に最新のマルチデータをYDU側のどこかに置いておいて、必要なときにYFG側からそれに対してアクセスできるようなシステムにするべき。そうなると現在のパケット通信+通信端末ソフトの形態を別の形態（たとえばにAX.25上でのTCP/IP接続）に変える必要があるだろう。来年以降は大幅に変えてやってみたい。
   　YDU側とYFG側のマルチ獲得状況の情報を一貫に保つことは、マルチ探しをする側の士気にも影響するので、重要であろう。

4. multi局からrun局への情報転送
   　これについてはシステムとしてはほぼ思った通りに動作してくれた。
   　情報の流れは次の経路をたどる。
   　YFG内のリグ->YFG側のパケット端末->(パケット通信回線)->YDU側のパケット端末->(ethernet)->マルチ情報表示端末->該当バンドのサブリグ->(周波数転送機能)->該当バンドのメインリグ
   　YFGで新マルチを発見してからYDU側で呼び始めるまでのタイムラグを減らすことが重要であるが、このシステムで、新マルチの発見から、YDU内のマルチ情報表示モニタまでその情報が来るまでの時間は、数秒に短縮できた。そこから先の時間短縮は、サブオペレータの技量次第ということになる。
   　一つ問題点として上がったのは、マルチ情報表示モニタに新しいマルチが上がったときに、それを知らせる機能を付けなかったために、YDU側のオペレータがモニタを見ていなくて気がつかなくて逃してしまったマルチがいくつかあったことである。新マルチの情報が流れてきたらモニタ全体を白黒させるとか、回転灯を回すとかして、派手にオペレータに知らせる機能をつける必要があると思う。
   　OS/2は実験的に導入してみたわけだが、ネットワークからのデータの取りこぼしもなく、安定して動作していた。ただしCTでCWのキーイングを行っている最中にウインドウのフォーカスの切り替えなどを行うとCWの符号が乱れる現象があった。また、CPUとメモリが十分でなかったためか全体的に重く、telnetでOS/2に入って、そこでCTデータのマージなどをやろうと思っていたが、無理があった。でも面白い環境になりそう。
   　今回EthernetとTCP/IPも初めて導入したが、まだまだ実験段階でごく初歩的な使い方しかしていないので、これからいろいろとアプリケーションを組んで、有効活用していく予定である。

5. ソフト面
   　multi局側はどうしても途中で集中力が継続できなくなり、特に、新しいマルチを見つけるのが難しくなってくる日曜日は、中だるみしがちだが、今回はVDAの統率が良かったためか最後まで集中して探してくれた。 　サブシステムは、メインとサブのオペレータの息がぴったり合ったときに初めて、うまく機能していた。システムの仕組をオペレータが十分に理解すること、事前に十分なリハーサルを行っておくこと、メインオペとサブオペの技量をきちんと把握して、作業分担をきっちりと決めておくことが重要だと感じた。
   　全体的にだいぶシステム化が図れてきたおかげで、小人数でもなんとか対応できるようになってきたし、全体の安定性も向上してきていると思う。
   　全体がコンピュータ化されてきているが、現在YDU内のコンピュータ関連のシステム作り、設定作業等はすべて私の仕事となっている。今後さらにコンピュータ化、ネットワーク化が進むことになると思うが、ちょっと負担が大きくなってきているので、その手の作業を任せられる人材の育成もクラブ内で行う必要があると感じた。コンピュータやネットワークは、おそらく今後、リグやアンテナと同様の扱いをしていかなくてはならないだろう。
   

7.　おわりに

　マルチオペ部門は、一匹狼が基本のアマチュア無線の中では珍しく、多数の人が一つの目標に向かって協調しながら作業をすすめていく協調作業環境です。そこでは、各自の仕事の割り当てがあり、それらを各自が努力して遂行し、またお互いに情報交換などを効率的に行いながら協調的に仕事を進めていくことが重要です。今回この原稿で書いたマルチ探しはそのごく一部です。

　しかし残念なことに、一匹狼の集合対としてマルチオペを捕えている風潮があって、マルチオペの潜在的な面白さが見失われているような気がしています。今最も世界的に使用されているCTのマルチオペサポートを見ても、そんな感じを受けます。

　私が面白そうだと考えていることは、マルチオペを行う際に行われるオペレータ間の協調にはどういうものが存在するのか、その中でどれが重要でどれが不要か、またそれらを支援するためにはどういったツール群を用意しておいたらいいのか、という点です。支援するためのツールとは、もちろんコンピュータとネットワークとソフトウェアです。幸いなことに、これらの基礎技術は、YDUがやりたいと思っている事を実現するのには十分なくらい成熟してきています。

　マルチオペの本当の面白さを理解できる仲間をYDUを通じてどんどん増やして、協力を得て少しずつでも面白いコンテスティング環境を作っていきたいと思っています。