XLX047 Reflector メーリングリスト


2022年11月21日をもって、D*STAR Network フォーラムへ統合致しました。


リフレクター接続方法

XLX･･･の数字の部分が全く同じREF･･･リフレクタ、又はXRF･･･リフレクタが現存する場合が有ります。 当XLX047においても、REF047は現実に別途平行して存在しています。従って混乱を避けるため下記2例の指定方法をご使用ください。

# 20190402_ircDDBGateway以降 （推奨）
設定ファイルのxlxEnabled を有効：1 にする
xlxEnabled=1
xlxHostsFileUrl=http://xlxapi.rlx.lu/api.php?do=GetXLXDMRMaster
（コマンドUR:XLX047BL ）
# DCS_Hosts.txt
DCS047   202.171.147.58
             ^ 空白の区切りは［tab］です。
（コマンドUR:DCS047BL ）

当リフレクタのIPアドレスは固定ですので自動更新等が有っても変化しません。

Hosts.txtファイルの保存されている場所は次のとおりです。

# Windowsの場合
C:\Program Files (x86)\ircDDBGateway
C:\Program Files (x86)\MicroWalt Corporation\WinDV
# Linux Debian, Raspbianの場合
/usr/local/etc
2018年版より/usr/share/ircddbgateway に変更されました。

Module D（4004）への接続方法（DMRのみ。D-STARで接続しても音声は聞こえません。）

常に接続する場合

MMDVM.ini 又はPi-Starで次のように設定します。 
[XLX Network]
Enabled=1
Startup=047
File=/usr/local/etc/XLXHosts.txt
Port=62030
Password=passw0rd
Slot=2
TG=6
Base=64000
一時的に繋ぐ場合

1.XLX047に接続します。お使いのソフト等によって方法が異なります。
2.4004にプライベートコールします。
　この時、Code Plugのチャンネルに4004コンタクトと同時にレシーブ・グループとして
　TG 6を設定しておくと、「Linked to XLX047D」の声が聞こえます。
3.TG 6 のチャンネルに切り替えてコールしてください。
　（現在はTG 6でテストしています。変更になる時は掲載します）

TG 64000にプライベートコールするチャンネルを作成しておくと、ここにカーチャンクすることで、接続先がアナウンスされます。 この設定に於いてもプライベート64000のチャンネルにTG 6のレシーブグループの登録が必要です。

xlxd v2.5.3から可能となったG3プロトコル(ICOM Terminal Mode)接続は、同固定アドレスにおいてD-STAR リピータを運用しているため利用できません。


Reflector Modules

ModuleUsageLinking URNotes
AInternational PeersXRF047AL
DCS047AL		 English : Peers にA として掲載されているすべてのリフレクタから声が出ます。詳細に付いては次項をご参照ください。
Bd*SquareXRF047BL
DCS047BL		 Japanese Language : 日本語で気軽に会話してください。他のリフレクタとのリンクは有りません。
d*Square stands for D-STAR Square and pronounciation is the same or shortly 'di: square'.
ディースター･スケア又はディースケアと読みます。どなたでも接続して「CQ」してください。
Cd*SquareXRF047CL
DCS047CL		 各局のご協力でインターリンクを外させて戴きＢモジュール同様に使用できるようにしました。（2018/08/0１）
DDMR OnlyXLX047
4004		 No TransCoding, DMR only
上記Module D （4004 ）への接続方法を参照の上、DMR モードで接続してください。
F-ZNot Available


Peers の仕組み

Peers とはお互いに一対一で接続（これをPeer to Peer と言う）された相手リフレクタを指します。 従いまして、［Peers］ をクリックすると、このリフレクタが接続契約した相手リフレクタの一覧が表示されます。

Peer to Peer 接続をXLXではインターリンク（Interlink）と呼んでいます。下図に於いてリフレクタ（☆）を接続する実線です。



AがBをコールするとお互いインターリンクしているDやEにも声が出ます。しかしBがリンクしているCへはBを通じて聞こえるわけではありません。 次に、Bが応答するとCやEに聞こえます。つまりCにはBの声だけ聞こえ、Eではどちらの声も会話として聞こえますが、声の聞こえる経路が異なります。 このように、自分の周りの第一階層目までの交信となり、相手の声のみ自分を含む相手のリンク先まで聞こえる事になります。

時計が止まる？

常に新しいデータを表示させる為に10 秒ごとに画面をリフレッシュする設定になっていますが、 ［Peers］［Reflectorlist］［D-Star live］［CPU］［Info.］の画面については読みやすくする為にリフレッシュしません。 現在時間を表示する為には［F5］を押してリフレッシュしてください。

