PATHpilotのブログ

145.825をUISS v5.4.4でウォッチしていると時々以下のパケットが受信される。

Fm A55BTN To APTT4 Via WIDE1-1,WIDE2-1 <UI pid=F0 Len=44 >[16:38:10]
GREETINGS FROM INDIA-BHUTAN APRS DIGIPEATER!

Fm A55BTN To APTT4 Via WIDE1-1,WIDE2-1 <UI pid=F0 Len=44 >[19:52:01]
GREETINGS FROM INDIA-BHUTAN APRS DIGIPEATER!

これは一体なんだろう？ってことで調べてみた。

A55BTNってコールサインは何なのか。グーグルってみたらEOS-7のページにたどり着いた。このページによるとEOS-7の別名、つまりコールサインがA55BTNってことだ。で、この衛星を飛ばしている国はインドとブータンだ。

EOS-7の軌道はN2YO.COMでゲットできる。

ISS TrackerによるとDownlinkは145.825MHz 1K2AFSK APRSだが同モードでのUplinkはないようだ。

ということで、ビーコンは受信できるけれど、デジピーターとしての利用はできないってのが結論。

ざんねん。。。

アマチュア無線デジピーターを搭載している衛星SONATE-2についての備忘録。

SONATE-2の事を知ったのは直接波が届く範囲のアマチュア無線局が145.825でパケットを送っていたから。そのパケットがvia DP0SNXになっていた。

DP0SNXとは何か、SatNOGS DBによるとSONATE-2のCallsignということだ。この衛星はニューラルネットワークコンピューターを搭載していて、ビジュアルセンサーと赤外線センサーを使ってデータを取りながら自律的に観測を行っているとの事。

SONATE-2サテライトについてはSONATE-2 Web Pageに詳しくかかれている。

SONATE-2の軌道についてはOrbiting Nowで見ることができる。

SONATE-2のデジビーターの情報はSatelite Frequency Listで見ることができ、以下となっている。

Uplink:145.825
Downlink:  145.880/437.025
Beacon:  145.840
Mode:  1k2AFSK/9k6GMSK,APRS,SSTV,CW  

UISS v5.4.4では1200bps AFSKを送受信している。Satelite Frequency Listをみる限り145.825をUp/Down Linkで使っている衛星は結構ある。

NTT ONU+ホームゲートウエイ一体型ボックスの初期化について備忘録。

このボックスの管理WEBの操作が必要になったがパスワードが不明。最終手段として初期化を行った。

1. 電源を切る（ACアダプターコネクタを本体から抜く）
2. 初期化ボタン（初期化と書かれた小さな穴）にセムクリップ等のピンを挿入しスイッチを押す
3. 初期化ボタンを押したまま電源を入れる（ACアダプターコネクターを本体に差し込む）
4. 本体の初期化インジケーターがオレンジ色に点灯するまで初期化ボタンを押したままにする（10秒以上かかった。気長に待つ）
5. 初期化インジケーターがオレンジ色に点灯したら初期化ボタン穴からピンを抜く

以上で初期化が完了。管理WEBには初期ユーザー名（user）と初期パスワード（user）でログオンが出来る。パスワード変更を求められるが初期パスワードのuserを入力しても受け付けられる。

初期化によって接続設定のユーザー名とパスワードの再設定等が必要になるが、それは仕方ない。。。。

以上

アマチュア無線ISSのパケット通信用（145.825MHz）にモクソン・ターンスタイル（Moxon Turnstile）アンテナを製作したのでその記録。

最終的に出来上がったモクソン・ターンスタイル アンテナ。かっこいいー。

今回製作したモクソン・ターンスタイル アンテナはTHE ARRL HANDBOOK 2017（21.65）に掲載されていたデータを元にしたものだ。以下の構成でアンテナペアを用意した。

HANDBOOKの記載の通りにMatching lineとPhasing lineも製作した。

まずこのMatching lineの意味だけれども、JI0VWLさんのブログを参照させていただいて以下の意味と理解した。

75Ωケーブルに50Ωアンテナを付けた場合、その正規Zは0.67になる。これに1/4λケーブルをつなぐとスミスチャート上で反時計方向に180度0.67は回転するので正規Zは1.5になる。これに特性インピーダンス75Ωを掛けると112.5Ωになる。これを並列につなぐと56.25Ωになる。50Ωぴったりとはいかないけれど、ほぼ50Ωとなり特性インピーダンス50Ωのケーブルで給電できるわけだ。

一般的にダイポールアンテナは75Ωと言われているけれど、このモクソンアンテナは50Ωになるらしい。したがってこの方法で良いらしい。

次にPhasing lineについてだけど、二つのモクソンアンテナの位相を90度ずらすことで指向性が円形になるらしい。言い換えるとアンテナ上で位相が回転するというこのようだ。

モクソンアンテナはリフレクターとペアになっているので上方に輻射され、さらに水平面は円形になる。つまりドーム型の指向性を持つということで衛星通信に向いているのだそうだ。

HANDBOOKではエレメント径を3/16inchで計算されていたので、約5mm径のエレメントを探した。結局加工性も考えて直径5mmのアルミパイプをビバホームで調達した。

問題はちゃんと曲げられるか。試してみたところ、曲げ方によってはクラックが入ってしまうことがわかった。

そこでアルミパイプにガムテープを巻いて、ゆっくりと曲げてみたところ、クラックが入らないで曲げられることがわかったのこの方法で曲げてみた。

アンテナエレメントの次はケーブル製作。50ΩケーブルとしてRG-58A/G、75Ωケーブルとして3C-2Vを調達した。のりしろを考慮して寸法に合わせてケーブルを用意し50Ωケーブルから2本の75Ωケーブルに分岐する部分を半田付け。熱収縮チューブを通したうえで芯線の半田付け。その後熱収縮チューブで被覆。その上にビニールテープを巻き、網線部分の半田付けを行った。

Phasing lineの接続も同様に行った。

給電部分のエレメントはダイソーのタッパー内に構成した。

アルミパイプに1.6ｍｍの銅線（VVF1.6mmの銅線）を入れて圧着した。エレメントはケーブル固定用のプラスチック部品で固定した。Phasing lineはタッパー内でループさせた。これに蓋を被せて防水するので同軸ケーブル端は防水処理はしていない。

組み上げた様子はこんな感じ（それにしても騒々しい部屋だね）。

給電部分のタッパーとリフレクター部分のタッパーは塩ビのパーツを使って固定した。上下エレメント間の間隔保持はセブンイレブンの割りばしにて固定。固定は結束バンドで、後からビニールテープを巻いて補強した。

全体を組み立ててみた様子はこんな感じ。

Rig Expertで特性を計ってみた。とんでもない特性ではなく、とりあえず使えるレベルになっている。

屋根に上げてみた。とりあえずマストへは結束バンドでの仮固定で、大きな作業変更に対応できるようにしておいた。

実機でSWRを計ってみた。1.5ということで、使えるレベルにあると判断。

これで実際にISSからの電波を受信し、実際にパケットを送ってみた。今までの2段GPに比べるとずっといい感じだ。とにかくGPで感じていた輻射角を感じさせない。

そこで常時設置に耐えられるように保持機構を作り直した。

塩ビパイプ接続部分はM5ネジで固定した。

マスト固定用に金具を取り付けた。

全体はこんな感じになった。かなりしっかりした構造になった（と思う）。

もう一度構造のおさらい。

エレメントはホームセンターで売っている電線固定部品（5mmケーブル用）で固定。タッパーにT字塩ビをM5.5のネジで固定。ケーブルがタッパーから抜けないように結束バンドをケーブルに巻き付け。Phasing lineはタッパー内に収容。

リフレクター側のタッパーもT字塩ビにM5.5ネジで固定。

アンテナユニットに先ほど補強した保持機構を取り付けた様子。なかなかかっこいいー。

アンテナ取り付けが完了した様子。

これでISS通信が楽しめる。

めでたし、めでたし。

ECHOLINKのLINKノードがDTMFで9999を受信すると、自動でECHOTESTサーバーに接続する。知らなかったというか、WIRES-XからDTMFで9999が送られてきて（送ってきた局がいる）ECHOLINKがECHOTESTに接続してしまったので驚いた。

実際のECHOLINKのDTMFのドキュメントでもそう書いてある。

Examples

(These examples assume that the default DTMF codes are configured.)

• To connect to node number 9999:

Enter:  9 9 9 9

EchoLink responds with:

"CONNECTING TO CONFERENCE E-C-H-O-T-E-S-T"

followed by

"CONNECTED"

because 9999 is the node number of conference server "*ECHOTEST*".

つまりDefaultではそうなってるみたい。でも、このDefault設定を変える方法が見つからなかった。

一旦接続すると接続したままになってしまう（TIMEOUTはあるのかも）ので要注意だ。

玄関ドアを開ける時に引っかかり感が出てるようになった。ラッチボルトの動きが悪いようで、メンテナンス実施。

ネット検索してみるとLIXILからラッチ箱錠として販売されている。結構大きなユニットだ。このラッチ箱錠を外すにはレバーを外す。レバーの固定ネジはカバーに隠されている。カバーは2つの爪ではめ込まれている。この2つの爪を2本のマイナスドライバーでこじる事で外すことができた。

カバーの爪を外してカバーをスライドしたところ。

カバー固定爪はこんな感じなっている。この2つの爪をマイナスドライバーで広げて外す。

カバーを外すとレバー固定ネジが2本見える。このネジを緩めることでレバーを外すことができる。

レバーを外したところ。レバー取り外しに先立って、ドアが閉まらないようにストッパーを設置した。レバーを外してラッチ箱錠が残っている状態でドアが閉まったら開けられなくなってしまう。

この後、ラッチ箱錠を外す。

ラッチ箱錠の隙間からシリコンスプレーをかける。オイル系の潤滑油は後々ゴミ付着等が発生したりするから避けた。

