【修正】H1のデジタルコンタクトリストの更新のための目先の対策

【修正】AT-D168UVのデジタルコンタクトリストの更新のための目先の対策

からエントリーを分けました。 

こちらはH1の話です。AT-D168UVでは、無線機で表示する際に漢字やかなや他の国の2バイトコードは化けるものの、 デジタルコンタクトリストをCPSに取り込む際にはエラーとして処理が止まることもなく、2バイトコードを使っている人がいていやだなあと思うくらいで済んでいたのですが、H1の場合は少し面倒でした。

当初、前のエントリーは、前段でAT-D168UVのデジタルコンタクトリストのCPSに読み込ませる際の当座のひと手間を、後段はH1のデジタルコンタクトリストをCPSに読み込ませる際の2バイトコードとの闘いを書く構図で、対策をステップバイステップで示すように作成した内容だったのですが、H1のひと手間が手順どおりに行っても結果がどうも不安定なんです。

現在のAilunce公式からダウンロードできるデジタルコンタクトリストは、VKの1局のデータの重複があって、そのままCPSに読ませるとエラーメッセージが出ます。このエラーの内容を示すcsvを別ファイルに出力できるので、これをExcelでみてみると重複レコードがあることが確認できます。Excelを使うのはエラーとして出力されたcsvを確認するところまでで、重複レコードの削除プロセスからは、CPSに読ませたデジタルコンタクトリストのcsvファイルを、

〇まともなテキストエディタの一つである、Microsoft Visual Studio Codeを使って、2バイトコードを検索して（キーは「[^\x00-\x7F]+」、これを何も入れないもの（つまり2バイトコードが入っている部分を詰めてしまう）に置き換えて、ただし、保存は必ず文字コードをUTF-8でする。これに加えて、気にするなら「 o,」（ブランク、o、カンマ）を「,」（カンマだけ）に置き換えると、化け残ったところが減ります。

で対処するということでまとめました。

〇その後、わざわざ2バイトコードを検索しなくても、VSCで文字コードを「UTF-8 with BOM（※）」で保存すればそのままCPSに押し込めるということがわかり、何度かやってみて成功。これで行けると、エントリーを書き替えました。 

※ 検索してみると、「UTF-8のBOM（Byte Order Mark）付きとは、テキストファイルの先頭に「EF BB BF」という3バイトのデータを付与し、そのファイルが「UTF-8で記述されている」と明示する仕組みです。主にExcelでCSVやテキストファイルを開く際に文字化け（特に日本語…日本語以外の2バイトコードも同じですよね…）を防ぐ用途で使われます。Webシステム開発などではBOMなしが好まれます。」だそうです。

ところがですね、書き換えた後に念のためということで、改めて同じ手順で作業をしてみると、CPS読み込みの際に2バイトコードが化けていることが原因のエラーが出るようになり、解消しません。

というところで、このbloggerに記事を過去に戻す機能があれば、書き換える前に戻したほうが良いことを思いつき、調べてみたのですが戻す機能はないとのことで、仕方なく、H1に関する記述は削って、AT-D168UVの当座の回避策だけを残した状態にしました。

 

もう一度H1について書こうと思うのですが、 ステップバイステップで画像を示しながらもう一度作成するパワーが残っていません。文字だけだと読んでもぜんぜん面白くないのですが、今の今の時点でわかっていることを箇条書きにしてみます。

〇『まともなテキストエディタの一つである、Microsoft Visual Studio Codeを使って、2バイトコードを検索して（キーは「[^\x00-\x7F]+」、これを何も入れないもの（つまり2バイトコードが入っている部分を詰めてしまう）に置き換えることで対処、ただし、保存は必ず文字コードをUTF-8でする。これに加えて、気にするなら「 o,」（ブランク、o、カンマ）を「,」（カンマだけ）に置き換えると、化け残ったところが減ります。』は有効。

〇『VSCで重複レコードを削除して、「UTF-8 with BOM」で保存した場合、エラーなしでCPSに読み込める場合もありますが、2バイトコードが含まれるレコードでエラーで読み込めない場合もあります。この方法は結果が不安定。』は不安定なまま。

