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

2026年2月28日にファイルの更新を行いました。(3/18:「デジピーターリスト」に新たにTGIFトークグループに接続しているSFRが載りましたが、Zone「VoIP」にはすでに含まれています。ですので、3/18付の変更はありません。)

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

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


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

2026年2月26日木曜日

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

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

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


それはそれとして、AT-D168UVのコードプラグの公開はもう少し続けようと思います。ただし、公開グループでメンテナンスされていくファイルと、こちらで公開するコードプラグのZone「VoIP」の内容はイコールではありません。

公開グループで共有されていくファイルは「DMRデジピーターリストに載って」いて、かつ「SFR設置者自らがTGIFトークグループに接続していることを開示している」ものになりますが、こちらで公開するコードプラグの内容は、「実験的にSFRを開設してTGIFトークグループに接続している」ものも含まれる(ただし、すべてではありません)ので、ちょっと差が生じることになります。

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

2026年2月15日日曜日

H1をあきらめない(その10、WPSDを試してPi-Starに戻す。そして【備忘】)

H1をあきらめないというテーマで悪あがきを続けている中での話になります。

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

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

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

 

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

 

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

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

 

【備忘】(2026/2/17 後から思い出して追記しています)

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

  1.  音量調整が極小音量域でできない。絞っていくと無音になる。無音から開けていくと9時くらいで突然音が出る。
  2.  VoIP経由受信時に頭切れが起きがち。直接波ではまだあまり使い込んでいないので未検証。
  3.  VoIP経由受信時に、データの品質が下がると他機種よりデコードできなくなるのが早い。※本エントリーで書いたように、ホットスポットの処理速度を向上すると幾分良くなる「感じ」がする。ただこれ、信号の受信を繰り返していくうちにデコードできない率が上がってきますね。元の木阿弥というほど悪くはなっていない「感じ」ですが、QSOをワッチしていると、時間の経過に伴って悪い方向に戻る「感じ」はあります。
  4.  選局ツマミを動かすと画面だけ選局したチャンネルに、音声は選局前のチャンネルになることがある
  5. A/Bいずれかのバンドで信号受信中にFMラジオをONにすると、受信信号に重なってFMラジオが聴こえる。本来仕様は受信信号優先にすべきなのかな?
  6. チャンネル名称など、無線機に表示するフィールドの数が少ないので、名前の付け方に制約がある。少ないフィールド定義の名称を画面に表示しても、表示領域にはまだまだ余裕があるように見えるので、フィールドを広げてもらえるとうれしい。 
  7. Call LogがDMR IDの数字でつまらないので、Digital Contact List(H1のCPSでは別の名前ですね)とマッチしたDMR IDはコールサインで表示してほしい。欲をいえば、時間とABどっちのバンドから取得したIDかを表示できたらAT-D168UVと同じですね。D168UVは同じIDが何度もアクセスしてきたら最新のものだけをログに残すという仕様になっています。 個人的にはコールサイン表示になってくれるだけでもありがたいです。
  8.  Ailunceリソースセンターから専用デジタルコンタクトリストをダウンロードできるのはとてもうれしい、もう最高。だけど、「VK3C**」1局のデータが重複していて、手作業で削除する必要がある。(削除した後に「UTF8(BOM付き)」で保存する必要があります。そもそもこの文字コードで保存できるテキストエディタ(Windows11のメモ帳はOK)を使わないとダメ。2026/2/16現在状況変わらず。)

 

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

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

2026年2月6日金曜日

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

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回押します。」からやりなおせば確実です。

 

さて、今のトークグループごとにチャンネルを作るのと、このように一つのチャンネルを使いまわすのとどちらが良いでしょうね。好みなんでしょうけれど。

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

AT-D168UV(その15、Manual Dialの使い方(これ、使える機能なのかしら?))

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

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

大前提として、他のチャンネルの設定が変わるのは困るので、プレーンなVoIP用のチャンネルを一つつくりました。 

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