ラッチ箱錠とレバーを元に戻す。

最後にカバーを戻して作業完了。

メンテナンス後、引っかかり感はなくなって動きはスムーズになった。

友人からWindows11にログオン出来なくなったという救援依頼が来た。

友人曰く、ログオンするときにいつもパスワード”1234”を入力するけれどもパスワードエラーになるということだ。実機のノートパソコンを持ってきてもらって自分でやってみてもその通りだ。パスワードが違うって怒られる。

いろいろ悩んだ。何回か間違ったパスワードを打ち込むとパスワードロックされましたって表示されて、暫く（10分程？）ログオンが禁止されちゃうし。でも、ちょっと待てよ、、、パスワードが4桁数字って変じゃないか？？これって本当はPINなんじゃないのか？？

つまり、PINが無効になっちゃってパスワードを要求してるんだけれど、普段パスワードを使ってないから記憶に無いってパターンじゃないのかなぁ。なぜPINが無効になったかは不明だけれど。

で、いろいろ調べて見て役に立つ情報にめぐりあった。でも、それなりに怖い作業なので、自分なりに解釈して実行してみた。

まずはShiftキーを押しながら再起動を実行する。トラブルシューティングが起動する。詳細オプションに入ってコマンドプロンプトを実行する。但し、機種によっては詳細オプションの中にコマンドプロンプトが出てこない場合があるみたい（別のWindows11マシーンでやってみたらコマンドプロンプトが出なかった。なぜ？？）。

で、コマンドプロンプトでの作業になる。

①　大抵はWindows 11はCドライブに入ってるはず。以下でファイルが見つかるはず。

dir c:\windows\system32\utilman.exe 

②　パスが正しい事を確認してから以下を実行する。まずutilman.exeをcmd.exeで上書きするのでバックアップを取っておく（後で戻すから）。

copy c:\windows\system32\utilman.exe c:\windows\system32\utilman.exe.bak

③　utilman.exeをcmd.exeで上書きする。

copy c:\sindows\system32\cmd.exe c:\windows\system32\utilman.exe　　
上書き確認は勇気を出して「はい」を実行する。

なんでこんな事をするかというと、ログイン画面の右下に表れる人形アイコンをクリックしたときの動作を変えるためのようだ。この人形をクリックすると通常はutilman.exeが実行されるようだけれど、それはコマンドプロンプトをメニューに含んでいないみたい。これをcmd.exeに変えてやる（cmd.exeをutilman.exeにスワップする）とメニューにコマンドプロンプトを含むようになる。つまり、このメニューは動的に設定されるみたいで、utilman.exeが実行できる内容で変化するみたい。見方を変えれば、utilman.exeはcmd.exeのサブセットみたいなもので、cmd.exeの機能を制限したものだと判断できる。この制限を取っ払う作業を上でしたわけだね、きっと。

ちなみに、この後人形アイコンから入るコマンドプロンプトで実行するnet userコマンドは、上記のトラブルシューティングのコマンドプロンプトでは実行できない（エラーになる）。だからコマンドプロンプトの渡り歩きみたいなことをしないといけないのだね。

④　スタートアップ画面が表示されたら人形アイコンをクリックしてコマンドプロンプトを表示して、以下を実行する。

net user "username" password

もちろんusernameは実際に使うユーザー名、passwordも実際に使うパスワード。このコマンドでusernameのパスワードを設定し直すわけだ。実行したらコマンドプロンプト画面を閉じて、ログオン画面で今セットしたパスワードをセットする。なお、このnet userコマンドは現在のパスワードを聞いてくることなしに、新しいパスワードが設定できる。ちょっと（かなり）ヤバいコマンドだ。

じゃじゃーん！でログオンが出来る。

⑤　ログオンができたらutilman.exeを元に戻しておく。元に戻すと人形アイコンをクリックしてもコマンドプロンプトは選択肢には入らなくなる。それ以外にどういう影響があるかは不明。案外もどさなくてもいいのかもね。

copy c:\windows\system32\utilman.exe.bak c:\windows\system32\utilman.exe

⑥　この後、スタートメニュー -> 設定 -> アカウント -> サインインオプション -> PIN でPINを設定する。この時インターネット接続してないとPIN設定が出来なかったけど、そういう物だったっけ？？？でも、一旦PIN設定するとインターネット接続はとくに関係ない感じでPINが使えるけどね。。。

この後再起動するとログイン画面でPIN入力が求められるようになる。更にPIN入力の下にサインインオプションが現れて、パスワードとPINのどちらを使うか選択ができるようになる。

めでたし、めでたし。

しかし、、、、こんなことが出来ちゃまずいんじゃないかなぁ、セキュリティ的に、と思ったりもする。この方法に助けられて言うのもなんだけど。。。。

今から50年近く前に作ったアンプが生家の押し入れから出てきた。恐る恐る電源を入れてみたらちゃんと動いた！！でも（記憶では製作時から）電源投入時に出力端子に大きな直流電流が流れるようで、スピーカーが壊れてしまいそう。で、スピーカー出力のオン・オフをするスイッチを作った。

これが押し入れから出てきたアンプ。

町田のサトー電気で買ってきたケースはこれ。CA-60W、809円。

このボックスにワンタッチ端子とスイッチを取り付ける。まずは端子を取り付ける位置を紙に書いてみる。

これをケースに貼り付ける。

センターポンチで印をつけてからドリルで穴を開ける。

ワンタッチ端子が取り付けられるか確認。ワンタッチ端子は台湾製で132円。それを2個。
 

取り付けに特に問題は内容なので、次に配線をする。ワンタッチ端子の半田付け端子部分の根元は絶縁用に熱収縮チューブを取り付けた。大型トグルスイッチも台湾製で176円。

中身はいたって簡単だけれど、これでスピーカーが保護できる。

早速50年前のアンプの上に乗せて使ってみる。アンプのパワーをオンしてから、3つ数えてこのスイッチをオンにする。アンプ電源を切る時も、まずはこのスイッチをオフにしてからアンプをオフする。

1250円位で作ることができた。コードや圧着端子は手持ちを使用。これで一安心。

ワルボロWYJ型キャブレターのオーバーホールをしたので、ついでにその構造の備忘録。

ワルボロキャブレターは草刈り機とかに使われてる。燃料タンクはエンジンの下側にある。つまり燃料ポンプが装備されているわけだ。そのポンプの駆動源はエンジンの吸入吐出圧力を使っている。

エンジンの吸入吐出圧力はエンジンからキャブレターの矢印部分に与えられる。

この吸入吐出圧力は脈動波としてのキャブレターのダイヤフラムを動かす。３がダイヤフラム室で吸入吐出圧力は矢印部分から入ってくる。

このダイヤフラムの脈動によって3のポンプが動作し、燃料は1から4に向かって流れる。

ダイヤフラムを被せるとこんな感じになる。吸入吐出圧力によって3部分のダイヤフラムが脈動する。ポンプとして動作させるために2と4の部分が逆止弁となって流れ方向を一方通行にしている。

ここに厚みのあるガスケットを被せ反対側のキャブレタ部との隙間によって流路を確保している。

左がポンプ部で右がキャブレタ部。

ポンプ部の反対側このようになっていて真ん中に燃料貯がある。ダイヤフラムポンプによる燃料流は4から燃料貯に流入する。この流入量を4にセットするニードル弁で制御する。ここに入った燃料は5を通してメインジェットから排出される。

ニードル弁、ニードルレバー等はこんな感じになっている。

これを組み込むとこんな感じになる。通常はスプリングによってレバー端が持ち上げられ、ニードルを穴に押し込み燃料流入を止めている。

このレバーを動作させるのがダイヤフラム・メタリングだ。メタリングの真ん中がニードルレバー端を押し上げるとニードルが穴から引っ張り出されて燃料が流れる。

ダイヤフラム・メタリングはこんな感じで取り付けられる。このダイヤフラム・メタリングがレバーを持ち上げるということは、燃料貯の圧力が低くなったということだ。言い換えると、燃料貯から燃料が吸い出されると圧力が低くなってニードルレバーが押され、その結果ニードルが穴から引っ張り出されるという事だ。これにより、メインジェットから燃料が吸い出されると、その分だけ燃料が燃料貯に流入するよう（燃料貯の燃料量が一定になるよう）に、この部分の機構が動くわけだ。

燃料貯の燃料は燃料貯中心に配置されているバルブを通してメインジェットに送られる。キャブレターを流れる空気も脈動するので、メインジェットから空気が入って来るのを防ぐため、このバルブが逆流防止をしている。構造はこうだ。5のバルブの中にはゴム板が入っていて、4本の爪でその動きが制限されている。メインジェット圧が高くなるとこのゴム板がポンプ側に押し付けられて逆流を防ぐ。メインジェットから燃料が吸い出されるときは、このゴム板が浮き上がって燃料が流れるが4本の爪でその高さが抑えられる、と言う仕組みのようだ。

以上のように、燃料貯やダイヤフラムポンプに燃料が充填されていればこのように燃料が流れメインジェットから放出される。この流入経路に燃料を満たすのがプライマリポンプの役目だ。

プライマリポンプの中にもバルブがある。なお8の穴はダイヤフラム・メタリングの燃料貯の反対側の空気呼吸用の穴だ。

このバルブの中心の赤いゴムが逆止弁になっている。この赤いゴムの中心は通常は閉じているプライマリーポンプを押しつぶすことで加圧されると燃料が流出する。プライマリーポンプが元に戻る時には負圧が発生するとこのゴム弁は閉じるのでこの穴を燃料は通らない。

逆止弁の中心は7をとおしてポンプ中心のメタル中心につながり、メタルの外周は6につながっている。プライマリポンプを押しつぶすと圧力によって赤いゴム全体が枠に押し付けられられるので6方向へ燃料が流れるのを阻止するが、元に戻る時には負圧によって赤いゴム全体が枠から外され６を通して燃料が流入する。

