ホットスポット経由で接続するチャンネルの表示について

自分の無線機のホットスポット経由でTGIFトークグループに接続する際のチャンネルの表示はどうあるべきかを考えてみます。

AT-D168UVの場合、今はディスプレイには「U2-01 JS1ZZZ」として、協議会のチャンネルの番号とコールサインを表示して、TGIFのIDは内部で持っているだけ。

H1はチャンネル表示領域が英数で10文字しかないので、コールサインのみにしています。同じくIDは内部で持っているだけです。

 

電波でデジピータにアクセスする場合は、周波数とコールサインを意識するので、それを意識したチャンネル表示にしているんだけど、ホットスポットからアクセスする場合は、コールサインよりもTGIFトークグループのIDを意識するので、そっちのほうが良いのではと常々思うのです。

 

ホットスポット経由の接続のときに、次はどこに行こうかと考えてロータリーエンコーダを回す際に、今の設定ではコールサインが表示されているのですが、どうもピンと来ません。「TGIF44050」とだけ表示するようにしてみましょうか。ほんとは、表示領域の制約がなければ、これに加えて地名くらいは入れたいんですけどね。

 

では、TGIFのIDの表示にするとして、レコードの並び順はどうあるべきかを考えてみます。

今は、エリア昇順の周波数昇順に並べていますが、並びはそのままでTGIFのID表示にすべきなのか、TGIFのIDの昇順に並べ替えるべきなのか、そうしたとして、使いやすくなるのかというところが気になります。

  

そもそもなんですが、ホットスポット経由で行く先のデジピータって限られてますから、かって調べたときのリストを更新しつつ、これをチャンネル化して、一旦はAT-D168UV用のZoneとしてまとめたものの、これをずっと維持していくしないはさておき（誰かが最新リストを作って維持してくれると楽ですよね）、限られた先にしか行かないのなら、行く分だけをつまみ食い的に設定しておけば十分なんですよね。限られているんだから、それがどこのデジピータに繋がっているなんて、頭の中でわかっているわけだし。 

なとどいう徒然書きでした。 

H1のVoIP経由受信時のアレの考察（その4・追記）

少し前の話になりますが、首が伸びきったところ（日本語の慣用句で、「なかなか来ないのを待つ」状況を「首を長くして待つ」といいます）でやっとH1が届き、動作チェック後にJARDに保証願い(*)を出し、首尾よく保証書が出て、関東総合通信局に届出をしたのが12/18でした。これでやっとダミーロードをアンテナに繋ぎ変えて送信できるようになりました。

今日のお題はH1で課題としている（課題の内容を修正しました）

(1)音量ボリュームの最小付近の調整ができず、ある点から突然音が出たり、音を絞ろうとしてもある点で無音になって、小さい音量の微調整ができないこと

(2)VoIP経由の受信の際に、受信開始から数秒音声が途切れること

(3)VoIP経由の受信の際に、受信中に音が途切れたり、無音になったり、パケット欠けのノイズが伴うこと

(4)チャンネルの名称のバイト数を英数で20文字程度まで増やしてほしい

(5)（追記）Call LogがDMR IDの数字でつまらないので、Digital Contact List（H1のCPSでは別の名前ですね）とマッチしたDMR IDはコールサインで表示してほしい。欲をいえば、時間とABどっちのバンドから取得したIDかを表示できたらAT-D168UVと同じですね。D168UVは同じIDが何度もアクセスしてきたら最新のものだけをログに残すという仕様になっています。 個人的にはコールサイン表示になってくれるだけでもありがたいです。

のうち、(3)についての考察です。 

 

今日、OMとTGIFトークグループに接続しているデジピータ（SFR）でQSOしていました。OMは隣のエリアからホットスポット経由でTGIFトークグループに、私もデジピータの設置場所から12kmの距離なので、途中で位相ズレやQRMが予想されることから、ホットスポット経由でTGIFトークグループに入ってのQSOです。 

 

ようやくH1が第15送信機として届出が終わったので、

〇私→H1（アンテナを繋げる！）→ホットスポット（Pi-Star）→TGIF44050 