現在リフレッシュ間隔はCPU負荷の軽減の為20秒にしています。また、［CPU］［Temp.］に関しては１分間でリフレッシュするように変更しました。

CPU負荷の累積的上昇を解消する

WEBページの編集などを行った後、結果はすぐに反映される為そのままにして置くことが多いと思いますが、 当初数％であった負荷が２０％になり25％になり、終には編集を開始したら５０％となりました。 このような時は、ps -e やhtop（又はtop）等で確認するとapache2が多数起動していることがあります。
$ sudo /etc/init.d/apache2 restart
を実行すると劇的に負荷が落ちます。いずれにしろ，通信に因る負荷の十倍もがapache に因るものであることが分かります。 現在はWEBのリフレッシュ間隔を20秒から10秒（10000）に戻してテスト中です。
$PageOptions['PageRefreshDelay']                     = '20000';                 // Page refresh time in miliseconds

2016年9月10日以降，格段にCPU負荷が下がっている理由は，
  • ルータを工場出荷状態にリセットしフィルタやポートフォワードを一から設定し直したことによる物と思われる。
  • それまではWEB閲覧者一人につき12％程のCPU負荷で有ったのが5～7％位に激減している。

2016年9月12日10時　ピーク55%はxlxd 1.3.7 ==> 1.3.9 へのバージョンアップ時
  • その後徐々に負荷が以前（ルータのリセット前）のように15％（WEB閲覧1名）前後まで上昇

2016年9月22日9時半 xlxd 1.3.9 ==> 1.3.7にダウングレード
  • ダウングレードの理由は更新後、通信時音声の切断があまりに多い（下記バージョン情報参照）ので以前と比較するため
  • この時点からルータリセット直後と同様に数％まで負荷が減少（経過観察）


バージョン情報

2016年9月12日　xlx 1.3.7 ==> 1.3.9
  • 音声パケット21フレーム毎に音声ヘッダーの一部を挿入することができる（推奨?）旨， 標準方式に謳われています。その機能がサポートされたとのことです。
  • 接続デバイス側がその音声ヘッダーを挿入して送ってくれば（デバイス側の対応が必要），その時点で音声が復帰することになり， そのタイミングは21フレームが送信を完了する0.42秒毎と言うことになります。
  • 観察の結果，更新中に音声が途中で途切れたと言われることが非常に多くなりました。

2016年9月22日　xlxd 1.3.9 ==> 1.3.7にダウングレード
  • 上記の理由により，元のバージョンに戻して様子を見ることにしました。
  • 数日の運用状況では，こちらの音声が途切れる報告は戴いておりません。

2016年9月26日　xlxd 1.3.7 ==> 1.3.9
  • ダウンロード，コンパイル，インストールを最初からやり直し，再度最新バージョンとしました。

2016年10月16日 11:17 JST Raspbian 4.4.13-v7 ==> 4.4.21-v7+
  • Raspbianをアップグレードし，再起動しました。

2016年12月15日 Raspbian 4.4.21-v7 ==> 4.4.34-v7+ #930
  • Raspbianをアップグレードし，再起動しました。

2016年12月17日 05:28 JST xlxd 1.3.9 ==> 1.4.0
  • グローバルIPが変動した場合の追従に問題有り。 接続リクエストを送信し続けるためインターリンクでの交信が遮断されます。　今までのバージョンでもこのことが原因であった可能性も出て来ました。今回の多発で顕著になったとも思われます。 対処法として，インターリンク先のエントリーをコメントアウトすると交信には影響が出ません。
  • なお，XLX866との間には別問題が発生。双方がリクエストを送り続けているようなので連絡し解決しましたが，年明けに再発。

2017年1月25日 06:45 JST xlxd 1.4.0 ==> 1.4.1
  • 再起動しました。ダッシュボードは未更新 ==> 15:10 ダッシュボード更新

2017年2月3日 09:05 JST xlxd 1.4.1 ==> 1.4.2 ダッシュボード2.3.3 ==> 2.3.4
  • 再起動しました。

2017年3月31日 Raspbian 4.4.34-v7+ #930 を 4.4.50-v7+ #970 にアップデートしたところ、xlxd 接続後、クライアント側から送信するとすぐにサーバーの受信が切れる現象が発生した。ＯＳのバージョンに起因しているのかも含めて調査中

2017年4月1日　OSに起因する問題ではなく、同モジュールに同一コールサインの2局が接続していると（テストのためそうしていた）起こる現象で、1局又は他の局であれば複数局接続していてもこの現象は起きない。（バグレポート発信済み）