6は燃料貯につながっている。7は燃料排出口に繋がっている。

つまり、プライマリポンプに負圧がかかる（つぶした後に元に戻る）時に、ダイヤフラムポンプ経由で燃料タンクから燃料が吸い上げられる。プライマリポンプをつぶすと燃料排出口に燃料が送られる。プライマリポンプの押しつぶしを繰り返せば、燃料タンクから燃料排出口に向けて燃料流を作り、キャブレター全体を燃料で充填することができるわけだ。

ダイヤフラム・メタリングの燃料貯の反対側は空気になっていて、ダイヤフラム・メタリングの動作に合わせて空気が自由に動かないといけない。この為の呼吸穴が8だ。ここがつまるとダイヤフラム・メタリングは窒息状態になるので動きが鈍くなる。

以上をまとめると、プライマリーポンプによってダイヤフラムポンプや燃料貯に燃料を充填したあとは、エンジンの吸入吐出圧力によるダイヤフラムポンプ動作によって燃料が燃料タンクから供給されるキャブレターがワルボロキャブレターなわけだ。

HRI-200を使ったWIRESのノード局をFTM-100で構成した場合の留意点備忘録。

FTM-100のノード局（仮にJA0XYZとする）がWIRESのPC画面の「接続局ID表示」で変な挙動をする。VoIPでルームにWIRES参加している他局（仮にJH0CDEとする）が送信中はJH0CDEがグリーンアイコンで接続局ID表示に表示される。送信が終わればこのグリーンアイコンは消える。しかし、JA0XYZ局が参加している場合、JA0XYZの操作とは無関係にJH0CDE局のグリーンアイコン消滅後に一瞬（1秒未満）JA0XYZ局のグリーンアイコンが表示され消滅する。

VoIPでルームに接続しているJH0CDE局が送信中はJA0XYZ局のFTM-100は設定された周波数で送信状態になっている。つまり、VoIPで送られてきたJH0CDEの音声をJA0XYZはFTM-100で中継しているわけだ。JH0CDEの送信が終わればこのFTM-100は受信状態になる。どうもこの時にスケルチが一瞬開いてしまうような感じだ。

実は類似の減少がEchoLinkとFTM-100との間でも発生していた。詳細はこちらを参照のこと。

FTM-100はDATA SQUELCHを供えている。これはデータ信号送出中のスケルチを制御するものだ。DATA SQUELCH にてTX:ONだとData送出中はスケルチをONにする。TX:OFFだとスケルチ制御をしない。どうやら、TX:ONだとData送出後にスケルチオンからオフになるときに信号が入ってきていないのにスケルチが開いてしまうようだ。

HRI-200はスケルチが開くとPTTをオンにする。入力信号をWIRESに送り出すにはこのスケルチ信号が頼りなので当然なのだけれど、上記不安定状態でもPTTがオンになるようだ。

FTM-100のSETUPメニューから　9. DATA -> 3. DATA SQUELCH -> 2. TX:OFF を設定すると、Data送出時にスケルチ制御をしなくなるので、結果としてこの不安定状態が発生しなくなる。

めでたし、めでたし。

SX-400のメーターランプが点灯しなくなった。そこで交換。

Power SWを入れてもSX-400のメーターランプが点灯しなくなった。調べてみるとSX-400はフィラメントランプを使ってるらしい。なので切れるわけだ。しょうがないので交換、といってもフィラメントランプに再び交換するなんてことはしないでLEDに交換することにした。

まずSX-400のカバーを外す。

カバーを外すとメーターがこんな感じで取り付けられている。メーターはフロントベゼルから飛び出している3つの爪で固定されている。そしてその爪の先端は接着剤で固定されている。接着剤はゴム系っぽい感じで結構柔らかい。

ボンドをカッターナイフとニッパーで取り除いて、一つだけで固定されている外側の爪のを外してメーターを後ろに送り出し、奥側の爪の部分を外すという手順でメーター本体を外した。

メーターが外れるとこんな感じなる。

悩んだのは透明なメーターカバーの取り外し。見た感じ、爪などの固定機構は確認できない。けれどもカバーが外れない。よくよく見たら透明セロハンテープで固定されていた（赤丸部分）。こりゃわからんね。

無事メーターカバーが外れた。

メーター軸の前にはフィラメントランプが半田付けされている。SX-400の外部電源は12V。テスターで確認するとこのランプ両端の電圧は外部電源とほぼ同じ電圧だった（若干低め）。ちなみに向かって左側がプラス。

手持ちの透明LED（白色LED）に1KΩ抵抗を付けてフィラメントランプの代わりにする。LEDアノードに1KΩ抵抗リードを巻き付けた。これを半田付けする。

実際にフィラメントランプの両端にLED＋抵抗を繋いでみて明るさを確認。十分に明るいと判断した。

さてさて、フィラメントランプを取り外す。端子がプラスチックのメーターフレーム差さっている。過熱でプラスチックが変形すると困るので、端子をヒートクリックで保護する。

ソルダーウィックで半田を吸い取ってからランプリード線を外す。

LED＋抵抗をランプの代わりに取り付ける。LEDをメーター軸の上に来るようにした。

LEDを点灯させてみる。結構良い感じ。メーターパネルが半田カスなどの飛散でよごれたので、ブラシで掃除してメーターカバーを取り付ける。メーターカバーのセロハンテープ取り付けはしなかった。フロントベゼルに爪で固定されるので、特にメーターカバーをテープ固定する必要性は感じなかったし。

全体を組み上げて、光具合を確認。なかなかいい。むしろちょっと明るすぎるくらい。

ということでSX-400の切れたフィラメントランプのLEDへの交換作業は無事終了したのであった。めでたし、めでたし。

幾つかあるブログの中で特に「クロール済み - インデックス未登録」の件数が多いブログがある。

なんでだろう？？って思って調べてみた。

幾つかのネット情報によると、どうやらインデックスするに値しないと判断されたようだ。

特に気になっているブログの状況はこんな感じになっている。一旦インデックスる登録されたページも未登録にされているようだ。

全体の85パーセント程度が未登録で、そのほとんどが「クロール済み - インデックス未登録」だ。

つまり、クロールしてページは認識したけれどインデックス登録しなかったってことだ。そしてその数は増えている。

一方、ここのブログの状況はこんな感じになっている。

明らかに差がある。ここのブログもインデックス未登録数の絶対数は大きいけれどおよそ全体の25％程度だ。

これら二つのブログの違いは、ブログスタイルの違いと考察した。前者のブログは写真多様で説明文が少ない。写真や動画で伝える事を意図しているので文章も出来るだけ軽量にしている。一方、後者のこのブログは解説や備忘録を目的としているので文章を充実させたいと思いながら書いている。クローラーが文章内容を解釈しているかは不明（特定単語やその出現頻度はみてる？）だけれど、それなりの重量感をもった文章を書けばインデックス登録される可能性が高くなる印象を持った。

以前からGoogle検索でヒットさせたいページは「しっかり書きましょう」ってアドバイスを頂くことが多いが、ブログのスタイルからもその意味がわかる（ような気がする）。

しかしこれはブログのスタイルの問題なので、まっいいか、って事なんだろうと思うけれど、各ブログ項目はさておきブログのメインページには訪れてもらいたいと思いえば、それなりのメリハリのあるブログ構成作りが必要なんだろうなぁって思う。

Sharp AQUOSをTP-Link Archer AX23Vでインターネット接続した際、ちょっと手間取ったのでその備忘録。

TP-Link Archer AX23Vを現在使っているルーター（NTTホームゲートウエイ XG-100NE）にケーブル接続して、AQUOS 4KTVJ22-2からTP-Link経由でインターネットアクセスする構成にした。

AQUOSからYouTubeやAmazon Primeがアクセスできることを確認したが、どうもネットアクセスが一部おかしい。NHK地上波デジタルのデータ放送で、レーダー拡大[ネット]をクリックしてもタイムアウトとなり、インターネットに接続してないとのエラーメッセージが出た。

ひとつ気になっていたことはTP-Linkのルーターを箱から出してそのまま使っていたこと。出荷状態だとルーターモードになっているんだろうなぁって思いながら、とりあえずそのままでインターネットアクセスできるから「ま、いいか」で使っていた。やはりブリッジモード（アクセスポイントモード）にしないといけないんだろうか。

ということで、マニュアルに従ってTetherというスマホアプリをダウンロードした。

起動するとアカウント登録から始まる。有効なメールアドレスをユーザーIDとする。このメールアドレスにアカウント・アクティベーションリンクが送られてくる。

その後ルーター管理者パスワードを設定してから、インターネット接続タイプの選択になる。DefaultでIPV6が選ばれたいた。ホームゲートウエイはIPV6接続なのでそのように設定した。なのでプロバイダー情報は聞いてこない（IPV6はMACアドレスで管理されているからPPPoEで必要となる接続先設定は不要）。設定が一通り終わると、ルーターは再起動される。この再起動でTP-LinkにWifi接続していたデバイスはそれ以外のWifiアクセスポイントに接続しなおしてしまうので、再起動後にスマホもTP-Linkに再接続する必要がある。

この後スマホからTetherに再ログインする。画面下のメニューからツールを選び、動作モードをクリックする。

動作モードでアクセスポイントモードを選ぶ（下の写真はセットが完了した後に開いた画面）。

これでアクセスポイントモード（ブリッジモード）に変更ができた。

で、早速NHK地上波デジタルのデータ放送からレーダー拡大をクリックすると速攻でレーダー画像が出てきた。

やっぱりルーターにカスケードで接続するルーターはブリッジモードじゃないとダメなのね。

Niftyからドメイン@niftyサービス終了のメールが2月7日に来た。このブログのドメイン pathpilot.jpが残すところわずか一ヵ月足らずで使用停止になる。

実はこのメールは2回目だった。1回目は12月13日に届いていたが、読み飛ばしていた（自分のミス）。だが、こんな重要な事、メール一発で済ませてしまうのはちょっと厳しいんじゃないかなぁ。

