PATHpilotのブログ

WIRES-Xでちょっとした問題に遭遇。考察結果を備忘録として以下に記録。

某AcerのノートPCにWIRES-Xをインストールしたところ、オーディオデバイスが接続されていないってことで起動できない。この状態で、マイクスピーカーコンボジャック（4端子ジャック）にピンジャックを差し込むとこの問題が解消されてWIRES-Xが起動できる。

ピンジャックを差し込む前は、ピンジャックを担当するオーディオデバイスとしてのRealTekマイクデバイスが未接続となっている。ピンジャックを差し込むと接続済みになる。

どうやらWIRES-XはRealTekマイクデバイスが未接続状態で「オーディオデバイスの接続が無い」と言ってきて、RealTekマイクデバイスが接続状態で「オーディオデバイスの接続が有る」と判断するようだ。

一方、このノートPCにはIntelスマートサウンドテクノロジーデバイス、つまり専用DSPが実装されていて、PC内蔵マイクや内蔵スピーカーはそのデバイスに繋がっている（ようだ）。オーディオデバイスドライバーを使う限り、アプリ的にはスマートサウンドテクノロジーを介しているか否かは透過的になっているはずなので、WIRES-Xのサウンドもスマートサウンドテクノロジーで動作するはずだ。

どうやら問題はWIRES-Xがこのスマートサウンドテクノロジーデバイスをオーディオデバイスとして認識（判別）することが出来ないことらしい。なので、何でも良いのでWIRES-Xが認識（識別）できるオーディオデバイスを接続状態にしてあげれば良いということだ。これを行うにはノートPCのマイクスピーカーコンボジャックにピンジャックを差し込んで（実際に外部マイクや外部スピーカーを接続する必要はない）RealTekオーディオデバイスを活性化すればよい。少なくともこのノートPCではピンジャックを差し込むだけでRealTekは活性化する。

仮にこのスマートサウンドテクノロジーをアンイストールしたとしたら、PC内蔵マイクとスピーカーが使えなくなるので嬉しくはない、というか結局は外付けマイクとスピーカーを繋がないといけないことになるので、上記ピンジャック接続作業より負担が増える。これらから、ピンジャック差し込み以外に対応方法はないのかもしれない。

今後のWIRES-Xのバージョンアップに期待したい。

WIRES-Xで自分のQSLイメージを相手に送る時の注意点について。

WIRES-XでNode to Node接続した場合、相手に自分のQSLイメージを送ることができる。そういった設定をしていない場合、Default画像として以下が表示されている。

自分のQSLイメージを相手に送る場合は、設定->基本運用情報で、QSL画像イメージのファイルをセットする。QSL画像のチェックボックスは相手のQSLイメージを自分のWIRES-X画面上で表示するか否かの選択で、相手にイメージを送るか否かには関係がない。相手にQSLイメージを送るには有効なBMPファイルをセットする。

さて、このBMPファイルだが、制約があることがわかった。解像度はQVGAである320x240だが、問題はカラー深度で、256カラーでないと転送してくれないようだ。試しに16ビットカラーにすると相手には表示されない。

上記画像は320x240で256カラーのファイルを指定して表示されたものだ。

手持ちのQSLカードイメージから変換する場合がほとんどだと思うが、要注意！

備忘録。。。

HAMLOG EMailのようなアプリからGMAILをアクセスするには、アプリ用のパスワードを取得し、それを使って認証する必要がある。

アプリパスワードを生成するには、Googleアカウントを2段階認証プロセスにする必要がある。これはGoogleアカウントの管理から実行する。

Googleアカウントの管理の画面に入って左側のメニューのセキュリティからアプリパスワードを選ぶ。

アプリパスワード発行対象アプリを記述する。なんでもいいと思う。

生成をクリックするとアプリパスワード16桁が生成される。

これをHAMLOG E-Mailのパスワード欄（赤丸部分）にコピーする。ここにGoogleアカウントのパスワードを設定しても認証エラーになる。

この後、送信確認と受信確認をしてからサーバーに登録・保存ボタンを押す。確認しないでボタンを押すと「確認せよ」って感じで登録・保存ができない。

固定ページにコメントを書き込むボタンを表示させる方法を見つけるのに手間取ったので備忘録。

