FT8でのQSOが終ってTurbo HAMLOGで記録しようとしたときに、時刻が間違っていることに気づいた。
QSO開始時刻は12:59 UTC。しかし、Turbo HAMLOGの画面では10:37 UTCになっていた。Turbo HAMLOGのバグかと思ったのだけど、JT_Linkerの時刻が10:37。ということは、WSJT-Xがおかしいのだろう。wsjtx_log.adiを開いてみたら、案の定、10:37と記録されていた。
じゃ、この10:37はなんだ、と画面をさかのぼってみた。
なるほど。この時刻にCQを出して応答をもらっていたのもの、途中で尻切れになったQSOがあった。そのときはオンエアはそれで一旦終了した。しばらく経ってからまたCQを出して、QSOが成立したのが今回。どうやら、WSJT-Xは先のQSOが続いていると認識したようだ。終了時刻は130045と今回のQSOの終了時刻が正しく記録されている。
- CQを出す
- A局から呼ばれる
- A局に応答するものの途中で尻切れ
- 再びCQを出す
- B局から呼ばれる
- B局とのQSOが正常に終了する
- WSJT-XはA局とのQSOの開始時刻を今回のQSOの開始時刻として記録する
尻切れになったと思ってCQに切換えたら、コンディションが戻ってA局からの応答が見えてくることもあるので、A局との開始時刻を保留しているという仕様は間違いではないのだろう。でも、別のコールサインの局と通信を始めた時点で、（内部の）開始時刻を更新して欲しいなぁ。
対策としては、尻切れQSOになった場合には、次の通信終了時にWSJT-XのLog記録時に注意することくらいだろうか？
なお、この動作を確認したのはWSJT-X 1.9.0-rc3。再現確認はしていない。
これまでに、eQSLで「Wrong Time」で何件かリジェクトしたけど、こういう理由だったのかも。ごめんなさい。
コメント
6mのFT8。Esが開いて8エリアが聞こえていた。CQを出している8エリアの局を呼んだが、別の局に応答。その交信が終わった後に、その8エリアの局が私を呼んできた。
最初のCQに対してGLなしでSN付きで呼んでいたため、8からのメッセージは「R-09」。予期せぬ事態に反応できず交信は成立しなかったのだが。もし、あのまま交信をしていたら、交信開始時刻はいつになるんだろうか。8から「R-09」を送ってきたときになるのなら、私は交信中に相手にSNレポートを送ってないことになるのではないか、と。
その時から後、DX以外はCQを出している局を呼ぶときはGL付きで呼ぶようにしている。
コメントありがとうございます。
ただいま、このブログはトラブルが発生しております。サービス提供会社と連絡を取り、復旧方法を模索しているところです。復旧した際には、頂いたコメントが消える可能性があります。何卒、ご了承ください。