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

　こちらの続き、その2です。3月30日の午後に、もう一息手を加えて、HOST-PCとTS-590の接続を変更してver11の構成となりました。かねてからの宿題だったPTTをつなぎました。リモート側には仮でマイクをセットしてみました。これで、本格的にPhoneも運用できるはずです。



　このようにすると、HOST側はサーバアプリだけになるので軽量化できます。伝送容量は1.5Mbps弱です。リモートデスクトップを使用してVBANを起動した場合、リモートデスクトップのセッションを切るとVBANの音声伝送も切断されます。リモートデスクトップは使わなくても、接続を解除できません。（タスクバーに置いておくだけで良い)

＃RDPの起動、停止でOSがサウンドデバイスを触るからだと思われます。

　リモート側でzlog起動が可能となるポイントは、リグへ電文送信コマンドを投げてCWキーイングを行う点です。リグ制御がすべてcomポートからの電文になり、キーイングのようなシビアな動きがありませんから、VSPEでネット伝送可能となります。さらに、ZLOGが手元に来るので、ブラックアウトのリスクが回避できます。ただ、TS-590リグコントロールコマンドがオマケ程度の実装みたいで、一度送った電文は、あとからの修正ができず、キャンセルしかありません。コールサイン送信中にミスタイプに気づき修正したくても修正不可という事になります。(キャンセルしてやり直すしかない)

＃zlog令和の改修、ありがとうございました＞JR8PPG

　Phone対策で、リグへの音声入力を背面ACCから正面のMICコネクタへ変えました。背面のACCではDATAモードにしないと変調がかからないためです。MICから入れたほうが使いやすそうです。同時に、PTTもつなぎました。リモート側ですが、NOTE-PCなどの内蔵マイクではイマイチ、マイクも相応の物にしないとダメっぽいです。

　この構成では、CWのオペレーションに制限がでてくるので、実戦で使うとイマイチだったという結論になりそうな予感がします。折角構築したので、何かで試してみます。

＃ハード構成はver11、ソフト構成はver10で着地かもしれません。

　先日の帰省時に、セットアップをリアルに触れるので、あれこれ変えました。前回以来、大きく変えたので、セットアップ図は２枚になってしまいました。今回は、1枚目のver10。

　ver10は２月半ば～３月３０日昼下がりぐらいまでのセットアップ状態です。



　ハード面はそのままで、SDRをホスト側で起動。当初はvoipの設定が不完全だったので、スペアナでバンド内を見るだけでした。ただ、SDRの画像伝送をガッツリ行うと、RDPの帯域が10Mbpsに膨らんでしまい、トータルでは12Mbpsぐらいにまで跳ね上がることがありました。回線能力的には持ちこたえるようですが、ブラックアウトのリスクが増えるのであまりよくない感じです。

　Ver10のポイントは、RDPの帯域削減とSDRの音声処理が課題で、3月30日の帰省時にその点の解決を進めています。

　SDRの音声伝送用に、HOST側でオンボードサウンドのLINE　OUTとINをジャンパーしています。SDRの受信音を一旦、オンボードのLINE-OUTへ出し、LINE-INで取り込み、VBANの入力へ回しています。VBANの仮想デバイスへ取り込むのもありですが、音飛びとあり、あまりよくなかったので、このような対策をとっています。

　VBANでは、BUS-B側をリモート先へ伝送する音声用のバスにします。LchにTS-590の音声、RchにSDRの音声を割り当てています。共に16kHzサンプリングのPCM伝送です。シャック側で、必要なチャンネルの音声を聴くようにします。

＃VBANのBUS-Aはリアルのデバイス有、BUS-Bはデバイス無し。と異なる。

　この状態は、一つの完成形かもしれません。RDPの伝送容量削減を行ったことで、全体で5Mbps強にまで削減できました。今のところ、この形で安定して動いています。

　

　こちらとか、こちらで触れたリモート運用時の伝送帯域削減の件です。いろいろ試した結果、RemoteDeskTopの接続時に以下を修正するのが、一番効果的でした。

