PATHpilotのブログ

ネット速度が異様に遅くなった。リモートデスクトップ画面が固まってしまう。

インターネット速度を計ったら数Mbps程度に低下していた。これはおかしいと思い暫くしてからSpeed Testで測定したらフレッツ網速度も20Mbpsと緯度になっていた。

現在の環境はドコモ光契約のフレッツ光ネクストの1Gプランで、IPv6のV6プラス。2020年の開通当時は500Mbps程度の速度がでていた。V6プラスが動いていないのか？と思いチェックしたがV6プラスで動いていた。この時点において、Speed Testはインターネット、フレッツ網ともに90Mbps前後の値を出していた。つまり、このレベルにトラフィックを落としているのはフレッツ網が原因といえる。

ドコモ光のサポートに電話したところ、それは機器故障で対応するとそちらにまわされた。で、PR-500KIホームゲートウエイの交換手続きをされた。無料で翌日配送で届くという。但し交換に当たっては一時的にネットワークが使えなくなるとの話。交換機が届いて交換する過程においてネットワークが不通になるのは当然と思うと同時に、無料でホームゲートウエイを交換できるということで交換を了承した。ただ、フレッツ網の速度が出ていないのでホームゲートウエイを交換することに、ネットワーク速度の改善の観点からは意味があるとは思えなかったが。

暫くしてネットが繋がらくなった。

慌ててサポートに電話したところ、交換する新しいホームゲートウエイにMACアドレス登録を差し替えたので、古いホームゲートウエイでは認証がエラーになるとの事。

そんな事聞いてないんですけどー。

電話の相手は「新しいホームゲートウエイの到着を待つしかない」という。なんということだ、、、、まさか交換品の発送手配の時点でネットワークが不通になるとは。。。。配達はなる早の翌日午前中指定にしたのは不幸中の幸いだった。しかし、丸一日近くネットがつかえなくなる。ただしこの状態でも光ケーブルでのテレビは受信できた。

翌日朝9時過ぎにホームゲートウエイが届いた。

中身は返送用紙袋、大きい箱、小さい箱の3つ。

小さい箱にはホームゲートウエイに装着するWiFiアダプターが入っていた。

大きい箱にはホームゲートウエイ、底面板、説明書、返送伝票などが入っていた。

まず、古いホームゲートウエイの取り外しから。同封されていた交換手順書通りに進めた。

ステップ１：光コンセントから光ケーブルを抜く

ステップ２：本体に繋がっているACアダプター、LANケーブル、テレビケーブルを外す。

ステップ３：底面板をはずし、光ケーブルコネクター部分のカバーを底面側にスライドして外す。

ステップ４：光ケーブルを抜く。

以上で取り外し完了。

新しいホームゲートウエイ（PR-600KI）のとりつけを行う。

光ケーブルコネクターのキャップを外す。

光ケーブルの差し込み。

カバーを取り付け、底面版を取り付けて完了。

光ケーブルを光コンセントに差し込む。

光コネクタのシャッターが閉じているので、親指でスライドしてシャッターを開ける。

光ケーブルを光コンセントに差し込む。

LANケーブル、テレビケーブルを取り付けて、電源を取り付ける。1分足らずで認証ランプが点灯し、開通したことがわかる。

早速速度測定を行った。結果は想定通りに変化（改善）せず。はやり、フレッツ網でサチっている。

この後も頻繁に測定を繰り返したが90Mbps前後で安定している。どうやら90MbpsあたりでQoS設定がされているようみ見える。

この後、再びサポートに電話したけれども、返答をまとめると「この程度の速度が出ていればNTT的（ドコモ光的）には問題ないと判断する」であった。残っているのは訪問サポートということだったけど、その場合訪問サービスマンがNTT側には問題ないと判断した場合、もれなく8,250円の出張料請求が発生するとのこと。まずまちがいなく請求書が渡されるのだろうから断った。サポートの電話はエンドユーザーの機器故障対応コールセンターにつながるようなので、ユーザーによる機器交換か問サポートしか提示できないようだということも分かった。だからコールセンター担当者は「もう、訪問サポート以外にご提案できるものはありません」と繰り返すのみになってしまう。機器交換して改善しないのに何を訪問サポートで確認するのか、こちらはフレッツ網の速度低下を調べて欲しいのだと繰り返すのみ。すれ違いは解消されなかった。ドコモにメンバーログインしてドコモ光のサポートページを辿ると、ドコモ光的には10Mbpsでていればシステム的には正常と判断すると書いてある。なんということだ。

まとめると、ドコモ光はベストエフォートサービスで1Gで契約してもその100分の1の10Mbpsでていればサービスレベルを満たしているとNTTは判断している。現在フレッツ網は90Mbpsで安定しているところをみるとQoSを90Mbps前後で設定していて、それ以上は出せない（帯域を独り占めできない）設定になっているようだ。安定して通信速度を得たければIPv6に切り替える事をドコモはガイドしているが、2023年4月末時点において、そのIPv6での最高速度が90Mbpsなのだ。

どうにもこうにも手詰まりだ。現在はドコモ光1Gだが、これを10Gにすることで改善するか。。。それくらいしか次の手がみつからない。

海老名警察署での運転免許更新方法の記録、ただし優良運転者に限る。

前日までに最寄りの大和警察署構内にある交通安全協会で証紙3000円を購入。自分はこの時更新通知ハガキを持って行かなかったからできなかったけれど（というかその必要性を後から知った）、証紙購入時に教本ももらっておくこと。

海老名警察署の駐車場は構内にある。駐車台数は多くはないけれど朝9時前に行けば結構空いていると思う。9時前に行っても建屋の中には入れる。ただし窓口はしまっている。けれどもATMに似た書類作成機械は動いてるので、窓口オープン前に書類を揃えられる。

9時5分前に着いたけれど、自分以外にだれもおらず、自分が一番乗りとなった。9時になって窓口が開いて書類を出したら、視力検査と写真撮影を行って（２，３分で完了）、9時20分開始の講習時間が掛かれた免許証受領証を渡された。この時、教本を持っているか聞かれて「持っていない」と答えると、歩いて1分ほどの交通安全協会に教本を取りに行くようにガイドされた。このとき「こちらから電話連絡しておくので、並ばなくていいです」と言われた。

交通安全協会に行って見ると沢山の人が順番待ちになっていた。つまり、みんなここで詰まってしまって警察署にこれないのだということが判明。ここで待っていたら9時20分に警察署に戻れない（何時に戻れるかわからない）ので、上記ガイドがあったわけだ。

窓口に割り込んで「教本を取りに来ました」というと「藤原さんですね。警察署から電話がありました」と周りの人に聞こえるように言ってくれた。そりゃ、待っている人たちからすると「あいつはなんだ！」って思うだろうからね。

ということで、事前に証紙を交通安全協会で購入するときは教本もあわせてもらっておくべし、ということなのだ。

9時20分開始の講習は自分も含めて5名だけ。30分で終了。終了後窓口前に来ると沢山の人が集まっていた。たとえ9時に証紙を持たずに来ると講習は2回目以降（10時20分開始）になってしまう可能性大だから1時間30分はかかってしまうわけだ。

自分は8時55分に着いて9時50分に終了。合計55分。

なお、自分の古い免許が欲しければ、新免許受領時に「古い免許が欲しい」といえば、穴あけ（神奈川県のマーク）して無効とスタンプして古い免許証がもえらえる。

次回も優良運転者だったらこの方法で行こう。しかし、ここが一番の課題だね。

備忘録

Windows + M : 全てのウインドウの最小化。つまりデスクトップだけになる。

Shift + Windows + M : 全てのウインドウを元にもどす。

備忘録

Alt + Ctl + 矢印キーで画面の向きが変わる。

ISSが日本海を通ったタイミングで通信を試してみた。 

以下が自分が送ったシグナル。

ISSのログをみると15時47分16秒に送ったポジションデータのみが受信されたようだ。

JK1ZRW-11が受信したISSパケットも同じ結果となっている。

