【お知らせ】
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年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でもカーチャンク自体を否定する例って無いんじゃないですかね。でも、それはそれ、これはこれじゃないかなあと。

 

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