実験稼働している基地局用Mesh Adapterで実現するOOB-Linkにより統合制御と連携機能の一つとして、PoCシステムとの連携機能（RoIP）を追加しましました。
今回は、一般的に普及しているZelloのチャンネルをAPI経由で直接接続できるリンク機能を内蔵し試験しています。
たくさんのユーザーになるべく簡単に、楽しんでいただけけるシステム造りが一番大切なことです。 加えてインフラとして構築、維持をしていくうえで管理者の皆様のご苦労も無視できません。
これまでのねらいであるSFR基地局の管理者の負担軽減の工夫の一つとして、直接SFRにZelloで接続し受信状況をモニターしたり基地局のコールサインで送信することが可能となりRF経由で直接確認できない場所からでも機器の状況を監視できます。
設定画面ではあらかじめ作成されたZelloのチャンネルを指定します。
この機能は公式APIを使用していますのでZelloから取得した鍵を登録して使用します。
アダプター内ではPTT Managerが無線機の状態を監視し、更にMeshサーバーと連携し接続状態を把握していますので、Meshセッション御発生中はもちろんローカルＱＳＯ発生中は音声ＩＤの送出を用区政する協調制御をしています。 PoC (Zello)経由の通信もこの交信の一環と認識しています。
設定画面のサンプル
Mesh-Adapterのダッシュボード画面にある動態表示です。
通信の向きに応じてドットが流れて表示されますので、RFとPoC間の通信方向がリアルタイムで認識できます。
また、これまではNetworkと現地RFの履歴を表示していいましたが、もう1つテーブルを追加してPoCリンク経由の通信も把握できるようにしました。
ZelloのAPI経由のシステムでは、リモート局がPTTを押下すると直ちに通信が発生し0.3秒程でMesh-Adapterまで寝具尾が到達しますのですぐにPTTを叩くことができます。 その上で音声データーを整えて配信されてきますので実際の音声の到達までに0.8秒のコストがかかりますが頭切れを防止で気比較的快適に運用できることが分かりました。
| 方向 | 計測区間 | 値（改善前 → 改善後） | 時間がかかっている所 |
|---|---|---|---|
| Zello → RF | 送話開始の通知 → PTT | 約 0.38 s（711112）・0.30〜0.36 s（711105） → 約 0.02 s | HS 内はほぼ解消（音量調整は PTT 後へ、ポート確認は libasound 直接呼び出し） |
| Zello → RF | 送話開始の通知 → 最初の音 | 1.31〜1.67 s → 最初のパケット到着と同時（0.08〜0.82 s） | Zello からの最初のパケット到着 |
| RF → Zello | BUSY → 最初の音の取り込み | 約 0.26 s → 約 0.001 s （BUSY 前 0.12 s も送信） |
受信ポートの常時取り込みで解消 |
| HS 送信 → Zello | PTT → 配信開始 | 約 0.18 s（中央値、711112） | Zello との往復 |
現在主にRaspberry Pi3B+にて通常運用を行っていますが、このシステムによりCPU使用率は待機時で3%、送受信時で7％程度に収まっており最新機種でなくても十分に性能を発揮できます。
| 項目 | JS1YQM-144 | 参考：JS1YQM-430 |
|---|---|---|
| 機種 | Raspberry Pi 3 Model B Rev 1.2 | Pi4 |
| コアの数 | 4 | 4 |
| 待ち受け（60 s） | 1 コアの 8.0 %（4 コア全体では 2.0 %） | 1 コアの約 3.1 % |
| Zello から送話中（30 s） | 1 コアの 10.4 %（4 コア全体では 2.6 %） | 1 コアの約 7.4 % |
一方でこれまで様々な端末でZelloとの連携を実験してきましたが通信の詰まりや過度な遅延を経験し少々不満があったのが正直なところです。 このＡＰＩ経由の通信のレスポンスがかなり改善されていることに気付きました。 アクセス端末からのレスポンスはほぼ従来通りでが、PTT押下時のTXビープが聞こえたときには既にSFRは送信状態になる程度の速さまでは改善できました。
今後様子を見てみたいと思います。
一方で多くの優れたPoC方式がありますので、今後様々な方式の接続も検討、開発する予定です。