残念なのはJM8SMOが当局宛に信号を送ってくれてたのに、それが受信出来なかったことだ。

日本アマチュア無線工業会のアンテナ利得大研究資料をみると、5/8λGPの段数による指向性特性がわかる。

今回の通信で使っていたのは3段GP。これは仰角がほとんどない。とりあえず2段GPに付け替えてみた。
これで次回挑戦してみたい。

UISSを使ってISSにパケットを送ってみた。

ISSの軌跡をOrbTrackで確認し、日本本土上空にくるまで待機。日本上空に来たことを確認してまずはAPRS Positionを送信。次にAPRS Messageを送信、続いて再度APRS Positionを送信した。最初のAPRS PositionとAPRS Messageの間にBU2DRからRS0ISS経由信号を受信した。

ariss.netでISSが受信した信号を確認できる。

日本の上にJA0WBTが表示されている。ISSに受信されたようだ。

Station ListのトップにJA0WBTが座標とともにリストされている。

Recent activityリストにJA0WBTがリストされている。順番に送ったAPRS Position、APRS Message、APRS Positionがログられている。

ちなみにStation ListのJA0WBTをクリックすると、その座標情報からGoogle Mapが表示される。

以上により、3段GPでISSに145.825MHzのAPRSパケットが届くことが確認できた。

ここまでは、めでたし、めでたし。

追記

JJ1WTK局のWebページでJA局が受信したISSパケットを見てみた。

時間で追っていくと、最初のポジションデータ送信はJJ1WTKとBU2DRの2局が受信し、それをI-Gateに上げたのだと読める。

2023-03-23 07:33:27 : JA0WBT>CQ,RS0ISS*,qAR,BU2DR-3:=3540.79N/13738.12E-NAGANO, Japan PM85TQ {UISS54}
2023-03-23 07:33:26 : JA0WBT>CQ,RS0ISS*,qAS,JJ1WTK-6:=3540.79N/13738.12E-NAGANO, Japan PM85TQ {UISS54}

次に送ったMessage送信はBU2DRとJK1ZRWの2局が受信し、それをI-Gateに上げたのだと読める。

2023-03-23 07:34:21 : JA0WBT>CQ,RS0ISS*,qAR,JK1ZRW-11::SAT      :Hi All.
2023-03-23 07:34:21 : JA0WBT>CQ,RS0ISS*,qAR,BU2DR-3::SAT      :Hi All.

最後のポジションデータ送信はJK1ZRW局が受信し、それをI-Gateに上げたのだと読める。

2023-03-23 07:36:02 : JA0WBT>CQ,RS0ISS*,qAR,JK1ZRW-11:=3540.79N/13738.12E-NAGANO, Japan PM85TQ {UISS54}

ISSはDigipeaterなので、地球から送られたパケットをレピートするわけだ。それを地球で受信している。

自分が送ったパケットはUI-View32とUISSの両方のログには残らない。なので送ったかどうかはUISSのログ頼りとなる。

解釈、合ってるかなぁ。。。。

ISSを経由したパケット通信にフォーカスしたアプリである、UISSをインストールした。

まず、UISSアプリのダウンロードURLは以下のとおり。
https://www.qsl.net/on6mu/uiss.htm
ここからWindows版をダウンロードする。

これはAGW Packet Engineのインストールを前提としている。自分はUI-View32の為に既にインストール済み。

インストール後の設定として以下の2点を行った。

自局の座標設定。これは Setup -> UISS... からSetupダイアログに入り、APRS...をクリック、Setup Your APRS Coordinates & IconをクリックすることでSetup APRS Coordinatesダイアログを表示することで可能。

最初はRF信号を表示できずに悩んだ。まずはSoftware Modem PreferenceでAGW using TCPIPを選択。次にPortsでRXをAllに設定した。これでRX、TXともにリグを通して出来るようになった。

運用方法については改めて報告。

備忘録

非Windows11 PCをWindows10 からWindows11にアップグレード

MicrosoftからWindows11のmulti-edition ISOイメージをダウンロード
setup.exeの実行、要件を見たいしていないことを確認
sources\appraiserres.dllファイルの中身を削除（ファイル自体を消すと再度作られてしまう）
setup.exeの実行
「セットアップでの更新プログラムのダウンロード方法の更新」をクリック
更新プログラム、ドライバー、オプション機能の入手で「今は実行しない」を選択して次へをクリック
ライセンス条項に同意するをクリック
インストール準備が完了したらインストールをクリック

10日以内ならシステム->回復->復元でWindows10に戻すことができる
10日以上に設定したかったら予め以下を実行
DISM /Online /Set-OSUninstallWindow /Value:100
Valueは日数指定、ここでは100日になる。
ただし、一旦この日数を過ぎるとWindows10に戻すことはできなくなる。

IC-705のVBUSに接続されている過電圧保護用ツェナーダイオードが焼けてしまった。焼けちゃったらダメだろーって思うんだけれど。

ちなみに、リペアセンターによると焼けたツェナーダイオードは以下とのこと。
ダイオード：1SMB5920BT3G
ツェナー電圧：定格6.2V

つまり6.2V以上がVBUSラインに加わると焼けるそうだ。これは困る。なので過電圧保護回路を入れたい。

ツェナーダイオードの電圧と電源供給電圧をLM358で比較し、MOSFETをスイッチングする。MOSFETのオンオフをするトランジスタは汎用トランジスタの2SA1015だ。LEDをON/OFFする2SC15815とはコンプリメンタリな関係のトランジスタだ。回路としてはコンパレータとMOSFETにスイッチングトランジスタと、非常にシンプルな回路となっている。ツェナーダイオードを切り替えることにより、5Vラインと13.8Vラインの両方に対応できるようにした。

この回路をベースに作業を進める。なお、ツェナーダイオードからDC IN＋への接続に20KΩと1KΩがパラレル接続になっている理由は本文後半に記載している。

スイッチングトランジスタとして2SJ555をつかう。2SJ555のオン抵抗が0.017Ωととても小さいためで、損失が少ないから都合がよい。

ゲートソース間電圧を確認する。

15V時
ゲートソース間電圧　VGS ＞ 14V となるのでIDは無限大となる。
6V時
ゲートソース間電圧　VGS ＞ 4V となるのでIDは70Aとなり、問題なし。

次に、記事には無かったゲート抵抗を加える。必要となるデータはターンオン時の上昇時間またはターンオフ時の下降時間（どちから短い方）、ゲートチャージだ。

15V時
ゲートチャージ VGS=14Vで180nc
ターンオン上昇時間（270ns）とターンオフ下降時間時間では上昇時間が短いので、ターンオフ時により多くの電流が流れる。ターンオフ時の電流に合わせてゲート抵抗を求める。

電流値 = 180nc / 270ns = 0.67A
ゲート抵抗値 14V / 0.67A = 20Ω

6V時
ゲートチャージ VGS=4Vで40nc
電流値 = 40 / 270 =0.14
ゲート抵抗値 4/0.14 = 28Ω

以上より22Ωとしてみる。

パーツの配置を考える。配線が交差しないように、幾度かリトライ。

配置が決まったのでパーツをセットして、電源ラインに1.6mm銅線を配置する。

出来上がった基板。
表側：

裏側：

負荷として10KΩを接続して遮断電圧の調整をしてみる。

9.1Vツェナーダイオード

コンパレータとして動作するオペアンプの出力が変化する時、つまり＋とーの電圧値が拮抗するところではオペアンプ出力が以下のようになることが分かった。

入力電圧：15.58V オペアンプ出力 LOW

入力電圧：15.70V オペアンプ出力 HIGH

この中間電圧では以下の波形となった。

入力電圧: 15.61V

入力電圧：15.62V

実際問題、このような電圧で入力電圧が安定することはないと判断されるので、特に問題ないと思う。

3.6Vツェナーダイオード

