F/H super fox mode デコードできない問題解決

現在オンエア中のK8Rが実はFT8 Fox and Hound のsuper fox modeで運用をしているらしい。

American Samoaは持っているけど、これは今後に備えて一交信はしておかねばなるまい。

WSJT-X 2.7.0-rc5をダウンロードし、D:￥Program files(x86)の下に￥wsjtxのフォルダを切って、そこにインストール。

インストール後、K8Rが出ている周波数に行ってワッチしてみるが、呼ぶ局はデコードするが、ご本尊がデコードされない。

ご本尊の信号はJT65の時間圧縮版みたいな小刻みに音程の変わる信号だと思うのだが、そういう可聴音が聞こえているのにデコードできない。

2.7.0-rc5のバグかもしれないので、その改善版をインストールしてみたがそれでも症状変わらず。

そんな時、2.7.0-rc5で確認されているバグを眺めていたら「インストール先のフォルダにスペースがあるとデコードできない」というものがあった。まさに今インストールしてあるフォルダ名には半角スペースが入っている。

そこで、インストール先をD:￥wsjtxにして、インストールしなおしたら、ちゃんとご本尊をデコードするようになった。

何なんだこのバグは・・・。

その後17mで、Super fox modeにしてK8Rを呼んだら、無事に拾われた。

YAESU SCU-17 はTS-480でも使える

この前の記事で、現在リグ~PC間のインタフェースが故障中と書いた。

今まで使っていたのがテクニカルシャックさんの「DIF-3S」だが、先日20mFT8で3DA0AQを呼んでいるときに、突然変調がかからなくなってしまった。そして信号もPCに入力できなくなってしまった。たまに何かの加減で使えるようになるのだが、どういうときに使えなくてどういうときに使えるのか分からない。

この製品ももう12年以上は使っているはずで、そろそろ部品レベルの寿命なのかも…と思い、メーカー品のインタフェースを探すことにした。

しかしこの手の製品はなかなか見つからない。そもそも最近のリグはもとからUSBがついていてPCと直結できるらしいのだ。結局メーカー品として手に入りそうなのは八重洲の「SCU-17」だけだった。

八重洲製品しかないのか…と思ったのだが、ネットで調べると実はケンウッドのTS-480（現在の私のメインリグ）でも使えるらしい。実際SCU-17のマニュアルを見てみると一連の八重洲製品のほかに「Interfacing to other transceivers」という説明がある。

私はFT-857も持っているので一台あっても損はないと思い、さっそくamazonでポチる。

8月12日、買い物から戻ると荷物が届いていた。

早速箱を開けてPCにドライバをインストールし、PC、TS-480と接続。配線としては説明書にあるFT-450Dと同じにした。

リグの電源を入れて、PCでJTDXを立ち上げると、すぐに何の問題もなくデコードを開始した。試しにVR2の局を呼んでみるとこれも無事応答が返ってきた。RS-232CのケーブルもつないだのでCATも機能し、リグで周波数を変えるとJTDX側の周波数も変わる。

DIF-3S時代に比べると配線も整理されてすっきりした（マイク入力や音声出力が不要になった）。こんなに簡単だったら早く買っておくべきだった。

SU1SK 17F、パイル参加中に他の局に呼ばれることについて

7月9日。

20:30ころ17mを覗くとSU1SKが大サービス中。MSHVで同時に3-4局を相手にしながらさばいている。

信号も-7dB前後で全く問題ない。これはチャンスがあると思って呼び続けてみたが、呼ぶ人も多く、なかなかリターンが返らない。

断続的に呼び続けているとJTDX上に自分が呼ばれたことを示す赤字の表示が出た。やっとリターンが来た！と思ったらDLの某局が私を呼んでいるのだった。そのまま無視していると3回くらい呼んで引っ込んだ。

SU1SKのパイルの様子を見ながら再度呼びに行くと、またこのDL局が呼んでくる。SU1SKからのリターンなのかこのDL局から呼ばれているのかがソフト上では瞬間的に見分けられないので、非常にうっとおしい。

22時過ぎにもう何度目かのチャレンジで再び呼ぶと、JTDX上に赤い字が出た。またDL局が呼んできたかと思って送信停止ボタンを押すと、なんと今度はSU1SKからの応答だった。あわてて再度送信ボタンを押してRR73を送った。

すると、またSU1SKからR-17という応答が来た。これはこちらのRR73が届いていないということなので再度RR73を送るのだが、そのような状況でもまだこのDL局は呼んでくる。

パイルに参加しているときに、別の局から自分が呼ばれることはFT8ではよくある。そのような時、そもそも自分はそのパイルになっている局と交信しようとしているのだから、原則応答しないことにしている。同じように、パイルに参加している局を私が横から呼んだりはしない。

CWなどではこういうことはまずないのだが、FT8は違うDFを選べば信号が重ならないので、結構カジュアルに呼んでくる。SUとJAのレア度を比べれば当然SUの方が珍しい。その辺のことはDL局にも分かると思うんだけどなあ。

FT8ペディションモードとQSOの機会均等化

夏のKH1/KH7Z、Baker and Howland Ｉｓ.のペディションで本格的に使われ始め、先日のVP6D、Ducie I.ではすっかり定着した感のあるFT8ペディションモード。

最初は、送受信にそれぞれ15秒掛かるFT8の効率の悪さを改善する単なる「QSO効率化」モードではないかと思っていたのだけど、実際に二つのペディションで使ってみて、実はそれ以上の効果をもたらす今までにないモードなのではないか？という気がしてきた。

「それはどういう効果なのか？」と言えば、

「従来のパイルアップに伴う様々な弊害を軽減し、Fox局とHound局の間に電波伝搬さえあれば、パイルアップ参加局にQSOの機会を均等に与える効果」が期待できるということ。

