JT65/JT9と、FT8を1ヶ月ほど運用しての所感

2017年11月末に変更届の審査が終わり、12月頭から運用を始めて、約一ヶ月経過しました。

以下、所感です。

・DX局には拾ってもらえない

と言いますかバンドそのもののコンディションや、私が使っていたアンテナ・送信出力(ローバンドで最大40Wほど)もありますが、やはりJT65/JT9に比べて、3〜6dBくらいレポートが悪い印象で、なかなか拾ってもらえません。40mbでは北米西海岸とインドあたりまでが限界でした。

みなさんどれくらいパワー出してるんですかね???

個人的な印象としては、特にローバンドではデコード率が良いRTTYというような感じで、ひょっとするとリニアで数百W出してる局が居ても不思議では無い感じでしたねぇ。

・auto SEQはじゃじゃ馬

パソコンは2013年頃のcore i5、4コア4スレで3GHzくらいの奴だったと思います。自分の時計をプラマイ200msec以内に合わせて、WSJT-Xでも送信開始に間に合わずに自動で応答できないケースが結構ありました。

この年末年始に限定するとJTDX18.1.0.xの開発評価版(人柱版)はその他に色々バグがあって、auto SEQは自分のところでは最初のCQへの応答についてはほぼ使い物になりませんでした。

応答を見たらダブルクリックしてましたので大体1秒は遅れてしまいました。メッセージ部でデコードできないのは多分そういう遅れなんでしょうね。

・国内ではそこそこ便利に運用可能

7041/3531で運用した限りでは、国内ではそこそこ交信成立するので早く終わるのは良いかもです。

ただ、年末年始に固めて運用して、現在運用中の皆さんで信号が強めの方は大体QSOいただいた為か、今回の帰省運用での後半は、JTDXでのJT65の運用で-19〜-23dBくらいのかなりキツイ条件で応答を頂くことが増えました。FT8で同じ条件なら多分交信に至ってなかったのではと思います。

・CQを出す前にワッチしない局が増えた気がしました

受信条件とか、私の設備の問題もあるのでしょうが、空いているときから連続でCQ〜交信と運用して居ても、いきなりdfを重ねてCQを出されるケースがありました。

7041に関しては国内は2〜2.5kHz内でFT8もJT65も共存して運用しています。FT8にせよJT65にせよ、JT65での2ターン程度(1:30ほど)のワッチは必要だと思います。

・耳が悪い場合は…

まれにかなり送信出力が高いのか、受信環境が悪いのか、こちらからのレポートといただくレポートで、ほぼ毎回10dB以上の差がある方がいらっしゃいます。もちろんレポートが悪くなる要因には混信とか近接局の強い信号でのブロッキングなどもあるとは思いますが…

ただ送受のレポートの差が、自分から送る方が常に10dB程度低い方は出力をもう少し絞るなりして送受のバランスをとった方が良いのでは無いかと思いました。

余計なお世話かもしれませんけど。

・無理にJCC/JCGコードを送る必要はありませんし、「型」通りで最初はOKです。

特に最近始められた方なのかもしれませんが、こんなパターンがたまにあります。

CQ JH8JNF QN23

JH8JNF JAxXXX PM95

JAxXXX JH8JNF -05

JH8JNF JAxXXX R-08

R JCG01027 73

(送信が無い)…(1)

CQ JH8JNF QN23…(2)

C100101 TU 73…(3)

JH8JNF JAyYYY PM95…(3)

こんな感じでこちらへの(1)の送信で戸惑ってしまって次の送信を控えられるケースで、次のターンのCQ((2)のCQ)への応答で送信される場合((3)で同時送信になる)がたまにあります。

無理に合わせてJCCコードなどを送る必要はありませんから、サラッと6回のやりとりで終わるのがお互いに綺麗だと思います。

他には(1)のところで、こちらからRRRを送るまで延々とR-08を送られるケースももっとあります。実際に混信などでこちらの送信がデコードできなかったりするのかもしれませんが、もしデコードできているなら、これもサラッとファイナルを送り返していただけるとお互いに楽かなと思います。

それから今回気になったパターンでは、常にレポートをRなしで送る方にも遭遇しました。これもグリッド付きの応答をされた方で、こちらからのレポートに対して応答がR抜きです。

この「R-08」のRはroger(了解)の意味のはずです。レポートへの応答の場合はR-xxの形が普通だと思います。

まあ細かいことを言うとこちらからのファイナルでのJCGコードの送信もRRかRRRにすべき、と言う話はありますけどね。

