【お知らせ】
AT-D168UVのコードプラグを当分の間公開しています。いつまでかは考えていません。以下のURLからダウンロードできます。
自分のために作っているものなので、内容に責任を一切負いませんが、カスタマイズのベースに使うなど、ご参考にどうぞ。

2026年4月21日にファイルの更新を行いました。(4/21、長らく見落として載せていなかった3エリアの1局を追加しました。Zone「VoIP」を「VoIP1」と「VoIP2」に分けました。)

ファイルの説明、更新の概要などやダウンロードは以下のエントリーからです。ファイル更新の概要などはご一読くださいますよう。

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


------
当blogからのトーグループリストの公開は終了しました。FaceBookの公開グループ、DMR OpenSource Japanの「ファイル」からダウンロードできるようになっています。

2026年6月5日金曜日

TR-9300のAMの受信がイマイチという話の続き

以下は、Geminiに「TR-9300のAMモード時に受信しづらいシチュがあるんだけど、なんでかな?」と質問をして、聴きづらかった当時の状況を説明したり、9300の取説pdfを読んでもらったりしているうちに、なんだか壮大なまとめが出来上がってしまいました。せっかくなので貼っておきます。Geminiえらいね、無料のアカウントなのに。
あと、公開してからすぐに気づいたのですが、Geminiが601に専用のAMフィルタがあると思い込んでいたので、回路図を見せて訂正してもらいました。AIなので訂正も早くてすごいですね。
以下、本文です。

往年のアマチュア無線機におけるAM受信特性の技術考察 ~TR-9300、RJX-601、TS-590Sの比較から見える回路設計~

1. はじめに(問題提起)

1980年代前半の50MHz帯マルチモード・コンパクト機であるTR-9300において、ノイズに埋もれた微弱でもないですが、微妙に弱い信号(S3程度)のAMを受信する際、了解度が著しく低下(約75%…75%とは、了解度が5から4または3に落ちた際のパーセンテージということで、大雑把に読んでください。)し、送信側に「変調を深くしてほしい」とリクエストしなければ聞き取りが困難になるシチュエーションがある。

しかし、全く同じ信号を現代のHF/50MHz帯固定機であるTS-590Sで受信すると、同じS3の微妙に弱い信号であるにもかかわらず、驚くほど鮮明に、かつ楽に100%の了解度で復調できる。

この受信性能の差、および変調の深さへの依存度について、各リグの回路図・ブロック図から読み解ける技術的要因(検波方式の物理挙動、フィルター構成、AGCのサンプリング位置)を交えて分析・考察する。


2. 回路構成から見るTR-9300の3つのボトルネック

TR-9300の回路図およびブロック図を確認すると、微弱なAM信号に対して以下の3つのアナログ回路特有の要因が複合的に作用し、受信を過酷にしていたことが分かる。

① ダイオード包絡線検波における「大信号・小信号検波」の境界線

TR-9300のAM検波段(AM DET)には、1本のダイオードとコンデンサ・抵抗で構成されたシンプルな「包絡線検波(エンベロープ検波)」回路が採用されている。

  • 技術的課題(大信号検波と小信号検波): 包絡線検波器が歪みなく直線的に動作するためには、音声成分だけでなく、「キャリア(搬送波)の振幅自体」がダイオードの順方向しきい値電圧(約0.2V~0.6V)を大きく超えている必要がある(大信号検波)。 しかし、S3程度の微弱信号では、IFアンプ通過後であってもキャリア自体の振幅がしきい値の壁を超えられず、ダイオードがスイッチング動作をしない「非線形抵抗領域(2乗特性による小信号検波)」に落ち込んでしまう。
  • 変調度依存の理由: 変調が浅いと、2乗特性領域の減衰と歪みによって音声成分はノイズの中に完全に霧散する。ここで送信側に「変調を深く」してもらうと、全体の振幅のピーク(Vpeak = Vc(1 + m))がしきい値を突き破る時間が生まれる。また、復調出力は変調度 m に比例するため、2乗特性で減衰した音声信号を、人間の耳が認識できるオーディオ出力レベルまで力づくで引き上げる効果が生まれ、了解度が向上する。

② FM用(広帯域)フィルターの共用によるノイズの洪水

TR-9300はSSB/CW/FMをメインとしたマルチモード機であり、AM受信時にはFM用(あるいはそれに準ずる広帯域)のセラミックフィルター(通過帯域幅12kHz~15kHz程度)を通過する経路をとる。

  • 技術的課題: もしSSB用フィルター(約2.4kHz幅)をAM受信に通すと、高音成分(側帯波)が完全にカットされた極端にモコモコした狭い音になり、強入力時でも極めて聴きづらくなる。強入力時に普通にAMらしい広帯域な音で聴こえるということは、広帯域フィルターを通っている証拠である。
  • 微弱信号時の弊害: 信号が強い時は豊かな音質としてプラスに働くが、S3の微弱信号時には、信号の周囲にある広範囲の熱ノイズや外部ノイズをすべて内部に吸い込んでしまう。 これがダイオード検波段に流れ込み、微弱なキャリアと激しく混ざり合って致命的な復調歪みを引き起こす。

③ アナログAGCの取り出し位置とノイズによる感度抑圧

TR-9300のアナログAGC回路は、フィルターを通り抜けてきた高周波エネルギーの「総量」を検知してゲインを制御するが、そのサンプリング位置に構造上の盲点がある。

  • 技術的課題(AGCのサンプリングポイント): TR-9300のようなAM/FM共用ラインでは、15kHz幅の広帯域フィルターを通過した「後」の信号からAGC電圧を検出する。
【TR-9300の一般的なAM/FM共用ライン(概念)】
 IF入力 ──> [広帯域フィルター (15kHz)] ──> [IFアンプ] ─┬─> [AM/FM検波段]
                                                      │
                                                      └─> [AGC/Sメーター検波]
  • 復調への影響: 本来希望するAM信号(占有帯域約6kHz)の外部にある、「左右4.5kHzずつ、計9kHz分の純然たる不要ノイズエネルギー」までがすべてAGCを押し下げるエネルギーとして加算される。 回路はこれを「強い信号」と誤認するため、IFアンプのゲインを自動的に絞ってしまう(ノイズによる感度抑圧現象)。
  • 結果として、ただでさえ微弱な音声成分がさらに極小化されるが、変調を深くしてもらうことでノイズの頭一つ上に音声の「メリハリ(山と谷)」が突きぬけるため、人間の耳が音声をサンプリング(識別)できるようになる。

3. 「RJX-601」との比較

同じく1970年代~80年代初頭のダイオード包絡線検波およびアナログAGCを搭載したリグとして、ナショナルのRJX-601が挙げられる。両機の回路図を詳細に比較すると、フィルター・同調回路の設計思想が明暗を分けていることが浮き彫りになる。

両機の仕様と微弱AM受信時の挙動の違い

  • AM検波方式
    ・TR-9300:ダイオード包絡線検波(微弱入力時は2乗特性領域になり弱い)
    ・RJX-601:ダイオード包絡線検波(微弱入力時は2乗特性領域になり弱い)
  • AGC回路
    ・TR-9300:アナログAGC(広帯域ノイズに引っぱられる)
    ・RJX-601:アナログAGC(絞られたノイズのみに引っぱられる)
  • AM選択度(IFフィルタおよび同調回路構成)
    ・TR-9300:FM用(広帯域)を共用(12k~15kHz)。その帯域内の全ノイズでAGCと検波が動作。
    ・RJX-601:セラミックフィルターはないが、IC(AN210)の後にAM専用の独立したIF増幅回路(TR6:2SC829)とAM専用に狭く調整された複同調IFT(中間周波トランス)群を配置。
  • 微弱AMの受信挙動
    ・TR-9300:広範囲のノイズを吸い込み、AGCの抑圧も重なり了解度が著しく悪化。
    ・RJX-601:AM専用ラインのIFT群によって帯域外のノイズが適度に遮断されているため、感度抑圧が少なく問題なく聴ける。