☆満を持して「メモ帳」の登場。当初、メモ帳は29万レコードのデジタルコンタクトリストを読み込んだタイミングで少しの間固まるので、まともなテキストエディタを使うべきということでVSCを取り上げたのですが、Windows11についてくるメモ帳は少し機能が増えていて、「UTF-8（BOM付き）」の保存も可能です。で、これを使って重複レコードを削除して、保存してCPSに読ませてみると、うまくいくんです。何度かやってみましたが、うまくいっています。

ただし、少しネックがあって、私のPCは数年前のCore i5のなんとかのメモリ16GBなんですが、メモ帳で大きなファイルを編集する際には操作に対する反応が遅くなって、複雑な長い作業が難しいと感じます。1レコードくらいを削除するだけなら、ゆっくりやれば済むのですが、それでもカーソルの動きが遅いので、ミスしないように慎重に作業する必要はあります。もっと速い機種ならこのあたりは楽になります。

 

まともなテキストエディタとは、Windows11のメモ帳だったというオチでしょうか。

ちなみに、重複レコードがある前提で書き始めた元のエントリーに使ったデジタルコンタクトリストは1/21のものでした。本日ダウンロードした1/30のファイルも、同じようにVKの1局の重複レコードが発生したままになっています。これが無ければ、ダウンロードしたcsvファイルをZIPファイルから取り出して、そのままCPSに読ませられるんですけどね。

 

以上、お粗末様でした。

【修正】AT-D168UVのデジタルコンタクトリストの更新のための目先の対策

2026年2月1日修正版です。【注意】を追加しました。

----- 

AT-D168UVの場合は （その6）の「各位におきまして、デジタルコンタクトリストを入れましょう。」のあたりをご参考いただければよいのですが、Radio IDからのダウンロードにはサブスクリプションが必要なので、Pi-Star公式からダウンロードすることをお勧めしました。

他にも篤志家の方々がダウンロードを可能にしていますが、ファイルサイズがまちまちというか、Pi-Star公式以外は、Radio IDのものも含めてけっこう大きいので、これが結果的にコードプラグのファイルサイズに関係して、大きくなればなるほどCPSでの読み込みや無線機への転送が遅くなるので、やっぱりファイルサイズの小さいPi-Star公式からのダウンロードをお勧めします。

他にもあるコードプラグをダウンロードできるサイトを貼っておきます。 

https://kf5iw.com/contactdb.php （こちらはAnyToneの機種向け）

https://www.iz8wnh.it/rpts/tools/DMR%20Contact%20Lists/ （こちらは他機種もあり）

Pi-Star公式からのダウンロードの話に戻ります。ただし、本日（2026年1月23日）現在、csvの見出し行に「,」が一つ足らなくて、実データのレコードのフィールドにズレが発生しているので、以下の要領で直してください。使うソフトはまともなテキストエディタです。私の場合はVisual Studio Codeを使います。マイクロソフト純正で無料です。そのままだと英語表示ですが、メニューを日本語化することができます。使い慣れた高性能なテキストエディタがあればそれでも良いです。ファイルが大きいので、Windows標準のメモ帳だと開けた時点で固まるのでお勧めしません。

「Radio ID,Callsign,Name,City,State,Country,Remarks」となっているのを、
「Radio ID,Callsign,Name,,City,State,Country,Remarks」と、NameとCityの間の","を1つから2つにします。 これで項目ズレは解消します。

今Pi-Star公式にあがっているデータは、テキストエディタで見ても、Excelで見ても、1行ごとに空白行がありますが、これは気にしなくても大丈夫です。 

こんなこともありつつも、AT-D168UVの場合はこの程度の話でデジタルコンタクトリストの更新ができます。2バイトコード（※）のフィールドは化けますが、化けるだけでCPSで読めないとか、そういう面倒はおきません。