上側のバンドで表示しているのがそのチャンネルです。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:デジピータから自分の声が戻ってくるはずです。 

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

  1. Manual DialのGroup IDで(例)44050を入れて送信
  2. 送信を終えて(または相手の信号を受信してから)、無操作時間が始まる。感覚的には30秒くらい経過(もっと短いかも)
  3. Manual Dialの内容がクリアされて、無線機はその前に接続していたGroup IDに設定が変わる(Manual Dial操作を行う前に電源を一度落としても、その前に接続していたIDを記憶しているようで、ちゃんとその前に接続したIDに設定が変わるようです) 
  4. クリアされた後に送信すると、その前に接続していたGroup IDで送信することになり、恥ずかしい思いをする
  5. この恥ずかしい思いをするパターンの送信中は、その前に送信したときのTalk Groupのリストの内容、「コンタクト」が表示されて、違うトークグループで喋っていることに気づきます 

のでご注意ください。 

このへん、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に読ませるとエラーメッセージが出ます。このエラーの内容を示す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公式からダウンロードすることをお勧めしました。

他にも篤志家の方々がダウンロードを可能にしていますが、ファイルサイズがまちまちというか、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以外での用途で使うことになります(実際にはそっち方面でまだ使い込んでいません)

2025年12月26日金曜日

AT-D168UV、H1(D168UVはその12、H1はその5、ホットスポット経由で接続するチャンネルの表示について)

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

AT-D168UVの場合、今はディスプレイには「U2-01 JS1ZZZ」として、協議会のチャンネルの番号とコールサインを表示して、TGIFのIDは内部で持っているだけ。
H1はチャンネル表示領域が英数で10文字しかないので、コールサインのみにしています。同じくIDは内部で持っているだけです。
 
電波でデジピータにアクセスする場合は、周波数とコールサインを意識するので、それを意識したチャンネル表示にしているんだけど、ホットスポットからアクセスする場合は、コールサインよりもTGIFトークグループのIDを意識するので、そっちのほうが良いのではと常々思うのです。
 
ホットスポット経由の接続のときに、次はどこに行こうかと考えてロータリーエンコーダを回す際に、今の設定ではコールサインが表示されているのですが、どうもピンと来ません。「TGIF44050」とだけ表示するようにしてみましょうか。ほんとは、表示領域の制約がなければ、これに加えて地名くらいは入れたいんですけどね。
 
では、TGIFのIDの表示にするとして、レコードの並び順はどうあるべきかを考えてみます。
今は、エリア昇順の周波数昇順に並べていますが、並びはそのままでTGIFのID表示にすべきなのか、TGIFのIDの昇順に並べ替えるべきなのか、そうしたとして、使いやすくなるのかというところが気になります。
  
そもそもなんですが、ホットスポット経由で行く先のデジピータって限られてますから、かって調べたときのリストを更新しつつ、これをチャンネル化して、一旦はAT-D168UV用のZoneとしてまとめたものの、これをずっと維持していくしないはさておき(誰かが最新リストを作って維持してくれると楽ですよね)、限られた先にしか行かないのなら、行く分だけをつまみ食い的に設定しておけば十分なんですよね。限られているんだから、それがどこのデジピータに繋がっているなんて、頭の中でわかっているわけだし。 

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

2025年12月21日日曜日

H1(その4、VoIP経由受信時のアレの考察・追記)

少し前の話になりますが、首が伸びきったところ(日本語の慣用句で、「なかなか来ないのを待つ」状況を「首を長くして待つ」といいます)でやっと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.

2025年12月17日水曜日

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」と5秒送信して、1秒休んで、再び「1,2,3,4,5」と送信することを繰り返して、それをキャリブレートをとったH1と、キャリブレートの結果350kHz外れたAT-D168UVで聴くということをやってみました。

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

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

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

 

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

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

2025年12月14日日曜日

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がダメになります。

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

2025年12月12日金曜日

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-D168UVは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)にしました。 

2025年12月10日水曜日