〇デジピータ（SFR、TGIF44050に接続）→438.59MHz DMRモード→我が家のベランダのホイップアンテナ→AT-D168UV→私

という構成で、AT-D168UVで自分の声を聴きながらH1で喋るというのをやっていました。

 

AT-D168UVから戻ってくる音は、H1から我が家のホットスポットでMMDVMからVoIPに変換する際の遅延、インターネット上をパケットが行き来する際の遅延、さらにデジピータ（SFR）側でVoIPからMMDVMで変換する際の遅延、最後にデジピータ（SFR）から我が家に到達する電波での遅延もあって、短いときにはエコーくらいに感じる遅れから、「そんなわけで」くらいの一言くらいの遅延があって、長くなると一文節くらい遅れて届きます。

OMも私もトークグループの中で会話しているので、遅延は最小限で済んでいるのですが、電波を経由するとさらに下線を引いたところの遅延が重なり、けっこうな時間差になります。エコー程度の遅延なら良いのですが、これが一文節くらい遅れると、喋り終わって少し聴いている間に電波からの私が喋り終わるので、なかなか不思議です。

OMが喋り終わって、遅延が大きくて電波ではまだOMが喋っている途中のタイミングで、トークグループではOMがスタンバイに入ってからしばらく空き時間があって、そろそろ私が喋らないと不自然だなと思いつつH1のPTTを押します。そうすると、AT-D168UVからOMの声がまだ流れている段階で、私の新たな送信が混じり…というか、SFR側でどこかのタイミングで私の信号に切り替わるんでしょうけれど…、そのタイミングでパケット欠けの「ピー」「ギャー」や無音になったりします。

AT-D168UVでは、VoIP経由のQSOを含めて、この現象は経験したことがなかったので、これがH1以外でも起きるのかと驚きました。一文節くらい離れると、かなりがんばって遅れ受信をしているでしょうから、CPUにかなり負荷がかかっていると思うんですよね。 

遅れ受信中のこの現象ですが、電波で受信しているAT-D168UVが原因なのか、デジピータ側SFRのBF-TM8250が原因なのかはわかりません。YouTubeの設定みたいに音の高さはそのままで2倍速で聞こえればよいのにと思いますが、それは余談です。

遅れ受信中の後から送信した私の信号が割り込んでのエラーだとすると、(3)については、H1の場合「VoIP経由の信号受信からデコードから音声化」のプロセスが遅く（私は遅く感じています）、一つ前の受信信号の処理をしているうちに次の信号が入感してしまって、後からの信号の処理をしようとする際にエラーが出がちなのかなと想像しています。(2)も原因が同じなのかなと思いつつも、信号不感状態から入感があって、そのときに最初の数秒が途切れることがあるので、受信時頭切れについては違う問題だと思います。

前エントリーで書いた「DroidStarから、テスト用のトークグループに対して「1,2,3,4,5」と5秒送信して、1秒休んで、「6,7,8,9,10」と５秒送信して、1秒休んで、再び「1,2,3,4,5」と送信することを繰り返して」のテストで起きた現象は、遅れ受信中の後からの信号の割り込みによるエラーなのかもしれないですね。

 

今日のエントリーはただの考察なので、何か結論を書いたわけではないのですが、Retevis / Ailunceのスタッフの皆様、以上の内容もご参考になれば幸いです。

上では送信系にH1を使って、受信にAT-D168UVを使っていますが、これを反対に、送信にAT-D168UV、受信にH1を使ってみたらどうなるでしょうね。ちょっと興味があります。本件、続きがある場合はこのエントリーの下に続けて書くことにします。

 

(*) Japan's amateur radio system requires a radio station license linked to a call sign, separate from the required qualifications of a radio operator. Furthermore, each transmitter must be individually notified to the Ministry of Internal Affairs and Communications (MIC). This system, unthinkable in 2025, remains unchanged from the 1950s. It's been simplified somewhat, but it's still ridiculously impressive, isn't it?
Prior to notifying the MIC, there's a system in place where a legally designated organization called JARD issues a guarantee that the radio meets technical standards, including spurious emissions standards, and the notification is then submitted to the MIC along with the guarantee. This guarantee isn't required for products from major domestic manufacturers; since manufacturers sell their products with construction design certification from the MIC, a JARD guarantee isn't required.
Japanese amateurs sometimes ask overseas transmitter manufacturers for block diagrams or spurious measurement documents, but this system is to blame. These standards must be met in order to use their products.
This part is translated by Google, so I apologize if it's hard to read.