【注意】テキストエディタについて：VSCでも良いですし、ファイルを開いたときに少し固まるのを気にしなければメモ帳を使っても良いのですが、文字コードはUTF-8（BOM無しのただのUTF-8）で保存しないとCPSにインポートできません。次エントリーのH1の例で試行錯誤した結果、BOM付きが良いと思って文字コードの保存をUTF-8（BOM付き）にしたらダメでした。

全世界のものではなく、日本の分だけあれば良いってことなら、項目行と4400001から4499999の範囲だけを切り取って保存して使えばよいです。
でも、最近は国内デジピータ（DMR SFRを日本国内では慣用的にデジピータと呼称しています。）にも海外からアクセスする局がいるので、日本以外の局もコールサインを表示できたほうが楽しいです。

（※）2バイトコードとは、コンピュータで漢字・ひらがな・全角カタカナなど1文字を2バイト（16ビット）の情報量で表現する文字コードの体系、またはその文字自体を指し、文字数が膨大な日本語・中国語・韓国語（CJK）…（わたくし注）ほかにもあるような…で用いられ、1バイトで表現される半角文字（アルファベット・数字など）と対比されます。

------------------------------------------------------------

元エントリーではこの後に続いてH1の話を書いたのですが、大幅更新した後に念のため再検証してみたところ、大幅更新の前のほうが正しい内容だったので、記事を先週までの内容に戻したかったのですが、bloggerは履歴の概念がなく、最新版しか保存されていないので、戻すに戻せない状況になりました。

H1のデジタルコンタクトリストに関する話は次エントリーに再構成しました。

H1で選局ツマミを回したときに意図したチャンネル以外を受信していることがある（その7）

以前よりたまにこの現象に遭遇するのですが、録画することができました。

FM放送でテストをしていますが、DMRモード（ただし、Zoneのチャンネルの変更のときに生じたことは確認しています。VFOモードのときは未検証です）のときにも同じ現象が発生します。

 

動画の説明ですが、

ch4に79.1MHz

ch5に79.5MHz

ch6に80.0MHz

の局をメモリしています。

 

最初に流れているのは79.5MHzで、1980年代初頭のアイドルソングが流れています。

選局ツマミを一つ送って、ch6の80.0MHzにします。画面と受信音が80.0MHzの内容に切り替わります。

 

次に、少し早いペースで2つ戻して、ch4の79.1にします。このとき、画面表示は79.1MHzの内容になっていますが、音声は79.5MHzの受信音が流れています。

 

最後に一つ送って79.5MHzにすると、画面も音声も79.5MHzの内容にになります。

望ましい動きは、多少ペースが速くても、選局ツマミを回して選んだ局の表示と音声が正しく流れることです。

 

H1の場合は、選局ツマミを回したとき、「画面の表示」と「信号の復調から音声出力まで」のロジックが別になっていて、「信号の復調から音声出力まで」のプロセスが遅いので、このような現象が起きるのではないかと思います。

 

 

※動画が再生可能になるまで、エントリーの更新から時間がかかるようです。見えない場合にはある程度時間が経ってからごらんください。

※どうもさっぱり再生可能になっている気配がないので、こちら でみてみてください。

H1でFM放送を聴いているときのバッテリーの減りが気になる（その6）

最近またあちこちで揺れています。適当な揺れが適当なタイミングで起きて、大きな地震が来ないで済むなら、毎日震度4が一度くらい来ても良いんですけどね。

山陰地方でちょっと大きな地震があったので、H1のFM放送受信機能でNHK東京FMの地震のニュースを聴いていました。

H1はキーの割り当てに余裕があるので、FMチューナの起動が楽で良いです。私の場合は上にあるオレンジ色のボタンでFM放送の入り切りしています。ここではAT-D168UVの出番はありません。

聴いていると気になるのがFM放送聴取中はディスプレイのバックライトが消えず、 バッテリーを消費して1%、また1%と残量が減っていくことです。

ほんとの緊急時には無線機を使ってラジオを聴くことはないとは思うのですが、ディスプレイが点灯しっぱなしではなく、最後に操作してから適当な秒数で消灯してほしいです。