3.6Vツェナーダイオードの場合、VR50KΩの範囲では調整できなかった。というよりもツェナーダイオード電圧が3.6Vにならず、2.0V程度になっていた。調べてみるとダイオードがにツェナー電圧によりブレークダウンするため必要な最小電流として通常5mAから10mAの間の電流が必要のようだ。適当に抵抗を決めたのが良くない。そこで電源からツェナーダイオードに繋ぐ抵抗20KΩに1KΩをパラに接続（0.95KΩ）し、電流量を増やしてみた。6Vで約6mA流れる。

結果うまくいった。

ケースへの収納

ダイソーで買ってきた3個で100円のキッチンプラケースに基板を収納した。

この状態で、総抵抗5オームのセメント抵抗を取り付けて電流試験（約3A）を行った。セメント抵抗はかなり熱くなったけどMOSFETは特に発熱はしなかった。これはオン抵抗が小さいことが効いているんだと思う。

蓋をして定電圧電源に接続、この先はIC-705の外部電源端子に繋がる。
 

まぁ、良い感じで仕上がったと思う。

CB1300のバッテリー、台湾ユアサは2年もたなかった。

木曽の寒冷気候、バッテリーには厳しいのかも。

昨今の経済状況から台湾ユアサは1万円を超えてる。2年前は6000円位だった。GSユアサは13000円台。なのでGSユアサを購入。

ポールに7MHz 1/4λバーチカルアンテナを取り付けた。

ポールの上から4段目長点に巻き尺とアンテナワイヤーを固定し、ポールを伸ばした。以降、アンテナアナライザーAA-1500で共振点を探しながらワイヤー長調整を行った。

ワイヤの根元はボックスで同軸に接続している。同軸外被側は車体に直接接続している。

調整の結果、7.1MHzの共振点はワイヤー長7.9mで得られた。計算値（300/7.1＝10.56）よりも随分と短い。

給電点を軽トラ運転席上にずらしたりすると共振点がさらに低い周波数に移動した。アンテナ系としてどういう形になっているのが分からないが、とりあえずSWR＝1.01という驚異的な値になったのでアンテナ的にはこれ以上調整のしようがない。

このあと、QRP 5Wで栃木と埼玉の局とつながりともに57のレポートを頂いた。これは使えそうだ。

追伸：

移動して運用すると共振点が変化することがわかった。地面によって変化するようだ。そこでワイヤー長を調整できるように、ワイヤーを10センチ単位で切ってギボシ端子で連結した。

今後、ロケーションによる共振点変化のデータを取っていきたいと思う。

今年で24年のCB1300SF、車検にだそうと決めてバイク整備。ブレーキフルードとクラッチフルードの交換。

フロントブレーキリザーブタンクを開けてみる。そんなにすごくは汚れていない。タンクの底にもゴミは溜まっていない。最後の交換から4年。

ブリードバルブに内径5mmのシリコンチューブを繋ぎ、ブレーキレバーを握ってブリードスクリューを緩め、フルードが出てきたらブリードスクリューを締める。この繰り返し。

左ブレーキシリンダーも同様に。

結構きれいになりました。

リアブレーキも。リアブレーキのリザーブタンクの蓋はタンクを外さないと外れない。見た感じ、こっちもあんまり汚れていない。

古いフルードをタンクからある程度抜き取ってから、新しいフルードを継ぎ足し、ブレーキレバーを押し込んで、ブリードスクリューを開けて、フルードが出てきたらブリードスクリューを締める。この繰り返し。

さてさて、クラッチのリザーブタンクを開けてみると、こりゃひどい。随分とゴミが溜まっている。車検を頼んだお店ではブレーキフルードと同時交換してなかったみたい。ちょっと意外な状態。

ゴミを吸い出して、新しいフルードを注ぎ足すことを数回繰り返す。

カバーを外す。

クラッチのマスターシリンダーがある。

ブレーキと同じようにブリードスクリューにチューブを差して、クラッチレバーを握ってブリードスクリューを緩め、フルードが出てきたらブリードスクリューを締める。この繰り返し。

随分ときれいになった。
 

という感じでフルード交換終了。

ヤフオク!で購入した16メートルアンテナマストを軽トラに取り付けてみた。

取り付ける前の荷台の様子。運転席後ろに取り付けてみる。

マストの根元固定部。合板に角材をコの字にネジくぎで固定し、その合板をM8のボルトで荷台に固定。ボルトには大型平ワッシャを入れてある。このM8のネジは荷台取り付けネジを外して、そのネジ穴に固定している。

ネジ位置は排水の為の段差があるので、12mmの合板を入れてある。

マスト根元を入れた様子。

マスト上部は軽トラの鳥居に、C型クランプで固定する。

C型クランプにはリピート型結束バンドで固定する。

軽トラの鳥居とC型クランプとの間に傷防止も兼ねて滑り止めのゴムを入れてある。

アンテナマストを伸ばした状態。

16メートル伸ばした状態。

根元部分や鳥居との固定部に若干の隙間があるので、固定を確実にするためにスペーサーを入れる予定。

その後は10メートル電線をマストに沿って固定し、7MHz 1/4λホイップの実験に移る予定。

移動用アンテナの基本形として、垂直ダイポールを作ってみた。

アンテナ自体はとってもシンプルなんだけれど、持ち運びを念頭に全体を仕上げるのはちょっと工夫が要る感じ。

アンテナはアルミ線を塩ビパイプにリピート型結束バンドにて固定し、BNC (J) Wターミナルを接続し、同軸ケーブルからの直接給電としている。

調整後のアンテナ総長は95cm。145MHzで短縮率0.98としても101cmと計算されるので、思いの外短い。

三脚に取り付けた状態。三脚は半分伸ばした位だが、それでも給電点地上高は2m以上ある。

この状態でのAA-1500によるSWRチャート測定結果が以下となる。ちょっと高め（アンテナ短め）となっているが、145MHzを中心にSWR<1.2は144.30から146MHzと運用上は特に問題がないと思われる。

とにかく構造が簡単なので、移動先でも調整することもなく（調整するにも出来ない）運用が可能というところがうれしい。

手荷物としてまとめた姿。

Windows 10やWindows 11でデスクトップ上のアプリ画面を全て最小化する方法の備忘録。

Windowsキー + D

これを押すと、デスクトップ上に表示されているアプリ画面が一斉に最小化される。再び押すと元に戻る。

と～きどき、アプリ画面が全て最小化されてしまう事があったけど、どうやらこのキーをおしてしまっていたみたい。。。。しらないとちょっと焦る。

EchoLinkでの特定局からの接続を拒否する方法。ちょっと場所が分かりにくかったので備忘録。

Tools -> Preferences

Deny these calls に接続拒否局をセットする。

接続拒否設定された局の端末では以下のメッセージが表示される。

Connection Failed.
Cannot connect to JA0WBT-L - Access denied

こんな表示なので、相手にはアクセス拒否設定されたことがわかってしまうんだけれども。。。。

IC-705が届いた。これでD-STARが出来るようになる。

さて、ターミナルモードを設定する前段階として、ネット環境の設定をしないといけない。そもそもIC-705がそれ以前のリグに比べて優れている点はWifiを具備し自らが直接インターネット接続できることで、ゲートウエイを内蔵したことにあるようだ。705以前はインターネットに接続したPCを用意し、それをゲートウエイとすることでターミナルモードを実現していた。

一般的にインターネットで双方向通信を行うには双方がグローバルIPアドレスで通信することになるが、普通は家庭内機器にグローバルIPアドレスを割り当てることは容易ではないので、ポート開放（Port Forwarding）を使うことになる。ポート開放はルーター上で行うので、ポート開放されるリグとルーターは一対一の関係となる。この関係を確実なものとするためケーブルでのネット接続が望ましい（というか安心だ）。Wifiを使うと話はややこしくなる。Wifiルーターが2台以上ある家庭で、PCやリグ側でWifiアクセスポイントを複数設定してあると、Wifiの接続状況に応じてWifiアクセスポイントを自動で切り替えるからだ。これだと一対一の関係が維持できない。