H1が来ました。（その3）

受信時の立ち上がり無音、頭切れと、受信中の無音化についてのおはなしです。 

FBのユーザーグループに質問をしてみました。

「皆さん、こんにちは。参考になるスレッドが見つからなかったので、質問させていただきます。
H1をDMRモードで使用し、ホットスポット経由で受信すると、受信音声の最初の数秒が欠落します。この問題を解決する方法をご存知の方はいらっしゃいますか？
デジタルモニターをオフにすると、状況はかなり改善しました。
しかし、受信時に信号の最初の数秒が欠落したままになり、会話に支障をきたします。
長時間の無音期間の後に無線機が信号を受信して​​いた場合は、省電力モードが原因の可能性があります。しかし、そうでない場合、QSOの途中でも最初の数秒が欠落することがある場合は、問題の診断が困難です。
ただし、欠落部分は毎回発生するわけではないため、問題の診断が困難です。」

これに対して、Pi-Starのキャリブレーションをやりなおしてみたらどう？という回答がありました。確かに、AT-D168UV用に-500kHzオフセットしているので、H1がこれからズレていたらパケット欠けもありえます。キャリブレをとりなおしてみると、極端に無音になることは減り、しばしば受信開始から数秒音声が欠けることは直っていませんが、改善したようが気がします。 

それで、以下の返信をしました。 

「ご示唆ありがとうございます。
帰宅後、Pi-Starのキャリブレーションを取り直してみました。
昨日までAT-D168UV用に-500kHzだったところを、H1用に-150kHzに変更しました。
まだ検証時間が少ないですが、ご示唆いただいたとおり、普通の信号受信中に無音になることはなくなったと思います。
信号の受信開始時に、ときどき1-2秒音声が欠ける現象は、変わらず起きています。
検証時間がまだ少ないので、今後この上に書いた内容は変わるかもしれません。

それと並行して、
DroidStarから、テスト用のトークグループに対して「1,2,3,4,5」と5秒送信して、1秒休んで、「6,7,8,9,10」と５秒送信して、1秒休んで、再び「1,2,3,4,5」と送信することを繰り返して、それをキャリブレートをとったH1と、キャリブレートの結果350kHz外れたAT-D168UVで聴くということをやってみました。

AT-D168UVはキャリブレートから外れていますが、よく追いついて音声歪もなく、受信信号の欠けもなく、復調できています。
一方、H1は、最初は追いついているのですが、だんだんと受信信号の最初が欠け、そのうちに「ピー」や「ギャー」といったパケット欠け時の音が出たり、受信時も無音になったりしました。この現象は、キャリブレートをやりなおす前にしばしば起きていました。

私が思うに、H1はこのような早い送受信のやりとりが苦手で、遅い、ゆっくりとした、十分にブレークインタイムをとるような送受信に適しているかと。
VoIP経由ではなく、完全なシンプレックスの交信の場合は、早いやりとりでもこのような現象：頭切れや無音やギャー には遭わないところが不思議です。

最初の質問のところで書くべきでした。ファームウェアとCPSは最新のものを使用しています。」 

 

けっこう厳しめの実験をしてみましたが、H1はゆっくり使うのが良いんでしょうかね。

このほか、改善要望の機会があるとすれば、電源を入れて、音量のボリュームを開けていくと、少し無音の領域があって、そこを超えると突然音が出るんですね。反対に、音量を絞っていくと、ある点で突然無音になります。ボリュームの可変に対して、ごく小さな音からリニアに音量変化が起きてほしいんですよ。このへんは外国製品なんだなと思いますね。比較するとAT-D168UVはよく出来ているほうなのかもしれません。