2月7日に届いたメールには以下が書かれている。

　　【重要】ドメイン@nifty終了に伴うドメイン移管お手続きのお願い

いつも＠nifty（アット・ニフティ）をご利用いただき誠にありがとうございます。
昨年よりご案内しております通り、2005年より提供してまいりました
「ドメイン@nifty」を2024年3月をもって終了することとなりました。

ご利用中のお客様には大変お手数をお掛けしますが、終了日までにお持ちの
ドメイン名を、他社ドメイン管理事業者に移管のお手続きをお願いいたします。
　

ドメイン@niftyサービス終了日：2024年3月
※詳細な日付についてはホームページに掲載いたします。

...中略...

 ＜重要＞
・ドメイン名の移管手続き完了後は、ネームサーバーを必ず変更してください。
　PDNS1.NIFTY.AD.JPなど、ドメイン@niftyで提供していたネームサーバーは切断され
　利用できなくなります。

おいおいどうするんだ、というかどうしたらいいんだ？？？

ガイドされたWebページを読むと移管先を自分で決めて移管先に移管申請をしろ、ってことだ。移管先を自分で決めろって言われても困っちゃうよね。自分はたまたまムームードメインにドメインを幾つか持っているのでそこで移管手続きが出来るが、ドメイン@niftyでしかドメインを持っていなければ業者探しから始めることになる。これはかなりハードルが高いと思う。

ムームードメインへの引っ越しに先立って、ドメイン@niftyに自分のドメインのAuthCodeを申請しないといけない。この申請はWhois情報公開代行サービスを使っていると却下されるとの事だ。そこでガイドに従ってnifty上で自分のドメインのWhois情報公開代行サービス利用を停止した。ちなみに情報公開代行サービスを使用しないと、自分のプライベート情報が公開されることになる。

AuthCode申請を7日16時20分に行ったら翌8日9時02分にメールで届いた。しかし、ここに至るには大きな問題があった。それはドメイン登録者番号をドメイン@niftyが公開していないことだ。7日夕方にniftyにメールで自分のドメインの登録者番号の取得方法を問い合わせたが8日中には届いていない。nifty自身はQ＆Aで以下を掲載しているのに。。。おたくもドメイン管理事業者でしょうが。。。
（追記:2月14日14時14分に@niftyカスタマサポートデスクから返事が届いた。既に他社にドメイン管理を移しているからそちらに問い合わせるように、との内容だった。自分はムームードメインのサービスを使って登録者番号の取得が出来たが、そうでない移管が制限される。改善を強く望むところ）

現在持っている @nifty with ドコモ光1Gと10Gの2回線を10Gにまとめる手続きの備忘録。

@nifty with ドコモ光1Gを長年使っていたわけだけど、回線品質改善のため10Gを追加契約した。つまり1Gと10Gのダブルでの契約になる。nifty mailやココログは1Gのnifty IDで使ってる。10Gのnifty IDはプロバイダーを使うための契約なので、nifty mailやその他のオプションサービスは使っていない。

先日ドコモショップにて話をしたところ、ドコモは光回線とniftyとをまるっと一つの契約として管理しているので、ドコモとしては全部解約になると言われた。これは困った、、、、というのがさっきまでの状況。で、今日はniftyのカスタマサポートにnifty IDを残す方法について問い合わせた。

• @nifty with ドコモ光1Gをドコモで解約しても、1Gに紐づいているnifty IDを残せるか？
• 残せるとして1Gに紐づいている@nifty IDと10Gに紐づいているnifty IDをまとめられるか（コスト節約のため）。

niftyカスタマサポートに電話して分かったこと。

• ドコモで@nifty with ドコモ光をまるっと解約すると、1週間から10日でniftyからnifty IDの取扱いについて確認のメールが届く。
• そのメールでnifty IDを残すようniftyに連絡すればnifty IDは残せる。
• niftyのファミリープランを使えば、10Gのnifty IDの子どもIDとして1Gのnifty IDを登録できる。その場合、nifty ID基本料金275円/月は無料となる。
• ファミリープラン登録手続きはカスタマサポートの電話メニュー３，５，２で繋がる窓口（料金プラン窓口）で行える。

ということで、ドコモ光1Gを解約できることがわかった。

解約手続きをしてレンタルしているホームゲートウエイをドコモに返却すれば1Gとはおさらばできる。気になるのは1Gの光ケーブルの取扱いか、、、、撤去しにくるのかなぁ。

2月12日にドコモショップで@nifty with ドコモ光1Gの解約をした。解約は即日。レンタルしているホームゲートウエイは返却キットが一週間から10日で送られてくるのでそれで返却することになるとの事。空段ボール箱とかが送られてくるのだろうか。ホームゲートウエイは電源もオフしてあったので、結線を外してとりあえず在り合わせの段ボール箱に収納。電柱から室内まで引き込まれている光ケーブルは撤収不要ということにした。なのでNTT（実際には外部業者）は撤去には来ない。

2月16日にNiftyより、ドコモ光解約に伴うnifty契約内容の確認・変更のメールが来た。早速@niftyカスタマサポートデスクに電話をし、解約したドコモ光1Gに紐づいていたnifty IDと付属サービス（ココログ）をドコモ光10Gの子どもIDとするべく、ファミリープランの適用をおねがいした。あっさり、終わった。

これでドコモ光1G回線は解約、それに紐づいていたnifty IDと付帯サービスはドコモ光10Gに紐づいているnifty IDの子どもIDとするファミリープランの設定が完了した。

2月17日にゆうパケットでNTT東日本レンタル機器返却キットが届いた。中身は丈夫な紙袋と、紙袋に貼る伝票＋返却機器リストと、ガイドシート。リストにはホームゲートウエイPR-600KIとWifiアダプターカードSC-40NEが記載されている。これらに加えてホームゲートウエイのACアダプター、台座、光ケーブルを手持ちの段ボール箱に入れて、送られてきた丈夫な紙袋にいれて梱包終わり。これを郵便局に持ち込んで完了。

めでたし、めでたし。

4:1バランを作った。目的は21MHzのデルタループアンテナの実験をするため。

作るに当たってJARLの技術資料を参考にした。ざっくり4:1の原理は、インピーダンスZのコモンモードチョークコイル2個を入力（同軸）側は並列に、出力（アンテナ）側は直列に繋ぐから、入力側はZ/2、出力側は2Zになって、インピーダンス比は1対4になるという事と理解した。

トロイダルコアはこの技術資料で使っているFT-114-43が手元にあったのでそれを使用。銅線は0.8ｍｍのポリウレタン銅線/2UEW。

トロイダルコアに銅線ペアを2セット、コアの半分に5ターンずつ巻く。

コイル端をカットし、サンドペーパーでウレタン被を剥がし、結線。

結線部分の半田付け。

これをバラン用のケースに取り付ける。出力側両端を200Ω抵抗で終端する。

4:1バランとして機能することをRig Expertで確認。

結果は以下の通り。この結果はバランケースの置き方などによって変動するので大体の値としてみる事になるけれども、ほぼ50Ωとなっており4:1バランとして機能していることがわかる。

完成。

これでアンテナの製作に進むことができる。

蓄電デバイスがどの程度動くのか確認した。

蓄電デバイスがどの程度チャージできているか分からないのでこの結果がどの程度の一般性があるかは分からない。

薄曇りではあったけれども比較的天気の良い日に屋根の上にソーラーパネル付きのTWELITEを置いておいた。

TWELITEを部屋に取り込み段ボール箱を被せて日光を遮った。つまり蓄電デバイスのみでの動作となるわけだ。

以下にTWELITEのVCC変化をグラフにしてみた。縦軸がVCC（Vx100）、横軸がサンプリングカウントで5秒に1回インクリメントしている。

VCCは明るいところでは3.5V程度あるが、段ボール箱を被せると３V程度に低下する。つまり、蓄電デバイス単独となるとVCCは３Vになるということだ。このあと徐々に電圧は低下していく。大体2.6V程度でTWELITE自体がPORしてしまう。その時のサンプリングカウントは400だ。つまり400 x 5秒 = 2000秒 = 33.3分。

結果：蓄電デバイス1.5F、送信インターバル5秒では暗所で約33分は動作した

TWELITE DIPの送信インターバルが5秒だと約33分程度は蓄電デバイス（1.5F）で動作することが分かった（少なくともこの建付けでは）。

ちなみにここのデータ取りは以下のPythonコードで行った。TWELITEからの送信データをCSVにしてファイルに書き出している。上記のグラフはそのCSVをエクセルでグラフ化したもの。

ダウンロード - twelitemonitor1.py

次は蓄電デバイス3.5Fで実験してみる。

電気二重層コンデンサを1.5Fから3.5Fに差し替えて実験を行った。まずローラーパネルが日光に当たるように一日外に出した。十分に充電と判断し、陽射しが残っている間にTWELITEを室内に取り込み段ボールで蓋をした。

段ボールを被せてから917カウント後にTWELITEはPORした。
917 x 5秒 = 4585秒 = 76分

1.5F : 33分
3.5F : 73分
-----   -----
2.3倍  2.2倍

この2つのサンプルではキャパシティ容量増加比と動作時間増加比はほぼ同じとなった。

次は送信インターバルを5分 = Sleep Dur 300,000ms（今までは5秒だったので60倍）にして発電停止後の動作時間を計ってみる。

1.5Fについて、Sleep Duration 300,000秒、すなわち5分で実験してみた。結果は約50分。横軸はTWELITEのCounterで92で遮光した。で、102が最後のログとなっていた。つまり102-92=10 10x5分で50分。誤差は5分はある。5秒インターバルで33分だった。思いの外時間が伸びなかった（2倍にもなっていない）。

Sleep Durationを変更しても動作時間が伸びないということは、TWELITE以外の消費電力が多い可能性を示唆している。今回の測定ではADT7410温度センサーモジュールを使っている。