家庭に複数台のWifiルーターがあったとしても、契約プロバイダーが一つだと家には終端装置が一つだけで、まずはそこにWifiルーターが接続されているはずだ。これを元ルーターと呼ぶと、それ以外のWifiルーターはその元ルーターからカスケード接続されることになる。一方ポート開放は元ルーターに対して設定するので、ポート開放前提のリグはこの元ルーターに接続しないといけない。そもそも、複数台のWifiルーターを備えている家は家の場所によっては元ルーターの電波が届き難いからだと思う。つまり、リグの設置場所は元ルーターの電波がそれなりの強度で飛んでこないといけない。ということでシャックと元ルーターの位置関係が問題となる。

内はこの位置関係においてハズレだった。シャックの位置は動かせないので元ルーターを動かすことにした。終端装置の直ぐ横に置いておいたルーターを屋根裏に移動した。古民家ゆえ、ほこりっぽいのでシューズが入ってた箱にいれた。

これでポート開放設定するWifiルーターがシャックの近く（正確には家の真ん中）に設置できたので、ポート開放が設定できる。

さて、705にはポート開放に加えてUDPホールパンチが備わっている。とりあえず分かっている範囲でその違いをまとめてみた。

ポート開放による局間QSOはとてもシンプルで双方が相手のグローバルIPアドレスに送信するだけだ。コールサインとIPアドレスのテーブルは管理サーバーが持っているので、送信に先立ってToコールサインのIPアドレスを管理サーバーに問い合わせる。呼び出しを受けた際に相手先コールサインをRX-＞CSボタンで設定するのは、管理サーバーにIPアドレスを問い合わせるコールサインを設定するためのようだ。また、ターミナルモードを使うには管理サーバーに自身のコールサインを登録しないといけないのもこの理由によるみたいだ。実際コールサイン登録時にIPアドレスが登録項目にあったが、あれがIP値の初期値だったように思う。このIPアドレステーブルは実際に管理サーバーにアクセスする度に更新されるので、初期値はどうでもよいみたいだ。

一方UDPホールパンチによる局間QSOはちょっとややこしい。そもそもポート開放を行わないので自分の信号をどうやってルーターの裏にいる相手局に届けるかが問題だ。UDPホールパンチはNATテーブルを活用してこの課題を解決しているようだ。

NATテーブルはルーター裏のローカルIPと通信先となるインターネット上のグローバルIPアドレスを関係づけている。つまり送信元のローカルIPアドレスと送信先のグローバルIPアドレスの関係を保持することで、送信先から返答が戻ってきたときに、その返答をこのテーブルをつかって送信元のローカルIPアドレスに届けるわけだ。つまり発信元手動のテーブル設定になっている。よってこの方法ではインターネットからの呼び出しを受け取ることができない。

UDPホールパンチでは、まず通信する2局を決めてから、それぞれの局側のルーターに、お互いの相手局に向けての信号を送ることで、NATテーブルを作成させる。そうすることで、相手局からグローバルIPアドレスでおくられてきた信号をロカールIPアドレスに変換するようにしている。そのため、交信相手を決めると、管理サーバー経由でその交信相手に自分への信号をおくる（NATテーブルを設定する）指示を出す。自分は交信相手が分かっているので管理サーバーにその相手局コールサインのグローバルIPアドレスを問い合わせ、そのグローバルIPアドレスに信号を送ることでNATテーブルを設定できる。一旦NATテーブルが設定できれば、双方向通信が可能となる。

課題は、こちらから呼び出すことが前提条件で、任意の局からの信号を待ち受けることはできない。

設定が終わったらならやま自動応答で自分の信号が正しくネットに送られたことを確認する。

上記が確認できてからエコーサーバーに接続すれば、自分の変調をエコーバックしてくれるので、変調が乗ることも確認できる。

これらの局は705の個人局リストに登録済みになっている。というか、そう意味だったのね。

IC-705のターミナルモードで海外レピーターをモニターしたい。それには海外レピーターリストをインポートする必要があるようだ。

ICOMのホームページから更新レピーターリストをダウンロードする。

ダウンロードされるZIPファイルの中身はこんな感じ。

まずは買ってきたmicroSDカードをIC-705にセットしてフォーマットし、設定セーブを実行する。
SET -> SDカード でそれらが実行できる。実行が終了したらIC-705の電源をオフしてmicroSDカードを取り出す。

取り出したmicroSDカードをPCにセットして内容確認。microSDカードはこんな感じのフォルダー構成となっている。

ダウンロードしたZIPから以下の2つのCSVファイルをIC-707￥Csv￥RptListに保存する。
705_J_GPS_200618.csv,  705_J_RPT_221222.csv


RepMoni_sample.csvはIC-705￥RptMoniに保存する。

icfファイルはIC-705￥Settingに保存する。

保存が完了したら、microSDカードをIC-705に戻し、パワーオン。

以下を実行して海外レピーターリストと、日本のレピーターリストを導入する。

① SET -> DVレピーターモニター設定 -> 接続先IPアドレスリスト（海外）-> RepMoni_sample.csv

② SET -> SDカード -> インポート/エクスポート -> インポート -> レピータリスト -> 705_J_RPT_221222.csv  

以上を実行したところで、早速海外レピーターをモニターしてみた。USAに合わせると確かにMONIが白表示されている。ずっと聞いているとCQを聞くことができた。まずは設定はうまくいったようだ。

追伸

接続先IPアドレスリスト（海外）はインポートしない、つまりmicroSDを直接アクセスすることになるようなので、このmicroSDはIC-705のスロットに挿したままとなる。

IC-705にパワーアンプMX-P50Mを接続した場合の送信出力測定結果。

MX-P50M製品仕様 (Aliexpressより)
-周波数帯域: 80m 40m 30m-17m 15m-10m
動作モード: ssb cw am、rtty、fm-デューティーサイクルの削減
-RF入力: 5w
パワーアウト: 45w
-Bandモード: 手動
-必要電力: 13.8v 8a、赤 "" 黒 "-"
-冷却方法: パッシブ空冷
アンテナコネクタso-239 50オーム
-サイズ: 155*100*35ミリメートルd * ワット * h
-重量: 0.55kg

MX-P50Mのパワー測定環境は下図の通り。ダミーロードで終端したSWR/パワーメータにてMX-P50Mの出力を測定する。IC-705の外部電源は外部電源からの供給としている。

システム全景。MX-P50Mの電源は13.8V/30Aの電源で供給する。

同軸ケーブルの接続の様子。

パワー測定はIC-705出力の最大出力を10Wに設定した上で、出力レベルを10％から50％まで10％間隔で増加させることで測定した。52%を測定しているが、これは52%がリコメンデーションとのアドバイスを頂いたため。

7.090MHz

３.5MHz、21MHz、28MHz

結果と考察

製品仕様として最大入力5Wに対して出力は最大40Ｗとなった。周波数によって最大出力は変化して、28MHzでは40Wに対して21MHzでは32Wとなった。また入力３Wまでは出力はリニアに増加するが、それを超えると周波数によって出力の伸びは変化する。傾向としては4Wを超えると出力はサチる感じである。よって、最大入力4Wまでが無理のない運用との印象を受ける。

ISSの信号を145.825MHzでモニターした。

以下IGATE TrafficとしてのISS関連シグナル。ただし、Jan-27,10:11:50のRF to Internetはテスト用に手持ちのハンディから発信したビーコン信号。

RF to Internet

・・自作ビーコン発生機からFT-70Dを通して発信した確認用信号
2023-Jan-27 10:11:50 JA0WBT-7>SUTPW9,WIDE1-1,JA0WBT-10,I:    
`AB(l!-[/`"9C}_0