H1が来ました。（その2・改、後半更に追記）

H1のテストを始めたのですが、どうやら直接電波でQSOする分には問題なさそうな気がします。気だけなんですが。というのは、まだ保証願を出しただけの状態なので、ダミーロードだとQSOにもなりませんからね。このへんは後日試してみるということで。

（補足）本エントリーに書いた検証で力尽きて記述が中途半端になりました。前エントリーで書いた内容と本エントリーでの対策に、矛盾というか繋がりが変なので補足します。 

〇アナログレピータの受信のところで（未検証）とした（ここは未検証のままです）、周波数を移っても移る前の周波数のQSOが聴こえていたことは、同じようにホットスポット経由の送受信の際に、ロータリーエンコーダを回して順次チャンネルに登録したTGIFトークグループを移っている際に、移ったつもりが前のトークグループでのQSOが聴こえ続けることがありました。ホットスポット経由の送受信の際については、前エントリーの画像1-2で、送信用のコンタクトと受信用のコンタクトを個別のトークグループ用に作成したものを指定することにより解決できています。

このとき、画像1-2については、さらにもう一要素ガチガチにしました。

画像1-2（補足） 

紺色で囲んだ部分、Radio IDをCPSのDMR Services→Radio ID Listから指定できるのですが、それまで「None」だったところを自分のRadio IDに固定して指定しています。Radio ID Listを一つだけ作成する場合は「None」でも良いと思うのですが、念のためということで。

また、右下隅のAPRSのところはやらないのでチェックを外しています。 

〇送信のときの頭切れについては、Tipsとして挙げた2つの話と、送信用コンタクトを個別のトークグループ用のものを指定することに解決できたと思います。（いろいろ試したので、何かキーとなった修正か覚えてないところがあります。不確かで申し訳ないです。）

ここまでやって、下に書いたホットスポット経由での受信のときの変な現象の話に繋がります。

--------

実は困った現象が出ていました。 

それは、
直接電波でQSOしているシチュエーションではなく、ホットスポット経由でTGIFトークグループに接続しているときに発生するもので、
〇【頭切れ】受信時に数秒頭切れがある→一つ前のエントリーで書いた話で幾分改善か
〇【時として無音】送受信を繰り返していると（または次々と続く会話をワッチしていると）、信号は入感していてAFは動いていてホワイトノイズのようなものは聴こえるが、人の声の再生ができない
というもの、深刻なのは後者でした。 

受信信号をデコードしてAFに出すまでの間にネックが起きているんだろうなと想像しつつCPSを眺めていると、ここか？と思いつき、Common→SettingsのGeneral Settingの一番下の、Digital Monitorをオフにしてみたら、オフにしてからここまでの時間、無音になるということはとりあえずは無くなっています。

（追記）ここまでの内容を書いたところでは改善したようにも見えたのですが、やはり受信時に欠落が起きます。受信の立ち上がりのところの欠落ならバッテリーセーブ系の制御をオフにしてみることで解決できるかと思い、

取説と無線機のメニューだとPower Save、CPSだと上の画像のようにBattery Save Modeをみてみます。選択肢が取説だと「動1-1静」「動2-1静」、CPSだと1-1と1-2でどっちが動か静かわかりませんが、オフにして、受信時頭切れがなおることを期待してみることにしました。

追試をしてみたのですが、バッテリーセーブが無効な状態でも頭切れが起きますね。その頭切れが起きているときですが、無線機では音声が欠落していても、信号入感を示す緑のLEDは点いている（画面は暗いまま）ので、そこからAFで音が出る段階が遅いってことなのでしょうね。いつもではなく、問題ないときは頭切れなく受信が始まります。このあたりがまた困りものです。

信号入感→緑LED点灯→どこかにしきい値があって、それを上回ると画面表示→画面表示から音が出るまでの間にしきい値があって、それを上回ると→音声デコード+AF出力という順のロジックになっているようです。

受信時の頭切れに関しては、以前よりも改善したものの、解決はしていません。