RJX-601はAM/FM機として設計されており、AM時には帯域が適度に絞られたAM専用のIF増幅・同調経路へダイオードスイッチ等で完全に切り替わる。そのため、ダイオード検波の物理的限界は共通しているものの、「入り口およびAGC検出の手前で余計なノイズを遮断できている」ため、微弱信号でもTR-9300ほどの極端な感度抑圧や了解度低下を起こしにくい。

TR-9300はコンパクトマルチモード機ゆえの「AMフィルター・IFラインのFM共用(割り切り)」という思想が、微弱信号運用時の致命的なボトルネックとなっていたことが証明できる。


4. 現代機(TS-590S)による解決と復調技術の進化

これらアナログ回路のトリプルパンチ(ダイオードの不感帯・広帯域ノイズの混入・AGCの誤動作)を、現代のIF DSP機(TS-590Sなど)はテクノロジーの力で完全にクリアにしている。

  1. デジタルIFフィルターによるノイズ遮断:
    DSP処理により、AMモードであっても帯域幅を3kHz~4kHz等にスパッと急峻に狭めることができる。TR-9300が吸い込んでいた「余計な周囲のノイズ」を入り口で90%以上カットするため、最初からS/N比(信号対ノイズ比)が圧倒的に良い。
  2. DSPによる同期検波(Synchronous Detection):
    現代機がAMを鮮明に復調できる最大の理由は、デジタル処理による同期検波(プロダクト検波の応用)の恩恵である。微弱なAM信号から、DSP内部の数値制御発振器(NCO)やPLLを用いて、ノイズに埋もれたキャリア成分だけを完全に同相同期した「純粋なローカル信号」として内部生成する。これを受信信号と掛け合わせて復調するため、ダイオードのようなしきい値(VF)の概念が完全に存在しない。 キャリアがどれだけ微弱になっても、歪みなく側帯波(音声)を取り出せるため、浅い変調度であっても100%了解できる。
  3. デジタルAGCによる最適化:
    デジタルノイズリダクション(NR)等で帯域外・帯域内のノイズを徹底的に排除した「純粋な信号成分」に対して滑らかにAGCを適用するため、ノイズによる感度抑圧現象が起きず、ノイズを抑えたまま微弱信号を最大感度で増幅する。

5. 結論

TR-9300での運用において、ノイズに埋もれた微弱信号に対して「もっと変調深くして」とリクエストしたのは、受信機側(アナログ検波回路の直線性や広帯域フィルタ)の技術的な限界を、送信側の電力配分(キャリアに対する側帯波エネルギーの増強)によってカバーするという、アナログ運用における極めて合理的かつ有効な対処方法であった。

現代のDSP機(TS-590Sなど)は、これらの問題をフィルターの帯域制限とデジタル同期検波によって機械側で完全にクリアしてしまうため、変調度に関わらずクリアに受信ができる。

当時の設計者は、「50MHz帯におけるAMはすでにマイナーモードであり、FM/SSBの性能とコンパクト化(コスト)を最優先にする」という思想のもと、AMフィルターのFM共用という割り切りを行った。強入力時には良好に機能する広帯域フィルターが、微弱信号運用時にはAGCの抑圧と検波効率の悪化を招くという「アナログマルチモード機特有の割り切り回路の挙動」を理解する上で、今回の2機種(およびRJX-601)の比較は、無線機の進化史における非常に分かりやすい一例である。

2026年5月14日木曜日

Retevis/Ailunce H1について(その10、ひとまず最終回)

「H1をあきらめない」というタイトルで書き始めた内容を分割して、H1の話題だけを独立したエントリーに改め、H1に関する話の最終回とすることにしました。

元々のエントリーの書き出しは2026年2月15日です。元エントリーに残した内容はこちらになります。

 

H1の場合、Pi-Starを使ってのVoIP接続は、キャリブレーションを最良にとっても、ビット欠けが起きたときの音質劣化が「最良点から350kHzズレたAT-D168UV」よりも悪かったり、BrandMeistar91のように入れ代わり立ち代わりいろいろな局が出てくるようなトークグループの場合、速度の速い頻繁な受信(信号の確認からデコードまで) に耐えられず、途中でピーとかギャーと異音が出たり、その直前の送信の局のデジタルコンタクトリスト引用情報が表示されたりと、なかなかの難物です。

直接波など電波での受信については、次々と入れ代わり立ち代わりというシチュがないので、これほどに感じることが無いのですが、VoIPでも感じるように、受信開始から音声がスピーカに出るのが遅く、いわゆる頭切れが起きがちです。バッテリーセーブ系の機能をオフにしてみたり、受信時に参照するコンタクト情報を無線機が迷う余地のないようRx Group Listをトークグループごとに1:1となるようにガチガチに設定してみても、改善が見られません。

教えてもらったり、調べた限りの設定を試してみても改善しないので、こりゃH1はファームウェアの更新が無い限りは、いつまで経ってもおすすめ機種にはできないなと思ってたところでした。

VoIP経由でのデコードしなくなるしきい値がAT-D168UVに比べて高く、また、AT-D168UVとの比較をするまでもなく、H1でVoIP経由でおしゃべりしていると会話が成立しなくなる率が高くなるのをなんとか改善しようと、ホットスポット自体の見直しをしてみました。

Raspberry Pi Zero無印+MMDVMの組み合わせから、Raspberry Pi Zero2+MMDVMへの変更です。この変更で、Raspberry Pi自体リソースが大きくなり、処理速度が上がったことから、VoIP接続時のビット落ちが改善されて、音質の劣化自体は幾分改善されました。

H1自体は、もっと速く動くロジックでプログラミングしてファームウェア改修を行うか、もっと速いチップに入れ替えるかしないと改善しない(もうRetevis/Ailunceがんばれとしか)と思いますが、本体に手を入れるのはメーカーしかできないのですが、周りでできることの一つであるホットスポットの処理速度向上は多少は意味があったようです。