・・ISSから受信した信号
DX6RANがRS0ISSを通して発信した（RS0ISSがレピーターとして機能）信号
2023-Jan-27 13:10:33 DX6RAN>APWW11,RS0ISS*,JA0WBT-10,I:
=1044.71N/12258.22Er(Time 0:00:00)!INSERVICE!
以下の3つはRS0ISS自身が発信した信号
2023-Jan-27 13:12:34 RS0ISS>0P0PS1,APRSAT,JA0WBT-10,I:
'v&l SI]ARISS-International Space Station=
2023-Jan-27 13:15:34 RS0ISS>0P0PS0,APRSAT,JA0WBT-10,I:
'v&l SI]ARISS-International Space Station=
2023-Jan-27 14:48:41 RS0ISS>0P0PS0,APRSAT,JA0WBT-10,I:
'v&l SI]ARISS-International Space Station=

Internet to RF

・・インターネット経由でポルトガルのCT1ENIが当局を経由してRF送信
2023-Jan-27 14:15:11 (Port 2) JA0WBT-10>APU25N:
}CT1ENI>CQ,TCPIP,JA0WBT-10*::RS0ISS :QSL and 73 via ISS

つまり自分がDigipeaterとして機能しているという意味になる

Local Station

・・ローカルステーションとしてRS0ISSが記録されている。
RS0ISS

JJ1WTK局が公開されているISS Packet受信状況。当局の受信記録もログられている。

Facebook RigExpertグループに投稿した内容をこちらにまとめておく。

事の発端はローカル局のアンテナ調査。6m同軸ケーブルでSWR＝1.9位になる件。同じアンテナで10mだとSWR＝1.1。そこで、ケーブル・インピーダンスを計ろうと思ったことが事の始まり。

ケーブル端に50Ωのダミーロードを付けてケーブルSWRとR,Xを測定したが、SWR=1.45、R＝72Ωと出た。ちょっと変なので、AA-1500に直接ダミーロードを付けて測定した。

Photo-1がダミーロードを取り付けているところ。Photo-4でDC抵抗が50Ωであることを確認。

この状態でもSWR＝1.44（Photo-2）、R＝72.75Ω（Photo-3）。System Impedanceは50ohmとなっている(Photo-5)。何かがおかしい感じがするのでSelf testを実施したらLoad Testにて232エラーとなった。232エラーが何を意味するかわからないけれど、Self Testがエラーに終わったのはわかる。

この状況をRigExpertグループにて報告したら、ダミーロードが3GHzまで対応するアダプターなしのダミーロードでないのがいけないとのコメントをいただいた。いいかげんなダミーロード取り付けが原因でSelf Testがエラーになるという指摘は反論することができないが、この状態でR＝72.75ohmというR,X Chartが出てくることは納得がいかない。50Ωのダミーロード直付けでR＝72ってのはどう見ても変だ。

Self TestがちゃんとしたダミーロードならPassするのだろうか？これはちゃんとしたダミーロードを買って試してみるしかない。一方AA-1500にはCalibration機能がある。カジュアルな方法になるけれども手持ちのダミーロードでキャリブレーションしてみたくなった。そのうえでケーブルインピーダンスを計ろうと思う。

まず同軸ケーブルの等価回路から特性インピーダンスを求める計算式を設定する。測定はRG58/1.5mと5D2V/6mの2本で行った。Open、Short試験でのShortではM型メスコネクターにて芯線と外被線をショートさせた。

それぞれのケーブルの特性インピーダンスはともに70Ω程度となった。50Ωのダミーロードを直結した状態とほぼ同じだ。なので、系としてはちゃんと動作している感じだが、インピーダンスが50Ωから随分と外れている。

そこでCalibrationを実行。

キャリブレーション後のケーブルインピーダンスはおよそ50Ωと算出された。こうならないとおかしい。

実際のアンテナのSWRがCalibration適用有無でどう変化するかを確認した。

SWRの変化の様相は周波数によって異なることがわかる。ただ、思いのほかCalibrationの影響が現れていない感じもする。周波数によってSWR値が変化する（10MHz）場合とSWR値はそれほど大きく変化しないが共振点が変化する（14MHz）場合があることがわかる。

よくよく考えてみるに、なぜCalibration機能があるのだろう？ここについてはもう少し考えてみたい。

XR2206を使ったFunction Generator kitを作った。このICはFSKをサポートするのでその動作について確認した。

奥がKit、手前がFSK切替信号を発生させているPico。

このキットは中国製で、正弦波と三角波を生成するFunction Generator。少ない外付け部品で広範囲の周波数の信号を作ることができる。回路図は以下のとおり。キットの回路図にFSK実験用のR10とPICO接続端子、SINE出力のAC成分だけを取り出すようにC10を追加している。

このXR2206はTC1・TC2間に接続されるコンデンサーCとTR1（P7）とTR2（P8）のそれぞれに接続される抵抗値R6,7,8とR10によってそれぞれ2つの周波数を生成する。この周波数のどちかを出力するかをFSKコントロール端子（P9）によって選択する。発生する周波数は以下のとおり。

F = 1/RC

キットの回路図にR10を接続し、FSK制御信号として、Picoから8msecインターバルの信号を入力した。その結果が以下のオシロスコープ出力結果になる。

周波数の切り替えはスムーズだ。全く同期がとれていない2つの発信波形を切り替えると、切替時点でレベルが大きく変化するが、XR2206は波形のレベルが引き継がれている。これってどうやって実現するんだろう？？優れものだと思う。

アマゾンでオーダーしたNEO-7M GPSモジュールが中国郵便ePacketで届いた。PICO-TNCのGPSモジュールとして使えるか確認する。

届いたのはモジュール基板とアンテナモジュール、ピンヘッダー。

ピンヘッダーを半田付けして、RS232Cレベル変換モジュールを通してPCのコムポートに接続してGPSモジュールの出力を見てみた。

GPSモジュールは以下のテキストデータを1秒間隔で出力し続けている。

$GPRMC,013837.00,A,3540.78920,N,13738.11534,E,0.134,,150123,,,A*76
$GPVTG,,T,,M,0.134,N,0.248,K,A*2B
$GPGGA,013837.00,3540.78920,N,13738.11534,E,1,06,1.91,540.5,M,36.5,M,,*53
$GPGSA,A,3,25,32,24,10,23,12,,,,,,,3.20,1.91,2.57*09
$GPGSV,3,1,09,10,47,226,29,12,51,054,26,22,29,312,10,23,26,190,12*7B
$GPGSV,3,2,09,24,22,071,09,25,79,103,30,29,12,146,08,31,26,273,26*77
$GPGSV,3,3,09,32,61,324,29*48
$GPGLL,3540.78920,N,13738.11534,E,013837.00,A,A*6D

この出力内容の内、$GPGGAはプロトタイプで使っていたGPSモジュールが出力していた$GNGGAとフォーマットが同じであることが確認できたので、この出力をそのままPICO-TNCのコードに読み取らせた。

結果は良好で、PICO-TNCはビーコンを発生することができた。なお、NEO-7Mモジュール基板はGPSデータ出力時にLEDを点灯する。よって、このLEDの点灯でGPSデータ受信が行われていることが分かる。

NEO-7Mモジュールをプラケースにねじ止め固定した。

蓋を閉じる前の様子はこんな感じ。ケース内のスペースにはまだ若干の余裕がある。

蓋を閉じるとこんな感じになる。FT-70Dよりも一回りちょっと大きなケースとなるが、プロトタイプ1号機としてはまずまずの出来だと思う。

PICO-TNCとFT-70Dで近所を軽トラ（超低速）で走ってみた。Beaconインターバルは1分。プロットはいずれも移動経路上にあり、GPSとしては使いそうと判断した。

このNEO-7Mモジュール＋アンテナモジュールはアマゾンで850円程。送料が800円かかる。とりあえず追加で3個をオーダーした。

追記

このGPSモジュールは捕捉できるGPS衛星の数が５から8個程度のようだ。秋月で購入したGPSモジュールは、みちびきも捕捉できるので12個だった。つまりこのGPSもジュールはそれなりの誤差があるということだ。