スムーズに交信が終わるようお互いに気をつけたいものです。

広告

2017-2018交信状況

少し長めの年末年始のお休みをいただきまして、12/28~1/9までJCG01027におります。

40mbのCWでJCG01027をお探しの方がいらして、CWでサービスしたのと、少々FM/SSBで遊んだ他はもっぱらJT系モードばかりとなりました。

JT9の運用局はほぼ壊滅で、国内外ともJT65/FT8が主な運用です。が、FT8ではなかなか海外には飛んでいってもらえません。

まず、12/28~1/7までのJT65での交信状況;

帰省20172018JT65

やっぱりこっちの方が安心感とのんびり感、出力上げなくても飛んで行ってくれる感があります。3.5のDXは1局はアメリカ、ユタ州でした。(3531でCQを出していたらコールされました)

いっぽう、FT8はこんな状況となりました。

帰省20172018FT8

運用局が多い分DXが多少JT65よりも多いのですが、JT65では北米とかヨーロッパを多少含みますが、FT8では北米ですら結構厳しく、ロシアのアジア地域や中国ばかりな感じです。(それでもインドが出来たような記憶があります)

ハイバンドの状況がよければまた違った結果になったかも。

40mbの深夜、ヨーロッパが開けている時間に7076でJT65をワッチすると東欧を中心に結構運用局がいるようです。

JT65/JT9の復権を期待しています。

JT65でやっとWAJAができました

7041で国内QSOするのに、WAJAを当面の目標としていました。

JCCの方は多分300位はいっていると思うのですが、WAJAは鳥取県がなかなか取れず…

本日7041をワッチしてたら3401(鳥取市)の方が出ていたのでコール、やっとQSOできました。

WAJA

JT65を運用し始めた頃、カードは来た物にリプライするような運用でしたが、国内からはかなり高確率でいただくことがわかったので最近は原則全発行になっています。

これから残りの件を受領したらデジタル特記で申請の予定です。

JTDXを18.0から18.1へ

twitterで、JTDXがFT8に対応したという情報を見かけまして、今晩、18.0.xから18.1.xに更新しました。

GUIにAutoseqだったかなんだったかそんなのが追加になっています。JT65でも動くようです。(ひょっとしたら18.0でもあったのかもしれない)

18.0までは、WSJT-Xの1.7ベースのプログラムだったようですが、18.1からはWSJT-X 1.8ベースになったみたいです・・・が、そのまま更新したのでは、周波数リストは元のまま=FT8の運用周波数が追加されず、また80mbも従来の3.576MHzがQRGになってしまいます。

FT8とか3.5のQRGを追加する手間と、JAの国内用の周波数を追加する手間を脳内で比較しまして、「周波数リスト」をリセットすることにしました。3.531/7.041はいつものように手動で追加です。ところで、WSJT-Xだと周波数リストを「保存」できるようなんですがJTDXだと保存できないんですね。

さて、国内局相手にFT8の練習をするかとも思いましたが、今日は何かトイレが近くて(笑)、せわしないモードは結局使わずじまい。

JTalertXのモニター局の数を見ると、もはやJT9が絶滅危惧種になってしまっています。そしてFT8が多すぎるかなぁ。

WSJT-X 1.8.0-rc2のインストール

FT8の申請、WSJT-XのRC2が出たら出す、と公言していたのでそろそろ申請せねばなりません。(とはいえ、川崎の方の環境からだと海外とQSOしてるわけでもないので、今度北海道から運用するときまでに出せば…的な考え方になってしまってます)

さて、今(2017/09/07 0200JST頃)、WSJT-Xの配布サイトで公開されているWSJT-X 1.8.0-rc2の、少なくともwindows用のインストーラもしくはアプリ本体にバグ、ないしインストール時の仕様変更かインストールフォルダ等の変更があったようで、アップグレードインストールだと、大変に困ったことが起きます。

周波数リストが空になります。

古い(1.8.0-rc1等)版がある場合はそれをコピーして残しておくとよさそうです。

残さずにインストールしてしまった方(私がそうw)は、コールサイン・グリッドやリグ接続などの設定も全部リセットされてしまいますが、設定をリセットして周波数リストを初期化できます。

Configurations>Defaults>reset

です。

前にも一度設定リセットで悲しい目にあった気がする・・・

 

追記 2017/09/07 22:19

朝、出がけにツイッター経由で、周波数リストだけリセットできるとの話があった旨知りました。

キャプチャ