※APRSやSFRなどの設定は全く考慮していません。「ホットスポット経由でTGIFトークグループに接続してまともにQSOする」というところまでの趣旨で検証した内容となります。

これで実用になりそうかな。（最初はなりそうだね？と肯定的に描いたのですが、否定的ニュアンスで読んでください）

それでも、同じトークグループをAT-D168UVとH1とを並べて聴いていると、ホットスポットからの信号の受信は同時に始まるのですが、受信音声の立ち上がりはAT-D168UVのほうが早いです。また、ネットの状態の変化で信号がデコードできない状況に陥る際のしきい値が、 H1のほうが高い、つまりネットの状態が一定以下になると、先にH1が受信できなくなり、少し粘ってAT-D168UVがダメになります。

この項、まだ続くでしょうね。 

H1が来ました。（その1・改）

ブラックフライデーとそれに伴う荷物量の増加からでしょうか、深圳・香港から国内に入って佐川に渡ったところでしばらく止まっていたH1ですが、ようやく我が家に到着しました。

11/23の夜に注文、11/24に現地配送業者にデータが行って、以降紆余曲折して12/10に到着です。玉石混交モールのchoiceモノに比べたら遅いのは仕方ないとしても、注文時期が悪かったですね。さっさと決断して注文しちゃえばよかったです。

早速開封して電源を入れてみます。首を長くしている期間が長かったので、メーカー公式からダウンロードした最新CPSで、あらかじめAT-D168UVと同じようなことができるようにしたコードプラグを作っておいたので入れてみます。このときファームウェアに新しいものが出ていたので、最新のV1.01.07.49に更新しました。

 

AT-D168UVとは違い、あらかじめ機能が割り当てられているキーがあります。これに加えて後から設定できる上下ボタン、PF1/2キーと、画像でいう「3 SOS Button」のボタンがあるので、ボタンに機能を割り当てられる自由度が高く便利です。※知らないだけでAT-D168UVにも同じような機能があるのかもしれないですね。 

あらかじめ機能が割り当てられているキーは

• テンキー左下隅の「＊」は、短押しでAバンド、Bバンドの切り替え（AT-D168UVでいうところの上バンド下バンドと同じです）、長押しでキーボードロックと解除 
• テンキー右下隅の「＃」は、短押しでシングルバンド表示とデュアルバンド表示の切り替えです。さらにシングルバンド表示にしているときに＊を押すとAバンドとBバンドの切り替えになります。
• 「赤いボタン」は、緑のメニュー奥底に進むボタンと対になっている「戻る」ボタンですが、これを長押しするとVFOモードとチャンネルモードの切り替えができます。さらに、VFOモードのときに#を短押しするとデジタルとアナログの切り替えができます。 

です。ちゃんと覚えればですが、これらがPFキーを使わずに割り当てられているのはありがたいです。で、私が今のところ任意に割り当てているキーはこんな感じです。

取説画像では「3 SOS Button」、上の設定画面では「Top」といっている上にあるボタンはFMラジオのオンオフに割り当てました。

PTTの上と下にPFキー（SK1/2というようです）があって、上側SK1でディスプレイの昼間モードと夜モードの切り替え、下側SK2でMonitor（アナログ時のスケルチオープン）です。※なぜSK1にそんな機能を割り当てたかというと、このボタンって割と触っちゃうんです。当初はFMラジオやデジタルとアナログの切り替えを当ててたんですが、PTTボタンを触ろうとして誤ってこちらを触ることが多く、重要な機能は割り当てちゃダメということしました。ちなみにFMラジオはAT-D168UVとは違って、国内バンドもロータリーエンコーダで普通に選局できます。 

上下キーはAT-D168UVのときと同じようにZoneの切り替えにしました。 

-----