このあたり、Geminiに質問してみました。

If you're not a Japanese speaker, download the image below.
You can then upload the image to an AI like Google Gemini, which will translate it into a language that's more convenient for you. 

英語訳すると、最初の「ダメじゃん」がけっこうきつい言葉になっているかもしれませんが、日本語としてはそこまできつい言い方はしておりませんので、念のため。 

それで、このような回答があったので、 バックライトの設定のロジックを考えてみました。

(1)常にオフ
(2)常にオン
(3)信号が途切れた5秒後にオフ
(4)信号が途切れた10秒後にオフ
(5)信号が途切れた15秒後にオフ
(6)信号があるかどうかに関係なく、最後の操作の5秒後にオフ
(7)信号があるかどうかに関係なく、最後の操作の10秒後にオフ
(8)信号があるかどうかに関係なく、最後の操作から15秒後にオフ

みたいにすれば良いのかな。
現在のCPSのメニューでは、

〇常にオン
〇秒数経過後消灯（5秒から1秒刻みで60秒まで設定可能）

で、それ自体は良いのですが、残念ながら、H1の場合は電波が入感している状態（FM放送の場合は起動している状態も同じでしょうね）はディスプレイが点灯するロジックになっているので、バッテリーの消費が気になるのであります。 

普段のQSOの場合の挙動、BrandMeister91などのにぎやかなトークグループを聴いているときに挙動、FM放送を聴いているときの挙動と、それぞれ人によってはこうあってほしい挙動が違うかもしれませんね。 

(3)(4)(5)と(6)(7)(8)の切り替え、「信号の有無を考えて消灯するか否か」が無線機のメニューの浅いところでできれば良いですが、その機能だけを他の画面系のメニューと分けるのもどうかと思うので、やはり上の8つから選ぶようにするのが無難かもしれません。 

H1のVoIP経由受信時のアレを、運用でなんとかかわせないか（その5）

H1のアレな話が続きます。

その4で挙げた課題をもう一度。

(1)音量ボリュームの最小付近の調整ができず、ある点から突然音が出たり、音を絞ろうとしてもある点で無音になって、小さい音量の微調整ができないこと
(4)チャンネルの名称のバイト数を英数で20文字程度まで増やしてほしい
(5)（追記）Call LogがDMR IDの数字でつまらないので、Digital Contact List（H1のCPSでは別の名前ですね）とマッチしたDMR IDはコールサインで表示してほしい。欲をいえば、時間とABどっちのバンドから取得したIDかを表示できたらAT-D168UVと同じですね。D168UVは同じIDが何度もアクセスしてきたら最新のものだけをログに残すという仕様になっています。 個人的にはコールサイン表示になってくれるだけでもありがたいです。 

→(1)(4)(5)、これは次回以降のファームウェアアップデートで改善されることを期待して待つしかないです。

 

(2)VoIP経由の受信の際に、受信開始から数秒音声が途切れること（いつもではないんです。BrandMeister TG91 World Wideのように、エラー補正で復号プロセスに負担がかかるようなトークグループを聴き続けていると、だんだんと症状が出てきます。）
(3)VoIP経由の受信の際に、受信中に音が途切れたり、無音になったり、パケット欠けのノイズが伴うこと（これも同じで、エラー補正でがんばることが重なると、今喋っている局の前に喋っていた局のDMR IDから結びついたデジタルコンタクトリストの情報が表示され続けていたりします。そのような場合、喋っている局の声が聴こえる場合もあれば、無音になることもあれば、「ビー」「ギャー」というノイズが出ることもあります。BM91のようにハードな受信環境ではなく、静かなトークグループでデータの品質が悪くないと思えるときも無音になったりするときもあります。）

→(2)(3)はその4に書いたことが原因なんでしょうけれど、パケットが欠けた状態の信号をエラー補正をがんばってやっているが故、処理が遅れてこうなるってのはおそらくそうなんでしょうけれど、隣で同じ信号を聴いているAT-D168UVがすんなり復調できているのに、H1だけダメってのは残念です。


