bookmark_border[615] 「バナバ島」その後

昨日は、12mと17mでもFT8でバナバ島とつながりました。これで合計4バンドです。

今回もDXPeditionのシーケンスに忠実に従って流していきました。ただ、先日も書いたように当局のJTDXではDXPeditionモードで「Use hound TX frequency control」がONにならないため、相手局からレポートが送られてきたタイミングでオンフレに切り替え、更に当局宛てのコールをダブルクリックしてRレポートを返信するという操作が必要です。

またワッチしていると、DFを変えなくてもQSOできた局もいましたので、無理にオンフレにする必要は無いのかも知れませんが、そこが今一つ理解できていません。

繰り返しになりますが、以下がHoundとしての標準的なシーケンスです。

  • スプリット(RigまたはFake It)を使用
  • TX用DFは1000Hz以上の空いているところに設定
  • Fox呼び出し時にはGLを付ける(Tx1で送信)
  • Foxからレポートが送られてきたら、それを受信したDFでRレポートを返信
  • FoxからRR73を受信してQSO終了(73は返信しない)

これが自動で進まないのが課題ですが、何か単純なことを見落としていると思いますので、改めて他の設定を含めて見直してみることにします。

bookmark_border[611] 再び15m FT8での混乱

昨日も15mバンドで悪戦苦闘しました。

初めに12mで運用しバナバ島やトーゴの局から応答して貰ったのですが、こちらの返信レポートがうまく届かなかったようで、いずれの局ともQSOは未完に終わりました。その後、15mにQSYし再度バナバ島の局にチャレンジしたところ、ようやくRR73を貰ってシーケンスが終了しました。

当局はJTDXを使っているのですが、Houndモードに設定しても「Use hound TX frequency control」がグレーアウトしてこの機能をONにできませんでした。

この機能の目的自体あまり理解していませんが、相手局へのレポート返信時にオンフレで送信するものだろうと勝手に解釈し、相手局からレポートが送られてきたタイミングで、JTDXの「Locked Tx=Rx」ボタンを押しました。

ただ、上の交信プロセスを見ると他局に対するDFになってしまっています。再び相手局からレポートが送られてきたためそれをクリックすると今度はうまくいったようで、RR73を受信しました。

DXpeditionについてあまり理解しないまま運用してしまい、少し反省しています。

それから、QSO後に気付いたのですが、DFが全体に上の方にズレています。あとでリグの周波数表示を見ると21.073MHzになっていて、FT8のQRGよりも1KHz低い周波数を示していました。なぜ変わってしまったかは分かりませんが、交信中もJTDXのウォーターフォールを見てFoxのDFが1000Hzを超えたところに来ているのは認識していました。FoxのDFは数百Hzの領域を使うものと思っていましたので何か違和感はありましたが、その時はQSOを成立させるのに必死でキャリアがズレていることまで考えが及びませんでした。

まあキャリアが多少(?)ズレていたとしても直接たたいて変調している訳ではないので、キャリア周波数+トーン周波数(DF)で帳尻があっていれば良いと思っています。

なお備忘録も兼ねて、Houndとしての振る舞いを以下のとおり纏めました。

  • スプリット(RigまたはFake It)を使用
  • TX用DFは1000Hz以上の空いているところに設定
  • Fox呼び出し時にはGLを付ける(Tx1で送信)
  • Foxからレポートが送られてきたら、それを受信したDFでRレポートを返信
  • FoxからRR73を受信してQSO終了(73は返信しない)

当局が使っているJTDXのHoundモードでは「Foxからレポートが送られてきたら、それを受信したDFでRレポートを返信」が自動でできなかったためマニュアルでやってみました。これは上述のとおり「Use hound TX frequency control」がONにできないためと思われます。この設定方法について勉強が必要ですね。

(11/7追記:他の方の交信記録を見ますと、このバナバ局とは途中でDFを変えることなくQSOが成立しているようです。ということは、これはDXpedition(F/H)モードではなくMSHVなのでしょうか・・・?)

 

bookmark_border[595] FT8 最大DT差許容値?

昨夜430 FT8で、DT差が「+2.5」の局とQSOが成立しました。

信号は割と強かったのですが相手局のSNRがかなり変動しているため、これほどのDT差ではデコードの限界だったのかと思います。

過去のブログ記事によると、これまでの最大は「+2.4」のようです。

「DT=2.4」局とのQSO成功

DTズレ

なお、自分自身のDTがズレているかもと疑いましたが、他局のDTを見ると大丈夫のようでした。

DT差について国内QSOではあまり気になりませんが、DXでしかも新エンティティ局との間で大きなDT差があると、それに合わせてQSOしようとするかも知れません。未だそのような状況には遭遇していませんが・・・

 

bookmark_border[534] JTDXアップデート(157→158)

JTDXを「2.2.158」にアップデートしました。

しばらくはこのバージョンがリリースされたのを気付かずにおり、それをネット記事で知ってJTDXサイトにアクセスしたもののPCからセキュリティアラートが出たのでダウンロードを見合わせていました。しかしそれも解消されたようですので遅ればせながら作業をしました。

その後、このバージョンで何局かとFT8でQSOしましたが、見た目には前バージョンとの違いはわかりませんでした。TCI(Tranceiver Control Interface)関係の改善とかFT8デコーダのバグフィックス等含まれるようですが、残念ながら当局はここに書けるだけの知識を持ち合わせていません。

なお、先のバージョン「157」から送信時に送信出力とともにSWR値が表示されるようになったのですが、これまでPCの負荷を考えてそれらの表示は消していました。今回「158」にアップデートしたのを機に表示をONにしてしばらく様子をみたところ、特にPC動作には影響無さそうでしたので今はONにしています。

FT8の送信中はリグの表示を「ALC」にしているため、PC上で送信出力とSWRが同時にリアルタイムでモニタできるのは便利です。ちなみにSWRが1に近い場合は値が表示されませんが、これはバグなのでしょうか・・・?

bookmark_border[511] RRRと73

昨日に続いてシーケンス繋がりの話題になりますが、以前も触れたように、かつてはJTDXでFT8を運用していると相手局からRRRが送られて当局から73を返信した後に何も返ってこない場合、こちらから自動で73を再送していました。

他方WSJT-Xでは、RRR後に73を受信するとそこでQSO完了というのが正常なシーケンスであることをブログ記事から学びましたので、その後はRRRを受信して73を送出した後は、Halt Txボタンを押して送信しないようにしています。

なおCQを出している局に応答する場合は、こちらからGLを送らずにいきなりSNRレポートを送ればRRR問題は避けられます。ただ国内もDXもそうですが、CQ局に対してGLを送るか送らないかは結構悩ましいです。自分なりの明確な基準は特に無いですが、バンドが混んでいるときはGL無し、比較的空いているときはGL付きでコンタクトしているような気がします。

また、相手によってはGL無しではダメとか、GLは煩わしいので不要とか色々と考えがあると思いますので、そこは周りの状況を見ながら臨機応変に対応ということでしょうね。

ところで、つい最近のことですがRRRを受信しこちらから73を送出した後、試しにHalt Txを押さずに様子を見ていましたら、相手局から73が返ってこないにもかかわらず、こちらからは73を再送しませんでした。JTDXのバージョンはv2.2.157です。これまでのアップデートで上記問題は解消されていたのかも知れません。全く気が付きませんでした。

ちなみに今公開されている最新バージョンは「158」ですね。先日JTDXサイトを見たときはセキュリティアラートが出ていたのでアップデートはしなかったのですが、先ほど見たらアラートも出ずにアクセスできましたので、折を見てアップデートしようかと思います。