$GPGGA,013837.00,3540.78920,N,13738.11534,E,1,06,1.91,540.5,M,36.5,M,,*53
$GPGGA,202824.00,3540.79166,N,13738.11552,E,1,07,1.55,510.8,M,36.5,M,,*59
$GPGGA,221438.00,3540.78683,N,13738.11710,E,1,08,1.10,513.7,M,36.5,M,,*52

実験をしている作業場所をGoogle Mapでみてみると35.67982（3540.7892）、137.63527（13738.1162）とでてくる。標高も30メートルは前後する様子だ。

PICO TNCのdemodulatorにおける信号処理を調べてみた。

demodulatorはADCデータを1バイト読み込み、ある値sumを出す。sumを算出するに当たってdemodulatorは以下の信号処理を行っている。

• Bandpass Filter 入力:adc  出力:val
• Digital Correlator (Delay) 入力:val  出力:m
• Lowpass Filter  入力:m  出力:sum

それぞれの処理後の値をプロットしてみた。

まずは全体像。それぞれの値に大きな差があるため、わかりにくくなっているが、mとsumの関係はわかる。

ADCデータ列

Bandpass Filterの出力。通過周波数は900Hzから2500Hz。これによってOffset成分がなくなる。

Delayの出力。DelayはMarkとSpaceのTone差を最大化することを目的としている。これにより、両Toneの分別がしやすくなる。ここでは446usのDelay値を積算することで1200Hzは正値、2200Hzは負値となるようにしている。一般的なDelayはDelay値を加算しているが、ここでは積算している。
  m=val[t] * val[t-446us]    なお、Sampling Rate =1200x11では6サンプル分遅延した値を積算している。

6サンプリング前の値を取り出す方法として、6エレメント（6サンプル）のリングバッファを使っている。リングバッファの場合、現在のポインタをtとすると、t+1は現在よりも5サンプリング前のデータが格納されている。t+2は4サンプリング前、、、、といった具合。なのでtは今から6サンプリング前のデータ格納されている訳で、その値を取り出してから、tに新しくサンプリングしたデータを格納する。こうすることで、過去のサンプリング値を取り出したあと、そこに新しいサンプリングデータを格納し、ポインターを一つ進める、という動作を繰り返すことで常に6サンプリング前のデータを取り出すことができる。

Lowpass Filterの出力結果。カットオフ周波数は1200Hz。プラス部分がSpace（2200Hz）、マイナス部分がTone（1200Hz）となってる。逆に言えば、この波形を取得するためにDelayを使っている。

レベル識別の閾値は以下のとおり

• sum <  - 4096 : bit=1 (Mark)
• sum >=  4096 : bit=0 (Space)

DIGITAL PLL

Ditigal PLLは11回で1 Time Domainを形成している。

• PLL Counter Step = 390,451,572
• PLL Counterは正値5回負値6回、または正値6回負値5回の合計11回で1 time domainとなる。
  
  • PLL Step 11回でbit decode
• 入力bitに遷移が発生した時にPLL Counterを25%調整する。
  
  • PLL Counter値が負値の場合は25％加算し、正値の場合は25％減算する。

このPLL Counter値の正負で25%加算減算するのがミソで、bit遷移が発生した時点でのPLL Counter値からPLL Counter値自体を調整し、遷移点とTime Domainの位置関係を保っている。

実験結果

PICO_TNCが発生するAFSK信号をPCに取り込み、サンプルコードでDelay（積算）とLowpass Filterを通してみた。

Beaconデータ：ダウンロード - mice7mono.wav

Delayコード：ダウンロード - dd_psude_stereo2.c

Delay後データ：ダウンロード - mice7mono_output.wav

LPFコード：ダウンロード - dd_lpf2.c

LPF後データ：ダウンロード - mice7mono_output_output.wav

Windows 10における以下問題の対応と方針

• wappxのシステムリソース消費大
• スタートメニュー表示なし
• 検索欄に入力できない

作業記録

gpeditにてwappxを未構成に設定。ターゲットPCは既に有効に設定してあった。有効設定でもwappxは可也のCPUとメモリーの両リソースを消費していた。

Regeditにてsvchostのwappxをclipsvc AppXSvcからNotFound AppXSvcに変更

以上でCPU使用率およびメモリー使用率はかなり低下した。

その他問題で実施したこと

スタートメニューが現れない件（参照リンク）

以下を試したが効果なし。

システムファイルの整合性等の確認

• DISM.exe /Online /Cleanup-image /Restorehealth
• sfc /scannow

システム必須アプリの再導入、PowerShellから以下を実行

• Get-AppXPackage -AllUsers |Where-Object {$_.InstallLocation -like “*SystemApps*”} | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register “$（$_.InstallLocation）\AppXManifest.xml” -Verbose}
  この実行は10時間以上時間がかかる。Powershellは途中でエラー終了してしまった。

検索入力が出来ない件（参照リンク）

以下を試したが効果なし。

• ctfmon
• コマンドプロンプト管理者権限で以下を実行
  REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v ctfmon /t REG_SZ /d CTFMON.EXE

復帰ポイント12月23日に戻す（Edgeのインストールがおこなわれていたようだ）-> 戻すことはできたが

スタートアップオプションからスタートアップ修復  -> スタートアップ修復するものがない

セーフモードからの回復、更新プログラム実施前に戻す　-> 更新から10日以上経過していると戻せない

--------

上記いずれもNG。イベントビューアをみると以下のエラーが多発している。

障害が発生しているアプリケーション名　TextInputHost.exe
障害が発生しているモジュール名　KERNELBASE.DLL
TextInputHostに障害が発生すると日本語変換にも影響がでるらしい（参照リンク）。

このTextInputHostのエラーがスタートメニューや検索での問題を引き起こしている可能性が高いと判断。上記参照リンクではインプレースアップグレードによる修復でリカバリー成功している。

TextInputHostに関する修正がKB5019157にて昨年Windows11に適用されている。恐らくWindows10にも適用がされたのではないかと思うが記録なし。ターゲットPCでは12月15日更新プログラムが適用された記録があるので、この変更がエラーの引き金になっている可能性が高い。しかし、更新から10日以上経過していると更新前には戻せないようだ。

KERNELBASE.DLLが何でエラーを出し続けているかは不明。何かしら入力デバイス（タッチパッドなど）から異常な入力が頻発するとこうなるのだろうか？こうなるとインプレースアップグレードが視野に入ってくる。デバイスマネージャでタッチパッドをアンインストールしても状況は変わらず。次の再起動でドライバー再導入となったが状況変わらず。

KERNELBASE.DLLの修復に関する記述から、KERNELBASE.DLLの入れ替えが有効と思われる。しかし、この作業をマニュアルで行うことはリスクが高い。むしろインプレースアップグレードを行う方が安全・確実と判断できる。

Windows10のインプレースアップグレード

手順に従ってインプレースアップグレードを実行する。インプレースアップグレードとはシステム部分のみを上書き（アップグレード）するWindowsインストール手法。

この時点での結論

Windows10のインプレースアップグレードを実施する。一般的な修復作業では改善が見られず、手探りでWindows内部に手を入れようとするとWindowsのデスクトップが立ち上がらなくなるリスクを伴うので、インプレースアップグレードにより包括更新を行うのがベストな対応と判断される。

作業内容の詳細

Group Policy Editorによる修正

ストアの更新プログラムの自動ダウンロードおよび自動ダウンロードを未構成にする。

Registryの修正

Windows 10無印ではgpedit.mscが存在しないのでRegistryを直接編集する。
コンピューター\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost
既に何かがインストールされているとxxx AppXSvcとエントリーされているはず。ここをNotFound AppXSvcとModifyする。
なお、Registry変更の場合は必ず事前にエクスポートして変更前データを保全しておくこと。

wappxの自動更新の未構成設定とRegeditによるwappxプロパティの変更の前後でのパフォーマンスモニター改善

作業前：wappxがCPUをかなり消費している。

修正後。wappxによるCPU消費は改善された

System File Checker (sfc) によるシステムファイル確認

破損ファイルが見つかったが正常に修復された。