これらの対策については、すこし悪あがきしてみました。
〇Common Settingから
　(a)Group Call Hang Timeをゼロに（とあるOMの情報）
　(b)Private Call Hang Timeをゼロに（同じOMからの情報）
※Hang Timeをゼロにする件は、Google Geminiによると0だとCPUに高負荷の場合があるので、0.5とか1で試してみろと言われているので追試中。3まで大きくしてしまうと、BM91を聴いている際には、その前にしゃべっていた人の情報が表示されたままになったりするので、大きくしてもそれくらいが限度ではと思っています。
　(c)Last Call Displayをオフ
　(d)Battery Saveをオフ
　(e)Digital Monitorをオフ
 
〇「♯キー」一度押しでAとBの2バンドを表示すると改善か（また別のOMの情報）
※追試したのですが、2バンド表示時に比べてシングルバンド表示のときに悪くなる感じはしません。反対に、2バンド表示にしてもシングルバンド表示のときに比べて良いという感じもしません。

〇DMR ServiveのTalk Aliesの「RX Talk Alies」をオフ
※受信時、すでにインストールしたデジタルコンタクトリスト（H1の場合はLocal Address Contactsと呼称します。）だけを参照し、受信している局が送信しているエイリアス情報は無視します。こうすると、長ーーーーい時間をかけて読み込んだデジタルコンタクトリストから、受信した局のDMR IDとマッチする場合には、住所やプロビンスや国の名前、送信者の名前などが全部表示されます。受信信号からその局のエイリアスを表示させるところまでのプロセスがなくなるので早くなる、かもしれません。

というところまでをやって、プラシーボ効果かもしれませんが、受信時の音声立ち上がりが少しだけ早くなったような…なっていないような…感じです。たぶんなっていません。

〇チャンネル設定の一番下のAPRS受信にマークを入れたら、受信開始時の頭切れがマシになった感がありましたが、 プラシーボ効果でした。時間が経過すると同じです。 （シングルバンド表示ではなく2バンド表示で使うほうが良いという情報をいただいたOMよりコードプラグを参考にさせていただきましたが、残念。）

設定を変えた後、その直後は良い感じがしているのは、「受信信号が無音になってしまったときに、PTTを一度押すと、その時点で受信のやりなおしになるので、その後その信号の切れ目くらいまでは改善する」ということと同じだと思っています。

〇受信音質の劣化については、Pi-StarのキャリブレーションをとってみろとFBのユーザーグループで示唆があったのですが、一番良いところに合わせたH1よりも、合わせた結果350kHzズレたAT-D168UVのほうが劣化がなかったりします。

VoIP経由の受信時に起きている現象なので、Pi-Starの設定でwi-fiを無効にして、ルータから有線接続してみました。ですが、受信の頭切れや無音になることは相変わらずです。


(1)と関連しますが、音量ツマミを絞って小さい音で聴こうとすると、音が出たり消えたりするポイントが8時から9時くらいにあるのですが、その閾値あたりにしておくと、スケルチの開閉と同じようにプチプチ言いながら音が出たり消えたりします。犯人は音量ツマミの絞りすぎなのかと思い、ケンウッドのSMC-34、ボリューム付きのスピーカマイクにして、本体の音量は大きめに、マイクで音量を絞って閾値付近にならないようにしても、受信開始時の遅れなどの症状が出てくるのは同じです。

さて、いろいろと情報をいただきながら（ありがとうございます）、設定の変更で症状をうまくかわせると良いと思い、年末年始に受信テストを繰り返しましたが、H1のVoIP経由の受信時に出る症状は改善に至ることができませんでした。これも将来のファームウェアアップデート待ちですね。

VoIP経由ではなく、デジピータ（SFR）への電波によるアクセスや、シンプレックスでのQSOでは不具合は感じないので、もうしばらくの間、H1はVoIP以外での用途で使うことになります。

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

自分の無線機のホットスポット経由で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.