このモジュールが怪しい。スペックをみると210uA(Typ)とある。これは常時通電モードの消費電流。ADT7410はシャットダウンモードを供えていてそちらは2uAだ。TWELITEではDevice ModeとしてADT7410を設定しているが、TWELITEのApp_TagがどのモードでADT7410にセットしているかわからない。ちなみにDefaultは常時通電モード。

とりあえずADT7410を取り外し、TWELITEのDevice Modeをアナログセンサーモード0x10（内蔵ADCレベルの取得）に設定して再テストすることにした。ちなみにDevice ModeをADT7410（0x30）にセットしたままでADT7410だけ取り外すとTWELITEは動作しない（多分ADT7410とコミュニケーションできないから）。電気二重層コンデンサは1.5F、Sleep Durationは5分（30,000msec）。

結果は劇的だった。33.16時間。Count=37からスタートして435まで（5min/count）。
(435-37)*5/60 = 33.16 hours
途中PCをスリープにしたので目盛りでCount=104から210までは飛んでいる。

これなら24時間を大きく超えているので、天候が良い日が続けば24時間稼働が可能だ。電気二重層コンデンサを3.5Fに交換すれば単純に2倍の時間は動作すると予想されるので66時間（約2日半）は動作すると思われる。

この事はTWELITE動作時間においてセンサー回路の設計がとても重要であることを示唆している。

秋月電子からソーラーモジュールと電気二重層コンデンサ1.5Fと3.5Fが届いた。

まずはソーラーモジュールからテストしてみた。ソーラーモジュールはSHARP製の300mWモジュールだ。これにC基板が付属したものを購入した。C基板が必要かどうか分からなかったので（でもセットで売ってるんだから理由があるのでは？って思い）とりあえずC基板付属を調達してみた。いろいろ考えたが結局Ｃ基板付属の意味が見いだせなかった。

ソーラーモジュールに出力線を半田付け。

ショート防止のために養生テープを貼り付けた。ガムテープだと剥がすのが大変かと思い、比較的やさしい接着力の養生テープを採用。

ソーラー電源管理モジュールに接続した。

既に日没後だったのでまずはLEDランプで動作確認。

オシロでみてみると2.9V程度の出力が出ている。これはかなり強力だ。

LEDランプを消してみると急速に2Vまで電圧低下する。これはソーラー電源管理モジュール内蔵の220uFの放電の様子を見ているんだと思う。2.0VになるとTWELITEがOFFになるので暫く2.0Vで水平飛行をする。

しかし、耐え切れなくてなって完全放電するみたい。

放電が進んでからLEDランプを点灯させると一瞬にして2.9Vまで回復する（当然か）。

ということで300mWのモジュールは結構パワーがありそうだ。次は電気二重層コンデンサを接続して蓄電をしてみる。

その前にちょっと特記すべき現象に遭遇した。LEDランプだけでTWELITEが動作するような書き方を上でしたけれど、どうもそう簡単ではないようだ。ちなみに上の試験はまだ明るいうち（外からの光が窓越しにはいってきていて、その上でLEDランプをつけていた）に実行したモノだった。夜になって外の明かりが無くなってLEDランプだけになったら様子は違った。

LEDランプだけだとTWELITEの電源電圧はこんな感じで振れてしまった。① おそらく電圧が上昇してTWELITEに給電できる電圧（オシロでは2.6V位か）に到達してTWELITEの電源がONになるけれども ②発電量よりも供給量の方が多く急激に電圧低下（220uFが放電してまう）を起こしTWELITEをOFFにする。③ また受光による充電による給電がはじまって②にもどる、、、、というサイクルが起きてるのではないかと思う。

LEDランプの発光量を弱にして（TWELITEが再起動しないほど発電量を下げて）電圧が降下した後、LEDランプに加えて昔ながらの豆電球懐中電灯の光を当ててやると、発電量が増加するがその過程で一瞬同様の事象が発生する。つまり電圧が過渡期で発電量が弱い場合にこのような発振的な事象が発生するんだと思う。

そんなこんなで電気二重層コンデンサ1.5Fを付けてみた。

朝日が出る前に窓際に一式をセットした。

日光が当たってきた。ガラスの関係で室内にはソフトな光が入ってくる。

光の強さによってTWELITE VCCは様子が変化した。光が強くなると高い周波数のノイズが入るようになった。電圧は大体3.2V位になっている。10分程光に当てた状態でソーラーパネルに遮蔽を被せるとノイズは乗るが電圧は3.2Vあたりで安定している。電気二重層コンデンサに充電がされているようだ。

朝日が当たる前：

薄っすらと光が当り始める直前：

朝日がうっすらと当たり始めた時：

しっかりと太陽光が当たっている時：

朝8時55分に外に出してみた。暫く充電をしてみる。

TWELITEは元気に動いている。
::ts=62
::rc=80000000:lq=78:ct=05F5:ed=810CCAC2:id=0:ba=3650:a1=1792:a2=2467:te=1050
::ts=63
::ts=64
::ts=65
::ts=66
::ts=67
::rc=80000000:lq=78:ct=05F6:ed=810CCAC2:id=0:ba=3480:a1=1792:a2=2467:te=1062
::ts=68
::ts=69
::ts=70
::ts=71
::ts=72
::rc=80000000:lq=78:ct=05F7:ed=810CCAC2:id=0:ba=3650:a1=1789:a2=2467:te=1050
::ts=73
::ts=74
::ts=75
::ts=76
::ts=77
::rc=80000000:lq=75:ct=05F8:ed=810CCAC2:id=0:ba=3470:a1=1792:a2=2467:te=1050
::ts=78
::ts=79
::ts=80
::ts=81
::ts=82
::rc=80000000:lq=78:ct=05F9:ed=810CCAC2:id=0:ba=3650:a1=1789:a2=2467:te=1056
::ts=83

想定外の結果になった。

ログを見ると5時3分位にTWELITEの送信が止まっていた。だいたい4時近くまで陽射しはあり、3時30分位までは斜めからではあるけれど日光が当たっていたと思う。5時3分はまだ明るい時間で、この時間に送信が止まるという事はソーラーパネルの充電電圧が低下してから1時間30分も持たなかったことになる。
Tickカウンター 27535まではct=1B64とインクリメントが続いている。その時の電源電圧2.675V
Tickカウンター 27540ではct=0001とリセットされている。その時の電源電圧は2.630V

::rc=80000000:lq=84:ct=1B63:ed=810CCAC2:id=0:ba=2680:a1=1534:a2=2467:te=0656
::ts=27531
::ts=27532
::ts=27533
::ts=27534
::ts=27535
::rc=80000000:lq=84:ct=1B64:ed=810CCAC2:id=0:ba=2675:a1=1534:a2=2467:te=0656
::ts=27536
::ts=27537
::ts=27538
::ts=27539
::ts=27540
::rc=80000000:lq=84:ct=0001:ed=810CCAC2:id=0:ba=2630:a1=1107:a2=2467:te=0850
::ts=27541
::ts=27542
::ts=27543
::ts=27544
::ts=27545
::ts=27546
::rc=80000000:lq=84:ct=0001:ed=810CCAC2:id=0:ba=2635:a1=1097:a2=2467:te=0612

どうやら電源電圧2.675Vを下回るとTWELITE DIPは電源電圧モニターが働くようだ。

ログが残っている最も過去はおよそ20分前。その時の電源電圧は2.880V。およそ20分かけて2.880Vから2.630Vまで0.25V低下したことになる。

::ts=26327
::rc=80000000:lq=84:ct=1A70:ed=810CCAC2:id=0:ba=2880:a1=1628:a2=2467:te=1075
::ts=26328

ソーラー電源管理モジュールのマニュアルには以下の記載がある。BYPをDO2に接続すれば0.2Vを稼ぐことができる。リニアに低下するわけではないと思うが約15分程度は延命できるとみることもできる。
BYP
TWELITEのDO2に接続します。
Hiにすると、蓄電デバイスとTWE_VCC間へ接続されているダイオードをバイパスします。
蓄電デバイスが2.3Vの状態でTWELITEへ電源を供給すると、ダイオードの電圧降下によりTVE_VCCは約2.0Vになり動作を停止します。バイパスを行うと、蓄電デバイスが約2.0VまでTWELITEを動作できます。
電圧条件は、TWELITEの電圧条件に従います。

どうやら受信データから電源電圧（ba）を取り出してプロットするアプリを作る必要がありそうだ。

TWELITE DIPにApp_Tagをインストールできたので、次はTWE-EH SOLARの実験だ。以後ソーラーモジュールと呼ぶ。

ソーラーモジュールを配線してLEDランプの下に置いてみた。TWELITEは時々（本当に時々）動作する。TWELITEはVCCが2.0V以下では動作しないので発電電圧（TWE_VCC）が2.0を超えないという事だとおもう。

朝、太陽が出てからソーラーパネルを日光に当ててみた。TWELITEは速攻で動き出した。

::ts=44032
::rc=80000000:lq=135:ct=0016:ed=810CCAC2:id=0:ba=3310:a1=0612:a2=2467:te=1562
::ts=44033
::ts=44034
::ts=44035
::ts=44036
::ts=44037
::rc=80000000:lq=132:ct=0017:ed=810CCAC2:id=0:ba=3420:a1=0598:a2=2467:te=1562
::ts=44038
::ts=44039
::ts=44040
::ts=44041
::ts=44042
::rc=80000000:lq=132:ct=0018:ed=810CCAC2:id=0:ba=3340:a1=0634:a2=2467:te=1562
::ts=44043
::ts=44044
::ts=44045
::ts=44046
::ts=44047
::rc=80000000:lq=132:ct=0019:ed=810CCAC2:id=0:ba=3380:a1=0627:a2=2467:te=1562
::ts=44048
::ts=44049
::ts=44050
::ts=44051
::ts=44052
::rc=80000000:lq=132:ct=001A:ed=810CCAC2:id=0:ba=3360:a1=0639:a2=2467:te=1562
::ts=44053
::ts=44054
::ts=44055
::ts=44056
::ts=44057
::rc=80000000:lq=132:ct=001B:ed=810CCAC2:id=0:ba=3350:a1=0624:a2=2467:te=1562
::ts=44058