AT-D168UV(その11、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の「挿入→図形」で丸で囲んだり吹き出しを入れてます。

AT-D168UV(その10、ホットスポットを持ち出せるようにした。やった!)

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できるのにね。

2025年12月5日金曜日

AT-D168UV(その9、H1を待ちながらAT-D168UVを見直す。)

本エントリーはAT-D168UVをお使いの方がごらんになっているケースが多いと思うのですが、国内ブランドのハンディ機とは違って、細かいところでアレに感じることがあると思います。でも、値段が安いし、こんなもんかな?と同時に感じているでしょうね、私もそうです。

このAT-D168UVですが、数年前に触ったQYTのCB-58(国内では有志の大変な努力があってQYT28として頒布されています)と比べてみると、数年分の進歩を感じました。

その数年分の進歩を感じつつDMRモードの運用を楽しんでいるんですが、ホットスポットを通じてTGIFトークグループで喋る自分の声を、デジピータからの電波でモニタをしてみたいという希望が出てきて、もう一台DMR機を買ってみようかという気になってきました。

で、RetevisAilunce、アイランスというブランドとしても展開しているようです。何の違いなんだろう)のH1という機種を物色してみました。SFR(シングルフレケンシーレピータ)機能が付いていることや、JARD保証リストに載ったことや、あとは2万円以下で買えるのでお財布に優しめというところからです。

本当はモービル機が欲しかったんですが、今のところDMRのモービル機は1機種くらいしか選ぶことがなさそうなので、もうちょっと待ってみようかと。

H1を意を決して注文したものの、なかなか届きません。このSYDという業者はトラッキングデータを載せるのが遅いので、荷物の現在位置を知るのにタイムラグが大きく、じりじりします。

12/5の朝になってみると、昨夜は無かった12/1のデータが入力されて、ようやく佐川のりんくう営業所に荷物があることがわかりましたが、今、佐川急便は荷物急増で届け先によって荷物の受付を中止したり(12/4実施、一日で解除)しているので、ここからまだまだ時間がかかりそうです。国際情勢が原因ではなかったようです。

で、待っているだけではつまらないので、H1のCPSを触ってみることにしました。Ailunce公式からダウンロードして起動してみると、プログラム自体は洗練されている印象があります。AnyToneのそれとは違い、色使いがおしゃれです。

今までさんざ貼ったので、AT-D168UVのCPSはすでに見飽きていると思いますが、実務的です。

 

首尾よく起動できたので、AT-D168UVのコードプラグで積み上げてきた内容をH1に移してみようということで作業を始めてみました。 

無線機本体の設定、例えばPFキーの割り当てなどは実際に無線機を触りながらじゃないとイメージが掴めないので、周波数やトークグループの登録を進めます。

やはりメーカーにより用語に方言がありますね。デジタルコンタクトリストのことをRetevis/Ailunceでは「Local Address Contacts」、AnyToneでいうところの「Contacts/Talk Groups」は 「Priority Contacts」と言っています。

実際にチャンネルをCSVを使ってメモリしていったりZoneを作っていくと、D168UVのほうが項目名称のバイト数が多かったり、Zone一つあたりに登録できるチャンネルの数が多かったりで、扱いが楽だということがわかりました。

何より大きな違いというか、AT-D168UVのほうが良いじゃん!という点は、Zoneの編集のGUIでした。H1の例で上に乗せた画像では、Zoneに加えたいチャンネルを一つ一つクリックしていきます。マウスで選択していくのもなかなかの手間ですが、これノートPCのスクラッチパッドで始めたらなかなかの手ごたえでした。対してAT-D168UVですが、わざと加えたいものを複数選択した状態でキャプチャを取ったのですが、シフトを押しながらクリックすると複数レコードを一度に選択できて、中央の→ボタンを押すと一度にZoneに追加できます。こういうところはきっと蓄積があるんでしょうね。見た目よりも使い勝手だよね、と感じます。

あと、TGIFトークグループ用に設定するチャンネルの名称に使える項目のバイト数が AT-D168UVに比べると少なくて、コールサイン6文字+4文字のみの範囲でどう表現するかを考えることになりました。

無線機本体の設定以外のところはコードプラグ化したので、あとはH1が来るのを待つばかりです。いつ頃着くかな、本来ならとっくに着いているはずですが、あと1週間くらいはみておきましょうか。 

 

余談なんですが、わたくしコードプラグの設定時に、スタートサウンドをOFFにしていて、ダウンロードしたコードプラグをそのままお使いの場合はスイッチオン時に無音で立ち上がってると思うんですけど、AnyTone機のスタートサウンドを聴きたい方は、無線機のメニューから出せるので、お好みで出るようにしてください。

QYT28のとき(たぶんQYT28、CB-58はAnyToneのOEM(または製造委託先が同じ)なんでしょうね。同じ音が出ます。)にスタートサウンドが爆音で出て、しかも止めるすべがなく、スピーカを手でふさいで起動していました。そんな苦い経験から、スタートサウンドは切ってあります。

