🔰 なぜこのシステムを作ったのか ― 音声スケルチからの脱却

デジタルノード（Pi-Star / WPSD）を運用していて、外部機器（OpenCCVoice などの音声ガイダンスや外部アンプ、表示器など）を連動させたい時、「今、ネットワークから電波（音声）を受信しているか？」を正確に知る必要があります。これまで、この「受信判定（Busy）」をどうやって取り出すかが大きな課題でした。

特定の機種であれば無線機の20ピンコネクタからGPIOで信号を取り出すことができます。しかしハンディ機など、そのような端子を持たない機種では、OpenCCVoice（NM2072を使った装置）のようにスピーカー出力を信号として取り込み、音声レベルで擬似的なスケルチを構成するという回路を使うしかありませんでした。

しかし、この音声連動（VOX）方式には弱点があります。

• 音声の頭切れや遅延が発生する
• 無音のタイミングでスケルチが閉じてしまう（バタつく）
• ノイズを誤検知してしまう

OpenCCVoice のアイデアは非常に素晴らしいものですが、その弱点を補う「完璧なBusy信号」が欲しい――そこから生まれたのがこのシステムです。

💡 Pi-Starから純粋な「真のBusy信号」を直接引き出す

音声のレベルに頼るのではなく、Pi-Star の心臓部であるMMDVMHostのデジタル処理ログをPython プログラムがリアルタイム（インメモリ）で監視します。ネットワークからデジタル音声ヘッダが届いた「その瞬間」にRaspberry Pi の GPIOピンをHIGHにし、通信が終わった瞬間にLOWに落とします。

これにより、遅延もバタつきも一切ない、完全無欠のデジタルBusy信号を物理ピンから取り出すことができます。ハードウェアの追加はGPIO17番ピンとGNDの2本だけ。OpenCCVoice のTM BUSY入力（Arduino Nano の D11）につなぐだけで、どんな機種でも対応できます。

🎯 強み：監視TG（WATCH_TG）と一致する受信のみをGPIOのトリガーとする

GPIO への出力はすべての受信で発生するわけではありません。設定した監視TG（WATCH_TG）と一致するTGの受信のみをトリガーとしています。たとえばデジピーターが TG1 で待ち受けている場合、TG1 の通信を受信したときだけ GPIO17 が HIGH になり、OpenCCVoice などの外部音声 ID 装置へ 3.3V の起動信号が送られます。他の TG の通信はスルーされ、GPIO は反応しません。また、自局のコールサインからの送信は除外されるため、自分の送信中に誤って信号が出ることもありません。

📋 主な GPIO 出力条件 ― ケーススタディ

※ 上表の「TG245」はあくまでも動作説明のための例示です。TG:245 は茨城県日立市の JS1YTZ が実際に使用している TGIF TG 番号ですが、ここでは「ホームTG以外の任意のTG」の代表例として挙げています。TG が一致しない場合はどの TG でも同様に GPIO は反応しません。

ここで、DMRGatewayの設定に起因する動作が顔を出します。TG1 で待ち受けているデジピーターに対して、利用者が無線機のダイヤルを操作して TG245 などの別の TG に切り替えると、DMRGateway の PassAll や TGRewrite の記述にしたがって MMDVMHost は TGIF ネットワークの接続先を TG245 へ変更します。これはシステムが設計通りに動作している結果ですが、交信が終わっても TG245 のままになってしまうという「戻し忘れ」状態に陥ります。こうなると、本来 TG1 に届くはずのトラフィックがローカルに降りてこなくなります。

「完璧な Busy 信号が取り出せるようになったのだから、通信終了のタイミングからタイマーを回して、変わってしまった TG を自動でホームTGに戻せばいい」――この発想から生まれたのが、本ツールの名前にもなっている TGIFChanger（TG 自動復帰機能） です。GPIO の Busy 検出エンジンの副産物として生まれた機能ですが、デジピーター運用における戻し忘れ問題を根本から解消する、実用上欠かせない仕組みとなりました。

ハンディ機ユーザーにも朗報！

固定機やモービル機には背面に「BUSY出力端子」が備わっていることがありますが、ハンディ機にはそのような端子がありません。このツールを使えば無線機本体からBusy信号をもらう必要はなく、「ノード側（Pi-Star）」が完璧なBusy信号を出力してくれるため、ハンディ機ユーザーでも高度な外部機器連動システムを構築できます。