DISMコマンドによるScanHealthtとRestoreHealthの実行

その後のsfcで正常性を確認。

上記作業後もスタートメニュー、検索とも改善無し。

Windows アプリ更新作業の実施（背景画面）22時から翌日7時まで実行後、途中でPowerShellが停止してしまった（前面に出ているファイルリストはイベントビューでエラーがログられているtextinputhost.exeの保存先）。この後の再起動でWindowsが立ち上がらなくなり（Explorer起動エラーと思われる）、タスクマネージャから再起動をかけたところWindowsが復旧した。このことから、真の原因が不明なまま大きなアクションを実行することはリスクが伴う判断する。

イベントビューワーのApplicationのイベントログには3分間隔でTextInputHost.exeの障害がログられている。障害を発生しているモジュールはKERNELBASE.dllなので、仮に障害対応を実施するとなるとKERNELBASE.dllに対して行うことになる。

TextInputHost.exeとの関係で入力デバイスの問題を仮定し、TouchpadをDisableしてみたが効果はなかた。

念のため、スタートアップオプションで修復作業を試みたがいずれも効果は無かった。



回復オプションで、explorerのシステムエラーがレポートされた。今回の障害との関連は不明だが、何かしらの異常な（大量な？）入力が行われている事を示唆しているようにも感じる。

加えてとても気になるのが頻繁（2,3秒おき）に回転リングが表示されることだ。これとKERNELBASE.dllとの関係を疑ってみる。

定期的にシステムリソースを消費しそうなアプリで、かつ年末にインストールされたものとしてAvast Antivirusが目に留まった。

これをアンインストールしてみる。結果は効果は認められなかった。

以上

追記

インプレースアップグレードによって今回の問題は解消！！！

やっぱりマニュアルでチマチマ作業するよりは一括で更新がリスクも少なく安全と実感した。ただし、Windows 10が最新バージョンに更新されることで戸惑うアプリもあるようだ。実際、更新後にAcrobat Readerが互換性問題を検出し、継続使用するか否かのユーザー選択を求めてきた。

手順はシンプルでWindows 10ダウンロードリンクにアクセスし、ツールを今すぐダウンロードをクリックする。後は表示される手順に沿って作業を進めるだけ。ただ、その前にセキュリティツールをアンイストールすることがRecommendされている。これはセキュリティツールがWindows インストールを阻害する（システムファイルへのWriteアクセスをさせない）場合があるため。インストールプロセスが途中で停止してしまい、システムが不定状態になると厄介なので、ここは確実にアンインストールする。実際の作業ではNorton 360をアンインストールしたが、このアンインストールに先立って、後の再インストールの為にユーザーアカウント情報を保存するか聞かれるので、保存するを選択する。これによってWindows 10インプレースアップグレード完了後にNorton 360をインストールすれば、アンインストール前の状態に戻せるはずだ。

Windows 10ライセンスを含めた個人情報が引き継がれると思うので、Windows 10の再インストール後も自分用にカスタマイズされたWindows 10環境はそのまま維持されるはずだ。

Windows 10インストール自体は結構時間がかかる。

Windows10本体のインストール後は更新プログラムのインストールが続く。この過程で何度か（5回くらいだったか）リブートする。

一連のインストール/更新作業が完了すると、ログオン画面が現れ、ログオンするとWindows 10インストール前のデスクトップが維持された状態でWindowsが立ち上がる。

事前情報通り、個人情報とアプリ環境はそのままでWindows 10本体が最新バージョンにリフレッシュされたようだ。このリフレッシュにより、イベントログ上もKERNELBASE.DLLエラーが引き起こしていた一連の問題がシステムログに記録されることは無くなり、障害は解消されたことがわかる。

以上

AFSKの復調について大変参考になる情報があったので、その要約も含めて備忘録。

復調における課題：

• Low SNR
• Hight Twist -  Mark信号とSpace信号の大きな振幅差
• Phase distortion - Mark信号とSpace信号が符号境界に到達しない
• Inter-Symbol interference - Mark信号とSpace信号がPhase Distortionにより重なる
• Frequency Distortion - Tone周波数とData Rateとの大きな差
• No error correction - 1ビットエラーで破棄

Hight Twist対策

Digital Correlator

Comb Filter（自らの遅延信号によりその信号自体を増幅する手法）の利用。

Delayを最適化することでMarkとSpaceのTone差を最大化することができる。
Zero Cross Detectorを使ってアナログ信号をデジタル変換し、同じDelayをComb Filterに適用する。

テストでの入力信号は以下。ジッターを発生させる低周波成分が含まれていてこのままではZero Cross Detectorにかけられない。

1200Hz-2200Hzを通過させるBandpass Filterを通すと、低周波成分が除去できる、

Bandpass Filterを通した波形をZero Cross Detectorにかける。

Digital Comb Filterを適用する。Digital Comb Filterでは以下を実行する。

1. Zero Cross Detector出力をDelayさせた信号とXORを取る
2. 得られた信号に対してLow Pass Filterをかける。
3. 得られた波形に対してZero Cross Detectorをかける。

XORを取った信号波形

Cutoff 760HzでLowpass Filterをとおした波形

Lowpass Filterを通した波形に対してZero Cross Detectorをかける。

Clock Recovery

送信信号に対して、受信側のクロックを同期させる必要がある。そうしないと上記Bit Periodが得られない。

この為にTX Dlayがある。TX Delayで送られる信号でこのClock同期をとる。よってTX Delayはそれなりの長さが必要となる。

この過程においてCarrierシグナルからビット周期（パルス幅）を測定する。

クロック同期をとるためにDigital PLLをつかう。Digital PLLはジッター量を計り、そのジッター量により、Data Carrierに同期しているかを判断する。

ここでは、シンボル周期をサンプリング数22で測定している。この範囲で上記矩形幅によってPLLを遅らせたり、進めたりする。

ロック状態と判断するには、ジッター幅が1.1サンプル以内になった時、アンロックと判断するのはジッター量が4.4サンプル以上となった時。

APRSでのNRZI方式について備忘録

APRSはHDLCフレームをAX.25で転送するとの理解で考えると、APRSのTNCはNRZ-SpaceでEncode/Decodeしていると解釈される。

NRZ-Spaceはレベル遷移をゼロで行う。一般的なNRZIは1でレベル遷移実行となっているからここが大きな違いだ。

これについてはWikiwandに書かれている。以下がNRZ-Space部分の抜粋。

Non-return-to-zero space

"One" is represented by no change in physical level, while "zero" is represented by a change in physical level. In clock language, the level transitions on the trailing clock edge of the previous bit to represent a "zero".

This "change-on-zero" is used by High-Level Data Link Control and USB. They both avoid long periods of no transitions (even when the data contains long sequences of 1 bits) by using zero-bit insertion. HDLC transmitters insert a 0 bit after 5 contiguous 1 bits (except when transmitting the frame delimiter "01111110"). USB transmitters insert a 0 bit after 6 consecutive 1 bits. The receiver at the far end uses every transition — both from 0 bits in the data and these extra non-data 0 bits — to maintain clock synchronization. The receiver otherwise ignores these non-data 0 bits.

更に重要なのは赤字部分。1が5つ続いたら0を挿入すること。これを知らないとデコードが出来ない。

GitHubからダウンロードしたpico_tncのsend.cのsend_byte()についての考察記録

なぜ、mark_tabのサイズは121なのか,、そしてspace_tabのサイズは96なのか。

wave_table.h

#define PHASE_CYCLE 6

#define MARK_TAB_LEN 121 // 66 * 5/6 + 66

#define SPACE_TAB_LEN 96 // 36 * 5/6 + 66