〇コードプラグを無線機に転送し終わり再起動後、初めての受信テストをしてみます。入感している信号を聴くには430のレピータを聴くのが最善で、ちょうど喋ってる人がいるので周波数を切り替えつつ受信テストを始めました。ここで少し挙動が変なのに気づきます。例えば439.62のレピータで誰か喋っているのを聴いていて、9.64に移ってみようとロータリーエンコーダをパチリと回してみても、62で喋ってる人がそのまま聴こえ続けます。？と思って戻ってみると再現しません。ロータリーエンコーダが空振りしたのではなく、周波数表示が変わったのを見ていますから、表面上の受信周波数が変わったのに、受信部は動いていないと考えてよいでしょう。もう一度、と再現してみようとしても再現できません。なんでしょうね。わたくしも歳をとってきたので、幻覚をみるようになっているのかもしれません。この点は未解決で未再現なのでとりあえず置いておきます。 （この部分は未検証です）

〇電源オンオフと音量調整を兼ねているツマミを、音が出る位置からすこしずつ絞っていくと、無音になり、クリックがあって電源オフになるという一連の動きがあります。このとき、クリックを完全にしないで音量プラス側にツマミを戻すと、電源がオフになるのにもかかわらず、ツマミは最大まで回ります。もちろん電源は切れていているので音は出ないのですが、この感触は不思議です。電源オンオフのクリックでワンパルス入るところの出方がいまいちなスイッチなんでしょうね。うちのはこんな感じですが、他の個体はどんな様子なのか気になります。赤ボタンに電源マークが印刷されているので、設計時点では赤ボタンで電源オンオフをやる気だったんでしょうか。

〇144MHz帯のバンド外受信、マリンVHFの感度は悪いですね。残念ながら川崎や横浜のポートラジオはよく聴こえません。アマチュア専用と割り切ればよいということでしょうね。430MHz帯のほうは近くに特小くらいしかないですが、近隣の交信が聴こえているので、それなりなんでしょう。144MHzのバンド内は試してないです。レピータを聴いた感じでは430MHzのバンド内の感度は悪くなさそうです。

〇無線機とCPSとの間の転送速度がAT-D168UVに比べると圧倒的に遅いです。H1はシリアル変換でAT-D168UVはUSB-Cだからかな。もう一つ、H1の場合、データケーブルでスピーカマイク端子を占有してしまうので、コードプラグを無線機に転送して、そのまますぐに受信テストというときにデータケーブルの一端のスピーカマイクプラグを抜かないと本体スピーカから音が出ません。この二点が地味に痛いです。

〇アナログのトーンスケルチの挙動が変です。439.98MHzのように88.5Hzの立川と77Hzの世田谷のレピータが共存する周波数の場合、一方だけを聴きたくて他方が聴こえないようにトーンスケルチを入れたいのですが、77Hzでは意図どおり効いて、88.5Hzではいつも開かないという症状。なので、88.5Hzではエンコードのみ、77Hzではエンコードとスケルチ両方に入れるということにします。

AT-Ｄ168UVは88.5Hzでも77Hzでもトーンスケルチが開かなかったので、それに比べたらまだ良いでしょう。某国DMR機はアナログのトーンスケルチの設計がイマイチなのかな。というか、関東地方のアナログレピータの例のような状況を想定してテストしてないんでしょうね。 これ、ケンウッドなど国内メーカーのDMR機はどんな感じなんだろう。

〇AT-D168UVと同じように、ホットスポット用に設定したチャンネルを作りました。概要はこんな感じです。

• ホットスポットとの通信用の周波数は438.01
• 接続先のTGIFトークグループごとにチャンネルを作成。TGIF4000と9990を入れて24チャンネル分。

要は、送受信周波数を438.01にしたチャンネルをTGIFトークグループのIDを入れて必要な分作っています。 この作成のときに「送信用コンタクト」と「受信用グループリスト」を、TGIFトークグループのIDごとに作成しないと、私の個体ではトークグループをちょいちょい移って移った先で電波を出しても「移る前のトークグループで電波が出ているような表示になる」「移った先の応答信号が聴こえない」という状況が起きます。そこで、以下のような設定をしました。おそらく通常のホットスポット用の設定よりもガチガチにしていると思います。

個別のチャンネル設定はこんな感じです。

画像1-1 

 

 

画像1-2（画像1-1を下にスクロールした状態）

※画像1-2は次のエントリーで補足があります。 

