bookmark_border[30] 嬉しい体験

しばらく6mでFT8を「ながらワッチ」していたら、突然当局が呼ばれて驚きました。PCで他の作業をしている最中で、何気なく画面を見たら赤文字が現れ、2~3秒は経過していたのですが慌ててクリックすると無事一発でQSOが成立しました。

当局がCQを出したのは10分以上前ですし、その後もQSOをしていないのでなぜ私がワッチしているのがわかったのでしょうか・・・もしかすると私がまだいると思ったのかも知れません。(当たりです)

あるいはPSK Reporterを見たのかも知れませんね。いずれにせよ、他局から呼ばれるのは嬉しいことです。

bookmark_border[29] FT8(強い信号の波形)

ワイドスコープのウォーターフォールで受信信号を見ていると、強く受信する局の波形がたまに別の場所にも現れることがあります。

少々見づらいですが、900Hz近辺に本体の信号があり、2700Hz近辺には幅の広い信号が出ています。2段のうち上段の半分ほどに来たところでリグのAGCをONにしたら2700Hz近辺の信号は消えました。

送信側の信号の歪なのか受信機の性能の問題なのかわかりませんが、前者の場合、私の信号も同じように他の局に影響を与えている可能性があり、ALCには留意が必要であること再認識しました。

bookmark_border[28] FT8(CQの波形)

JTDXのワイドスコープでウォーターフォールを眺めていたら、CQ局の波形に共通点があるのを発見しました。

FT8 CQ

これは2局がCQを出しているときのウォーターフォールの画像を切り出したもので、共通点としては人が右を向いて口を開けているように見えます。他のCQ局の波形も見てみましたが、やはり同じような形でした。ただし信号が弱いと判別が難しくなります。

おそらく「CQ」を8値のコードに置き換えると、波形的にこのように左の方に偏り右側に大きな空間ができるのだと思います。PCがデコードし表示する前にCQを受信しているのかどうかわかると、何かメリットがありそうな気がします。

bookmark_border[27] ブラジルとの初QSO

15mバンドのFT8でブラジルの局とQSOできました。相手局が他局へ73を送る前にTXをセットしてダメ元で呼んでみたら、当局は-16dB、相手局は-9dBでQSO成立しました。南米自体初めてで、しかも周波数をこちらに寄せてきてくれて二重の感激です。

QRZ.comを見ますとどうもその局はeQSLはやっていないようですので、紙QSLを交換しようと思います。

bookmark_border[25] CPU負荷状況

FT8信号受信の際、CPUにどの程度の負荷がかかるかをタスクマネージャーで観測しました。

CPU1

15秒周期でCPUがほぼフル稼働していることがわかります。ここでは1サイクルあたり24局分のデコードに成功していますが、CPU稼働率はほぼ100%です。おそらくこれ以上の局数には対応できないものと思われます。

下は別のバンドでの受信中、極端にデコード率が悪くなった例です。

CPU2

ここでは8局しかデコードされず、「音声の損失 8」と表示されていますのでPCとしては計16局受信した認識はあるものそのうちの半分しかデコードできていないことがわかります。

CPUの負荷グラフでは、最後のデコード時から遡って1周期半(約20秒)あたり前から継続して負荷が重くなっています。詳細を見ると、このタイミングで「svchost.exe」が立ち上がっているようです。これはWikipediaによると「複数のWindowsサービスを受け持つシステムプロセス」だそうで、簡単に消すことはできないとのことです。

どのような頻度で「svchost.exe」が立ち上がるのかはわかりませんが、自分が交信中にこれが立ち上がると相手局の信号がデコードできなくなり、当局のCPU性能が原因でQSOが成立しなくなるおそれがあります。何か良い方法がないものかと思います。