とりあえず作ってみたブログ

　この前のAA-CWは自宅からリモートで部分参加でした。RTC-59の導入でローテーターも回せるようになりましたので、セットアップをVer3からさらに変えて以下のようになりました。



　コンテスト参加時はノートPC　2枚体制です。受信のみとか、FT8で遊ぶときはPC1だけですべての操作を完結させています。(PC1,2ともにすべてのソフトウェアをインストール済みです。必要なものだけ起動します）

・PC1－リグ受信音伝送・ZLOG操作(windowsのRDPを使用)
・PC2－リグコントロール(操作用)・ローテーター制御(BGARTC)

　このような分担に変えています。セットアップの様子は、表題の写真の通りです。左のThinkPADがPC1、右のミニノートがPC2です。

　4月下旬のALL JAでは、リグの受信音伝送はPC2側でしたが、PC1の11世代i5のノートへ変えました。こちらの方が、音声遅延も短くなり安定性も向上しています。少し前のテスト通りの結果でした。サウンドデバイスを外付けにしたほうが、内蔵より弱い信号が聞きやすいです。あとは音量調整がつまみであるのもありがたい。改めてサウンドデバイスは手を抜かないほうが良いと思ったところです。

　ローテーターのコントロールはZLOG側のHOST上で実行のほうが安心ですが、画面が込み入ってしまう点や、操作系をPC2へ集める、という考え方だったので、comポートのネット越し操作にしています。通信がシビアで落ちると焦る。。という事もないので、これで十分でしょう。注意事項としては、BGARTCを複数起動したときの挙動です。アンテナの方位調整は、複数のアプリから行っても問題なく動きますが、オプションのRL、8個については、ソフトからRTC-59への一方通行なので、複数のソフトからRLを操作すると状態不明になりかねません。要注意です。(複数のソフトからRTC-59が操作される、という事を想定していないと思われます)

　アンテナですが、タワーをフルアップし、トライバンダーも回せることから、RN4DXとTH5mk2という組み合わせにしています。RN4DXとCD78jrを切り替えるBOXを準備中です。

　リモートシャックですが、年明けから本格的に運用を始めて、AA-CW終わりでQSO数は900局ぐらいです。次の参戦で１ｋ局を超えると思われます。

　

　この前の週末はこの作業以外に、ケース実装済みのRTC-59を取り付けてきました。既設のローテーターはKR-1000SDXと年代物、自前で引っ張り出したDINコネクターと、RTC-59の接続ケーブルを作って接続。



　こちらが接続図。手動で右回り、左回りの動作をまず確認、つづいてPCからの制御ソフトであるBGARTCを立ち上げて初期設定。もともとが南が起点設定だったので、北を起点設定に書き換え、90度ごとの角度電圧を取り込み設定するだけでした。
　リモート運用を意識して調達しましたが、手元操作の時でもこれは便利。マウスでポチった方位へ自動で動くからこれはやめられませんね～。ボタンを押さなくても動くから楽ちんです。



　ということで、このローターを購入以来、25年以上使用してきた、上の写真の自作リモコンが不要となってしまいました。最初は単に回転スイッチを引っ張り出していたのですが、のちにPICを内蔵させて、スイッチ操作にロック機能を持たせていたのでした。

　表題の写真。左は、RTC-59とローテーターのコントローラ、設置の図。右のキャプチャーは、大阪の自宅から遠隔操作しているときの一コマです。

　年明けに受け取っていたこちらの基板(RTC-59)を、やっとケースへ納めることができました。LCDの角穴の加工が邪魔くさい・・勢い余ったところがあるので正面からの写真は割愛です(笑)

　制御ソフトはBGARTCを使います。(ソフトはこちらから取得)外部制御用にRL出力が８個取れますので、とりあえずフォトカプラでオープンコレクタを引っ張り出しておきます。

　

　左側がRL部分の回路図。フォトカプラを8個並べるだけ。右が実装した様子です。こちらはオプション基板を買う手もありますが、複雑ではないので自分で作るでも十分でしょう。(買ったほうが配線がきれいにできるかも?)

　最後に自分用の備忘録です。



　コネクタのピンアサインです。なお、PCへの接続はUSBですので、この資料からは除外です。

　末筆ですが、ソフトウェアとハードウェアを提供されているお二方に感謝です。

　リモートシャック関連の備忘録です。久々にWSJT-Xの設定をしたらはまってしまいました。しばらく、リグコントロールができない、HAMLIBエラーに悩まされていました。



　この状態で、やっとOK。なお、COM10はVSPEによる仮想ポート。本来のリグはCOM2ですが、遠隔のためリグコントロールアプリとWSJT-Xを同時に使うためにVSPEで仮想COMポートを作り共用しています。

　すごくはまってしまいましたが、初心に帰ってこちらを見て間違いに気づいた次第です。スプリットの設定、それから、制御信号の強制設定もいるみたいです。
　とりあえず、これで受信はできるようになりました。送信はまた改めて手を付けます。ってことで、送信もVOXではなくCATに変えないといけないでしょうね。

＃リグコンはRS-232C、音声は背面ACCからとっています。
＃送信はまだ試していません。後日やりましょう。

　RemAudの調整の件、続きです。と言っても、やり直した・・ではなくて、クライアント側のCPUパワーの違いによる状況を比較しておきます。ともに、ノートPCでOSはWin10PRO。ネットはWIFIで接続、同じ室内なので同じアクセスポイントへつながります。RemAudは、16bit、fs=11kHz、mono、送信パケット長は40mS、受信バッファー10mSという設定です。SSB/CWにおいては、fs=22kHzは過剰でしょう。AMラジオを聴きたいから、fs=22kHzにしていたり(笑)

〇Core i5-i5-1135G7の場合



　リグコンのソフトと同居しても、リモートデスクトップが同居しても大丈夫。時間とともに遅延増加。。ってこともなさそう。さすが、バックグランドで受信音を再生しながらWEB閲覧すると、遅延が増えることも・・。これでも耐えられるようにするには、もうちょっと高価なPCを買わないといけません(笑)

〇Celeron N4100の場合

　

　２つ貼り付けます。左側がリグコンと同居した場合です。右側がリグコンソフトの通信を切った状態。これだでかなり変わります。kenwoodのリグコンソフトは常時100kBPSぐらいの帯域を使うようです。それでも影響されます。明らかにバッファー使用量が異なります。遅延もその分全然違います。この状態でweb閲覧したら、そのうちに音が飛ぶんじゃないかと思われます。

　やはり、処理能力はCPUパワーに依存します。CeleronN4100のノートpcで音声を取っていましたが、もう少しCPUパワーのあるPCで伝送したほうが良いかもしれません。

　こちらの続きです。DF3CB氏作のRemAudの調整方法を試してみました。調整を方法を解説した先人の記録があればよいのですが、残念ながら見つけられませんでした。当方で試した結果から、以下のようになっていると想像します。これを、備忘録としてまとめておきます。(最新版のVer2.1を使用)

〇使用環境について

・remaudの伝送設定は16bit、サンプリング周波数22kHzのモノラル。
・運用環境はフレッツ網内(Ipv6)の折り返し通信によるVPN。
　回線遅延は片道５～７mSと思われます(大阪⇔兵庫県西部の間）

　おそらく、これが低遅延かつ落ちにくいネットワークを最安で構築する方法だと思います。その代わりにNTTの東西を跨ぐことが普通にはできません。(別料金を払えばできるようですが・・）

〇レイテンシー(遅延量)の見積もり

　多分、この考え方であっているはずです。

遅延量＝送信パケット長＋回線遅延＋(受信パケット長×バッファー数)＋PC処理(ADとDA)

　送信パケット長はサーバー側のこの画面の黄色の丸印。ご本家だとここです。



　受信側。クライアント側の設定はこの画面です。ご本家ではこちらです。

　

　クライアント側が遅延量のカッコの部分です。赤が受信パケット長。青がリミットバッファー数。遅延量は、受信パケット長と使用バッファー数の掛け算になっているとみられます。クライアント側の右隅に出る数字（赤丸）が再生しているバッファー位置、すなわち青丸で指定した量の中で実際に使われている部分を示していると思います。

〇送信パケットサイズの調整

　まず送信側から調整。データサイズを小さくすると、遅延は短くできますが、ショートパケットを短い間隔で投げ続けることになります。となれば、PCのネットワークカード、ルーターの処理に負荷がかかることになります。（ルーター、ショートパケットを連発するとスループットが落ちます）なので、程よきデータサイズを探ることになります。（送信パケット長が10mSなら１秒間に100回送信、40mSなら25回に減ります。)

　故意に、受信バッファーを最小にした状態を作ります。（クライアント側の青丸を「１」にする。赤丸は「１０」。）
送信側の送信パケット長(黄丸)を10から順番に増やして変化を見ます。最初の10mS設定では、おそらく音がブツブツにぶっ飛んでしまうはずです。音がブツブツに切れる状態から抜けるまで、増やします。増やしすぎると、遅延が増えるので、ブツ切れにならないところでストップ。

　当方の環境だと。10～20mSでは、ブツブツでNG。30mSだと、数十秒に１回で音が途切れる。40mSで収まりました。ということで、ここは40mSで固定。

〇受信側の調整

　受信の調整、最終的には、赤丸の受信バッファ長10mS、青丸のバッファーオーバーランのリミットは「0」(自動)に落ち着きました。

　当初は、送受のパケットサイズを一致させて、バッファーのリミット(青)を積み上げていくという方法でした。これでも、安定ポイントは見つけられます。ただ、時間とともにバッファー量が増える傾向があります。バッファーの状態は、上の画のクライアント側の赤丸部分です。こちらの環境では、送受のデータ長を40mSとしたとき、接続時は使用バッファー数が２程度で収まり、実測した遅延は110mSぐらい。ところが時間とともに増加し、バッファー数が６になったころには、遅延は260mSまで増加しました。
　送信パケット長を固定し、受信パケットサイズを送信より大きくした場合も、一致した時と同じ傾向です。遅延が時間とともに増えました。
　送信パケット長より受信パケット長を短くしてみたところ、比較的低遅延で動きました。表題のキャプチャーがその状態の遅延量実測画面です。Ｌ側にAMラジオの受信音、Ｒ側がリモートシャックで受信した音声です。(この実測方法の子細はこちらで)

　バッファー量の数字ですが、青丸のリミット設定以内であれば緑表示。リミットを超えると赤表示に変わります。赤表示だと、音飛びが起こるという意味ではなく、設定よりバッファーの使用量が多い、という警告表示に過ぎないようです。またリミットを超えると、バッファーが生成されなくなるというわけでもないようです。この数字が大きいほど、遅延も多くなっていきます。受信側は、この数字が緑の範囲になるように落とし込めると良好な状態が確保できているという事になるかと思います。

〇最後に勝手な想像

　ここからは想像(妄想?)です。
　データのやり取りがTCPのため、必ずackが戻りますし、ダメなら再送。となると、送信パケットはそれなりの大きさにして、データ送信回数を減らすほうがトラフィック量が減り無難な感じがします。
　受信パケットサイズの件。当初は一致、あるいは送信より長くして、再送に備える・・という発想でした。この設定では時間とともに遅延が増える方向へ傾くようです。受信バッファーが埋まらないとサウンドカードへデータが送られないのでしょう。また受信バッファーはどんどん生成されるようです。リミットを設定してもリミット以上に作成させるようです。
　結局、受信バッファーを短めに設定して、届いたデータは逐次サウンドカード側へ流してしまうほうが、時間がたっても遅延が増えにくい感じです。
　受信側のPCの能力にも遅延量は支配されるはずです。今の受信側はceleron4100のノートPCなので、処理能力の高いPCに変えるとまた設定値が変わってくるのではないかと思われます。

--

　しばらくこの設定で運用してみます。不具合があればまたやり直しでしょうねぇ～。

　リモートシャック関連です。この前のALL　JAコンテスト中に気が付いた不具合修正をメモしておきます。

　

　CPUパワーの消費状況を比較してみました。左が修正前、右が修正後。起動しているアプリケーションの割には、CPUパワーが喰われています。タスクマネジャーで変なプロセスがいないか?見て気が付きました。

　・Windows Image Acquisition（WIA）が高CPU状態になっている。

　今の用途には、画像取り込みなんて不要、タスクマネージャーで強制停止したところ、あっさりCPU食いつぶし状態が改善したのでした。ついでに、サービスの起動を自動(遅延)としておき、立ち上がりにくいようにしておきます。

　今のホストPCに交換してから、CPUパワーの割にイマイチな反応だなぁと思っていましたが、どうやらずっとこのWIAサービスが無意味に働いていたのが原因っぽい感じです。この状態でしばらく使ってみて様子を見ます。これでもダメなら、WIAサービスは手動にして起動しないようにすることになるかと思います。

　コンテスト後になりますが、音声伝送周りを修正しました。



　RemAudのbufferサイズを変えました。もともと20mSだったのを40mSへ増やしています。クライアントソフトの右下(赤丸)の数字がバッファーの消費状態を示すようです。数字が大きくなり、緑から赤に文字が変わると状態が悪いと見てよいようです。赤文字の状態で悪化するとデータ欠落による音飛びやノイズが出ることもあります。
　こちらの環境では20mS→40mSと増やすことで、ほぼ常時緑文字だと思います。こちらもしばらく運用して様子を見るしかありません。

　バッファーを増やせば安定性は向上しますが、レイテンシー(遅延)が相応に増えます。過剰なバッファー追加は、リニアPCMの非圧縮によるエンコード・デコードのレイテンシー短縮というメリットを捨てることになりますので、妥協できるポイントを探すしかないと思われます。(音声圧縮の場合、エンコード・デコードで遅延が必ず発生し、リニアPCMより大きくなります。なお、遅延量は圧縮アルゴリズムやデータレートにより大きく変動します)

[2022.4.28 21:12ごろ追加]
クライアントのバッファーの数字の意味は、再生中のバッファー位置を表すようです。赤字になると、バッファー量が多すぎるという警告で、パケットロス等の品質を表すものではないようです。故意にバッファーを詰めると、緑字でも音がブツブツに切れました。詳しくはもう少しあれこれ試してから・・
該当部分の説明はこちらのリンクを！

　リモートシャック関連。VSPEを使ってシリアルポートのネット越し操作を試してみました。具体的な手順はこちらに詳しく書いてあります。先人の知恵をありがたく利用させていただきました。

〇サーバ側(HostPC)
・新規作成でTcpServerを選ぶ、事前に用意した仮想ポートを割り当て。
・Windowsからのファイアーウォールの警告が出るので、VSPEも例外追加

〇クライアント側
・新規作成でコネクタを選択して、仮想ポートを作る
・作った仮想ポートへTcpClientを割り当て。server側のIPアドレスとポート番号を合わせる。

　という操作で、comポートのネット越しが出来ました。早速、実家にあるTS-590SGを実際に接続されているホストPCからと、自宅のリモート側のPCから、同時にコントロールソフトを立ち上げてみた、というのが表題のキャプチャです。

　あとは、キーイングをうまく処理できれば、ホストPCでzlogを立ち上げてリモートデスクトップで触るということをしないでも、手元のPCでzlogを立ち上げリモート先のリグをコントロールできますねぇ。

　週末実家へ行きましたので、リモートシャックのホストPCを入れ替えてきました。処理能力はVer2の倍ぐらいあるはずです。

構成はこんな感じ
・CPU　Core i5-10400
・Mem　8GB
・SSD　500GB(M2)
・OS　Win10PRO(64bit)
・サウンド　サウンドブラスタ　Audigy FX
・シリアルポート　５ポート　（４ポート追加)

　サウンドのオンボードはどうなんだろう?ってことで、エントリーモデルだけど内蔵カードを追加してみました。
　PC起動は、外部から接点渡しでも可能ですが、今のところWOLだけも問題なさそうなので接続しませんでした。PCへ外部制御機能を追加したけど、なくても大丈夫かも(^^;;;
　リグの電源制御は復活しました。これで、スイッチング電源入れっぱなしで放置しなくて済みます。
　シリアルポートは4ポート追加して、5ポート化します。VSPEは、OSの64BIT化に伴い、FREE版を卒業してライセンスを購入しました(^^;;

　という事を反映した、Ver3のリモート構成図が以下です。



　この状態でしばらく試してみます。

　現時点のリモートシャックの構成図です。全体を描いたものが無かったので作ってみました。フォーマットはこちらの方のアイディアを参考にいたしました。多分、これでどんなソフトをどう使っているのか？ほぼ網羅しているはずです。

　それから、リモートシャック関連でカテゴリを追加です。過去の分も、追いつく範囲でカテゴリ変更しましょう。

[2022.3.15　夜追記]

　リモートシャック構築当初の構成図も作ったので貼り付けます。



　当初、操作側のPCは１台でした。zlogとリグコントロールソフトと音声伝送のVoipツール。いろいろなものが同居すると操作性が悪いです。何度かテスト運用を行った結果、リグ操作とログ操作、PCを分離するほうが良い、という結論に至ったのでした。Core2DUOでは、動くことは動きますが、ふとした瞬間に動作が重くなることがあり、処理能力不足でもありました。

　また、リグの受信音の伝送がkenwood純正のソフトでした。こちらは低ビットレートで、ネット環境が悪くても音声は通りますが、パイルになったときや弱い信号は了解度が劣ります。あと、圧縮遅延もそこそこあるのが気になりました。ってことで、あとから非圧縮のリニアPCM伝送へ切替えました。
　フレッツ網内折り返しのVPNを構築したことから、少々帯域を喰ってもデータ欠落が起こりにくいのでリニアPCM伝送ができます。業務用のルータでIPv6を使うというのが構築のポイントです。(ヤフオクで調達)

　最初のhostPCはOSがWin7PROでした。windows純正のリモートデスクトップが使えるのは便利でした。今のHost2は、CPUがXEONのため処理能力に問題はないと思いますが、HOME版のため純正のリモートデスクトップが使えないのは残念です。次のホストマシンはWin10PROで用意しました。次に実家へ行くとに設置できたらいいなぁー。