画像1-2に緑で注釈を入れている部分について。DMRモードの設定は、「Simplex」「Repeater」「Double Slot」と選べますが、画像1-1の青い注のように送受信同じ周波数で使うのでシンプレックスを選ぶのが自然だと思います。でも、ここをRepeaterを選ぶことで送信時（受信もかも）に頭切れが少なくなるとのTipsをOMにいただきましたので、書いちゃいます。（本項最後尾にも同様のTipsあり） 

 

• 画像1-2の右上「送信用コンタクト」：送信したいトークグループのIDを1ファイルごとに作成します。項目名が「Priority Contacts」ですが、チャンネル設定での項目名は「TX Contact Name」なのでわかりにくいです。

• 画像1-2の左側中段「受信用のグループリスト」、RX Group List：「リスト」なので、複数のトークグループをひとまとめに登録できます。複数登録して、チャンネル設定で複数登録しているリストを選べば、複数のトークグループを同時に聴ける…んでしょうね、試していないのですが。私の場合は、一つのトークグループだけを登録した「リスト」のファイルを必要分作成して、チャンネル設定時に選んでいます。

 

 

とりあえずこんな設定をして、ホットスポット経由でTGIFトークグループに接続する場合に、トークグループごとに作成したチャンネルを次々に移って行っても、移った先のチャンネル（トークグループ）でカーチャンクするか、TGIFの自分のアカウントのSelfcareのページで接続先トークグループを変更した場合には、前のチャンネル（トークグループ）の受信を引きずることなく、移った先のトークグループで送受信できています。完全にこれで解決というところまで検証しきっていませんが、これで使ってみようかと。

 

この画像は、同じTGIFトークグループを、AT-D168UVで電波で、H1でホットスポット経由で聴いているところです。ダミーロードがごついので早く外したいですね。 

 

もう一つ、送信（受信もかも）時頭切れ対策のTipsです。これは個別チャンネルではなく、全体の設定に影響しますが、Common→Settingsを開いたGeneral Settingの赤で囲んでいる3つの項目もゼロにすると良いとのことです。ありがとうございました。

 

以上はホットスポット経由でやろうとしている故の込み入った設定です。

 

電波で438MHz台のデジピータに、TG1のTS1のCC1で接続する場合には、単純にそのように設定するだけでQSOできちゃうのではと期待しているのですが、電波でのデジピータ接続はまだ未検証です。

 

この機種は一筋縄ではいかないので、続くと思います。タイトルも最初から（その1）にしました。 

Boot imageで遊んでみました。

AT-D168UVの起動時の画像を変更できることは知っていたのですが、H1が来ないのでやってみることにしました。

CPSの「Optional Settings」で「Power ON」タブから「Power-on Interface」を「Custom Picture」にして、その設定を無線機に転送してから、再びCPSの「Tool」の「Boot Image」で画像をPCから取り込んで、画像だけを送って試せます。

The Power of Dreamsのキャッチの会社のロゴが良いでしょう。ここは無線機メーカーじゃなくて関係ないロゴや画像のほうが面白いでしょうね。ウナギイヌやケムンパス、バカボンのパパで立ち上がってくるD168UVもなかなかだと思います。

Tipsを書いておきます。
〇ベースとなる黒バック（黒バックが無難です）部分は横300*縦340で作成。
300*300などスクエアな画像だと、無線機での表示時に縦に伸びるので、最初から300*340で作成する
〇ロゴ部分は200*200（ロゴによって縦横デコボコしていると思うので、サイズは目安）くらいに縮小して貼り付ける

私は事務屋なので、画像編集の達人ではないので難しいソフトは使えません。Windows11でも動くフリーウェアの「Jtrim」とWindows標準のペイントを駆使します。 

ちみに、ここまでいろいろ書いたCPSの画面の注釈は、画像をキャプチャしてwordに張り付けて、wordの「挿入→図形」で丸で囲んだり吹き出しを入れてます。

ホットスポットを持ち出せるようにした。やった！

H1がまだまだ来ないので、目先の興味を解決することにしました。

