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

　先日の帰省時に、セットアップをリアルに触れるので、あれこれ変えました。前回以来、大きく変えたので、セットアップ図は２枚になってしまいました。今回は、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がクリック付きのロータリーエンコーダ―でした。安価なものでクリック有、無し、２種類購入して比較した結果、クリック有のほうが操作感が軽いので、クリック有で使っていました。
　しかし。。。メインダイヤルはクリックの無いほうが操作感がいい。でももう一方のＡ社のクリック無しローターリーエンコーダ―は軸が重く、頻繁に使うメインダイヤルとしては使いにくくパーツケースの肥やしになっていました。



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



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

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

　年の瀬にまとめた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ソフトを入れ替えようかと思っているところです。

　この構成図の修正です。つぎ足しが増えて、線が交差してしまいましたので、交差しないよう書き換えてみました。



　並びを変えて、線が交差しないようにしています。ここまで描きましたが、音声伝送ツールの手直しを目論見中です。こちらのツール(VBAN)を使っている方を見かけますので、試しているところです。

　VBANでは、音声パケットがTCPではなくUDPを使いPCM伝送です。ネットワーク構成がフレッツ網内通信で完結できるので、今のところエラーフリーで動いています。ネットワーク周りの細かい設定はありません。送信パケット長も受信バッファー長も自動設定です。
　唯一の難点は、双方のIPアドレスが決め打ちであることです。シャック側のホストは固定していますが、自宅側が固定ではないので、IPアドレスを固定するか？都度打ち直すか？この点は悩みどころです。
　VBANとRemaudで遅延時間の比較を行い、乗り換えるのか？どうするのか？考えることにしましょう。

　この前のバンドスコープ対応を反映したリモートシャック構成図ver8です。前回のver7から比べて、SDRを追加したのでさらに構成図が見づらくなってしまいました。SDRとリグコンを同居させてみましたが、使いづらいの一言しかありません。SDRでPCを１枚専有させたほうが使い勝手がいいので、ノートPCが３枚必要となってしまいました。

＃そろそろ、一から書き直したほうがよさそうです。