スタートサウンドの設定変更は、緑ボタン→Settings→Radio Set→Voice FUNC→StartSound→お好みでONの緑ボタン、現状どおりならOFFで赤ボタンです。

2025年11月25日火曜日

先日の訂正に至った経緯や細かいおはなし

今回はほとんどの方が興味のない内容になります。読み飛ばし推奨です。

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

この色は自宅の中 この色はインターネット網 この色は概念的にデジピータ側


自分(AT-D168UV)←→438.01MHz←(ダミーロード)→ホットスポット←

→インターネット網←

→TGIF.networkのトークグループ(例えばTG44050) 

→インターネット網←→デジピータ←→電波で付近の局


という構図で、インターネット経由でTG44050に接続している神奈川区のデジピータでQSOしたりしています。 

実際に運用していると、自分の側では、

自分(AT-D168UV)←→438.01MHz←(ダミーロード)→ホットスポット←

→インターネット網←

→TGIF.networkのトークグループ(例えばTG44050)→インターネット網←

→デジピータ←→電波で付近の局

と、TGIFトークグループまでの行き来を強くイメージします。トークグループまで行ければその先は機械的にデジピータとつながっていて、そこでしゃべるとその先の人と電波でQSOできるという感じです。

 

反対に、デジピータ側からは、

自分(AT-D168UV)←→438.01MHz←(ダミーロード)→ホットスポット←

→インターネット網←

→TGIF.networkのトークグループ(例えばTG44050)←→インターネット網←

→デジピータ←→電波で付近の局

と意識している範囲がこのようになると想像しています。


細かい話になりますが、このときのAT-D168UVは、

「周波数438.01MHz、送信のためのトークグループIDは44050、受信のためのトークグループIDは送信用と共用、200mW出力、使うRadioIDは自分の個人局用のもの」という設定でメモリしたチャンネルに合わせています。 ※タイムスロットの話はややこしくなるので省略します。

438.01はホットスポットとの通信用に設定している周波数です。電波はケーブルから置き換えただけの通信経路です。438.01でホットスポットに届いた信号は、ホットスポットの中でTGIFトークグループをめがけてインターネット網に送信します。そして、インターネット網を通じてtgif.networkのTG44050に届きます。無線機で438.01で送信する際に、送信用のトークグループIDを44050にしているので、私が無線機でしゃべる信号はトークグループ44050側で復号できます。反対にトークグループから出る信号はID44050なので、同じIDで受信設定している私の無線機で復号できます。

インターネットから直接TG44050に接続する手段もあります。PCやスマートフォンで動かすことができるDroidStarです。(このリンクですが、公式ではないのですが、私の場合はここがわかりやすかったので貼っておきます。) 

ここまでが無線機を持った自分と、ホットスポットを通じてインターネット経由でトークグループ(デジピータ)とやりとりするおはなしです。


ここからが本題なのですが、

AT-168UV限定なのか、他のDMR機もそうなのかというところはわからないのですが、TGIFのトークグループに接続する場合、これまで、自分とトークグループの関係は1:多であると思っていたんです。というのは、当初、無線機の設定の際に、Recieve Groups Listに複数のトークグループを入れておいたことから、複数のトークグループでカーチャンクして接続操作をした後は、複数のトークグループの音声が無線機から聴こえていました。

それが当たり前だと思っていたんです。自分からはトークグループは複数同時に接続できるもので、これを一つに限定したいなら、TG4000でカーチャンクして切断操作をすればよいと考えていました。

 

ある日、TG9900の音声テストのトークグループで「あーあー」とやっていたら、突然TG44050のデジピータのIDが聞こえてきました。9990を聴いているのになんで?と驚きました。

後から考えるとなんてことないことなのですが、そのときは、TG44050でカーチャンクして接続した後、そのままTG9990をメモリチャンネルを移った状態です。

そのTG9990のメモリチャンネルは、送信はTG9990に限定しますが、受信は「Recieve Groups Listに複数のトークグループを入れておいた」ものを選んでいるので、当然含まれているTG44050が聴こえてきます。最初、TG44050を通じて神奈川区付近で438.59MHz(けっこう広範囲に飛んでます)から「あーあー」と延々やっていたのかと赤面したのですが、そうではなく、無線機のメモリチャンネルに設定したそのものの動作をしていただけなんですね。わかっていたんですが、こりゃまいったなと思いました。きっといつか間違えるに違いないと。


