PR

FT8を運用してみて

FT8を使い始めて約十日。この間、FT8に限定して運用してみた。WSJT-X 1.8.0-rc2も出たことだし、ここらで一旦まとめてみる。

交信局数を数えてみたら100局ほどだった。JT65やJT9で既にQSO済みの局も多い(数えてはいないけど)。一方で、ニューエンティティも数局。

FT8は15秒で送受が入れ替るのでスピーディではあるが忙しい。とは言え、基本は自動でシーケンスを進めてくれるので手間要らずでもある。そのあたりは、こちらの記事に書いた。

FT8 初QSO
FT8の申請が通ったことだしQSOしてみようと思いWSJT-XのモードをFT8にしてみたところ、「Auto Seq」と「Call 1st」というチェックボックスがあることに気づいた。こりゃ何だ、ということで、早速検索。見つけたのがこちらのブ...

「Auto Seq」と「Call 1st」は常時オンにしている。これ以外ではまだ使ったことがない。「Call 1st」をチェックしていない場合は、自分で応答する局を選ばなきゃいけないのだろうから相当慌ただしいと思う。

シーケンスのうち、「Tx 5」はプリセットのマクロを選択できるようになっているけど、送信の際に勝手にクリアされて標準メッセージに置き換えられる。Auto Seqにしていなければ、クリアされずに選択したものが送れるのかな?こうしたこともあってか、自由テキストを送ってくる相手はほぼ皆無。これまでに一局だけだったかな?他人のQSOをモニタしていても、そういうのはほとんど見かけない(ゼロでもない)。

それから、JT65などに比べて、デコードの限界値がよくないため、再送を繰り返すことも多い。これに関しては、こちらの記事。

FT8、意地の再送
FT8だとデコードできなかった場合には自動再送してくれるので手間はかからない(オートシーケンスモードを使っていれば)。FT8はJT65に比べて受信限界レベルが良くないので、この自動再送が機能することが多々ある。今回、自動再送がかなり続いたQ...

CQ局を二回くらい呼んで応答がないので諦めて「Enable Tx」をオフにしたらその後で応答があったということも多い。これも、デコード限界がよくないことの影響か?こういうときは慌てて「Enable Tx」をオンにする。諦めて(DFを変えて)こちらがCQを出したら、その段階になってさっきの応答が来るということも何度か経験した。この場合はWSJT-Xのオートシーケンスがキチンと働いてQSOが進む。このときにこちらのCQに別の局から応答があったらどうなるんだろうと思うが、今のところ、その経験はない。たぶん「Call 1st」が効いて先にデコードできた方でシーケンスが進むんだろうとは思う。

FT8の送信時間は12.64秒。そこからデコードが始まって、15秒になると次の送信が始まる。デコード時間を考えると、送信開始タイミングまで1秒あるかどうか。なので、デコード結果からCQ局を見つけて、選択(クリック)し、「Enable Tx」をクリックする、という一連の動作をやっていると送信開始タイミングに間に合う訳がない。

では、次のタイミングまで待つしかないかというと、そうでもない。多少、送信開始が遅れても相手はデコードできるようだ。例えばこれ。

先方のCQが00秒開始。なので、本来ならそれへの呼出は15秒から始めるのだけど、操作に手間がかかって17秒からの開始になっている。2秒ほど遅れてしまっているが、先方からの応答がもらえている。こんな感じで、多少の遅れは許されるようだ。慌ただしいことに違いはないが。

ちなみに、JT65だと何度か再送しているようなので、こんなワザも見かけたりする。

JT65による時分割送信、というのかな?
JT65では約50秒間送信するが、そのすべてを受信できなくても復号できる。実際、分の途中から受信を始めたり、逆に途中で(他のバンドに移ったりして)受信を止めても復号できることも経験している。 で、これを巧みに使った(?)、時分割送信とも言え...

JT65は冗長送信の仕組みを持っているので時間がかかるけれど、その一方でデコード限界が低いのだろう。

FT8のデコード限界も、WSJT-X 1.8.0-rc2で改善されている。リリースノートによれば、場合によっては-24dBまでデコードできるらしい。私自身が確認できたものでは、-22dBというのがあった。

今後、さらに改善されることを期待しておこう。それがJT65側にも反映されて-30dBとかまでいけたら嬉しいな。

それから、WSJT-X 1.8.0-rc2で改善されたものと言えば、オートシーケンスの挙動。CQ局を呼び出して応答がもらえなかったとき、rc1ではそのままずっと呼び出しを繰り返していた。それがrc2ではCQ局が他の局に応答した場合には、こちらの送信が停止される(自分が受信している周波数で応答があった場合。CQ局が別の周波数に移って他局に応答した場合は自動での送信停止はなされない。挙動をよく見ていると、自分が受信している周波数での応答ではなく、自分が送信している周波数でCQ局が他局への応答を行った場合に自局の送信が停止されるようだ。スプリットでCQ局を呼ぶと、他局とのQSOが始まっても自局の送信は停止されない(呼び続ける))。ムダな送信をしないようになっている。どんどん自動化されると面白みが減ってくる気がしないでもないけど、こういうムダの排除は助かる。今後にも期待。


【追記】
3秒遅れでの呼出しでもとってもらえた。二回確認できたので、(運が良ければ)3秒遅れでも大丈夫だと考えて良さそうだ。


【追々記】
5秒遅れでの呼出しでもとってもらえた。

ここまで遅れても大丈夫なことは、さすがにそうそうはない。でも、運が良ければこういうこともあるという例ではある。諦めずに呼んでみるべし。


【追々々記】
4秒遅れの例。

コメント