2017年4月7日　表のように一つのゲートウェイに接続された複数のDExtraプロトコルのDSRepeaterが、XLXの同じ一つのモジュールに接続されている時、そのDSRepeaterのネットへの送信が一瞬で遮断されると言う現象です。 
	ircDDBGatewayは一つです。 ( jl3zbs.gw.ircddb.net )
	#Flag	DV Station	Band	Last Heard		Linked for		Protocol　Module	IP
	1	JL3ZBS-D	Dongle	2017.04.07 05:53	0 days 00:41:03 s	DCS	　B	*.*.*.31
	2	JL3ZBS-B	70cm	2017.04.07 05:47	0 days 00:09:25 s	Dextra	　B	*.*.*.31
	3	JL3ZBS-A	23cm	2017.04.07 05:53	0 days 00:04:00 s	Dextra	　B	*.*.*.31

	1.  #1からの（#2と#3）への送信は完璧に#2と#3へ届きます。
	2. （#2又は#3）からその他への送信は一瞬で遮断されます。（ただし、コールサインは表示される）

2017年4月14日 xlxd 1.4.2 ==> 1.4.3
  • 4月1日に発見したバグについてレポートした所、今日xlxd 1.4.3がリリースされました。 残念ながら解消して居らずircDDBGatewayのバグでは無いかとの記述がリリースノートに有りました。 私的見解としてはDextraプロトコルにポート情報が無い事が原因ではと考えています。
  • 対処法として、全てのxlxdへの接続にDCS プロトコルを採用しました。
  • 再起動しました。

2017年5月3日 Jessie 4.4.50-v7+ #970 ==> 4.9.25-v7+ #994
  • アップグレードし、再起動しました。

2017年5月18日 16:30JST #define STREAM_TIMEOUT (0.200) ==> (0.400)
  • 再コンパイル後、アップデートしリスタート: TEST1（Open/Closeの繰り返し）はこれにより解消

2017年5月19日 05:45JST #define STREAM_TIMEOUT (0.400) ==> (1.600)
  • 再コンパイル後、アップデートしリスタート: TEST2（headerを3回待つ）

2017年6月10日 08:45JST Jessie 4.9.25-v7+ #994 ==> 4.9.31-v7+ #1005
  • アップグレードし、再起動しました。

2017年6月22日 05:35JST #define STREAM_TIMEOUT (1.600) ==> (2.600)
  • 再コンパイル後、アップデートしリスタート。

2017年7月12日 13:15JST #define STREAM_TIMEOUT (2.600) ==> (10.000)
  • キャリアの電波不感地帯（山間など）でのアンリンクを最小限にする為に延長。再コンパイル後、アップデートしリスタート。

2017年7月15日 Stretch 4.9.37 -v7+ #1017 アップグレード
  • アップグレードし、再起動しました。

2017年7月25日 06:28JST 原因不明のフリーズ（SSHも入れず）。7/15アップグレード後2回目。
2017年8月 5日 06:27JST 原因不明のフリーズ（SSHも入れず）。7/15アップグレード後3回目。
  • 電源OFFにて復帰、update & upgrade実施ご再起動。

2017年8月5日 10:00JST Jessieで従来XLXとして使用していてStretchにアップグレードした物から、 StretchとしてクリーンインストールしてからXLXなどを新規にインストールしたSDカードに変更
  • アップグレードし、再起動しました。（Stretch 4.9.40-v7+ #1022）

2017年8月26日 09:19JST xlxd v1.4.3/Stretch 4.9.40-v7+ #1022 ==> xlxd v2.0.0/Stretch 4.9.44-v7+ #1029
  • Raspbian 9（Stretch）が正式リリースされたのでアップデート
  • xlxd v2.0.0が正式リリースされたのでアップグレードし、再起動しました。
＝MEMO＝　２０１８年２月、Raspbian 4.9.x から4.14.x へのアップグレードの際、 再起動後apache2が起動しなくなり、さらにその問題を解決しようとしたところbashエラーが発生してログインできなくなりました。 xlxdは稼働していましたのでやむを得ず、4.14.xの新規サーバーを構築した上でリプレースしました。
その際に、本info.も過去のバックアップ（２０１７年８月）以降を消失しました。（再稼働2018.2.21）


2018年3月14日 05:54JST システム・バックアップとRaspbian Stretch 4.14.24-v7+ #1097へアップデート
  • 2月のクラッシュ後取れていなかったバックアップを作成。（イメージバックアップ）
  • すでに4.14.20にてセットアップしていたのでカーネルのアップデートも行いました。