そう考える理由は以下の通り。

（１）Fox局とHound局が同時に送信してしまうことがない。

⇒これはペディションモードと言うよりはFT8の効能なのだが、従来のパイルアップでは意図するしないに関わらず、DX局の送信中に呼んでしまう局が後を絶たない。FT8ではそんなことをしていたらいつまでたっても交信できないので、そういうことをする局は減る方向に働くはず。

（２）Hound局は、他のHound局と周波数がかぶらないように呼ぶことが出来る。

⇒これもFT8というかWSJT-Xの機能のおかげなのだが、WSJT-Xにはバンドスコープが付いているので、自局で受信できる限りにおいて他のHound局をうまく避けながら呼ぶことが出来る。帯域幅も50Hzしかないので、UP1～3KHzの間であれば、最大40局がお互いかぶらずに呼べることになる。これは従来のモードでは成しえない効果。

（３）一度ピックアップされたら、他のHound局に邪魔されず交信を進めることができる。

⇒これはペディションモードの良く考えられた機能。Up0～1KHzの間は、ピックアップされた局との交信のために予約されているので、いわゆる「呼び倒し」をする局に邪魔されることなく、交信終了まで持っていける。

以上のような理由から、FT8ペディションモードのパイルは、従来のモードのパイルに比べてかなり「お行儀良く」なっているはず。Fox局のほうはスキマー的に、ある一定の帯域幅の中の聞こえた（見えた）局をピックアップしていくわけだから、基本的に、Fox局とHound局の間に電波伝播があって、信号が届いてさえいれば、そのうちQSOのチャンスが訪れるように思える。

DX局を追いかけるには、どうしても高いタワー、多素子のビームアンテナ、そして高出力のリニアアンプを必要とするが、それは「相手に電波を届けるため」と言うよりは「パイルアップに勝つため」という側面が大きい。環境面、資金面でそういったものを用意できないDXerは長年涙をのんできたと思うし、そういった力まかせの世界に嫌気が差している人も多いはず。しかしFT8ペディションモードの登場はそういった状況に変化をもたらす可能性がある。

もちろんFT8ペディションモードの交信はレポート交換のみで、それ以上のメッセージを交換することは出来ないし、Fox局が複数局を相手にし始めれば、Fox局の信号ががくんと弱くなってしまう原理的な問題はあるのだが、個人的には従来のDXの世界に付きまとっていた嫌な側面を幾分でも改善してくれそうな気配がして、今後FT8ぺディションモードがどのようなモードとして受け入れられていくのか、期待している。

80mのFT8 デコードできるようになった

昨年12月28日のブログで、3.572にダイヤルを合わせるとFT8のデコードが出来ないことを書いたのですが、先日、なぜか分かりませんが、デコードできるようになりました。

デコードできるようになったと理由として考えられるのは、ウォーターフォール画面の上に出る受信周波数を示す緑の「U」型のマークを、ウォーターフォール画面上の何か受信している場所（3.573MHzより上の周波数）に持っていったこと。この操作をしたら、まずその周波数の信号がデコードできて、そのあと、3.572～3.575の間の信号を複数デコードするようになりました。

今は、WSJTを起動すれば80mでもどのバンドでも、おおむね3KHzの範囲の信号をちゃんとデコードしてくれます。何が悪かったのか良く分かりません。

ともあれ、80mでFT8が使えるようになったので、しばらく運用してみたところ、WでもVKでもあっさりQSOできてしまいました。もう少し早い時期に80mでFT8が使えていたら、この冬のローバンドが楽しめたと思うのですが。。。

FT8で北米東海岸

今朝はゆっくり7時半頃起床。

特に狙っているDXもなかったけど、ベランダのアンテナを伸ばしてワッチしてみると、20mのFT8で東海岸の局が見えている。東海岸なんて久しく交信していないので、WSJT_1.9.0-rc3の習熟をかねて呼んでみる。

■パイルになっている局の呼び方

WSJTでは今まで、CQを出した局を見つけてから、その局をダブルクリックして呼んでいたのだが、最近のFT8の局数の増加で、その局が呼ばれて続けているときは（パイルになっているときは）、CQを出さずにそのまま次の局と交信していくことが多くなってきた。そういう場合、どのタイミングでダブルクリックをすれば良いのか確かめてみた。

これはそれほど難しくはなくて、パイルになっている局が「73」を送信したのが画面に出た直後に、ダブルクリックすればよいようである。

■再送の仕方

さて、今日つまづいたのがこれ。

K2EQ局を呼び、首尾よく拾ってもらえたのでレポートの交換をし、最後にこちらが「73」を送ったところ、それが相手に届かなかったようである。なぜなら、K2EQ局が再度「RRR」を送ってきたからである。

それをみて再度「73」を送ろうとしたが、その送り方がわからない。WSJTのソフトのほうは、もう交信が完了したと認識しているので、当然「73」の自動再送なんてしてくれないのだ。

もたついていたらそのうち相手が「73」を送ってきてくれたので、交信としては一応成立したと思うのだけど、こういう細かい操作はもう少し調べないといけなさそうである。

FT8の80m

今年の秋からFT8の運用を始めたのだが、いまひとつ使いこなせないでいる。

一番困っているのは80mの運用。リグのVFOのダイヤルを3.573MHzにして受信すれば各局の信号がデコードできるのだが、3.572にするとまったくデコードできない。

3.573MHzで運用するとオフバンドになると言うことで、WSJT-Xも3.572の設定にしてあるのだが、3.572にVFOをあわせてデコードできたためしがない。

WSJT-Xの画面を見ていると、JAの局も結局3.573で運用しているように見えるのだが、大丈夫なのだろうか？