ホームページを開設したけれどもGoogle検索に出てこない。Googleにインデックスを作ってもらう必要があるようだ。そこでGoogle Search Consoleでインデックス作成（クロール実行）リクエストを出したのでその備忘録。
今回新たに作成したホームページのURLを最上段のURL入力欄にいれてみると、「URLがGoogleに登録されていません」と出てきた。つまりクロール対象になっていないからGoogle検索にヒットしないわけだ。そこで「インデックス登録をリクエスト」をクリックする。すると登録可能かテストする旨のダイアログが表示さて1分ほど待たされた。
この後、URLがクロールキューに入った旨のメッセージダイアログが表示された。
これでクロールされるはずなので、暫くするとGoogle検索にひっかかってくるはずだ。
EchoLinkでHAMSTIR STとHAMSTIR Xを使っている。HAMSTIR XはWIRES-Xとの相互接続のために使用。今回の構成でEchoLink側のみ、おかしな動作をするので、まずは現状の記録から。
システムの全体構成図は以下のとおり。
ここでの「おかしな動き」とは以下の通り。
上記動作をイラストで表すと以下のとおり。
1. 
2. 
3.
この現象をEchoLink SysOp画面で見ると以下となる。
この現象の観察を通して、現時点で以下の結論に到達している。
要追加調査。。。。。
解決！！
HAMSTIRの開発元であるOneChipDesignより大変貴重な情報を頂く事ができ、無事問題が解消したので以下にその情報を転記（一部編集）。
問題のポイントは、送信時スケルチ出力の設定です。
[TX]: ON(初期値)にすると、送信時 Hレベルの信号が出力するようで、
受信に戻った時の Lレベルに戻るタイミングのバラツキで、
EchoLinkの方が受信信号有りと判断してしまい誤動作になるようです。
・FTM-100の設定例 (WIRES-Xノード局モードにはしない)
設定画面に入るには、[DISP SETUP]ボタンを長押しします。
[DATA] =>[1.COM PORT SETTING] =>[COM OUTPUT] : PACKET
[DATA] =>[2.DATA SPEED] : DATA 1200 bps
[DATA] =>[3.DATA SQUELCH] : 2 TX OFF
・FTM-400の設定例
設定画面に入るには、[DISP]ボタンを長押しします。(HRI-200制御モードにはしない)
[TX/RX] =>[AUDIO] =>[MIC GAIN] : NORMAL
[DATA] =>[COM PORT SETTING] =>[OUTPUT] : OFF(camera)
[DATA] =>[DATA BAND SELECT] =>[DATA] : MAIN BAND
[DATA] =>[DATA] : 1200bps
[DATA] =>[DATA SQUELCH] =>[DATA] : TX/RX BAND
[DATA] =>[DATA SQUELCH] =>[TX] : OFF
いやぁ、FTM-100Dのマニュアルは見たつもりが、DATA SQUELCHなる設定がある事には気が付かなった。スケルチ設定のところはいろいろと設定してみたものの、それは実際の電波受信時のスケルチ設定のところどまりだった。
やはり技術力のある会社さんの製品はこういったテクニカルサポートもすごく魅力的なところだ。深々と感謝！！！
備忘録
自分のリンクノードには自分のスマホ（古いスマホ）から常時接続している。なのでリンクノードには古いスマホが接続中と表示されている。
出先から上記自分のリンクノードに他のスマホ（新しいスマホ）から接続すると、リンクノードの接続が古いスマホから新しいスマホに置き換わる。二重接続はしない。
新しいスマホの接続を着ると再び古いスマホに接続が戻る。
注意：同じWiFi上で上記を行うと新しいスマホはリンクノードに接続できない。上記が可能となるのはそれぞれのスマホが異なるネットワークを介してリンクノードに接続する場合のみ。
EchoLinkとWIRES-Xの中継装置を立ち上げたので備忘録。
今回構築した中継装置の概要はOneChipDesign社のHAMSTIRを使って構築した。
HAMSTIR ST：EchoLinkのPCからアナログトランシーバーへのインターフェースボックス
HAMSTIR X：インターフェース分配器。2つのインターフェースボックスからのアナログトランシーバーへのインターフェースを一つにまとめて一台のアナログトランシーバーに接続するとともに、2つのインターフェースボックス間の信号中継を行うインターフェースボックス。例えば、HAMSTIR STからのインターフェース信号はトランシーバーインターフェース（Mini DIN 10p）とHRI-200に送られる。
HRI-200はWIRES-Xのインターフェースボックスなので、HAMSTIR Xを使う事で、EchoLinkとWIRES-Xとの間の中継を行うことができる。今回の中継装置ではHAMSTIR Xの先にアナログトランシーバーを接続していないで、EchoLinkとWIRES-X間の中継のみをおこなう。
この構成ではWindows上でオーディオ入出力レベルのチューニングが必要となる。
HRI-200ではEchoLinkからの受信音声はUSBオーディオ入力で、EchoLinkへの送信音声はUSBオーディオ出力で設定される。
HAMSTIR STではWIRES-Xからの受信音声はPCのMic入力で、WIRES-Xへの送信音声はLINE OUTオーディオ出力で設定される。
それぞれのレベルを調整することで、EchoLink上のオーディオレベルとWIRES-X上のオーディオレベルを調整することになる。
HRI-200でのオーディオレベル調整
送信音は100、受信音は71に設定した。この設定はPC上ではUSBオーディオのスピーカーとマイクのレベル設定にコピーされる。
EchoLinkからの送信はPCのLINE OUTのスピーカーレベルで設定し、100と設定した。
EchoLinkへの受診信号はMic入力としてインターフェースボックスから取り込まれる。ここではレベル100でマイクブースト20dBとした。10dBではレベル不足（EchoLink端末としてのスマホで聞くと音が小さい）で、30dBにすると音が割れてしまう。
EchoLinkアプリ上での設定
System Setup
HAMSTIR STのLINE OUTケーブルとMICケーブルを接続した端子（Audio Device）をInput DeviceとOutput Deviceに設定する。
Preferences
Allow conferenceにチェックをいれて複数のUserがこのLink Stationに同時接続可能とする。接続可能Station数の上限はとりあえず10とした。
Sysop Setup
RX CtrlはSerial CTSとする。Serial PortはHAMSTIR STをPCにUSB接続した際にデバイスマネージャに現れる２つのCOMポートの内の小さいCOM番号のCOMポートを設定する。今回の構成ではCOM5とCOM6となった。
TX CtrlはRTSとする。Serial PortはRX Ctrlと同じにする。
IdentificationではDefaultでWhile not activeにチェックが入っているのでこれを外す。そうしないと10分おき（設定値による）にEchoLink上のJA0WBTのモールス信号がWIRES-Xに中継されてしまう。
OptionではAnnounce connectsとAnnounce disconnectsをNoneにする。Noneにしていないと、接続・切断した際にEchoLinkから送信されるメッセージ（例：JA0WBT disconnected）がWIRES-Xに中継されてしまう。
WIRES-Xの設定
アナログSQLをNoToneにする。ToneSQLが設定されていると、EchoLinkからの信号が入ってきてもToneが付いていないので送信できない。この場合、WIRES-X上では中継局ノードが緑色のボックスで表示されるが相手に送信信号が飛ばない（トランシーバーが繋がっているノードのトランシーバーは電波を出さない）。
切断タイマー無効設定とする。
以上でEchoLinkとWIRES-Xの中継が可能となった。
アンテナ・ケーブル アナライザー AA-1500 ZOOMのSetting画面を見ていたらブルーツース 有効/無効の設定があるのに気が付いた。
AA-1500はBluetoothでも接続ができるんだ！ってことで普段AA-1500をUSB接続しているノートPCでの接続を試みた。PCではAA-1500を検出してペアリングが完了した。けれども、、、、
PC上で動いているRigExpertアプリであるAntScopeのSetting画面にはBluetooth接続らしき選択がない。見た感じSerial Portのみのサポートにみえる。選択肢にあるCOM3, 4, 7, 8とも既に構成済みのCOMポートだ。つまりPC上のアプリはBluetooth経由でのAA-1500接続をサポートしていない（と判断した）。
いろいろと調べてみるとAndroid用のAntScopeがあることが分かった。さっそくPlayストアからダウンロードしてみる。
AntScopeをスタートすると早速Bluetoothでアンテナアナライザーを探しにいっている。AA-1500をタップすることで接続が完了する。
測定範囲を設定する。
SWRの測定を実行。
放っておいたらBluetooth Timeoutになった。
以上よりBluetoothはPCアプリではなくスマホアプリで使用する前提のようだとわかった。
昔自分も英語マニュアルを日本語化するときに悩んだけれども（今は会社の翻訳ガイドがあって悩むことはない）、Bluetoothをブルーツースと訳すのはちょっと違和感を感じる。。。。
起動しなくなったWindows10の修復を行ったので、その備忘録。
Window10が黒い画面で窓マークと回転マークの表示から先に進まない。途中で電源OFF/ONを行うと自動復旧と自動診断が走り出した。
結局自動復旧は失敗。
トラブルシューティングを実行。
詳細オプションを選択。
ここから更新プログラムのアンインストールとかシステムの復元とか試したけれどもいずれもNG。
そこでスタートアップ設定に進む。
「セーフモードとネットワークを有効にする」を選んで起動する。
セーフモードでWindows10が立ち上がった。なんとかなりそいう。
コントロールパネルからWindows Updateの追加のトラブルシューティングを実行する。
何かが破損していたようだ。とりあえず復旧ができた。
この後、エクスプローラーでCドライブのプロパティからツールを選んでチェックを行う。エラーが報告された。
遅ればせながら、ここでBIOSメニューのHDD診断を行う。HDDはデバイスとしてはちゃんと機能していることが確認できた。
再起動しても自動修復できないと報告される。Windows Updateの修復だけではだめで、Cドライブの論理修復が必要と理解した。そこで再びセーフモードでWindowsを立ち上げ、コマンドプロンプトで chkdsk c: /f を実行した。Cドライブはブートドライブなのでボリュームがロックされていてこの瞬間修復はできないけれど、次回の起動時に修復を自動実行する。
修復実行中の様子はこんな感じ。ちょっと時間がかかる。
無事Windows10が立ち上がって、復活した。
結論からするとWindowsファイルシステムが壊れていて（不整合状態になっていて）、起動が出来なくなっていたようだ。なぜ、不整合状態になったかは不明だけれども、とりあえずこの方法で修復できることは分かった。
Logger32での自分の緯度経度設定の仕方がわからなかったので備忘録。
今までTeam Viewerを個人使用で使ってきた。いろいろと面倒なことが起きたのでChrome Desktopに乗り換えようと思う。
インストールは至って簡単で、Chrome Desktopをインストールするだけ。クライアントからのアクセスはChomeを使う。重要なのは同一Googleアカウントで、サーバー、クライアントともログインするということ。つまり、同じGoogleアカウントでログインしているPC同士はPINコードさえ入力すればリモートアクセスを許可するというもの。
同じGoogleアカウントでログインしていて、Chrome Desktopサーバーとなっているマシーンはクライアントから一覧で見ることができる。
ここでログインしたいRemote Desktopを選択すればよい。
ではTeam Viewerの良いところがあるか、自分の過去の利用状況から考えてみた。Team Viewerで使ったのはファイル転送や再起動などだ。それ以外は単純なRemote Desktopとしてしか使ていない。
Chrome DesktopでもCtl+Alt+Delを送ることができるからリモートから再起動が可能だ。
ファイル転送もできる。
となると、Team Viewerを使い続ける意味があるのか？今の所、それを主張しうるポイントがない。今後はChrome DesktopでリモートFT8運用をおこなってみるかな。
新しくWindows10タブレットを手にいれた。この機に回復ドライブ（Recovery Drive）の作成をしてみたので備忘録。
まずWindows10の回復ドライブの作り方。
コントロールパネルを開く。
スタートアップメニュー → Windows システムツール → コントロールパネル
コントロールパネル → システムとセキュリティ → セキュリティとメンテナンス と進む。
画面の下の部分に回復(R)とあるのでそれをクリックする。
回復ドライブの作成を選ぶ。
選んでから内部処理が進むと、USBドライブをセットするように指示がでる。そこでUSBをセットすると、セットされたUSBを作成先ドライブと認識し、確認画面が出てくる。なので、上記指示が出るまでUSBは差さない。なお16GB以上が必要と表示される。今回は3台のWindows10で同時に実行したけれど、早いマシーンでも回復ドライブ作成に1時間以上かかる。
作成自体は特に考えることもなく3台とも完了した。問題はこれから。回復について。3台のうちの1台のマニュアルに、「回復時にBitLockerキーを聞かれることがある」とある。BitLockerってなんだ？？？
BitLockerでGoogleってみると、マイクロソフトアカウントに入ってデバイスのBitLockerキーを見るような記載がある。で、ログインして入ってみた。すると登録デバイスが1台だけ表示されている。
この1台をみると回復キーの管理にたどり着く。これをクリックすると回復キーが表示された。
このBitLockerって、ドライブの暗号キーらしい。つまり、回復する場合に暗号キーが必要になるというわけだ。確かにキーが無いと回復はできないだろう。でもなんで1台だけしか表示されないんだろう。
そこで3台の違いを調べてみた。3台は、ThinkPad、Fujitsu Windows10 Tablet、Lenovo Windows10 MiniTower。
まず、BitLockerで回復キーが保管されているThinkPad。システムとセキュリティにデバイスの暗号化がある。
デバイスの暗号化を開いてい見ると回復キーのバックアップがある。見た感じ、Cドライブは既に暗号化済みでそのキーのバックアップについての操作になっているようだ。マイクロソフトアカウントのデバイスで取得できる暗号化キーはこれな訳だ。つまり、暗号キーはマイクロソフトサイトにも保存さているということだ。
では残りの2台はどういう状態なのか。Fujitsu Windows10 Tabletをみてみる。ThinkPadとはちょっと表示が違う。BitLockerドライブ暗号化とある。
BitLockerドライブ暗号化をクリックすると以下の表示になった。つまり、BitLocker暗号化が未だされていないということだ。なのでマイクロソフトアカウント上にBitLockerキーがないわけだ。なるほど。多分、暗号化するとキーがマイクロソフトアカウントにも保存されるのだろう。
もう一台のMiniTowerはどうか。こちらにはBitLocker自体が存在しない。つまり、ドライブの暗号化がサポートされていない。なぜ？？？
BitLockerはWindows10の標準機能らいしが、なぜMiniTowerにはそれが無いのだろう？
いずれにせよ、BitLockerで暗号化しているPCは1台しかないので、マイクロソフトアカウント上でも1台しか表示されないんだと思う。ThinkPadのBitLockerキーはファイルは回復ドライブUSBに、更に印刷もして保管することにした。
とりあえずこの先は宿題として、今日の作業記録はここでおしまい。
Wordpress 5.8に自動更新されて初めてページ編集を行ったら、いろいろなところが変わっているというか、今まで使えていた機能がつかえないし、見出しもフォーマットが異なったりしている。
5.7と同じように使う方法が分からなかったのでWordpressのDowngradeを行った。
DowngradeのPluginはここにある。
Downgradeする前の状態はこんな感じ。自動でフル更新をEnableにしてあった。
これをPluginを使って5.7に戻す。Settingをクリックする。
ターゲットを5.7に設定し、変更を保存をクリックする。
変更を保存すると以下が現れるので本体(コア)のアップ/ダウングレードをクリックする。
以下の画面が現れるので5.7-jpを再インストールをクリックする。
インストール状況が表示される。完了すると以下の画面が表示される。
メンテナンスリリースとセキュリティリリースのみを有効にする。
既に5.8でいろいろと編集した部分では、5.7では未知のパラメータが入っているブロック（たとえばボタン）があるようで、そのブロックについて問題を修正するか否か聞いてくる。もちろん修正して未知のパラメータは削除する（元にもどす）。
H2が左端に寄るなどの問題はあるが、一応もとに戻った感じがする。
教訓：メジャーバージョンのバージョンアップを有効にしてちゃだめ。