周波数リストのところで、マウスを右クリック、出てきたメニューでResetを選択、です。

これでいくと私みたいに全部の設定を初期化しないで済みます。

まとめますが、1.8.0-RC1->RC2へは、次のような周波数リストの移行方法があります。

  • RC1で、周波数リストをSave as…で保存しておき、RC2でそれを読み込む。もし、今から作業される方で、7041とか144MHz/430MHzなどの日本国内特有の周波数を追加している人にはこれがお勧めです。
  • バックアップを取らずに移行してしまった人向けには、追記で書いた、空の周波数リストの上で右クリックからResetをかけて、周波数リストを初期化するのがいいでしょう。これだと、コールサインやグリッド、リグの制御などの情報は残ります。
  • 私がやってしまった方法は、設定の完全なリセットです。全てパーです。特にPSKreporter向けのアンテナの情報とかもクリアされてしまいまして、お手軽ではありましたが失う物が多かった…w

以上です。

6mbのJT65モード

まともな6mbのアンテナがない私が書くと負け犬の遠吠え的な状況ではありますが、昨年からちょっと気になっている6mb のJT65の現状について所感を。

まずJT65というモードですが、元々の由来はさておき、”WSJT”がweak signalのWSで始まっているくらいですから、”弱い信号”をすくい上げて通信をするためのモードであるのは確かだと思います。

さて、ここで「弱い信号」にも色々あると思いますが、1. “遠くから来て弱い信号”とか”減衰が激しい伝播パス”を通ることで弱いなど経路起因の弱い信号、2. “送信側がQRP送信しているために信号が弱い”、3. “(2とある意味近い部分がありますが)アンテナの利得や設置状況的に利得が弱い”、4. “周囲環境のために受信側の受信能力が低い”(3の場合もそうですが)など。

アマチュア無線の場合は局の設備はバラバラですね。6mでも海外DX中心の方のようにタワーにロングブームのビームアンテナをスタックでという人もいれば、バーチカル系のアンテナでEsで楽しんでいる人だっていると思います。また私のようにアパマンで、とにかく交信さえできればという人も少なからず居るのではと思います。

2015年頃はそうでもなかったように思うのですが、昨年くらいからJT65でヨーロッパと交信している局が増えました。また世界的にも、そして特に日本国内でもJT系のアクティビティが上がっているためだと思いますが、6mbでは開けると「わっ」と集まってくる感じです。特にDXを追いかけている方に多い印象。

うちのようなベランダアンテナではDXの信号が見えないことも多いので、そういうときは送信を控えたり、上側に逃げてJT9で遊んだりしますが・・・最近では「奇数分送信しろ」なんてメッセージをもらったり、クラスターに「お前はQRM以外の何物でも無い」なんて書き込まれたり、エスカレート気味です。

珍しいところがでると帯域中がその局を一斉コールするようになって、そうなると(6mに限りませんが)既に行われているQSOはなんのそので好きなところでその局をコールするなんていうパイルアップにもなっています。

HFの方だと国内が開けている時間帯とDXが開ける時間帯が明確に分かれていることも多いのですが、6mだとEsのマルチホップなどで伝播しているような時は、国内やアジア近郊が開けるタイミングと一緒になったりもして、どうにも棲み分けがしづらい状況のようです。

DXがオープンしている時は、国内目当て局は遠慮することもあるでしょうし譲る気持ちは忘れずに居たいし、またそういう譲歩を受けたDXを追いかける側も譲歩してもらったんだということを意識してくれれば、上述の「お前はQRM以外の何物でも・・・」みたいなクラスターアップも無くなるんじゃないかな。

どうも最近の6mのJT65は「CQ DX軍団」が出てきたりすることもあって、ちょっと殺伐としている印象があります。皆さんはどうお感じかな。

40mbの場合は日本のバンドプラン的に7076の方に出られないことから、強制的に国内目当てとDX目当てが棲み分けになっています。6mの場合にはそういう棲み分けはないけれど、ぼちぼち日本国内向けのQRG周波数も決めておいた方が良いのではないでしょうかね。50276の、特に最近の夕方の運用され具合はちょっと怖いものがあります。

JTDX17.7導入の3:あれ、デコードが終わらない

JTDX、基本的なところはマルチパスでノイズの影響を減らしているとか、そんな感じなのでしょうが、やはりノーマルのWSJT-Xと比べると計算時間が長いです。

昨日はこんなことがありました。
“JTDX17.7導入の3:あれ、デコードが終わらない” の続きを読む