・カラー数。最高品質(32bit)　→　HightColor(15bit)　へ削減。
・デスクトップ背景　→　チェックを外し壁紙は伝送しない。
・SDRの画面では、ウォーターフォールの作画エリアを縮める。

　この３点が効果的でした。RemoteDeskTopの接続画面にいろいろオプションがありますが、色数の削減と背景伝送のOFFが一番効果がありました。(残りはOFFにしても大勢に影響しない感じでした)
　SDRのウォーターフォールのエリアを小さくするのも効果的です。画面の変化量を減らすことが、帯域削減に直結しています。

　試しに、SDRをサーバモードにして手元側PCでSDR#を走らせて、zlogはリモートデスクトップで使用、と混在も試してみました。伝送帯域は1Mbps強に削減されますが、とにかく操作性が悪い、使える画角が狭くなるなど、イマイチだったので却下です。

　表題のキャプチャー、左側が削減前、右側が削減後。左はARRLのコンペの時の様子、帯域の記録を忘れていましたが、10Mbps強消費したはずです。右が、この前の大都市コンテストの様子。５Mbps前後へ抑え込んでいます。

　RemoteDeskTopを使わず、主たるアプリケーションはすべて手元で走らせる、シャック側はリグ制御、音声やSDRデータのIP伝送だけに特化できれば、伝送帯域は大きく減らせることができます。この点は、すでに可能な部分とまだ難しい部分が混ざっている感じなので、次の課題でしょう。

　リモート運用専用のTS-590用コントローラー、製作してから1年ちょっと。何度か手直ししています。RITもロータリーエンコーダ―でしたが、波形乱れかな？パラパラ設定値が飛ぶので使い物にならず、断念してスイッチへ変更。(昨年５月過ぎ？)

　メインダイヤルのVFOがクリック付きのロータリーエンコーダ―でした。安価なものでクリック有、無し、２種類購入して比較した結果、クリック有のほうが操作感が軽いので、クリック有で使っていました。
　しかし。。。メインダイヤルはクリックの無いほうが操作感がいい。でももう一方のＡ社のクリック無しローターリーエンコーダ―は軸が重く、頻繁に使うメインダイヤルとしては使いにくくパーツケースの肥やしになっていました。



　この製品は軸が重たいけど、裏面のカシメを緩めたら、軽くなるらしい、って書いたネット記事を見かけたので、ダメもとで試してみたのが上の様子です。緩めるだけで、かなり軽くなりました。写真を見たら、かなり緩めているのが分かるはずです。



　交換した後の背面です。エンコーダーは向かって左から、紫・黒・黄の順でつないでいます。

　組み直してから、試運転。緩める前は重くてすぐに嫌になっていましたが、ずいぶん軽くなったので使えるかもしれません。しばらく運用して考えましょう。

　初めて、関西ハムシンポジウムを覗いてきました。場所は20年以上前になるけど、かつての関ハム会場だから迷うことなく到着。(昔話はこちらででも)

　会場が狭いので、ゆっくり回っても30分ほどで回れてしまいます。お友達への生存表明の場みたいな感じです。記憶があるうちに、立ち話した方々をメモっておきます。JJ3TBB,JR3SZZ,JA3KIO,JN3QNG,JS3EOE,JS3CGH,JQ3IHF,JH3BUM,JA3TZT,JK2VOC,JS3CTQ,JF3PLF(一瞬だけでしたけど)・・・

　立ち話に専念し、怪しげな散財をすることもなくお昼前に会場を出ました。相変わらず、飲食店が少ない場所なので、危うく昼食難民になりかけました。さっさと梅田へ戻るのもありかもしれません。

　年の瀬にまとめたver9の系統図を、まとめページにも反映させました。
　VBANの設定は、もう少しチューニングできそうな気がします。気がするだけなんですが・・AudioDeviceのbufferは、デフォルトのまま使用しています。UDPの投げっぱなしなので、送信パケットは短く、受信バッファーは回線品質を見て必要最小限ではないかと思っていますが・・。