先日、近所のデジピータ（のトークグループ）を聴いていると、米国西海岸からCQを出している人がいて、この人もVoIP経由で入ってるのかーと思いつつ呼んで、しばしQSOでした。

やはり、車に無線ルータを持ち込んで、 ホットスポット経由で出ているとのことでした。そうなんですよね。これ、私も出先のホテルの一室から自宅近所のデジピータ（のトークグループ）にアクセスしてローカルと話すなんてことをやってみたいと思っていたんです。

そうするためにはネックがあって、Pi-StarのWi-Fiへの接続設定のところがよくわからなくて、pistar.ukにはWi-Fi に簡単に接続できるようwpa_supplicant.confを作成してダウンロードさせてくれるツールがあるんですが、ダウンロードしたファイルをテキストエディタで開いて中身を一応確認して、Raspberry Pi（うちのはZero）からSDHCカードを抜いて、このファイルをコピーして貼り付けて、再びSDHCカードを挿してという作業が必要だと思っていました。接続先の無線ルータを変更するたびにカードの抜き差しとファイルの書き換えは面倒です。

で、もともとPi-StarのConfigを開いてみると、下のほうにWi-Fi設定の部分があって、ここを弄ると複数の無線ルータへの接続設定ができて、切り替えて使えるんだろうなとは思っていたんですが、ななめ読み的に触ってみてもよくわからなかったんですね。

H1が来ないので（再）… 

このトラッキングサイトだと最新状態になってませんが、どうやら昨夜佐川の関西のセンターを通過したようです。明日あたりには届くのかな。

それはさておき、真面目に設定をしてみることにしました。

Pi-StarのWireless Configrationを開いたところです。厳密にいうと、開いて「Add Network」を押したところなんですが、複数の無線ルータのSSIDとパスワードを入れられるようになっています。最初にwpa_supplicant.confをSDHCカードに入れてブートして接続した状態では、ここには一つしか設定がありませんが、こうやって複数設定できるんですよね。複数設定した後の挙動がよくわからなかったんです。Saveを押しても何も変わらないし、再びAdd Networkを押すと入力した設定がクリアされてもう一度入力しなおしになるし。

H1が来ないので時間がありますから、もう少し画面と向き合います。どうやらNetwork0 、1と数値が小さいネットワーク設定が優先順位が高いんだろうな、ということで、

• Network 0に優先する機器（例iPhone） 
• Network 1に通常使う機器（自宅の無線ルータ） を入れて
• Save(and connect)を押して、リブート   

してみたら、iPhoneでテザリングされた状態でPi-Starが起動してきました。

その状態でiPhoneのインターネット共有（テザリング）をOFFにすると挙動不審になったので、自動的にNetwork1を掴みにいくのかと思ったのですが、そうでもなさそうです。粘り強く待っても良かったのですが、無線ルータへの接続状態が変わったらPi-Starをリブートするのが良さそうです。

これで挙動がわかりました。今は、

• Network 0をiPhoneテザリング時として
• Netwotk 1を自宅無線ルータの2.4GHz WPA2
• Network 2を自宅無線ルータ予備機の2.4GHz WPA2

で設定しています。これでiPhoneテザリングで出先に持ち出し、iPhoneからのWi-Fiの信号が出ていないときには自宅無線ルータに、自宅無線ルータが何らかの原因で落ちているときには予備機に接続します。

自宅無線ルータは先週末に壊れて買い換えたばかりで、ついでにWPA3に対応しているのですが、Raspberry Pi Zero（+MMDVM）では2.4GHz帯（5GHz帯は非対応）のWPA2までの対応のようで、WPA3だとダメでした。

ここまでできるとなるとですね、

これを持ち出せば、出先でいつものデジピータ（のトークグループ）に出られるんですよ。好きなんですよね、こういう箱庭的？な楽しみ方。

iPhoneにDroidStarを入れてあるので、それでも同じことは出来るんですが、やっぱり無線機のPTTを押して電波を出してQSOしたほうが楽しいです。
どこのデジピータでもそれぞれのトークグループにリンクしてもらえれば、そこまでVoIPで行くことでその先のデジピータ到達範囲の局とQSOできるのにね。