mark_tab[MARK_TAB_LEN]={.....　　1200Hz正弦波

space_tab[SPACE_TAB_LEN]={....     2200Hz正弦波

phase_tabは、spaceは6サンプリング周期ごと、markは11サンプリングごとに区切られ、6区画で1波形となる。

つまり、1波形を6等分したもの＝60度分。

1200baudでは66サンプリングで1サイクル＝360度となる。

static const uint32_t *phase_tab[2][PHASE_CYCLE] = {

{ &space_tab[0], &space_tab[6], &space_tab[12], &space_tab[18], &space_tab[24], &space_tab[30], },

{ &mark_tab[0], &mark_tab[11], &mark_tab[22], &mark_tab[33], &mark_tab[44], &mark_tab[55], },

};

phase_tabには1波形分のサンプリングを6等分（60度分）した数の波形データが入れられており、最終エントリーの先頭から66サンプリング分（360度＝1DMA分）が設定されている。つまり、どのエントリーからDMAを始めても1DMA分のデータは揃っていることになる。

send.c

dma_handler()

....

データの1bit単位で波形を1サイクル分設定する

phase_tabから取り出すポインターから66サンプリング分（360度分）がdma_blockに格納される。

   tp->dma_blocks[next][idx++] = phase_tab[level][phase]; // 0: space, 1:mark

仮にlevel=1, phase=5の場合、phase_tab[1][5], つまり mark_tab[55]（300度）から66サンプリング（6phase分＝360度分）が取り出されることになる。

したがってサンプリングテーブル（mark_tab）はその長さ分（66ｘ5/6＝300度）が1波形分（66＝360度）よりも余分に必要となる（合計 66x5/6 + 66=121）。

level=0, つまりspaceだったら次回の生成波形は60度（6サンプリング分）波形を前にずらす。

   if (!level) { // need adjust phase if space (2200Hz)

      if (--phase < 0) phase = PHASE_CYCLE - 1;

   }

減算する前のphaseが0、つまり先頭だったら最後尾にする。

なぜspace (2200Hz）だと１波形ごとに6サンプリング分前にずらすのか。

1200Hzで1サイクルが完結する時間スロットでは2200Hzでは2200/1200=11/6サイクル発生することになる。

つまり、サイクル完結に1/6（60度）足りない。仮にこの時間スロットの開始点で2200Nz波形を連続して生成する場合、その波形は前回の開始点波形にたいして1/6サイクル分（60度）後戻りした時点の波形から始まらないと連続性が保てない。

1200Hz波形は2200Hz波形を11/6倍だけ時間方向に引き伸ばしたものと考えることができる。よって2200Hzの後に1200Hz波形を同じタイムスロットで連続性を保って生成するには11サンプル分（60度）後戻りした時点の波形から始めると波形の連続性が保てることになる。

この様子を図示すると以下となる。Markが1サイクルする時間間隔ではSpaceは出力ゼロになるまで60度足りない。次の波形を連続させるには次の波形を―60度ポイントから波形生成を始める必要があるわけだ。

そもそも、1200Hzと2200Hzでのビット表現となるとどうしても波形は不連続になるが、その事は問題なのだろうか。

この事に関する記述がある。

この波形不連続は、1200Hzと2200Hz以外の非常に多くの周波数成分を発生してしまうようだ。このノイズ成分により、信号復調率が落ちるのだろう（多分）。

PICOのPIOを使ったPWM信号出力をDMAで動作させる方法について備忘録

注：PIOを使ったPICOのPWM機能をDMAで動作させる方法はいまいちわからなかった。（というか、PIOのTX FIFOにデータを送った場合、PIOはGPIOピンに0/1信号しか出せず、PWMレジスターに値を書き込めない。そもそもDMAには自己完結型のDREQインターバル設定ができるので、DMAでPWMレジスターに値を書き込むだけなら、PIOは特に必要ないかも。。。）

ここではPIOに32ビットデータを1ビットずつ設定した周期でGPIO出力させることでPWM信号を作る方法について備忘録する。

• DMAはDREQによってDMA転送を1データ単位（32ビット）ごとに実行する。
• DMAは自らのDMAインターバルによってDREQを自動発生することもできる。
  
  • channel_config_set_dreq(&pwm_dma_chan_config, DREQ_PWM_WRAP0 + led_pwm_slice_num)
• DMA ch構成では、転送ソースアドレス、転送ターゲットアドレス、転送カウントを設定する。
  
  • dma_channel_configure(
    　　dma_chan,　　　　　// DMAチャネル
    　　&dma_chan_config,    // DMAチャネル構成情報
    　　&pio0_hw->txf[state_machine_id], 　// PIOのTX FIFO
    　　// &pwm_hw->slice[led_pwm_slice_num].cc, // PWMレジスタの場合
    　　data_table, 　　　　　// データ元
       　256,                              // 転送カウント
    　　false                             // スタートタイミング（即時スタートの場合はtrue）
    );
• DMAは設定した転送カウント分の転送が完了するとIRQを発生する。
• このIRQを使って次回DMA転送するデータを設定する。

• PIOはTX FIFOの1データ単位（32ビット）を取り出す。
• 32ビットを1ビット取り出すにはshiftを使う
  
  • channel_config_set_transfer_data_size(&dma_chan_config, DMA_SIZE_32);
    新しくTX FIFOからデータを取り出すまで1ビットずつシフトし1ビットずつとりだす動作を32ビット行う
• PIOのTX FIFOが空になるとDREQを発生させる。
  
  • channel_config_set_dreq(&pwm_dma_chan_config, DREQ_PIO0_TX0);
  • 上記と以下は等価
    channel_config_set_dreq(&pwm_dma_chan_config, pio_get_dreq(pio, state_machine_id, true));
• 対象とするDMA chにこのDREQを紐付けることでTX FIFOが空になるごとにDMAを行うようにする

＝＝＝＝＝＝＝　Program 1　DMAだけ、IRQなし　＝＝＝＝＝＝＝

Main C Program

#include <stdio.h>
#include "pico/stdlib.h"
#include "hardware/dma.h"
#include "hardware/pio.h"
#include "hardware/clocks.h"
#include <hello.pio.h>

int main()
{
   PIO pio = pio0;
   uint state_machine_id = 0;
   uint offset = pio_add_program(pio, &pio_dac_program);
   pio_dac_program_init(pio, state_machine_id, offset, PICO_DEFAULT_LED_PIN, 2000.f);

   int pwm_dma_chan = dma_claim_unused_channel(true);

   dma_channel_config dma_chan_config = dma_channel_get_default_config(pwm_dma_chan);

   channel_config_set_transfer_data_size(&dma_chan_config, DMA_SIZE_32);
   channel_config_set_read_increment(&dma_chan_config, true);
   channel_config_set_write_increment(&dma_chan_config, false);
   channel_config_set_dreq(&dma_chan_config, pio_get_dreq(pio, state_machine_id, true)); // pio sm, TX

   dma_channel_configure(
      dma_chan,
      &dma_chan_config,
      &pio0_hw->txf[state_machine_id],
      data_table, 
      256, 
      false 
   );

   dma_channel_set_read_addr(dma_chan, mark_tab, true);   // DMAをスタートする

   while(true) {
      tight_loop_contents(); 
   }
}

PIO Program

.program pio_dac

.wrap_target
   out pins, 1
.wrap

% c-sdk {

static inline void pio_dac_program_init(PIO pio, uint sm, uint offset, uint pin, float fs) {
   pio_sm_config c = pio_dac_program_get_default_config(offset);

   sm_config_set_out_shift(&c, true, true, 32);
   sm_config_set_out_pins(&c, pin, 1);
   // sm_config_set_fifo_join(&c, PIO_FIFO_JOIN_TX); これはなくても動作は同じ
   sm_config_set_clkdiv(&c, (float)clock_get_hz(clk_sys) / fs);

   pio_gpio_init(pio, pin);

   pio_sm_set_consecutive_pindirs(pio, sm, pin, 1, true);
   pio_sm_init(pio, sm, offset, &c);
   pio_sm_set_enabled(pio, sm, true);
}
%}

＝＝＝＝＝＝＝　Program 2  DMAとIRQの両方　＝＝＝＝＝＝＝

Main C Program

検証にあたってはこのブログを参考にした。