ソーラーパネルを日陰の状態から日光にあてるとTWE_VCCは3.2V程度まで上がる。

ソーラーパネルを日陰にするとTWE_VCCは徐々に低下していく。階段上になっているのがTWELITEの送信タイミング。この時TWELITEの送信間隔は5秒に設定している。

TWE_VCCが2V程度になるとTWELITEは動いたり動かなかったりする。動くと電圧はドロップし、徐々に回復する。つまり日陰で細々と充電するわけだ。けれども2.0Vを越えられないようだ。

次にVC2を見てみた。マニュアルによるとVC2は蓄電デバイス（デフォルトで220uFコンデンサ、写真アカ丸のC2）の充電電圧モニター出力だ。

充電電圧モニターこんな感じの鋸状の波形になっている。真ん中の谷はTWELITE動作時。充放電サイクルを繰り返しているんだと思う。

このC2には外部に並列コンデンサを付けることができる。それによって充電デバイス容量を増やすことができるわけだ。以下の写真は外部コンデンサーとして220uFのケミコンを取り付けた様子。

外部コンデンサー220uFを追加すると充電電圧モニターはこんな感じに変わる。充電容量が増えた分、充放電サイクルが長くなるようだ。

仮に外部コンデンサーを取り付けても日陰になると直ぐにTWE_VCCは2ボルトになってしまう。次は外部蓄電デバイスとして電気二重層コンデンサ、いわゆるEDLCを取り付けて日光が当たらない状態でどのくらいの動作時間が得られるか実験だ。なにしろ1FのEDLCでも220uFの4500倍の静電容量となる。

仮に220uFで送信4回できるならインターバル5秒だと20秒、4500ｘ20＝ 90000秒、　90000秒は25時間なので、一回充電すれば1日は持つことになる（かな）。

TWELITEでソーラーパワー（TWE-EH SOLAR）無線マイコンTWELITE用ソーラー電源管理モジュールを使う。

ソーラーパワーの使い方はネットに書かれているけれど情報が拡散していてなかなか分かりにくい。

まずは無線タグアプリ（App_Tag）をインストールすることが必要だと分かった。最新のTWELITE Stageをダウンロードする。古いままでやっていたら何が何だかわからなくなった。。。。

最新版のTWELITE Stageを使用すること。

で、TWELITE_Stage.exeを使ってTWELITE APPSビルド＆書換を実行した。インストールするのは、子機（DIP）はApp_Tag_EndDevice_Input、MONO_StickはApp_Tag_Parent_MONOSTICKだ。

App_TagをDIPにインストールしたけれどインタラクティブモードに移行しない。
どうやらM2をグランドに落とさないといけないようだ。M2がオープンのままだとOTAモードが働くと書いてある。なんだかちょっと違うような雰囲気だけれども、M2をグランドに落とさないとインタラクティブモードにならない事に変わりはない。

で、M2をグランドにおとしてみたらインタラクティブモードのメニューが現れた。
OTA（On The Air）をPORで起動しないようにするにはオプションビット ?????4?? を設定しろとある。現時点のオプションビットの値が0x00000011だから0x00000411に設定すればよいのだろう。

しかし、Optionを00000411にしてもやっぱりM2をGNDに落とさないとインタラクティブモードに入れない。

App_Tagで子機をインタラクティブモードにするにはM2をGNDに接続すること。通常動作に戻すにはM2をOPENにすること。
この操作を実行するために簡易的にR2にスイッチをつけた。

子機をインタラクティブモードにしてSleep Durを(2000) 2秒にした時のMONO Stickのアウトプット。この画面はMONOSTICKのターミナル画面。MONOSTICKは1秒間隔でモニター結果をターミナルに出力するようだ。tsとはTimeStampだと思う。起動（リセット）直後はts=1でそこからインクリメントされていく。子機からの信号を受信するとその結果を表示する。以下の表示結果はMONOSTICKのOption Bitsを0x00000000に、子機（DIP）のSensor Modeを0x11に設定した場合の表示フォーマットだ。ちなみにこのモニター時にはアナログ温度センサーとしてMCP9700を取り付けてある。

::ts=2270
::rc=80000000:lq=132:ct=00CD:ed=810CCAC2:id=0:ba=3060:te=1090:a0=2467:a1=709
::ts=2271
::ts=2272
::rc=80000000:lq=135:ct=00CE:ed=810CCAC2:id=0:ba=3060:te=1110:a0=2467:a1=711
::ts=2273
::ts=2274
::rc=80000000:lq=132:ct=00CF:ed=810CCAC2:id=0:ba=3060:te=1090:a0=2467:a1=709
::ts=2275
::ts=2276
::rc=80000000:lq=132:ct=00D0:ed=810CCAC2:id=0:ba=3060:te=1090:a0=2467:a1=709
::ts=2277
::ts=2278
::rc=80000000:lq=132:ct=00D1:ed=810CCAC2:id=0:ba=3060:te=1060:a0=2467:a1=706
::ts=2279
::ts=2280
::rc=80000000:lq=132:ct=00D2:ed=810CCAC2:id=0:ba=3060:te=1060:a0=2467:a1=706
::ts=2281
::ts=2282
::rc=80000000:lq=132:ct=00D3:ed=810CCAC2:id=0:ba=3060:te=1090:a0=2467:a1=709
::ts=2283
::ts=2284
::rc=80000000:lq=132:ct=00D4:ed=810CCAC2:id=0:ba=3060:te=1090:a0=2467:a1=709
::ts=2285
::ts=2286
::rc=80000000:lq=132:ct=00D5:ed=810CCAC2:id=0:ba=3060:te=1090:a0=2467:a1=709
::ts=2287

• rc: 中継機のSID(中継していない場合は0x80000000)
• lq: LQI
• ct: 続き番号
• ed: 子機のSID
• id: 子機論理デバイスID
• ba: 子機の電源電圧
• te: 温度(℃)×100
• a0: AI1(mV)
• a1: AI3(mV)

なおSensor Modeの設定値は以下の通り。

I2CデバイスとしてATD7410を接続してみた。

::ts=3158
::rc=80000000:lq=132:ct=002E:ed=810CCAC2:id=0:ba=3050:a1=2467:a2=0701:te=2006
::ts=3159
::ts=3160
::rc=80000000:lq=141:ct=002F:ed=810CCAC2:id=0:ba=3050:a1=2467:a2=0701:te=2006
::ts=3161
::ts=3162
::rc=80000000:lq=141:ct=0030:ed=810CCAC2:id=0:ba=3050:a1=2467:a2=0701:te=2006
::ts=3163
::ts=3164
::rc=80000000:lq=141:ct=0031:ed=810CCAC2:id=0:ba=3050:a1=2467:a2=0701:te=2006
::ts=3165
::ts=3166
::rc=80000000:lq=141:ct=0032:ed=810CCAC2:id=0:ba=3050:a1=2467:a2=0699:te=2006
::ts=3167
::ts=3168
::rc=80000000:lq=141:ct=0033:ed=810CCAC2:id=0:ba=3050:a1=2467:a2=0701:te=2000
::ts=3169
::ts=3170
::rc=80000000:lq=144:ct=0034:ed=810CCAC2:id=0:ba=3050:a1=2467:a2=0701:te=2006
::ts=3171
::ts=3172
::rc=80000000:lq=144:ct=0035:ed=810CCAC2:id=0:ba=3050:a1=2467:a2=0701:te=2006
::ts=3173

ATD7410（Sensor Mode=0x32）のデータフォーマット以下のとおり。ちなみにこの実験時の室温はおよそ20℃だった。

• rc: 中継機のSID(中継していない場合は0x80000000)
• lq: LQI
• ct: 続き番号
• ed: 子機のID(MACアドレスの下8桁)
• id: 子機論理デバイスID
• ba: 子機の電源電圧
• a1: AI1(mV)
• a2: AI3(mV)
• te: 温度(℃)×100

どうやらApp_Tagで温度測定ができそうだ。子機（DIP）のSleep Durを長くすればそれだけ省電力となる。

さて、これにソーラー電源管理ユニットをつないで様子をみてみる。

28ピンのゼロプレッシャーICソケットをブレッドボードに取り付けたくて作業した記録。

28ピンのゼロプレッシャーICソケットはそのままではブレッドボードに差さらない（ピンが短い）。ICソケットをアダプターにしようにもICソケットに差さらない（ピンが太すぎる）。で、細いピンヘッダー半田付けすることにした。

さすがにソケットにピンヘッダーに直付けは自身がないのでユニバーサル基板を介することにした。

まずはICソケットをユニバーサル基板に半田付けする。この際、後からピンヘッダーを半田付けするため、ちょっと多めに半田を盛っておく。

基板をクリップで固定する。


ここからがミソで、ピンヘッダーに丸ピンICソケットを差しておく。これはピンヘッダーが半田ごての熱で溶けて変形したりピン抜けしたりすることを防ぐため。これをしないと大変なことになる。


こんな感じにしてヘッダーピンをICソケットの半田付け部分に半田付けをする。


ICソケットによって固定されているので半田ごてによる各ピン保持部分のプラスチック変形を防ぐことができる。


もう一方も同様の方法で半田付けする。ICソケットのピンへのヘッダーピンの半田付けする側は揃えること。


思ったよりもきれいに出来た気がする。



ブレッドボードに挿すにあたって、ICソケットを一段かませた。というのもちょっと幅がありすぎて配線の邪魔になったので。


拡大鏡前提の作業になるが、コツがつかめれば出来ない作業では無い事がわかったのだ。めでたし、めでたし。