自分とトークグループの関係は1:多であることは変わりません。設定で実現します。というか実現しちゃってます。

HotSpotをテストしてみようⅠ及びⅡの訂正 で触れた話なのですが、この訂正では細かいところまでは書かずに、とりあえず間違えそうな設定方法は否定しておいたほうが良さそうということで、早足で関係個所に消し線を引いたところなのですが、

これに気付いたきっかけというのは、接続しているトークグループはカーチャンク無しで切り替えができますよ、ということを教えていただいたことでした。(成り行きをちょっと脚色しています。)

キャプチャはホットスポットに使っている社団局のTGIFのSelfCareのページです。ここに現在接続中のトークグループが表示されます。この画像でいうと、「TS2=245」の部分をクリックまたはタップすると、「Change TG」とトークグループのIDを入れるダイヤログが表示され、そこに移りたいトークグループのIDを入れると移ることができます。

ところが、このキャプチャをとったタイミングは2つのトークグループにカーチャンクした後だったので、当然ながら2つリストされているかと思ってました。ところが、後からカーチャンクした日立デジピータに接続しているTG245の分しか表示されていません。


ん?と、見ながらしばらく沈黙しました。

TGIFのFAQでは「TGを移る場合にTG4000は必要?」という質問に対し、「No you don't, you can move to a new Talk Group without doing a 4000. The 4000 talkgroup passes no traffic and is a great landing place to park your radio if you wish to receive nothing. Other than that, the last talkgroup you key up will be where you are 'parked'.」としています。いらないんです。そこまでは以前教えていただいて認識してたのですが、その先をちゃんと読むと、最後に居るトークグループが自分が駐車中の場所だというんです。

つまり、最後にカーチャンクして接続したトークグループと自分が1:1の関係で使うことがTGIFの想定であることを、このキャプチャのSelfCareのページと、このFAQが言っているんだと気づきました。そこで急いで訂正に走ったわけです。


繰り返しますが、送信用のトークグループと受信用のトークグループは同じ設定、自分とトークグループの関係は1:1で使うのがわかりやすいです。メモリチャンネルごとの設定では、送信のトークグループIDは一つのみです。受信については上で言ったように複数同時に聴く設定もできます。でも、複数同時ではなく送信と同じIDのみにしておいたほうが無難でわかりやすいです。

無線機の設計は、仕事で使う際に、センター局からの一斉広報用のトークグループがあって、これはセンターから端末への一方通行か、限られた端末からの返信に限り、端末同士は別のトークグループで交信するといった用途を想定しているんでしょうね。

なので、業務用の無線機で遊んでいるわたくしたちの場合は、アマチュア無線的にトークグループやその先のデジピータへのアクセスに使うなら、無線機の仕様や拡張性はそれとしても、使いやすい方法を見つける必要があるんだなということがわかった一件でありました。

2025年11月24日月曜日

HotSpotをテストしてみようⅠ及びⅡの訂正

少し前に、Xのフォロイーの方に、現在接続中のトークグループをTGIFのSelf Careのページで切り替えられますよ、というアドバイスをいただきました。

現在の私の使用形態は、無線機からホットスポット経由でTGIFネットワークに接続して、デジピータとリンクしているトークグループをワッチして、デジピータに電波でアクセスする人と、TGIFトークグループにアクセスする人を聴けるようにしています。

で、無線機に設定している個人局のTGIFのアカウントのページのSelf Careのページに行っても、現在接続しているTGIFトークグループが表示されていなくて、いつも「None」なんです。変だな、ドネーションでもしないと見えないのかなと思っていたのですが、ホットスポットに設定している社団局のアカウントのSelf Careページをみると、ちゃんと現在接続中のトークグループが表示されているじゃないですか。


ということで、ここまでの考え方に誤りがあることがわかりました。Recieve Group Listの設定方法に誤りがあった(これは使わずに、チャンネルごとの設定では「None」を選ぶのが良いです)んですね。ごめんなさい。

HotSpotをテストしてみよう及びを訂正します。誤り部分は消し線をいれています。 

試行錯誤の日々故の与太話の修正ということでお目こぼしいただければと(拝)