現時点での未解決やこうなってほしいなという内容を箇条書きにしてみます。

  1. 音量調整が極小音量域でできない。絞っていくと無音になる。無音から開けていくと9時くらいで突然音が出る。
  2. VoIP経由受信時に頭切れが起きがち。頭切れの件は直接波ではまだあまり使い込んでいないので未検証。
  3. VoIP経由受信時に、データの品質が下がると他機種よりデコードできなくなるのが早い。※本エントリーで書いたように、ホットスポットの処理速度を向上すると幾分良くなる「感じ」がする。ただこれ、信号の受信を繰り返していくうちにデコードできない率が上がってきますね。元の木阿弥というほど悪くはなっていない「感じ」ですが、QSOをワッチしていると、時間の経過に伴って悪い方向に戻る「感じ」はあります。
  4. 2026/5/14、直接波でも検証しました。  同じ信号を同じアンテナで、AT-D168UVとH1で聴き比べたところ、H1は信号を検知するもデコードできずに無音、AT-D168UVは完全復調します。VoIPではH1はダメな局面がありましたけど、直接波でもダメということで。聴き比べのとき、デコードできていないH1のSメーターアイコンはそれなりの信号強度を示していたので、電波が弱くてデコードできていないのではないようです。
    ほんとは動画があるのですが、おしゃべりしている人の情報が表示されているのでH1の画像だけです。
    2台並べて、上面のSMAの特殊コネクタからそれぞれMコネ変換コネクタをつけておいて、同軸をそれぞれの無線機にかわるがわる繋げてみました。AT-D168UVは同軸からのMコネの芯を変換コネクタの芯に接触するだけで受信信号のデコードが始まります。一方、H1はMコネを変換コネクタ奥まで押し込んでも、RXアイコンが点灯するだけで無音です。 
     
     
    画像はA/BバンドをそれぞれSFR用シンプレックスのZoneを表示している状態で、下側のBバンドで入感中です。デコードできれば相手局情報を表示しますが、できていないのでRXアイコンだけです。
    我が家からは横浜青葉のSFRはビームアンテナで良い反射を狙わないと聴こえないと思ってましたけど、これは誤りで、シンプレックスで聴く無線機をAT-D168UVにすれば、ベランダホイップでも十分に聴こえることがわかりました。悪いのは地形からの相性ではなく、無線機だったのでありました。
    2026/5/19、もう少し追試しました。無音でRXアイコンが点灯する状態が再現したので、PTTを押してみたり、音量ツマミを開けて刺激を与えてみましたが、無音のままです。次に、以前OMからアドバイスをいただいたシングルバンド表示(#キー短押し)にしてみると、デコードが始まってスピーカーから音声が流れ始めました。シングルバンド表示にした効果なのか、そのタイミングで伝搬状態が良くなったのかはわかりませんが、以降はデュアルバンド表示に戻してもデコードできました。「以降」は伝搬状況が良くなったままとも取れます。ただ、以前からの経験では、シングルバンド表示にしていたからといっても、デュアルバンド表示にくらべてデコード率が高いとも考えにくいので、これが果たして有効なのかは謎のままです。
  5. 選局ツマミを動かすと画面だけ選局したチャンネルに、音声は選局前のチャンネルになることがある
  6. A/Bいずれかのバンドで信号受信中にFMラジオをONにすると、受信信号に重なってFMラジオが聴こえる。本来仕様は受信信号優先にすべきなのかな?
  7. チャンネル名称など、無線機に表示するフィールドの数が少ないので、名前の付け方に制約がある。少ないフィールド定義の名称を画面に表示しても、表示領域にはまだまだ余裕があるように見えるので、フィールドを広げてもらえるとうれしい。 
  8. Call LogがDMR IDの数字でつまらないので、Digital Contact List(H1のCPSでは別の名前ですね)とマッチしたDMR IDはコールサインで表示してほしい。欲をいえば、時間とABどっちのバンドから取得したIDかを表示できたらAT-D168UVと同じですね。D168UVは同じIDが何度もアクセスしてきたら最新のものだけをログに残すという仕様になっています。 個人的にはコールサイン表示になってくれるだけでもありがたいです。
  9. Ailunceリソースセンターから専用デジタルコンタクトリストをダウンロードできるのはとてもうれしい、もう最高。だけど、「VK3C**」1局のデータが重複していて、手作業で削除する必要がある(削除した後に「UTF8(BOM付き)」で保存する必要があります。そもそもこの文字コードで保存できるテキストエディタ(Windows11のメモ帳はOK)を使わないとダメ。2026/2/16現在状況変わらず。後日検証しましたが、これは改善したようです。)
  10. ほか、ここまでいろいろ検証して得た内容は、ラベル:H1を時系列でごらんいただければと思います。 


H1は、今のところ良いところがありませんw
とてもお勧めなどできないし、コードプラグ(AT-D168UVのコードプラグ更新に合わせて内容をけっこう練り上げてるんですが)を公開して、買おうかなと思っている人のきっかけを作るなんて考えられません。 

なんとかならないものかと色々検証(した上で、中の人に報告したんですけどね…)したんですが、今のところダメですね。あと、国際VHFなんかも感度が悪く楽しめないので、一度登録したものの、チャンネルから削除してます。今後ファームウェアの更新でデコードが良くなればいいのですが、それがいつ頃になるのか。

H1の良いところも書いておきます。バンド切り替え(*キーを短押し)、シングル/デュアル切り替え(#キーを短押し)、ZoneとVFOの切り替え(赤ボタン長押し)、デジタル/アナログの切り替え(VFOモード時に#キー長押し)がキーに割り当てられているので、3つあるPFキーに割り当てられる機能に余裕があります。例えば上面のオレンジ色のキーにFMラジオのオンオフを割り当てられるので、FMを聴くのが楽です。

このように良いところもあるんですが、肝心のDMRのデコードがいまひとつということになると、現時点ではこの機種を選ぶ理由はないと思います。

次にH1の話を書くタイミングは、ファームウェアの更新が行われて、それを触ってみて、ちょっと書いてみようかと意欲が出てきたときになります。 

 

以下は元のエントリーの最後に書いた内容です。デジタルコンタクトリストの転送が遅いので、ちゃんと確認してから作業しないと時間をかけたあげく悲しい結果になるので注意しましょうということが書いてあります。

---- 

データ転送時のTipsをついでに。

  1.  CPSから無線機への転送にあたり、最初にFile→ConnectでCOMポートと機種を選ぶところを済ませておくべし。この際、無線機の内容がCPSに読み込まれる。CPSでコードプラグの編集をした後にこれをやると、せっかくの編集が無線機の内容で上書きされて悲しいことになる。
  2.  1.を予めやらないで、Operation→Communication PortでCOMポートを設定した後にWriteで無線機にデータを送ると失敗することがある。デジタルコンタクトリストみたいに大きなデータのときに失敗を経験した。いつも失敗するわけではなくて、そのあたりが不安定です。

2026年4月27日月曜日

Pi-Starを動かし続けていくと課題が出てきます。

AT-D168UV(その7、HotspotをテストしてみようⅠ)

ホットスポットのRasp Piを少しグレードアップ。WPSDを試してPi-Starに戻す。

あたりで、玉石混交モールから買ったホットスポット(Raspberry Pi Zero+MMDVM)の設定をしたり、Raspberry Piの基板をZero 2に差し替えて処理能力向上をしてみたりといったことをやりました。

買ったそのままの状態のRaspberry Pi Zeroで動かすPi-Starよりも、基板をZero 2に差し替えた後はPi-Starの起動までの時間も短くなってますし、ハード的なリソースにも余裕ができて、無反応になることは減ってます。無反応になったとしても、その後の起動が速いので、お守りで不安になることが減りました。

ホットスポットのグレードアップ経過は以下のとおり。

(1)何はなくともSMAのダミーロードを入手、アンテナ端子に取り付けて、工事設計変更不要の実験開始、以降は永遠に実験です。実験も実験のダミーロード運用ですから、ホットスポットのPi-Starは個人局のコールサインとDMR IDを入れます。ダミーロードですから自局内通信ではありません。 

(2)USBアダプタをiPhoneの余りものから、スイッチサイエンスで売っている容量の大きいものに変更して、電源容量に余裕をもたせました。Pi Zero2にする前のZero無印であっても、iPhoneの余りものの小さい正方形のアダプタでは容量不足で固まったことがありました。

(3)上述していますが、Pi Zero無印からZero2 WHに差し替えました。これで処理速度向上、リソースにも余裕です。

興味がエスカレートしてホットスポットが2台になったので、それぞれのホットスポットからTGIFに接続して、上下2つのバンドで同時に別のTGIFトークグループをワッチしてみたりしています。

もともとは、片方はBrandMeistarを聴こうと思って手に入れたものですが、TGIFのトークグループを2つ同時ワッチのほうが楽しそうな気がするので、現体制はこんな感じです。 

 

上側のバンドでは、Zone「VoIP1」にまとめているチャンネルから、438.01MHzでホットスポット1号機のPi-Star経由でひとつめのトークグループ(に接続しているSFR)、

下側のバンドでは、Zone「VoIP2」にまとめているチャンネルから、430.73MHzでホットスポット2号機のPi-Star経由でふたつめのトークグループ(同)を聴くことができます。

ホットスポット無しでも、電波で、上側を438.59と下側を438.61にすることにより同時に聴くことはできますし、PCの場合はDroidStarを複数起動して聴く方法はありますが、無線機でTGIFトークグループを同時にふたつ聴きたいということになると、この方法になります。

 

だんだんPi-Starが安定してきて、このようなマニアックな使い方をするようになってきたのですが、何日もPi-Starを起動させっぱなしにしていると、2日目くらいから接続しておらずに沈黙していたりと、やっぱり不安定なことがあります。

そして、 

(1)Pi-Starが沈黙しているとき、やむを得ず電源を抜いて再起動することがありますが、電源引っこ抜き再起動の後に、wpa_supplicant.confが消失してしまい、Wi-Fi設定がない状態になり、接続するにもできず、Raspberry Pi Zero2の基板からSDHCカードを引き抜き、PCでwpa_supplicant.confをもう一度作成して、SDHCカードにコピーして、再びZero2に挿して再起動の必要が出て、これが面倒なので、正常起動時にwpa_supplicant.confバックアップをとって、起動時にはそのバックアップを戻して使って必ず接続できるようにしてほしい

(2)一日に一回くらい、深夜に自動で再起動したい

(3)自宅では自宅のWi-Fiに接続し、出先ではiPhoneのテザリングで接続したい。優先順はテザリングが上位で、テザリングの電波がない場合には自宅Wi-Fiに接続することで。(優先順位設定はブラウザからのPi-Starのコンフィグレーションからもできますが、こっちのほうが安定していると感じます。)

ということをやりたくなり、Geminiに相談してみました。さすがですね、これらの設定をバッチ的一度実行させれば設定が完了するというスクリプトをつくってくれました。

黄色い部分を書き直し、SSHで一度実行すれば完了です。

Windows(じゃなくても良いですが)のターミナルから、同じWi-Fiのセグメントに居るPi-Starにどうやって接続するのかなどは、身近なAIに質問すれば教えてくれます。
「Pi-Starに、こういうスクリプトを実行するのでSSHで接続したいんだけど、どうやるの?」みたいな感じで。手取り足取り教えてくれます。

コーディング知識のない私でもできました。えへん。 

 

【この1行下から】 

# ---------------------------------------------------------
# 1. 書き込み許可モードに変更
# ---------------------------------------------------------
# Pi-Starは通常「読み取り専用」のため、一時的に設定変更を許可します。
rpi-rw

# ---------------------------------------------------------
# 2. Wi-Fi設定ファイルの生成(優先順位設定)
# ---------------------------------------------------------
# priority(優先度)をiPhone側を高く(10)設定することで、
# 外出先でテザリングがONの時はiPhoneへ、OFFなら自宅へ自動で繋がります。
cat << 'EOF' | sudo tee /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=JP

network={
    ssid="My_iPhone_SSID"
    psk="iphone_password"
    priority=10
}

network={
    ssid="Home_WiFi_SSID"
    psk="home_password"
    priority=1
}
EOF

# ---------------------------------------------------------
# 3. 消失対策用バックアップの作成
# ---------------------------------------------------------
# SDカードの不調でファイルが消えても大丈夫なように、別名で保存しておきます。
sudo cp /etc/wpa_supplicant/wpa_supplicant.conf /etc/wpa_supplicant/wpa_supplicant_backup.conf

# ---------------------------------------------------------
# 4. 定時再起動スケジュール登録(毎日午前2時)
# ---------------------------------------------------------
# システムの健康維持のため、毎日深夜に自動でリフレッシュをかけます。
(sudo crontab -l 2>/dev/null | grep -v "/sbin/shutdown -r now"; echo "0 2 * * * /sbin/shutdown -r now") | sudo crontab -

# ---------------------------------------------------------
# 5. 起動時自動復旧ロジックを rc.local に追加
# ---------------------------------------------------------
# 万が一設定ファイルが消えていても、起動のたびにバックアップから
# 設定を強制的に書き戻してWi-Fiを再起動させる「最強の盾」です。
sudo sed -i '/exit 0/d' /etc/rc.local
cat << 'EOF' | sudo tee -a /etc/rc.local
# Wi-Fi Recovery Logic
if [ -f /etc/wpa_supplicant/wpa_supplicant_backup.conf ]; then
    cp /etc/wpa_supplicant/wpa_supplicant_backup.conf /etc/wpa_supplicant/wpa_supplicant.conf
fi
sleep 5
/sbin/ifconfig wlan0 up
/sbin/ifup wlan0
exit 0
EOF

# ---------------------------------------------------------
# 6. 設定の反映と終了
# ---------------------------------------------------------
sudo chmod +x /etc/rc.local
rpi-ro

echo "=========================================="
echo "      Settings Applied! Rebooting...      "
echo "=========================================="
sleep 2
sudo reboot

【この1行上まで】

この一度実行すれば設定が有効になるスクリプトは、Geminiの共有用チャットからコピーやダウンロードもできるようにしてあるので、ご参考ください。 リンク先のGeminiのチャットですが、共有するために一度貼り付けているので、同じような内容が2度続けて表示されていますが、半分から後ろの部分をお読みいただければと思います。

2026年4月24日金曜日

CQを出した後に程なくカーチャンクがあった。これは応答なのか?

というテーマです。

若いころと違って、のべつ幕無しにしゃべっているとげっそり疲れるので、最近は電波を出すよりも聴いていることが多いのですが、それでもたまにCQを出すことがあります。

関東地方に限らず、あちこちに技術的研究がエスカレートした個人(ほめてます)や地域単位でSFR「DMRデジピーター」の開設があり、少しずつ電波を出す人が増えてきていると感じています。今の段階では、アナログのモードとは違って極端に知性を感じない人はいないので、快適にこの趣味を満喫できます。


SFRでCQを出してみて、それに対する応答がなく…まあ、まだまだ空いているので、聴いている人は少ないし、仮に聴いていてもすぐに応答できない場合もあるでしょうから、応答なくその場の一連の送信は終了という例が多いのですが、

CQを出して受信状態に入って、少しするとカーチャンクが入るということがあります。親しい友人であれば、これは声を出す前にとりあえずPTTで反応したんだろうなということで、ディスプレイに表示されたその友人のコールサインを呼んで(捕まえてw)おしゃべりが始まるわけですが、そうでない、初めて目にするコールサインの場合があるんですね。以下はこの場合の話です。


このモードやそのSFRをにぎやかにしたい、積極的にその場を活性化しようという空気の中にいる場合なら、少しだけ待ってから、やさしくその局を呼ぶということもあるのかなあと思うのですが、少し違和感があります。

DMR IDをちゃんと無線機に設定してカーチャンクをすると、それを受信している無線機にはDMR IDや、デジタルコンタクトリストで突合されたコールサインや名前などの情報が表示されます。表示することが前提なんだから呼んでいるのと同じだよ、という意見もあるかもしれません。このあたりの一般的な考え方ってどんな感じなんでしょうね。

それまで話をしたことのない人のCQに対してカーチャンクで反応をみてみる人がいるとして、これ、アナログのモードだったりすると、誰かがCQを出した後に、瞬間的な無変調が出るのと同じやつです。メインチャンネルやレピータでたまにあるやつですよね。これ、呼ばれてるんじゃなさそうだけど、自分のCQに対する反応のひとつで、人恋しさに短いキャリアを出すものの、積極的にCQに応答するものでもないやつで、客観的にはイタズラに見えるやつです。

自分のCQの後、程なく初めて見るコールサインのカーチャンクがあるとして、ディスプレイに表示されたコールサインをすかさず呼ぶことが、ひょっとしたらカーチャンクをした人にとって意地悪に感じる(悪気なくカーチャンクしただけで、その事実は忘れてほしいので放っておいてほしい?)こともあるのかな、なんて思います。 また、本当に呼んでくるのであれば、カーチャンクに続いて声を出して呼びかけてくると思うんですよね。

CQを出した後のほどないうちのカーチャンク、しかも、知らない人からのカーチャンクに対してどう反応するのが正解なんでしょう。私の場合は、DMRとて単に搬送波に重畳された符号の交換ではなく、仲立ちが音声のモードなんだから、応答であればちゃんと声を出すべきと考えているので、冒頭に書いた友人を捕まえておしゃべりというシチュエーション以外では、応答しないのが正解なんだろうなと思って、黙って待機します。


それはそれとして、送信テストのための純然たるカーチャンクの場合もあると思うんですよね。「自分の無線機がちゃんと設定されていて、SFRやトークグループに接続できているかのテスト」をしたくてカーチャンクをするというのはよくあることです。

誰かがそのSFRで喋っているのを聴いて、その場において自分の電波がSFRに届いているのか確認したくての、空気を読まないカーチャンクというのもあると思います。アナログの無線機と違って設定項目が多いですから、どこのSFRでもカーチャンク自体を否定する例って無いんじゃないですかね。でも、それはそれ、これはこれじゃないかなあと。

 

細かいことをグチグチと書きましたが、要は、呼んでくるなら、わかりやすく声を出して呼んでねということでした。お粗末。 

2026年2月26日木曜日

TGIFトークグループリストについて

これまでホットスポット経由でその先にあるSFRにアクセスするために、カーチャンクやインターネットで検索して、Zone「VoIP」用にTGIFトークグループリストを作って、せっかく作ったのだからということで、AT-D168UVのDigital→「Contact/Talk Groups」にあるトークグループリストを公開していたのですが、こちらのblogを通じてのトークグループリスト単独の公開は終了することにしました。

 

「TGIFトークグループリスト」については、これから先は、FaceBookの公開グループ「DMR OpenSource Japan でファイルを共有して、気づいた方が更新していくという形式にゆだねようと思います。 

今後、公開グループで共有されていくファイルは「DMRデジピーターリストに載って」いて、かつ「SFR設置者自らがTGIFトークグループに接続していることを開示している」ものになります。


それはそれとして、AT-D168UVのコードプラグの公開はもう少し続けようと思います。ただし、こちらのコードプラグに含まれるTGIFトークグループリストの内容は、「実験的にSFRを開設してTGIFトークグループに接続している」ものも含まれる(ただし、すべてではありません)ので、公開グループのものと中身に違いが生じる可能性があります。

コードプラグに含まれるTGIFトークグループリストですが、ここまで公開してきたTalkGroups.csvの形式で見てみたい場合は、コードプラグをダウンロードして、AT-D168UVのCPSで開いて、上部メニューのTool→Export→ダイヤログが表示されたらTalk Groupsボタン→ファイル名を付けて、ダイヤログ下側のExportボタンを押して保存してください。それをExcelやテキストエディタで開いてみてください。それが今まで公開してきたTalkGroups.csvの形式のファイルです。

2026年2月15日日曜日

ホットスポットのRasp Piを少しグレードアップ。WPSDを試してPi-Starに戻す。

我が家のホットスポットの1号機と2号機は玉石混交モールから通販で買ったもので、マザーボードにRaspberry Pi Zeroが使われています。Pi Zeroに挿入されているSDHCカードには予めPi-Starがインストールされていて、Wi-Fiのコンフィグレーションファイルを入れるか、LANケーブルをMicroUSBに変換するコネクタを付けて電源を入れたら使える状態になっています。その上にMMDVMの基板が載っていて、ケースに入っていて、6000-7000円くらいで購入できるお手軽なものです。

これまでAT-D168UVで使う限りは、キャリブレーション(MMDVMの送受信周波数を無線機と同じくすべく可変する機能)をシビアに取らなくても、あっさりとVoIP経由でTGIFトークグループでQSOできていました。

H1では、頭切れやビット欠けによる異音が頻発したことについて、Facebookのユーザグループで質問をしてみたところ、キャリブレーションが取れていないのでは?という示唆があって、H1向けにAT-D168UVの最良点から350kHzズレた点に取りなおしてやっていたのですが、目立った改善はありません。

OMとのやりとりの中で、これまで試していなかったホットスポットのサーバプログラム(っていうのかな)をPi-Star以外のものに変えて試してみようと考え始めました。

今はプレインストールされたPi-Starを最新の状態に更新しつつ使っています。これ以外にも無償で入手できるものにWPSDがあります。これを使ってみようと、うちのホットスポットにインストールをしてみたのですが、動きませんw

SDHCカードが壊れたか、ネットワーク接続のプロセスにおかしいところがあるのか、またはホットスポットのどちらかの基板が壊れたかと、けっこうな時間動かなくて悩んでいたのですが、基板のLEDの点灯の様子をGeminiに質問したら

〇「Piの緑LEDは点灯したまま動かず、MMDVMはゆっくりと点滅を繰り返す」その状態はそもそもRaspberry Piが動いていない

〇そもそもPi Zeroは32ビット動作

〇現在公開されているWPSDは64ビット版だけなので、それを入れても動くわけがない

〇Pi Zeroを使いたいならPi-Starしかない。WPSDを使いたくて、かつ、同じ大きさの基板が良ければPi Zero 2に交換するしかない

とのご指導がありました。

そりゃいくらやっても動かないわけだ、ということで、ホットスポット2号機はPi-Starに戻しました。この際なので、1号機2号機ともにPi Zero 2にしちゃえということで、秋月に発注してみました。

玉石混交モールで買った我が家のホットスポットですが、Pi-Starだけを試すならそれでも良いんだけど、その先いろいろ試すならバラでもっと良いPiを買っておいたほうが無難…ってことは後からわかるんですよね。でも、目先安いほうが良いので手を出すわけですが。MMDVMの基板だけ欲しくても意外と高いので、正解ではあるんですが。 

※改めて玉石混交モールを覗いてみると、Raspberry Piの基板を除く、MMDVMとケースとアンテナがセットになっているものが安価に出ていますね。今ならそっちを選ぶんだよなあ。Piの基板はスイッチサイエンスや秋月など、国内販売店から買えますからね。  

ということで、2営業日後にPi Zero 2が届いたので、早速Pi Zero無印からZero 2に基板を入れ替えて、WPSDを試してみました。

Pi-Starとインストールというかビルドまでの作法が少し違うので戸惑いましたが、SDHCカードにダウンロードしてきたイメージを移して起動すると、Pi Zero 2が無線LANのアクセスポイントになるので、iPhoneのWi-Fi設定で「WPSD-config」を選んで接続します。ホテルのWi-Fiに入るときのようなブラウザの立ち上がり方をしてくるので、その先は設定を見つけて、自宅無線LAN網に入れるという手順が最初に必要です。

管理画面はPi-Starよりデザインがおしゃれですが、Pi Zero 2には重たいサーバプログラムのようで、Pi Zero無印でPi-Starを動かしていたときよりももっさりとした動きです。アップデートをして、落ち着いた翌朝に試すことにしました。

翌朝になりTGIF31665を聴いてみるも、Pi Zero無印で動かしていたPi-StarでVoIP接続していたときと違いを感じません。

〇受信開始時に頭切れする

〇信号受信時にしきい値を下回ると音声が途切れたり「ブー」とか「ベー」とか異音がすることの頻度はZero無印にPi-Starのときと変わらない印象

と、相変わらずです。

早々にWPSDはあきらめて、Zero 2でPi-Starを動かしてみることにします。こっちのインストールは慣れているので楽です。すんなりとビルドが終わって起動してきますが、すんなりという言葉が出てくるくらい、Zero無印のときと違います。やはり速いですね。

再び受信テストです。時差の関係でTGIF31665が静かになっちゃったので、新たに知ったTGIF777でテストをします。

TGIF777とは:現在アクティブなTGIFトークグループを任意に聴かせてくれるトークグループID。777を選ぶと、そこには実際にトークグループがあるのではなく、喋っているトークグループの内容を適当に選んで聴かせてくれます。聴かせてくれる内容は制御されているようで、別の無線機から聴いても同じトークグループ、人だったりします。これなら複数の無線機での同時受信テストに使えますね。

TGIF777を聴く方法:
〇CPSでTalk GroupリストにTGIF777を加える
〇CPSで受信用コンタクトはNoneで送信用で読んでもOK、別途777でガチガチに作成してもよい
〇CPSで新規にチャンネルを作って、それらコンタクトを指定する。周波数はホットスポット用
〇【重要】Digital MonitorをONにする。TS1と2両方聴けるように。Digital Monitorはメニューの浅い階層でON/OFFできるので、PFキーに割り当てるほどではないと思う。めんどくさかったら常時ONでも不都合はないかも
CPSのチャンネル設定の中でこれのON/OFFの設定ができれば良いのですが、D168UVもH1も、メニューからON/OFFするしかないです。

ということで、両機の聴き比べ再開です。

ホットスポット1号機2号機ともに、Pi Zero2にPi-Starで、AT-D168UVとH1で同じトークグループをそれぞれ聴き始めます。キャリブレーションは1号機はAT-D168UVに、2号機はH1に合わせて調整しました。

結果ですが、基板をPi Zero無印からZero 2にしてホットスポットの処理速度をあげたせいなのか、

〇H1の頭切れ(依然としてある)
〇H1の一定しきい値以下でデコード不可(もうちょっと粘ってほしい)
であるのは変わらないんですが、デコードできずに異音が出る頻度は下がったように感じます。H1でダメなときはAT-D168UVでもダメというときが増えたようにも感じます。H1だけダメというときも相変わらずあります。

比較内容を数値化できないので「感じ」ばかりですが、Piの基板交換で処理速度を上げた効果はありそうです。

H1は、短時間で複数の局の入れ替わり立ち代わりの受信を繰り返すと、直前の局のデジタルコンタクトリスト引用情報が表示され続けてしまう現象があります。今回テストに使ったTGIF777は少し特殊な設定のようで、AT-D168UVでもDroidStarでも、受信し始めたグループで最初に送信した人の情報が表示され続けます。なので、画面をみたときに、この点も症状改善ならずと思っていましたが、同時に他機種でも出ているので、TGIF側の設定ということで納得しました。

ちゃんとテストするならBrandMesiter91でもやるべきなんでしょうね。Pi-Starに登録できるDMRリフレクタは一つだけなので、TGIFの設定に代わってBMの設定をしないといけないのと、VoIP接続はTGIFトークグループばかりなので、テスト以外では使いもしないBMの設定は面倒ということで、今回は省略しています。  

2026年2月6日金曜日

AT-D168UV(その16、チャンネルからTalk Groupを選んで使う方法)

前のエントリーでManual Dialの機能を理解していないまま本エントリーを書いています。そのあたり、ちょっと差し引いてごらんください。おおよそのみなさんはご興味のない内容だと思います。はい。 

このエントリーもいまひとつ勢いで書いたものの、読み直すとよくわからないものになっていました。主題としては、 

今はVoIPのZoneにトークグループごとに作っているチャンネルをロータリーエンコーダを回して選局しているのを、

チャンネルは一つしか使わないようにして、自分ですでにリスト化したトークグループのリストから、都度、任意にトークグループを選べるようにしたらどうか

というところの試行錯誤です。

冗長になりますが、もう一度かみ砕いて説明します。

私の好みでは、操作をするにしても、いちいち設定をしないと目的(TGIFトークグループにに繋がっているSFRでおしゃべりをすること)を達成できないのは面倒なので、予めそのSFRの数だけチャンネルを作って、ホットスポット経由で接続してカーチャンクさえすればすぐにCQを出せるのが良いという考え方でこれまでコードプラグを作ってきたのですが、ちょっと視点を変えて、チャンネルはバラバラたくさん作らずに、トークグループの設定だけを都度変更してみたらどうだろうか、ということです。そういう趣旨でこのエントリーを書きました。下でも同じことを言っていますが、そういうことです。

この色で書いているのは訂正と後日コメントです。(2026/5/14)


前エントリーを書いた時点では、Manual Dialの機能を理解できていなかったので、この趣旨では使えなそうというこで、次の手段として、臨機応変に接続先のトークグループを変更するには、予めCPSで設定したTG List(CPSでは「Contact/Talk Groups」※1)から選ぶのが無難だろうと考えました。

 (※1…なんで同じ項目なのにあちこちで名前が変わるんだろうな…これH1だともっとアレなんだよな…)

というか、本エントリーの書き出しではこうは書きましたが、本当は実はManual Dialの話より、ホットキーの使い方などを考えていたときの思いつきはこっちが先だったんです。

完全手入力ならManual Dialなんだろうけど(この時点ではよくわかっていない)今はVoIPのZoneにトークグループごとに作っているチャンネルをロータリーエンコーダを回して選局しているところを、チャンネルは一つしか使わないようにして、自分ですでにリスト化したトークグループのリストから任意にトークグループを選べるようにしたらどうかと。

ホットキーを使うのも良いのですが、キー一つ(本当は緑色の[メニュー]長押し+テンキーのいずれか)で切り替えるにしても、その設定内容を暗記すればよいけれど、設定がいちいち見えないのでちょっと不安、でも、リストから選べば安心、という発想です。

で、前エントリーの話で挙げた、一つのチャンネルから設定するという話に戻ります。

  • 周波数は「TGIFに接続しているホットスポット1号機」に設定している438.01MHz
  • TG1、TS1、CC1の中立的な設定
  • チャンネル名称はそれっぽく「Manual 438.01」

このチャンネルはそのままに、話したい、ワッチしたいトークグループへの切り替え方法を書きます。

スタートはここから。上の条件で作ったチャンネルを上側のバンドで表示しています。チャンネルを表示して待ち受けをしている状態から赤い[戻る]ボタンを1回押します

そうすると、トークグループのリストが表示されます。↓にスクロールして、接続したい局を緑ボタンで選びます。ホットキーを使う場合には、どの局が何番だっけと設定を暗記する必要がありますが、ここではリストから選ぶので脳内メモリ不足でも安心です。

次に「3 Select」を選んで、緑ボタンで[Select]。


ContactがSelectされたと表示されます。この後は一番上の待ち受けの画面に戻ります。そこで送信すると送信中は送信に使っているコンタクト(自分でTalk Groupのリストから選んだトークグループの情報。個別のTalk Groupのレコードを「コンタクト」というんですね。)が表示されます。

この方法だと、Manual Dialのように短時間で設定がクリアされることもなく、前回の設定がそのまま残っています。前回の設定を思い出せない場合には、改めて「チャンネルを表示して待ち受けをしている状態から赤い[戻る]ボタンを1回押します。」からやりなおせば確実です。


さて、今のトークグループごとにチャンネルを作るのと、このように一つのチャンネルを使いまわすのとどちらが良いでしょうね。好みなんでしょうけれど。【好みは都度設定の少ない、トークグループごとにチャンネルを作ってZoneにまとめる今の方法ですけどね。】

 

VoIPというか、ホットスポット経由での接続の場合、SFR(=デジピータ)を438MHz台を選局するがごとく、次々と切り替える度にそのままワッチできるわけではなく、トークグループごとに接続操作(そのトークグループで一度カーチャンク)しないとトークグループの内容が聴こえないので、チャンネルを作って並べるメリットはあまりないように感じます。操作ミスを防止したいという観点なら、トークグループごとにチャンネルを作るのが最善ですね。 【操作ミス防止大事です。やっぱりチャンネルをたくさんつくって並べましょう。】

【更新】AT-D168UV(その15、Manual Dialの使い方)

更新版まえがき(2026/5/14)

当初、Manual Dialという機能を理解していないままこのエントリーを書いたのですが、どうやら、このManual Dialという機能は、「他のデジタルやアナログ機などのトランシーバで、送信中にDTMFでコード入力をして、その周波数で接続しているノードなどからその先の別のノードへの接続や切断操作に使うことと同じ」なのかもしれないと考えを改めました。

というのは、最近SFR-Meshという考え方のDMRリフレクタ(の一種なんでしょうね)が始まって、入り口と出口は最寄りのSFR(デジピータ)で、その先は接続操作によってネット経由で繋がっている別のSFRと接続しておしゃべりをする、ということが始まっていて、そのマニュアルを読んでいると、Manual Dial機能を使って接続や切断操作をしていることが書いてあるからです。まだちゃんと読んでいませんが、これまでは、漫然と、Wiresやエコーリンクみたいに、近隣のSFRに接続して、送信中にDTMFをピポパしてやるのだと思っていたのですが、ちょっと違うことを理解しました。

最寄りSFRから、その先のSFR-Meshなどのリフレクタへの接続や切断の操作をするときに、一時的にManual Dial機能を使ってコマンドを入れる、ということなんだと思います。 

その観点から、一度書いた与太話を校正しながら内容を更新しようと思います。以下、原文です。【】で囲んだ部分や消し線は校正して内容が変わったものとして読んでください

------

Manual Dialという項目がAT-D168UVのメニューにあって、見かける度に「これはきっと予めCPSなどで設定したものではなくて、思いついたタイミングでその場でDMR IDと通信できるように設定する方法」なんだろうなと思っていました。

【そのようにできなくもないのですが、原文の方法だとけっこう窮屈で意図しない操作の結果になります。更新版まえがきのとおり、DMRでの、目の前に見えるSFRから、見えないその先への接続操作の機能のようです。】 

やりかたを書いてみます。

大前提として、他のチャンネルの設定が変わるのは困るので、プレーンなVoIP用のチャンネルを一つつくりました。【これは実験にもなっていないので、次回更新時にVoIPのZoneから削除します。】 

  • 周波数は「もともとTGIFに接続しているホットスポット1号機」に設定している438.01MHz
  • TG1、TS1、CC1の中立的な設定
  • チャンネル名称はそれっぽく「Manual 438.01」
  • 【ここでは438.01のTG1TS1CC1でチャンネルを作っていますが、実際の運用の際にはシンプレックス用のSFRのZoneから(例えばこちらの近隣では、川崎中原区のSFRの周波数の438.53がSFR-Meshに参加しています。)、Manual Dialを使おうとするSFRの周波数を選べばよいと思います。SFR-Meshの接続SFRのリストが公開されていますね。チャンネルの呼称はデジピータリストに準じているようです。】 

【以下は凡例として読んでください。Manual Dialを使う際の挙動も書いてあります。】 

上側のバンドで表示しているのがそのチャンネルです。VoIPのZoneに入れました。このプレーンなチャンネルでManual Dialを使ってみます。 チャンネルを表示して待ち受けをしている状態から赤い[戻る]ボタンを2回押します。そうすると、項目:Talk Groupのメニューが表示されます。

項目:Talk Groupは緑の[メニュー]ボタンを一度押して、上下にスクロールすると表示される、メニューの第一階層にあります。AT-D168UVはメニューの選択のためのスクロールを、ロータリーエンコーダを使ったりテンキーの数字ボタンを押せない機種なので、[戻る]を2回押したほうが早いです。

で、「3 Manual Dial」を選んで緑ボタンで「Select」です。

そうすると、Private IDを入力する画面になります。個人のDMR IDを入力して送信すれば、相手が同じDMRリフレクタ(例えばTGIF、例えばBrandMeisterなど)に接続中であれば、相手の無線機に反応があるのでしょう。詳しくはわかりませんが、そんなイメージなんでしょうね。

今回はPrivate IDあての通信ではなく、トークグループあてなので、ここでテンキーの[#]を一度押します。

そうすると、このようにGroup IDを入力する画面になり、トークグループのIDを入れられます。ここで44050を入れて、そのまま送信するとTGIF44050に接続できます。438.59MHzの神奈川区のSFR:デジピータから自分の声が戻ってくるはずです。 

【この例では、TGIFに接続済の自分のホットスポット(比較しての例示では、中原区のSFRに相当します。)から44050(その先のSFR-Meshに参加しているネットワークの先の見えないSFRに相当します。)に接続していますが、実際にはSFR-Meshへの接続操作により、接続されているSFRのリストのTalkGroupの番号を入れることになります。】 

送信後は一番上の待ち受け状態の画面になります。ところが、このManual Dialの機能にはネックがあって、送信後に待機時間がある程度あると、Group ID(Private IDでも同じです)に入力した内容がクリアされて、その前に接続していたGroup IDなりに接続先が変わります。

  1. Manual DialのGroup IDで(例)44050を入れて送信【実際には44050ではなく、接続されているSFRのリストにある番号を入れる】
  2. 送信を終えて(または相手の信号を受信してから)、無操作時間が始まる。感覚的には30秒くらい経過(もっと短いかも)
  3. Manual Dialの内容がクリアされて、無線機はその前に接続していたGroup IDに設定が変わる。【Zone「SFRchs」で438.53を選んでいる場合は、TG1のTS1のCC1の中原区のSFRにアクセスする状態、Zoneに設定しているチャンネルの設定に戻る。】(Manual Dial操作を行う前に電源を一度落としても、その前に接続していたIDを記憶しているようで、ちゃんとその前に接続したIDに設定が変わるようです【これ、あたりまえの挙動ですね。Manual Dialは一時的な操作なので、時間が経過すれば元々のチャンネルの設定に戻るだけです。】) 
  4. クリアされた後に送信すると、その前に接続していたGroup IDで送信することになり、恥ずかしい思いをする。この恥ずかしい思いをするパターンの送信中は、その前に送信したときのTalk Groupのリストの内容、「コンタクト」が表示されて、違うトークグループで喋っていることに気づきます 【SFR-Meshの接続マニュアルを読むと、一定時間が経過して無線機のManual Dial操作が終わって、元々のチャンネル設定(TG1TS1CC1)に戻っても、SFR-Mesh内の接続先とはタイムアウトするか、明示的に切断操作をするまでは繋がったままとのことです。】

のでご注意ください。 

このへん、Geminiに聞いてみたらこんな答えでした。ある程度汎用的な回答なので、デフォルトのIDが何を指すか明確ではないですが、クリアされた後にはその前に使ったTalk Groupのリストのいずれか一つが選ばれているんだろうと想像しています。

お粗末様でした。
 

2026年2月5日木曜日

AT-D168UV(その14、PFキーの使い方とZoneとVFOモードについて、そしてホットキー)

今は、アナログFMでシンプレックス運用をするときはVFOモードで、DMRで使うときはZoneから出たい周波数群を選んで使う前提でコードプラグを作っています。

AT-D168UVで初めてDMRとFMに出られるトランシーバを触ったので、こういうものかと思って使っていたのですが、その後H1が手元に来て比較してみると、開発時期やメーカーの思想の違いもあるのでしょうけれど、無線機を触ったときの操作性ではH1が優れている(※1)と感じました。※1:無線機の送受信の性能という意味ではありません。 

H1の場合、機能を割り当てられるキー(AT-D168UVはPF1とPF2だけです)がSK1とSK2に加え、本体上面に本来緊急用として使うオレンジ色のボタンがあり、このほか、本体正面のキーに機能が割り当てててあって、

〇赤い[Exit] ボタンは、長押しするとVFOモードとZoneの切り替え

〇[*]キーは、長押しするとキーロック(これは使っていない)、短押しでA/Bバンドの切り替え

〇[#]キーは、VFOモードのときに長押しするとデジタルとアナログの切り替え、短押しでシングルバンドとデュアルバンド表示の切り替え

これらの機能はSK1などに割り当てるのが不要です。 試行錯誤の中で触って慣れてくると、この割り当てがありがたく感じてきます。

 

AT-D168UVについても、VFOモードのときにデジタルとアナログの切り替えが簡単なら、現在4つも作っている「DMRのシンプレックス用のVFOイメージで使えるZone」と、それらにぶら下がっている560チャンネルを削減できます。

 

【現状】今のOptional Settings のKey Functionはこんな感じです。

〇PF1の短押し「ポチ」はA/Bバンドの切り替え、長押し「グーっ」はVFOとZoneの切り替え。長押し操作のときは、スピーカーから「プ」と音がでるので長押しが動作したタイミングがわかります。「プ」の後で指を離すと長押しで設定した機能が有効になることがわかります。

〇PF2の短押し「ポチ」と長押し「グーっ」には両方ともにMonitor、アナログFM時のスケルチオープンです。

〇Zoneの切り替えは↑↓キー(Zone表示時の標準機能)で行います

アナログで弱い信号を聴きたいときには、直感的にPF2を押し続ければスケルチが開くので、良いと思うのですが、反面、少ないPFキーの割り当てをこれでつぶしてしまうので、もったいないなとも思っていました。

 

【考え中】そこで、デジタルとアナログの切り替えを簡単にすることで、Zone5つと560チャンネルの削減を可能とするためのキーボードアサインを考えてみました。

〇PF1の短押し「ポチ」はA/Bバンドの切り替え、長押し「グーっ」はVFOとZoneの切り替え(ここは同じ)

〇PF2の短押し「ポチ」でスケルチレベルの可変、長押し「グーっ」でデジタルとアナログの変更にしてみました。

今までは、スケルチを開けたいときにはPF2キーを「押しっぱなしにする」でしたが、感覚的な操作ではなく少し頭を使うことにして、スケルチレベルを変更したいときにはPF2を「ポチ」と短く押します。「ポチポチ」と押すごとに、スケルチレベルが1→2→3→4→0→1と変わります。スケルチを開きたいときにはすぐに0にしたいのですが、変更できる方向がこの方向だけなので、一度深くしてから0にするという操作になります。変ですけど。

PF2長押し「グーっ」でデジタルとアナログの切り替えです。「グーっ」と押しているときに、「プ」と音がして、指を離すと切り替えが行われます。VFOモードで操作していて、今はアナログのときに、周波数を移ってデジタルで運用したいときに、ここを長押しです。変わる順番は「Digital」→「Ana+Dgi」→「Dgi+Ana」→「Analog」のように変わります。この順番だと、デジタルからアナログに戻すには、3回長押し、「グーっ→プ」×3 をする必要があります。

テンキーでダイレクトに周波数を入力することと合わせて、こうやってデジタルアナログを切り替えることができるなら、素早いQSYはできますし、専用のZoneは不要、560チャンネルも不要になります。

(2026/2/7追記)と、ここまで【考え中】とした内容のコードプラグを試験公開してみます。こちら から。次のタイミングのコードプラグ公開からはこのPFキーの設定になります。また、次のタイミングの公開時に、この試験公開は終了します。

(2026/2/8追記)早くも新たにTGIFに接続しているSFRがあることがわかったので、試験公開は終了し、この考え方のコードプラグを正式公開します。この日付けの更新内容はAT-D168UV(その6、コードプラグとトークグループリスト)を参照してください。 

 

PF1及びPF2キーは、さらに「長押し2」の機能を割り当てられますが、PFキーの使い方を複雑にすると忘れるので、とりあえず今はこれ以上はやめておきます。

PF2長押しで、「長押し1」のデジタルアナログ切り替えをスルーして、そのままFMラジオ起動までできれば良いのですが、試しにやってみたところ、先にPF2長押し1のデジタルアナログ切り替え機能が動いて、そのあとに長押し2でFMラジオが起動するので、実用的ではないです。 長押し1の機能が動いても支障がないような組み合わせなら良いかもしれません。

 

あとはホットキーの活用でしょうかね。ホットキーでFMラジオを呼び出せれば便利なんだけど、ということでやってみたのですが、ホットキーはメニューの浅い階層への呼出までで、むしろ、SMSやグループコール設定の切り替え向きの機能のようです。

私の場合、Talk Groupの切り替えは都度無線機の操作で行うのではなくて、あらかじめTalk Groupごとのチャンネル(VoIPのZoneがこれにあたります)を作って操作ミスを少なくする方法を採っているので、ホットキーで切り替える方法は少し慣れてから考えることにします。

この例では、「メニュー長押しの後に1」で、メニューのRadio Setまでの呼出を設定しています。FMラジオの起動は、この先、[4]Other Func→[13]FM Radio→[2]ONの操作が必要です。いまいちです。AT-D168UVはアマチュアバンド外の感度が悪くないので、FMラジオを簡単に聴けると良いんですけどね。 

もう一つ、 「メニュー長押しの後に2」では、Call Logの画面まで行けるようにしました。その先、Last Callに入れば、ワッチしていた周波数で出てきた人のコールサイン(※2)が表示されます。 ※2:デジタルコンタクトリストが入っていて、DMR IDがマッチした場合だけです。 

ちなみに、画像上側のHot Key1から6は、下側の「Fun Key+いくつ」のメニューボタン長押しで行う設定とは違って、PFキーに割り当てる機能のようです。でも、ここまで書いたようにPFキーは他の機能で使ってしまっているので、ホットキーを割り当てる余地はなさそうです。 

2026年1月30日金曜日

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

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

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

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

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

現在のAilunce公式からダウンロードできるデジタルコンタクトリストは、VKの1局のデータの重複があって、そのままCPSに読ませるとエラーメッセージが出ます。

この不具合、2026年3月31日に検証してみたらVK3の局のレコードの重複は解消していました。すんなりCPSに読み込めます。2バイトコードが含まれているフィールドが化けるのは同じですが、化けるのを気にしなければ問題ありません。  

以下は古い内容です。2バイトコードのフィールドの化けを対策、というか、どうせ読めないのならフィールドを空白にしたくて試行錯誤した内容です。 

このエラーの内容を示す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バイトコードが含まれるレコードでエラーで読み込めない場合もあります。この方法は結果が不安定。は不安定なまま。

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

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

 

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

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

ご注意:2分くらいで30万件ある全世界のデジタルコンタクトリストの無線機への転送が終わる場合には、間違いなくちゃんと転送できていません。面倒ですが、一度見出し行だけのcsvファイルを作って、これをCPSに読ませて、ゼロ件データとして無線機に転送して、無線機のデジタルコンタクトリストを空っぽにしてから、再び30万件の転送をすると、ちゃんと長時間(概ねですが、1%転送するのに1分弱くらい)かけて転送が行われます。 

以上、お粗末様でした。

2026年1月23日金曜日

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

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

----- 

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

2026年3月31日現在、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のデジタルコンタクトリストに関する話は次エントリーに再構成しました。

2026年1月17日土曜日

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

以前よりたまにこの現象に遭遇するのですが、録画することができました。
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の場合は、選局ツマミを回したとき、「画面の表示」と「信号の復調から音声出力まで」のロジックが別になっていて、「信号の復調から音声出力まで」のプロセスが遅いので、このような現象が起きるのではないかと思います。
 
 
※動画が再生可能になるまで、エントリーの更新から時間がかかるようです。見えない場合にはある程度時間が経ってからごらんください。
※どうもさっぱり再生可能になっている気配がないので、こちら でみてみてください。

2026年1月7日水曜日

H1(その7、FM放送を聴いているときのバッテリーの減りが気になる)

最近またあちこちで揺れています。適当な揺れが適当なタイミングで起きて、大きな地震が来ないで済むなら、毎日震度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つから選ぶようにするのが無難かもしれません。 

2026年1月5日月曜日

H1(その6)VoIP経由受信時のアレを、運用でなんとかかわせないか

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以外での用途で使うことになります(実際にはそっち方面でまだ使い込んでいません)