APRS実験の記録。2024年1月19日。

結論から言うと、伊奈川流域でのAPRS信号は今回の機材では基地局での受信は困難であるということだ。

FT-70D/出力HIGH/付属ホイップアンテナにて、APRSビーコンインターバルは1分に設定した。これら機材をウエストポーチに入れ、ウエストに固定してバイクで現地に向かった。

伊奈川沿いに上流に上ったが、R19を外れた後は基地局にて電波受信ができなかったようだ。帰路に伊奈川神社に寄ってきたが、そこからの信号は受信できたようだ。

浦川砂防ダム上流

伊奈川神社

先日製作したTWELITE DIP BLUEユニットにて子機ユニットと中継ユニット間の通信距離実験を行った。

通信距離レベルが分からなかったので、まずはスポーツ公園の400メートルトラックにて実験を行った。
子機を三脚に固定しグランドの東端に設置した。

子機ユニットを段ボールに貼り付けて、その段ボールを三脚のアタッチメントに固定した。

中継機ユニットとUSB親機（白いUSBモジュール）＋PCを持ってグランドを端まで移動した。USB親機の受信性能は高くないようなので、長距離通信は子機ユニットと中継機ユニットで行い、中継機ユニットUSB親機は至近距離で通信する構成としている。

PCにてTWELITE Stageを実行し、子機ユニットからの信号を中継機ユニットで受信したうえで、その中継信号をPCのUSBソケットに接続してあるUSB親機で受信する。通信距離はおよそ267メートルで、子機ユニットと中継機ユニットの間の通信は良好に行われている様子だった。

これならば木曽川越えが可能かもしれないと、子機ユニットを和村の河岸段丘に設置したうえで

中継機と親機＋PCを持ってこの子機が良く見える木曽川対岸の須原のJR線上の峠道（越坂）の途中まで移動した。

この距離で子機・中継機とのパケット通信は70%程度は成功している様子だった（TWELITE Stage画面上の受信パケットのスクロール状態で判断）。通信距離は854メートル。これは可也すごい！ことだと思う。

今回の実験はTWELITE DIP BLUE (送信出力 2.5dBm = 1.778mW) で実験したが、TWELITE DIP RED (送信出力 9.19dBm = 8.299mW)であれば1kmを越える通信は可也余裕があると予想される。

前回の考察でマッチング回路は74pFと0.405uH(405nH)あたりで構成できることがわかった。

ということで、2年前に50MHzダイポールで実験したときと同じようにバランとLCのボックスを用意しようと思う。
バラン部については前回同様というかコアにワイヤーを巻いてつくるとする。

Lはカリキュレーターアプリで計算すると以下の感じになりそうだ。コイル径は単三電池に巻くことを前提としている。

Cは以前ヤフオク!でゲットしたエアバリコンを使うことを前提としたい。このエアバリコンは2連しきで片方が24 - 140pF、もう片方が22 - 95pFとなっている。80pFあたりを中心にすることを考えると 24 - 140を使ってみることを考えたい。

これらをボックスに入れてアンテナに繋ぐことにする。実際にどのLC値にするかは、一旦アンテナを作ってアナライザーでスミスチャートをとってみてから決めることになる。ということで、次はアンテナエレメントをゲットする。多分、1x18x2000 + 1x15x2000 + 1x12x2000 で5mのエレメントを作ることになるかなって思う。V字型エレメントの先端はアルミ線でつなぐのかなって思う。まずはこのアルミパイプを調達せねば。

21MHz Deltaループアンテナについて考察記録。

先人の知恵に習い、21MHzのデルタループアンテナをMMANAで考察してみた。

計算タグからワイヤー編集を繰り返し、とりあえずの形状にたどり着いた。

 

先人の知恵もアンテナの開き角を小さくしていく（扇を畳む）とインピーダンスが下がると書かれているので、その方向にワイヤー編集を勧めた結果、以下のような形状に落ち着いた。


問題はワイヤーの長さだ。約5.9ｍもある。仮に給電点を地上高5mとしてもそこから約6mも上方向に伸ばさないといけない。これはかなり厳しい。

そもそも正三角形に近い形の場合について再度考察してみる。

この場合 Z=107.58+j1.001となっている。Mr.Smithでマッチング回路を考察すると並列C=74pF、直列L＝405nHとなることが分かる。

おそらくマッチング回路を入れることになるだろう（開き角を自由に調整できるとは思えない）と想定すれば、作りやすい形でデルタループを作って、あとはマッチング回路でがんばるってことになるんだろうか。

それにしてもデルタループ（というよりもループアンテナ自体）は全長が1λになるとなれば結構な大きさになっちゃうね。

TWELITE DIPに専用ダイポールアンテナを取り付けるため、U.FLコネクターを半田付けした。

やりたい事はTWELITE DIP2つで、一つは子機、一つは中継機として構成し、子機と中継機の通信距離測定。この為、TWELITE純正の外付けダイポールアンテナをTWELITE DIPに取り付けたいわけ。

取り敢えずの完成形は以下。タッパーにいれて実験する。

ケース壁に貼り付けてある長方形の板がダイポールアンテナ。

このダイポールアンテナはU.FLコネクターでTWELITE DIPと接続するようになっている。けれども、自分がストックしていたTWELITE DIPは簡易アンテナ（マッチ棒）を取り付けるタイプでU.FLコネクターが付いてない。で、自分で半田付けすることにした。

とにかくコネクターは小さい。2mm角くらいだろうか。

横にピンセットを置いてみると大きさがわかる（超～小さい）。

このコネクターをTWELITE DIPに半田付けするわけだ。

コネクターを取り付けるパターンの内、①がセンター線、②から④が外被となる。コネクターが乗ると①と②は半田ごてが入れにくいので、①と②のパターンには半田を薄く乗せておいた。半田を乗せる前にフラックスも塗っておいた。

コネクターをパターンに乗せて、①のパターンとコネクタ端子を過熱して半田付けしコネクターを固定した。そのうえで②部分を過熱し、コネクターをパターンに半田付けした。③と④はコネクターが固定されてから半田付けした。①から④まで半田を薄く乗せておくのが良いかもしれない。というのも③に乗せた半田量がちょっと多すぎてソルダーウィックで半田を取り除いたりしたからだ。つまり、半田を後から盛ると半田量のコントロールが超難しいので、予めパターン上に半田を薄く乗せておくのが良いように思えた。

③部分は余分な半田をソルダーウィックで吸い取った。

アンテナのケーブルを取り付けて完成。

出来上がりはこんな感じ。

半田付けが細かすぎて容易な作業ではないけれど、それほど難易度が高いという感じでもなかったが、コネクターパターンが小さすぎて（コネクターからのはみ出し量が少なく過ぎて）半田ごての小手先で半田を乗せるのに手間取った。

上記の２が中継機で３が子機となる。簡易的に中継実験を行ったが動いているようだ。次はスポーツ公園に行って距離測定実験だ。

カンピロバクターに当たったときの記録。カンピロバクターの培養検査は受けてないが、数年ぶりに会って同じものを食べた友人も同様の状態となったので、鶏肉によるカンピロバクター確定と判断した。

12月29日の夕刻に友人と駅前の焼き鳥屋で2人忘年会。結構人気のお店で16時開店前から人が待っている状態だったんだけど、ここで出てきた料理に問題があったようだ。自分でも「大丈夫か？」って思ったけれど、レバー串がほぼかなりレアだった。若干の不安があったが、どうやらそれが的中したようだ。

12月31日の朝、車の洗車をしていたら急に寒くなった。洗車が終わって家の中に入っても寒さが止まらない。寒さというより悪寒だ。耐え切れず「貼るカイロ」を背中に貼った。ただ、食欲はあり、腹痛も下痢もなかった。悪寒は更に強まり、夕方に熱い風呂に入って少し収まった感じがしたが、夜通し悪寒と暑くて発汗の繰り返しだった。熱は測らなかったが、あの感覚は38度を超えていたと思う。

1月1日の朝、いつも通りに4時50分起床、ルーチントレーニングもして、近所の神社に初詣をした。その後近所の公園まで散歩して帰宅。一見、回復したようだった。しかし9時位に下腹部中心に非常に激しい腹痛が起きた。何かに挿されるような、まるで腸をねじられるような激しい痛み。起きていることができず、ベッドに丸まって寝るしかなかった。仰向けでは激しい腹痛も、横向きで丸まって寝ると幾分痛みは和らいだ。便も出るし、尿もでるので、腸閉そくでも尿路結石でもないようだ。悪寒も時々襲ってきた。つまり、下腹部の激しい腹痛と発熱のダブルパンチだ。ただ、食欲はあり、昼には餅を2個食べたり、正月料理を食べたり、酒も飲んだ。

1月2日、症状は1日同様に発熱と腹痛が発生。これに下痢が加わった。水上の便がでてくる。比較的悪寒が少ない時、家族に言われて初めて熱を測ったら37.8度だった。つまり、こんな体温を中心に上下を繰り返していたんだろうと思う。食欲がなくなってあまり食べることができなくなった。

1月3日、症状の改善はなく、食欲は更に低下。お湯をかけたご飯、牛乳、経口補水液を飲むくらい。下腹部の痛みと下痢が同期するようになった。トイレに行けば下腹部の痛みは和らいだ。夜の体温は38.2度だった。早々にベッドに入らずを得なかった。

1月4日、朝の感覚として腹痛は可也和らいでいるように感じた。激しい痛みは遠のいた感じだ。体温も朝の時点で36.9度だった。悪寒も感じない。朝とお昼はお湯をかけたご飯のみ。でも晩御飯には若干復活してきて煮物と白飯を食べることができた。