2018年4月1日                DMR専用モジュールEを設置。使用上の注意書きをinfo.htmlに追加

2018年4月2日 09:14JST Stretch 4.14.31-v7+ #1104へアップデート再起動

2018年4月20日 05:00JST ノードの接続が出来ないのに気付き、xlxdのみrestartして復旧
  • 20日午前0時半頃xlxdが原因不明で停止しました。その他の機能（WEB表示MRTGなど）に異常は無くrebootせずrestartで復旧しました。
    ルクセンブルグのマスターサーバのメンテナンス又は一時的ストップによって各リフレクタ側でのリスタートを要する状態に陥ったものと推測します。
2018年5月1日 15:50JST Stretch 4.14.37-v7+ #1111 へアップデート再起動

2018年6月1日 10:43JST Stretch 4.14.44-v7+ #1117 へアップデート再起動

2018年7月5日 09:18JST Stretch 4.14.52-v7+ #1123 へアップデート再起動

2018年8月2日 04:45JST Stretch 4.14.58-v7+ #1130 へアップデート再起動

2018年10月1日 05:33JST Stretch 4.14.73-v7+ #1148 へアップデート再起動
＝MEMO＝　今回のアップデート後、messgesに大量のkernelログ吐き出しが確認されたためPi2で確認したところ、 同様のログが1回確認されたが、Pi3（リフレクタ実機）のように連続することはなかった。（予備microSDでも同様）
従って、決定的なOSのクラッシュではないと判断し、rsyslog.conf にてkernel logging をコメントアウトして使用中（原因究明中）。

2018年11月 6日 20:30JST Stretch 4.14.79-v7+ #1159 へアップデート再起動

2018年12月 4日 10:56JST Stretch 4.14.84-v7+ #1169 へアップデート再起動
  • ダッシュボードをアップデートv 2.4.0
  • グループが複数になったのでフィルターを有効にしました。
2019年 2月24日 05:37JST Stretch 4.19.23-v7+ #1203 へアップデート再起動

2019年 5月 5日 05:50JST Stretch 4.19.37-v7+ #1216 へアップデート再起動

2019年 6月27日 06:00JST Stretch 4.19.55-v7+ #1241 へアップデート再起動

2019年11月 5日 15:20JST Buster 4.19.75-v7+ #1270 へアップデート再起動

2020年 1月 8日 06:40JST xlxd v2.3.4 へアップデート再起動

2020年 2月20日 16:40JST Buster 4.19.97-v7+ #1294 へアップデート再起動

2020年 2月21日 11:40JST xlxd v2.3.5 へアップデート再起動

2020年 4月 8日 05:25JST xlxd v2.4.0 へのバージョンアップとOSのアップデート再起動

2020年 8月 2日 サーバ移設中、予備共にメモリ クラッシュのため、再構築（デフォルト暫定版）

2020年 8月 5日 06:25JST WEBサーバの再構築元どおりに復帰・稼働

2020年11月17日 12:00JST リフレクタ・サーバーOSのアップデートと再起動実施

2021年 1月 7日 06:24JST xlxd v2.4.1 へのバージョンアップのためリスタート実施

2021年 3月 4日 06:12JST Buster 5.10.17-v7+ #1403 へアップデート再起動

2021年11月 9日 16:24JST xlxd v2.5.1 へ、PiOS Buster 5.10.63-v7+ #1459 へアップデート再起動

2021年11月19日 10:24JST xlxd v2.5.2 へアップデートのためxlxdをリスタート

2022年 1月26日 06:10JST Bullseye 5.10.92-v7+ #1514 へアップグレード再起動

2022年 5月12日 16:43JST Bullseye 5.15.32-v7+ #1538 へアップグレード再起動

2022年11月22日 09:36JST Bullseye 5.15.76-v7+ #1597 へアップグレード再起動

2023年 5月23日 11:00JST xlxd v2.5.3へアップグレード Bullseye 6.1.21-v7+ #1642 へアップデート

2024年 2月 4日 09:50JST Bookworm 6.1.21-v7+ #1642 へアップグレード再起動
       ～ 2月 5日 11:05JST その他メインテナンスのため数回再起動しました。
       ～ 2月 7日 Dashboard を v 2.4.2にアップデートし、php 8.2に対応しました。


ハードウェアメンテナンス

2017年1月22日 16:00 JST　ルータ交換
  • Aterm WG300HP に交換。

2018年7月4日 18:00 JST　5V電源交換
  • より電流供給の安定したものに交換した為、一旦シャットダウンしました。