🌐 「TGChanger」はいわばオマケ機能 ― でも強力

ツールの名前になっている「TGIFChanger（ダイナミックTGの自動復帰機能）」ですが、実はこの機能は補助的なツール（オマケ）です。

Pi-Star や WPSD の設定ファイル DMRGatewayの書き方を調べていたとき、TGIF ネットワークへそのままTG番号を送るだけで接続先を切り替えられることに気づきました。

ここで、逆転の発想が生まれます。前のセクションで述べた「DMRGatewayの設定による意図せぬTG切り替え」を問題として捉えるのではなく、意図的に利用することを考えました。「どうせTGが切り替わるなら、ユーザーが無線機のダイヤルを回すだけで全国・全世界の任意のTGへ自由につなげられるはずだ」―― そのアイデアです。

ただし、そのままでは交信が終わってもTGが変わったまま残り、本来のホームTG（地域の待機チャンネル）のトラフィックが降りてこなくなる「戻し忘れ問題」が残ります。

🗾 このシステムが実現すること

• RF主体のデジピーター利用者が、無線機のダイヤル操作だけで全国・全世界のデジピーターへ一時的につながれる
• 交信が終われば、指定した時間（デフォルト 120 秒）後に自動でホームTGへ復帰する
• 大きなシステム変更や追加機材は一切不要。今ある Pi-Star / WPSD にインストールするだけ
• 特別な費用もかからない。すでにネットにつながっているデジピーターが、そのまま全国ネットワークの一員として機能する

利用者（RF側）のメリット

• 新しいアプリのインストール不要
• 追加のハードウェア購入不要
• 難しい設定や操作不要
• 使い慣れたCPソフトでメモリーにTGを書き込むだけ
• 交信が終われば自動でホームTGに戻るので、戻し忘れの心配もなし

デジピーター運用者がTGIFChangerを導入するだけで、利用者は何も変えずに恩恵を受けられます。利用者に負担をかけない、シンプルで優しい仕組みです。

⚙️ TGIFChanger v2.3 の主な技術的特徴

従来のシェルスクリプト版（v1.x）からPython 3 ネイティブデーモンへと完全フルスクラッチで書き直されました。Raspberry Pi Zero などの非力な環境でも動作するよう、システムへの負荷を極限まで抑えています。

① Python 3 統合デーモン ― 圧倒的な低負荷

MMDVMHost のログをメモリ上で直接リアルタイム解析。CPU負荷をほぼゼロに抑え、WPSD の頻繁なログローテーションにも瞬時に追従します。

② 正確なタイマー管理 ― API二重送信ゼロ

安全なインメモリタイマースレッドを実装。ネットワーク瞬断時でも、TGIF APIへの復帰リクエストの二重送信や連打を完全に防止します。

③ 究極のBusy検出精度

MMDVMHost ログの RF_VOICE_HDR / NET_VOICE_HDR イベントを直接捕捉。音声レベルに依存しない、ミリ秒単位の応答性を実現します。

④ Pi-Star / WPSD 完全対応

両OSのログパス・ローテーション挙動の差異を自動判別。インストール時に環境を自動検出し、適切な設定を適用します。

📦 インストール手順

Pi-Star または WPSD に SSH でログインし、以下の1行をコピー＆ペーストして実行するだけです。古いバージョンの削除から最新版の組み込みまで全自動で完了します。

curl -L https://raw.githubusercontent.com/ji2tab/TGIFChanger/main/install.sh | sudo bash

新規インストール時は対話式プロンプトが表示され、以下を設定できます。

• 監視TG（WATCH_TG）：切り替えを監視するTG番号
• 復帰TG（RESTORE_TG）：通信終了後に戻すホームTG番号
• 復帰までの時間（秒、デフォルト 120 秒）

🗑️ アンインストール

curl -L https://raw.githubusercontent.com/ji2tab/TGIFChanger/main/uninstall.sh | sudo bash

🔗 GitHub リポジトリ

ソースコード・最新ドキュメント・詳細な技術仕様はGitHub で公開しています。

👉 https://github.com/ji2tab/TGIFChanger/tree/main

📝 執筆：JI2TAB（尾張旭DMRデジピーター 管理人）
🏢 JJ2YYK あいちデジタルコミュニケーションハムクラブ