1月5日、夜中下痢でトイレに行くことは無かった。朝はいつもの4時50分に起床、軽い運動もできた。体はかなりだるいし、下腹部が重たい感じがするが、下痢と腹痛で苦しむことはなくなった。朝食はご飯に入り卵を乗せて、みそ汁と一緒に食べた。昼はガストでハンバーグを食べた。さすがに晩酌は控えたけれど、ほぼ復活。

1月6日、下腹部に違和感が残るものの、ほぼ完全復活。昼は焼き肉屋、近所の神社に正月飾りを納めにいった。

まとめると以下となる。
12月29日夕方：感染
12月31日午前：発症（発熱）
1月1日午前：下腹部の激しい痛みと発熱
1月2日：下痢の始まり、発熱と激しい腹痛は残る
1月5日：発熱、下痢の終息
1月6日：完全回復

いやぁ、新年早々参った、参った。以降、火が十分に通っていない肉、特に鶏肉は絶対に食べないようにする。

国立感染症研究所は以下のように記述している。
症状は下痢、腹痛、発熱、悪心、 嘔吐、頭痛、悪寒、倦怠感などであり、他の感染型細菌性食中毒と酷似するが、潜伏期間が一般に2〜5日間とやや長いことが特徴である。感染性腸炎研究会資 料によると、入院患者の98%に下痢が認められ、その便性状は水様便（87%）、血便（44%）、粘液便（24%）である。下痢は1日に10回以上に及ぶこともあるが、通常2〜6回で1〜 3日間続き、重症例では大量の水様性下痢のために、急速に脱水症状を呈する。また、腹痛は87%、嘔吐は38%にみられた。発熱時の平均体温は38.3℃ で、サルモネラ症に比べるとやや低い。

診断については以下のように記述している。
感染症の診断は臨床症状からは困難で、糞便等から本菌を分離することが最も確実である。本菌の 同定には通常3〜5日間程度必要である。

治療については以下のように記述している。
患者の多くは自然治癒し、予後 も良好である場合が多く、特別治療を必要としない。

以上をまとめると、下痢、腹痛、発熱で数日苦しむが、自然治癒に頼るしかない。

カンピロバクター自体は非常に多く存在する細菌で、感染が見つかっても保健所に報告する必要はないようだ。ただ、これが食中毒と判断された場合は保健所への報告が必要らしい。また、カンピロバクターは乾燥に弱く、人から人への感染は基本的にないようだ（感染者の便を直接摂取するような極端な場合を除いて）。

APRSISCE/32のScrollerのウインドウが左上隅にコンパクトにまとめられてしまった。これをスクリーン上下幅まで拡大させた時の備忘録。

APRSISCE/32をインストールした直後はScrollerウインドウはスクリーン上下幅まで拡大されていたけど、ある日なぜだか左上隅にコンパクトにまとめられてしまった。Scrollerとは受信したステーションのパケットを表示するウインドウで、見ていて楽しい。自分の場合はIGate/Digipeteaterも表示するようにしている。楽しいのでScrollerウインドウサイズを元にもどしたい。

コンパクトになってしまったScrollerウインドウ：

APRSISCE/32はオプションが沢山あって、どこをどう設定すれば良いかなかなかわからなかった。いろいろ放浪した結果、以下をつきとめた。設定前はAutoになっていたけれど、これをNarrowにしたらScrollerが大きくなった。まとめると、Configure -> Screen -> Orientation -> Narrow 。方法が分かっても、これでScrollerが大きくなるのが納得いかない（直感的にたどり着かない）。

Scrollerウインドウサイズを元にもどす方法：

ちなみにIGate/Digipeater表示を加えるにはConfiguration -> Scrollerで設定する。

ScrollerにIGate/Digipeater表示を加える方法：

やっぱり、APRSっておもしろい。

ドコモ光1Gでniftyを使ってる。これに加えて@nifty with ドコモ光10Gを開通した。つまり2回線を併用している。

ドコモ光1Gで「ネットが切れる！」と家族（孫）が切れるので、回線を1Gから10Gに変更しようと考えた。しかし、、切替工事ってのは大体想定外の事が起きる。実際、起きた。10G回線工事に来たが、配線した後の検査で光強度が規定値に達していないことが判明。どうやら、このエリアは実際に10G配線した実績がないようで、結構大規模の改修工事が必要だと言われた。で、結局再工事は1ヵ月後。つまり、切替工事をしたら場合によっては1ヵ月ネットが使えない状態になっていたかもしれない。

10Gの回線を使ってみて特に問題はないようなのでドコモ光1Gを解除しようと思ったわけ。Niftyによると解除とはドコモ光でniftyをプロバイダーとして選択している場合、ドコモ光のみを使わないようにするのが解除で、ドコモ光とniftyの両方を使わないようにするのが解約だ。

この解除手続きを行うには、まずはドコモに行って解除手続きをせよとNiftyはガイドしている。そこでドコモにいったわけ。そうしたら、ドコモカウンターでは「お客様はドコモ光とniftyのセット契約になっていますので、解約しかできません」と言われた。ドコモ的には、niftyのサービス利用料もドコモ経由でユーザーに請求してる。つまり、niftyはユーザーにサービス利用料を直接請求する手段を持っていない。ドコモのサービスを使わなくなった時点でサービス利用料の請求ができなくなるので、ドコモ的にはniftyだけを残す術がない、ということだ。

となると、ドコモ光の解約とniftyのサービス料請求方法の変更（nifty的にはドコモとの契約からユーザー個人との契約に契約変更する必要がある）を同時に行わないといけないわけだ。これは予めniftyと段取りをしないといけない。

そもそもドコモ光1Gのniftyアカウントを維持したいのはメールアドレスとブログサービスの為だ。メールアドレスは至る所に登録してあるし、ブログはおよそ10年分書き溜めている。ブログを引っ越すとしてもGoogle検索のインデックスが変わるとGoogle検索から辿れなくなるので、とても面倒なことになる。

まずはNiftyに連絡して状況整理をする必要がある。しかし今日は12月30日、正月が明けないと手も足もでない。

さぁ、どうする？？？（続く）

続きはこちら

NEC WiFiルーター WX4200D5でWIRES-X HRI-200ノード構成が出来なかった件の備忘録というか疑問の記録

Aterm WG1800経由で構成済み・運用中のWIRES-Xノード（HRI-200の先にはYaesuモービル機、430帯でノード運用中）のWG1800をWX4200D5に取り換えたが、運用できなかった。

WIRES-XアプリはHRI-200に接続されているモービルトランシーバーの受信信号を確認し、自分自身のノードアイコンを緑色（ノードからルームへの送信）にするが、音声データをルームに送出しない（ルームが音声データを受信しない）。

手順

1. 変更前、ノードPCはHRI-200経由でモービルトランシーバー（430MHz帯）に接続しており、ハンディ―トランシーバーからそのモービルトランシーバから電波を送ることで、ノードPC経由でルーム接続している。今回はWiFiルーターの入れ替えなのでノードPC、HRI-200、モービルトランシーバの接続は一切触っていない。
2. 使用中のWG1800をWX4200D5に置き換える。
3. 光ケーブル収容のネットワークモデムもリセットする。
4. WX4200D5にて、ノードPC上のDHCPでのインターネット接続を確認。
5. PC上のIPアドレス(192.168.10.10)等を固定IPに変更。
6. PC上で上記固定アドレスでインターネットアクセスできることを確認（Chromeでインターネット上のWebをアクセス）。
7. WX4200D5のWebコンソールにて、上記固定IPアドレスに対してWIRES-Xのポートを開放する（ポートマッピング）。
8. WIRES-Xアプリでポートチェックを実行し、全てがOKとなることを確認。
9. WIRES-Xアプリでいつも接続しているルームに接続
10. ルームに接続されている他のノードからの音声は、上記モービルトランシーバから電波として送信されハンディ―トランシーバーで受信できることを確認。つまりこのノードPCはルームからの音声を受信することができる。
11. 上記ハンディ―トランシーバーからモービルトランシーバーに送信した場合、ルームに音声が送られない。つまりノードPCからルームに音声が届かない。ただし、このノードは緑色アイコンとして表示される。つまり、モービルトランシーバーはハンディートランシーバーの信号を受信し、ルームに対して送信操作をするのだが、音声がルームに送られない。ハンディ―トランシーバーから音声を送っている間、ノードPCのサウンド画面ではHRI-200 A（CH1）Audio Codecのレベルは変動するので、音声はPCに入ってきている。そもそも、PC周りはWiFiルーター以外は取り換えていないし、PC上の設定も変わっていなので、音声がPCに入ってくるのは当然だと思う
12. ノードPCを再起動しても状況は変わらない。
13. この状態でWX4200D5をWG1800に戻すと、WIRES-Xアプリ上の表示（緑色）の仕方は同じでルームに対して音声が送られる。つまり、この現象はWX4200D5についてまわっている。

まとめると、WG1800をWX4200D5に入れ替えるだけで（ポート開放設定済み）、音声のみがルームに対して送られなくなるのだ。

これは一体どういうことだろう。。。

そもそもトランシーバーの受信信号をWIRES-Xアプリがルームに送出するには、スケルチが開いて音声データが入力される必要がある。しかし、スケルチさえ開けば音声は無変調でも送り出されるはずだ。つまりこの場合、スケルチは自ノードから送信PTTとして働くわけだ。それで音声データがルームに送られないというのは音声データパケットがルームに届かないということか。

アプリで受信したデジタル音声をデコードする作業を考えてみると、まずはデータバッファにある程度データが溜まってからDMAでデコーダーに送るんだと思う。音声が出てこないということはデータバッファにデータが溜まらないってことだ。

ポート開放と関係があるのか？送信はノードPCからデータを送り出す方向だからポート開放とは逆方向。そもそもポート開放（ポートマッピング）はインターネットから自IPアドレス/ポートに送られてきたパケットをポートマッピングしたPCにリレーする手段だ。だからポート開放とは無関係だろう。WX4200D5にすると、音声データパケットが送りだせないのか？？？

うぅ～ん、わからん。