＃デフォルトでは、音切れしにくいように無難なところを取っている感じです。

　リモートシャックの構成図、ver9です。この前の構成図のところでふれていた、音声伝送をVBANへ変更した件を反映させました。



　VBAN関連、適当にメモっておきます。
・IPアドレスは決め打ちのみ。使用端末だけ、DHCPで固定したIPを吐き出すように設定変更。
・IPアドレス以外に、stream名も一致しないと通信できない。

　VBANはマルチキャストでの送信もできるようです。マルチキャスト送信すると、IPアドレスの決め打ちは不要になります。ただし、シャック側と自宅側のサブネットを統一する必要があります。となると、VPNの設定を一からやり直さないといけないので、今のところボツにしています。(マルチキャストの逆、1対1の通常の通信はユニキャストです。)

　まとめページはまた後日にでも。

　昨年に引き続き、今年のリモート運用でのコンテスト参加のまとめです。



　昨年より大幅に出来高は増えました。ハード面は昨年よりさらに手直しが進みました。システムの構築は、気になったところからちびちび変えていくことになると思います。引き続き、大きな課題は運用時間の確保でしょう(笑)。

＃そもそも運用時間が確保できるのならリモートなんていらないですねぇ。

　ここ2年の一回当たりの運用での最大局数は、アールのコンペの383局。400局が壁になっています。来年こそは400局の壁を越えてみたいものです。(リアル運用なら2000年代前半に1000局越えは何度もありました)

この時に触れた音声伝送の件です。

　両端を試験的に、VBANへ変えてみました。使用しているグレードは、VoiceMeeterなので、一番シンプルなバージョンです。この前の全市全郡コンテストで使用した感触では、遅延時間は短いと感じました。遅延が伸び縮みする感じもないので、IPアドレスの問題さえ回避できればいい感じです。ということで、遅延時間を実測してみました。

〇測定方法

NHK R1の音声で、手元のラジオでの受信音、リモートジャックの受信音、これらを同時に録音して波形比較。(Lch側ラジオ、Rch側リモートシャックとして録音)

　まぁ、毎度な方法です。なお、自宅のほうが圧倒的にR1の送信点に近い状態です。経路差が90kmあるので、約300uS(0.3mS)、リモートシャック側の遅延が増えることになります。VBANではサウンドデバイスのドライバをいくつか選択できますので、設定できる範囲で変更してみました。(ドライバ設定は、MME、WDM、KSが選べる。違いはこちらを参照)


〇条件１　ー　両端を　WDM　とした場合



　波形上の遅延量は　104.8mS。経路差補正を入れたら、104.5mS。


〇条件２　－　両端を　MME　とした場合



波形上の遅延量は　206mS。経路差補正を入れたら　205.7mS。
(この場合、経路差補正は誤差の範囲って感じになりそう)


〇条件３　－　シャック側WDM、自宅側KS　とした場合



波形上での遅延量は　91.3mS。経路差補正を入れると　91mS。
やはりこれが最短でした。WDMでもそこそこ良い感じです。

　今のところ、VBANの子細設定はデフォルト値のままです。MMEとWDMで大きく遅延量が違うのは、VBANの設定を見るとbufferがMMEはWDMの２倍のサイズとなっている点が大きいと思われます。
　通信状態を見ながら、bufferを詰めるとどうなるのか?というテストはまた後日です。もっとも、この状態でも、RemAudと同等以上なので良しとしてもいいかもしれません。(RemAudの件はこちら)

＃RemAudは、時間と共に遅延時間が延びることがある、これは難儀なところ。

　VBANの設定はまだまだ理解できていないので、もう少しつついてから整理してみようかと思います。

　この前のVer8aの内容も含めて、まとめページを更新しました。ここまで来たら、後は運用だけなんでしょうけど、VoIP周りの手直しを始めてしまいました。
　遅延時間や安定性がよさそうなら、VoIPソフトを入れ替えようかと思っているところです。