【お知らせ】
AT-D168UVのコードプラグを当分の間公開しています。いつまでかは考えていません。
内容に責任を一切負いませんが、カスタマイズのベースに使うなど、ご参考にどうぞ。

2026年2月1日にZone「DMRchs」を「SFRchs」に変更すること、VoIP経由でアクセスする際のTGIFトークグループに関するチャンネルを、以前加えたつもりが出来ていなかったので、レコードを追加しました。
ダウンロードと説明は以下のエントリーからです。

「AnyTone AT-D168UV(その6、設定ファイル(コードプラグ))」
https://tr-1300.blogspot.com/2025/09/anytone-at-d168uv4.html

また、ホットスポット経由でTGIFトークグループにアクセスする場合に参考になるTalk Groupsリストを「DMR雑感(11/10版)」からダウンロードできるようにしています。(【訂正】勘違いをして変更なしと表記していましたが、本当は2/1付け変更をしていました。内容は当該エントリーを参照してください。)
https://tr-1300.blogspot.com/2025/11/dmr1110.html

2025年12月21日日曜日

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」と5秒送信して、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.

0 件のコメント:

コメントを投稿