Greencube Terminalを推す理由

Greencube Terminalを使うメリットについて書き出してみました。
GreenCubeに出ている方には、ぜひご一読いただきたいと思います。


（1）パイルを捌く側のメリット

- 呼んで来た局のコールサインがCallingMeウィンドウに格納されるため、GCDigipeaterのように、いちいちTrafficウィンドウをスクロールして確認する必要が皆無

- CallingMeウィンドウには、呼んで来た局におけるGreenCubeの仰角とLOSまでの概算時間が表示されるので、先にLOSする局を選んで応答する、といった芸当が可能

- マルチコール・レアアクティベーションモードで、複数の局への一括応答が可能。ただし混み合っている時にこれをやると、パケット長が長くなることによりアップリンクが通りにくくなる可能性があるので、TPOに応じて使い分けると良い。なおGCDigipeaterの最新版（v0.27）でも複数局への一括応答は可能だが、コールサインを手動でTo欄へ記述しなければならないため正直面倒

- 応答後にログへ保存した局が再び呼んで来ても、CallingMeウィンドウにコールサインが載らないようにするオプションがある。SettingsのLoggingタブ内にある「Do not insert call into CallingMe again after logging」にチェックを入れることで実現

- メッセージにマクロを使うことができる。これを活用することで、メッセージ内のグリッドスクエアを常に統一することが可能


（2）呼ぶ側のメリット

- 当該局におけるGreenCubeのおおよその仰角が表示されるので、当該局にてGreenCubeがLOSした後も呼び続けるということをしなくなる

- グリッドNewやイニシャルNewの局が一瞥して判別できるので、自身の目的に沿った局をいち早く呼ぶことが可能。ただし、GCDigitalにある、エンティティNewの局をハイライト表示する機能がない点に注意。特にCFM済みグリッド、かつ、エンティティNewの局は、イニシャルNewとして表示されるので、注意が必要である

- COSIリストやIgnoreリストを有効活用することで、情報の取捨選択がより高度なものとなる。私の場合、グリッドNewだがLoTWでのCFMが見込めない局（＝LoTW非ユーザーの局）は、Ignoreリストへ入れている。また事前に情報のあった移動局や珍局、偶然見かけるもQSOに至らなかった上記の「CFM済みグリッド、かつ、エンティティNewの局」など見つけたら即座に呼びたい局をCOSIリストに入れている

- 遅延メッセージによるQSOは、DXCCなどのアワードに無効との見解が出ている。これを受け、遅延メッセージ（TX Delayが15秒を超えるもの）は背景色がグレーで表示されるため、無駄呼びを未然に防ぐことができる。なお、遅延メッセージを活用することでGreenCubeのFootPrint外の局ともQSOはできるし、そういう楽しみ方を否定するものではない


（3）その他のメリット

- TCP接続・UDP接続により他のログソフトへQSOデータを受け渡すことが可能。これにより、コールサイン等を手動で転記することによるミスが未然に防げる。私の場合、相手局にJK2XXKを「JK2KKX」と転記された上でLoTWへアップロードされたため照合できなかった、ということがあった

- 上の件、私は現在、TCP接続でN1MM+と（JT_Linker経由で）HAMLOGの2つへ、QSOデータの確定と同時にそれを転送。注意点としてN1MM+の場合、ログウィンドウを閉じているとQSOデータの受領ができないことが判明（最小化なら大丈夫）。同じくHAMLOGの場合、たまに転送が上手くいかないことがある（この時はJT_LinkerのResendボタンをクリックすれば解決）


（4）パイルを捌く側が使うソフトによる呼び方の違い（考察）

4-1 GCTerminalの場合
自局のコールが相手局に届けば、相手局のCallingMeウィンドウに自局のコールサインが載る。よって自局のコールが1〜2度デジされれば、後は応答があるのをひたすら待てば良く（＝無闇に呼び続ける必要がなく）、そうすることで自局への応答を見逃さない（＝自局の送信と相手局からの信号が重なることで受信不能となるのを未然に回避する）ことに繋がるとともに、必要以上の送信を控えることで相手局（や他に交信したいと願う局）のアップリンクがデジされやすい環境を作ることにも繋がる。

4-2 GCDigipeaterの場合
GCTerminalで言うところの Traffic Window しかないため、パイルを捌く側は、呼ばれてハイライト表示した局をクリックしてTo欄へセットし応答する……という手順を踏む。この時、気持ち的には先に呼んできた局から順に応答したいところ、実際には、受信したパケットを絶えず表示し続ける画面を遡ってスクロールすることが困難であるため、直近で呼んで来た局へ応答する傾向が強い。となると呼ぶ側は、呼んで呼んで呼びまくる以外に方法がなくなってしまう。こうなると、いわゆる「レンダーマン」は登場する、設備的に充実している局しかアップリンクできないetcetc.で、呼ぶ側もパイルを捌く側もますますアップリンクが困難になってしまう。まさに負のスパイラル、総倒れである。

4-3 前二項の視点を変えると
呼ぶ側でGCTerminalを使う局は、パイルを捌く側がどのソフトを使っているのかが分かるため、ソフトに応じて呼び方を変えることができる。一方、GCDigipeaterを使う局は、パイルを捌く側が使うソフトの別を判別する術がなく、従ってとにかく呼ぶことしかできない。

4-4 ではどうすれば？
パイルを捌く側も、それを呼ぶ側も、GCTerminalを使うことで、お互いが効率よく、しかも不要な送信を抑えることができ、結果的に交信局数を伸ばすことができると言えよう。


（5）デメリットはあるの？

- （再掲）エンティティNewの局をハイライト表示することはできない

- 多機能ゆえ、設定箇所がGCDigipeaterよりも格段に多い

- GCDigipeaterからの乗り換え（＝ADIFを移行）の際、GCDigipeaterのログデータには相手局のグリッドスクエアが含まれていないため、何らかの方法で付加してやらないと、GCTerminalのグリッド検索機能が有効に働かない　※こちらの記事中にて支援ツールを提供中（要Excel2007以降・要LoTWユーザー）