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

　この前の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ですので、この資料からは除外です。

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

　この時にぽちった移動する局の再免許申請。先月末には免許状が発給されていましたが、なかなか窓口へ行くことができず、昨日やっと受領しました。(４月下旬に近総通へ行く用件があったのでついでに受け取ろう!という魂胆でぽちりましたが、用件の日には間に合わずでした。）

日程はこんな感じ。

・4月15日(金)　オンラインで再免許申請をポチリ
・4月27日(水)　手数料納付通知。夜にネットで手数料をポチる。
・4月28日(木)　審査完了。免許状発給。

　用件があったのは28日の朝。もう一息早ければでした・・。もっと早く出せばよかったねぇー。

　リモートシャック関連の備忘録です。久々に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ごろ追加]
クライアントのバッファーの数字の意味は、再生中のバッファー位置を表すようです。赤字になると、バッファー量が多すぎるという警告で、パケットロス等の品質を表すものではないようです。故意にバッファーを詰めると、緑字でも音がブツブツに切れました。詳しくはもう少しあれこれ試してから・・
該当部分の説明はこちらのリンクを！

　

　夜間勤務多め、昼間の隙間で製作しました。しかも２台作ってしまいました。小さいほうこちらで使うつもり、もう一台の大きいほうはリモートシャック用に持ち帰ろうかと思ったり。(大きいほうは、zlogとMMTTY、兼用版です)

　この回路図と同じもので最初に作ったのは20年以上前です。実家では、基板むき出しのまま、小さいポリ袋に収容して、とりあえず絶縁確保、そんなええ加減な状態で20年ほど使っていたりします(笑)。そろそろバラックを卒業せねば。。。ということで作り直したのでした。

　この手の、CWキーイングIF、やり方はいろいろあるはず。個人的に実績のある回路にしてしまいました。世間にあるものを参照すると、BE間に入っている47kΩは無くてもいいように思われます。

＃どこかのデッドコピーだけど、どこで見たものか失念しました(^^;;