公開日 2025年6月13日 最終更新日 2025年6月13日 by JE2UFF_Toshi
おはようございます。今朝も良い天気になりました。朝からよく晴れて、昨日より暑くなりそうです。梅雨の中休みでしょう。週末は雨予報ですが、本当に雨降るのか疑問になるほどの天気です。
最近いろんなMLを見ておりますが、Digiモードでは度々アプリケーション連携でトラブルが発生しているようで、解決を模索するような投稿が多いですね。
最近のMSHVのMLでは、GridTracker2との連携問題が上がっておりました。
確かに自分も連携ではかなり苦労しました。特にWindowsがセキュリティアップデートを掛けると、動かなくなるケースが多ですね。
そしてもう一つの曲者がUDP Serverの設定でしょうか。
UDP Serverのポート番号を変えられる場合は未だ良いのですが、アプリによっては固定されておりマルチキャストを使用するような場合にトラブルが多いような気がします。
自分の場合、最近ではやはりMSHVのデータがGridTracker2に飛ばない問題が発生しました。
アプリによっては、ポート番号が固定されていたりするのがかなり影響があり、この時にはJTAlertのポート番号が固定されているのが主原因でした。
この内容もMSHVとHamAppsのMLに投げられておりましたが、JTAlert側では仕様を変更しないとの話から途中で尻切れになっていたりしておりました。
また、国によっては使用するポート番号が他の機器(例えばHGWで使用)で使われているので、バッティングしてダメとかいろいろあるみたいです。
自分の場合は、最終的に全てJTAlert経由で行う事で解決しました。MSHVからはいろいろなところにデータを送らないで、JTAlertのみとする。JTAlertはMSHVから受けた受信データやQSOデータを受取、QSOデータはそのままDXkeeperへ転送する。また同時にGridTracker2へも転送する。
この部分がマルチキャストの部分で、GridTracker2はマルチキャストで受けるようにする。
最終的な設定は、MSHVのUDP settingはIP 224.0.0.2 port 2237とする。
JTAlertのMSHV接続の設定を同じようにIP 224.0.0.2 port 2237と設定する。
GridTracker2はマルチキャストを有効にし、IP 224.0.0.2 port 2237にする。
従って、MSHVで連携する場合には、全てのアプリでIP 224.0.0.2 port 2237を使用することでQSOデータが問題なく統一される。
この時、LoTWやeQSL、QRZ.COM、Clublogとの連携は、MSHVからではなくJTAlert経由で引き渡すDXkeeperが各サーバーに転送することで完了させる。
MSHVの場合は、このように全て同じIPアドレスとポート番号になるが、WSJT-XやJTDXの場合には、同じようにマルチキャストを使用するがResendするUPDパケットのIPとポート番号は異なるので注意が必要。
WSJT-XやJTDXの場合は、沢山の情報がネットに出回っているので自分の環境にあっているモノで設定すれば、ほぼ問題なく連携が可能となる。
しかし、MSHVの場合は情報が少なくなかなか解決しなかった。少なくとも、Helpファイルに書かれている設定では、各アプリが接続されるがデータが流れない問題が発生する。
この問題を解決するのに、自力ではかなり時間が掛かったが、Helpファイルに書かれたポート番号から1つずらすことで一気に解決した。
今は問題なく動いているが、OSまたはアプリがメジャーアップデートをすると、また動かなくなる場合が多々あるので、アプリ連携についてはIPアドレスとポート番号の関係性をよく理解しておく必要がある。
Logアプリのデータを起点に、交信済みまたは未交信の判断をモード別、バンド別に行い結果をJTAlertとMSHVへ反映させる連携は非常に優れており、ムダな交信を省く事ができる。
これはデジタルモードになり、通信がアプリで行われるようになったから出来上がった仕組みだと思う。
アプリの機能も向上し、改めてすごい時代になったものだと感心する。