まず、Defaultでは固定ページにコメントを書き込むボタンは表示されない。

各固定ページのプロパティのディスカッションにあるコメントを許可にチェックを入れる。

変更を適用すると、対象の固定ページのコメントを書き込むボタンが表示される。

CocoonのDefault設定では固定ページや投稿のAuthor表示をする設定になっている。このAuthorはリンク先がついていて、それをクリックするとそのAuthorの固定ページ・投稿の一覧が表示される。

このようなことは適用したくないので非表示とした。その備忘録。

まずはDefaultでAuthorが表示される（赤丸部分）。これはリンクになっていて、そのAuthor（この場合はpathpilot）が書いた固定ページと投稿がリストされる。

これはCocoon設定->本文->投稿情報表示設定 の投稿者名の表示のチェックを外すことで非表示にできる。

この変更を適用した後の状態。Authorが表示されていない。

ホームページを開設したけれどもGoogle検索に出てこない。Googleにインデックスを作ってもらう必要があるようだ。そこでGoogle Search Consoleでインデックス作成（クロール実行）リクエストを出したのでその備忘録。

今回新たに作成したホームページのURLを最上段のURL入力欄にいれてみると、「URLがGoogleに登録されていません」と出てきた。つまりクロール対象になっていないからGoogle検索にヒットしないわけだ。そこで「インデックス登録をリクエスト」をクリックする。すると登録可能かテストする旨のダイアログが表示さて1分ほど待たされた。

この後、URLがクロールキューに入った旨のメッセージダイアログが表示された。

これでクロールされるはずなので、暫くするとGoogle検索にひっかかってくるはずだ。

EchoLinkでHAMSTIR STとHAMSTIR Xを使っている。HAMSTIR XはWIRES-Xとの相互接続のために使用。今回の構成でEchoLink側のみ、おかしな動作をするので、まずは現状の記録から。

システムの全体構成図は以下のとおり。

ここでの「おかしな動き」とは以下の通り。

1. EchoLinkのUserノードからSysOpノードであるJA0WBT-Lに接続し、Transmitする。SysOpノードはRXモードになり、Userノードからの音声はHAMSTIR ST→HAMSTIR X→FTM-100Dと送られ、FTM-100Dより送信される。またHAMSTIR X→HRI-200を経由してWIRES-Xノードが接続しているWIRES-X Roomにも転送される。ここまでは想定通り。
2. EchoLinkのUserノードがTransmitを終了すると、EchoLink SysOpノードはアイドル状態になり、FTM-100DおよびHRI-200を通した送信は停止する。ここまでも想定通り。
3. この後（SysOpノードがアイドル状態になって1秒未満）、SysOpノードはTXモードになりUserノードに信号を（勝手に）送る。UserノードはRXモードになり、Transmitができなくなる。ここがおかしな動き。この状態では、SysOpノードはTXモードになるがWIRES-X側は送信状態にはならない。つまりEchoLink側だけが勝手にTX状態になる。なお、この現象はFTM-100Dの電源がONになっている場合にのみ発生する。

上記動作をイラストで表すと以下のとおり。

1. 

2. 

3.

この現象をEchoLink SysOp画面で見ると以下となる。

この現象の観察を通して、現時点で以下の結論に到達している。

• 本現象（勝手にTXがONになる）はFTM-100Dの電源が入っている場合にのみ起きる。仮にFTM-100Dが変な動きをしている（電波を受信していないのに受信データをHAMSTIR Xに送っている）とすると、EchoLinkとWIRES-Xの両方が送信するはずだ。よってFTM-100Dの動作が異常だとは言えない（FTM-100DはEchoLinkだけにおかしな信号を送ることはできない）。
• FTM-100Dの電源が入っていない状態では、EchoLinkとWIRES-X間の相互通信は問題なく実行され、本現象も発生しない。よって、HAMSTIR STに問題があるとは思えない。
• 以上より、FTM-100Dの電源状態（信号状態）を認識することができ、EchoLink側だけにおかしな信号を送ることが出来る（EchoLinkとWIRES-Xに対して別々のインターフェースを持っている）HAMSTIR Xの動作があやしい。

要追加調査。。。。。

解決！！

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をブルーツースと訳すのはちょっと違和感を感じる。。。。