JTDX の周波数較正2021年03月01日 17時34分10秒

IC-7300 のファームウェアのアップデートを行ったら、FT8で受信される局のDFが微妙に周囲とずれていることに気が付きました。

以前周波数較正を行ったのですが、ファームウェアのアップデートで基準周波数調整の値が変わってしまったようです・・・ orz  ファームウェアのアップデート前にはご自身の設定を必ず保存しましょう。

ということで WSJT-X を使用して調整を行いました。

やり方以前の記事を参考にしてみてください。


For FT8 and other digital communication enthusiasts2021年03月01日 18時01分54秒

After updating the firmware of the IC-7300, the DF of the station I was receiving became slightly different between my friends, so I used the FreqCal mode of WSJT-X to calibrate it.

Probably the value of the reference frequency adjustment has changed.

After this calibration, there is no more frequency discrepancy between me and my friends who are using external reference signal with IC-7610 even on 6m band.

If you don't mind a slight shift in frequency, you don't need to adjust it, since the difference is only a few Hertz. However, if you are concerned about the slight difference in frequency when exchanging information with your friends or QRV information in a group, this is a good option.

For more information on how to calibrate, please read 13.1 in the user guide.

https://physics.princeton.edu/pulsar/k1jt/wsjtx-doc/wsjtx-main-2.3.0.html#_frequency_calibration




IC-7300 基準周波数調整2021年03月02日 10時08分22秒

JTDX WSJT-X での周波数較正について記事を書きました。


ふと思ったのですが、全てのシーンで正しい周波数になるようにやっぱりリグそのものの周波数較正をしたほうが良かろうかと・・・

ここで紹介する方法はいろいろなリグで使用可能と思います。

IC-7300 のファームウェアのアップデートをした後の基準周波数調整の値は27.5%になっていました。


周波数較正のツールとして目で見て数値でも分かるようにWSJT-Xを使います。取扱説明書に記載のある方法でも良いですが、耳で聞いて「うねり」がどうのこうのよりも、数値とグラフで目てみたほうがはっきりすると思います。

まずはWSJT-Xのユーザーガイド 13.1 をお読みください。


私の過去記事もお読みください。



1.メニューからモードを選び、一番下の FreqCal を選定します。


2.メニューから設定に進んで周波数へと進みます。運用周波数の Modeをクリックして周波数をモード別でソートします。するとFT8用周波数の下に FreqCal というモードでリストが出てきます。 この中で Region ALL の 5.0 10.0 15.0 の3つだけ残して削除します。他の周波数は日本ではほぼ利用しません。




スロープ インターセプトは 0になっているか確認します。



3.そしてメニューのファイルからログディレクトリを開くに進んで、もしそこに fmt.allというファイルが在れば削除します。

4.そしてメニューのツールから周波数較正実行をクリック。


5.メイン画面の「モニター」の下4段目 の「測定」 にチェックマークを入れます。

数分間放置プレー。WSJT-Xは30秒ごとに周波数を変えて受信していきます。



1500のところにラインが出ますが、リグの基準周波数がずれているとバンドが変わるごとにラインのズレも大きくなっていきます。





6.この状態でリグの基準周波数調整の値を動かしてみます。


どの周波数でもDFの値が小さくなる値にセットします。すると


ズレがほぼ無くなります。

これでリグの周波数のズレは最小になりました。

この状態で最初からWSJT-Xの周波数較正の作業をやれば完璧です。 WSJT-Xの校正値(スロープとインターセプトの値)と同じ値をJTDXにも入力すれば、当然JTDXでも正しい周波数で運用することができるようになります。

私のリグでは 34.5% が最適値でした。  

ICOMの他のリグでも基準周波数の較正ができる機種ならば当然同様の手順でできますし、YAESUのリグでも可能だと思います。例えばFT-991ならばメニューのREF FREQ ADJ を上記「6」の時に動かせばよいわけです。

作業はご自身の責任で実施されてくださいね。

一連の調整は「簡易」なものです。 100%完璧な調整ではないことをご承知おきください。

IC-7300 Frequency calibration2021年03月02日 11時40分20秒

I found  the frequency shifted a few Hz when I was doing digital communication with WSJT-X/JTDX, and the DF value was out of sync with my friends and QRV information.
If you have never calibrated before, why not try it?

The instruction manual says to set it by judging whether there is a roar or not by ear, but this method allows you to judge it by numbers and graphs.

I initially used WSJT-X to calibrate the frequency so that I could operate on the correct frequency when using WSJT-X/JTDX. I posted an article on this subject, but I deleted it and am posting this article. This time, I have come up with and carried out a simple way to change the value of the IC-7300's reference frequency adjustment to get the correct frequency. Good results were obtained, so I will introduce it here.
I'm sure many of you have already done this and know about it.

The tool used is WSJT-X. Please read section 13.1 of the user manual first.

Check the value of the reference frequency adjustment of the IC-7300. On my rig, it was initially set to 27.5%. This value should be different for each person's rig.
Put the WSJT-X into FreqCal mode. 


Go to Settings, then Frequencies, and make sure the Frequency Calibration value is set to 0.



The frequencies used in FreqCal mode will vary depending on where each person lives, so edit the working Frequencies to remove them, leaving only the frequencies used for calibration.
In my area, I was able to use 5.0MHz, 10.0MHz, and 15.0MHz, so I narrowed it down to just three.




Next, go to Tools from the menu and check the box for Execute frequency calibration cycle. 




This will switch the frequency for FreqCal that you set every 30 seconds and receive the data. If you look at the wide graph, you will see a line around 1500. If it is exactly right, there is no problem, but I am sure there will be some deviation. In the menu, you can find Save and Tools. Below the middle of Save and Tools, there is an item called "DF". And the value of DF is the deviation from the reference frequency in each band. Depending on the reception conditions, you may get some strange values, but ignore them.


Let's try to change the value of the reference frequency adjustment of the IC-7300.



 The DF value becomes smaller for each band, and the line on the wide graph is set to the value closest to 1500. This is all you need to do to adjust the reference frequency of the rig. It's easy because you can check it by looking at the DF value and the line on the wide graph.


Now we have a simple, but almost correct calibration.


In addition, when operating the digital mode in WSJT-X/JTDX, once the reference frequency adjustment values are determined, you can then calibrate the rig with WSJT-X, and it is almost perfect.

The values calculated by WSJT-X can also be used by JTDX. You will be able to operate at the correct frequency in all situations, not only in digital mode operation.

If other ICOM rigs are capable of calibrating the reference frequency, the same procedure can be used, and I think it is also possible with YAESU rigs. For example, with the FT-991, just move the REF FREQ ADJ in the menu to the "6" position above.

The discrepancy is only a few Hz to begin with, so there is no need to adjust it, but if you are concerned about it, please do so at your own risk.


第41回全市全郡コンテスト結果 発表されました2021年03月03日 22時10分26秒

タイトルの件発表になっています。


私は祝い事があったのでちょっとだけの参加。


C35で書類を出しています。  19位でした。  (^^)

入賞された皆さんおめでとうございます。


FT8愛好家の皆様へ2021年03月16日 11時08分55秒

全てのFT8愛好家の皆様へ
1.必要に応じてご自身が使用しているソフトウェアをアップグレードしてください。

この機会に是非ご自身が使用中のソフトウェアが最新版か確認しましょう。
 
   JTDX      http://www.jtdx.tech/en/
   MSHV     http://lz2hv.org/mshv
 
WSJT-X は 2.3.1、 JTDX は2.2.156、 MSHV は2.55  
(2021年5月10日現在)

それぞれのソフトウェアには32bitOS用と64bitOS用がありますので、ご自身のOSに適したものをイントールしてください。

2.交信の完了には "73" が必要だと頑なにおっしゃる方がいらっしゃいますが、 "WJST マニュアル" には以下のような記載があります。 
 
[If you have received RRR — that is, a definite acknowledgment of all of your information — the QSO is “officially” complete. However, the other station may not know this, so it is conventional to send 73s (or some other conversational information) to signify that you are done.]

もし貴方が RRR を受信したならば、すなわち全ての情報を確認した場合、QSOは公式には完了です。しかし相手方はこれを認識していない可能性があるため73(または、その他の情報)を送信して、完了したことを示すのが一般的です。

ということですので、RRRやRR73を送受した場合には、私はログに交信を記載します。

3."Enable PSK Reporter Spotting" 機能を有効にしましょう。

もし貴方がPSKR MAP  https://pskreporter.info/pskmap.html
を使ってFT8を楽しんでおられるのでしたらば、ご自身が受信した局の情報も「ギブアンドテイクの精神」から送信するようにしましょう。
ご自身の環境にインターネットがない、インターネットがあってもパケット代金が高い、またはPSKR MAPは使わないという場合には機能を有効にする必要性はありません。

詳細は

4.FT8等のデジタルモードで発行されるQSLのレポート欄について

私は気にしすぎなのかもしれませんが、「RS」「RST」欄にただ単に 「-05」等の数字が「単位」も示されずに記載してあるカードを見るとちょっと気になってしまいます。FT8等のデジタルモードで交換されるレポートは"SNR (dB)" です。ご自身の発行されるQSLにはどのように記載されますか? 私は RS/RSTではなく SNR として、単位の dB も明記しています。



5. Grid Locator
ソフトウェアへ入力するご自身のグリッドロケーターは、最低でも6桁で入力しましょう。 PSKR MAP を見ると、4桁の方は海上に位置が示されていたりします。JTDX は8桁のグリッドロケーターの入力に対応しています。8桁まで入れれば PSKR MAP で他局と自局の位置が重なるようなことはありません。自分のグリッドロケータは 


このサイトで調べることができます。

さらにWSJT-X も JTDX も自身のグリッドロケーターを10桁で表示することが可能です。そのためには ini ファイルをテキストエディターで編集する必要性があります。

[Configuration]
MyCall = JP1LRT
MyGrid = PM95tq47gc


6. 50MHz FT8 運用には気をつけていただきたいことがあります。

を御覧ください。

FT8 デコード可能範囲2021年03月17日 10時22分53秒

過去の記事の書き直しです。


FT8で、スプリット運用をして離れたDFで呼んでも全く応答がないのに、そばのDFで呼ぶとすぐ応答があることがたまにあります。
一因として相手がワイドグラフの表示範囲を狭めている可能性があります。
ご存知のようにWSJT-XとJTDXは、ワイドグラフに表示されている範囲でしかデコードしません。 ワイドグラフの表示範囲が500~2200Hzであれば、その範囲内の局のみがデコードされ、例えば2500Hzの局があってもデコードされません。
局によっては、意図的にワイドグラフを狭くしている場合があります。遠くのDFに呼びかけても全く反応がない場合は、近くのDF、特に低いDFに呼びかけてみると、反応があるかもしれません。意図的ではなくて「何も知らないまま」帯域を狭めている人もいるとは思いますが。
お使いのリグによっては、受信帯域が狭く、その上限が2400前後になる場合があります。意図的ではなく2400以上のコールをデコードできない場合もあると思います。




また、私はワイドグラフを意図的に狭くしてもあまりメリットはないと思います。私は常にワイドグラフに0~3000Hzを表示し、必要に応じてPBTなどのフィルターでダイナミックレンジやSNRの向上を検討しています。
このケースは最初は0-3000までをRIGのフィルターでも絞らずに受信していて、次にRIGのPBTフィルターで帯域を800-2500に絞り、次に帯域を1300-3000に変化させたものです。
JTDXのワイドグラフは0-3000のまま維持しており、RIGのフィルターの外でも「強い信号」の局はデコードされます。
RIGのフィルターで帯域を絞り、「強い信号」を追い出すことによって帯域内の「弱い信号」のデコード率を向上させることができます。




逆に上限を広げた場合はどうでしょうか? ほとんどの運用局が3000以下で運用しています。したがって3000以上に広げても3000以上はスカスカの状態だと思います。しかし混雑していた場合には、あえて3000より上に出てくる局もいます。試しに3200くらいで運用したことがありますが、時々コールされました。

CPUに対する負担を考えてみると、表示させている範囲でデコード作業を行いますので、無駄に広げてもCPUに掛かる負担が増えるばかりで良いことはありません。例えば3500とか4000まで広げても運用局のいない周波数のデコード作業を行いますので無駄になってしまいます。
JTDXの場合は使用スレッド数でワイドグラフの表示範囲を分割し、それぞれのスレッドが分割された範囲のデコードを担当するので、誰もいない部分のデコードに割かれるCPUスレッドが無駄になってしまいます。

新記録2021年03月18日 18時50分43秒

私の設備で一回のデコード局数が65というのは新記録でした。

すごいパイルでしたが、パイルになる前にできました。 (^^)

65デコードでこのLagタイムでしたらまあまあですかね。設定は重くしてあります。
デコード周期 3, デコーダー感度 サブパスを使用。



ノイズキャンセラー2021年03月24日 12時12分12秒


MFJ-1025/1026, ANC-4 等のノイズキャンセラー。うまく動作するかはノイズ受信用アンテナをいかにうまく設置するかですね。

ノイズ専用アンテナで受信するノイズ信号が弱すぎるとうまくキャンセルできません。

似た製品に WiMo QRM Eliminator があります。

中国のAliexpressでも模倣品と思われるものが安価に販売されています。
https://ja.aliexpress.com/item/1005001903209355.html

私はANC-4を持っていますが、やはりノイズ様アンテナがネックでうまく使いこなせていません。難しいです。

FT8 CQing Refuses to Send 73 After Receiving 732021年03月25日 09時30分23秒


The English article is after the Japanese one.

WSJT-X 2.4.0 -rc3をFT8運用にお使いの方、結構いらっしゃるのではないでしょうか。
RRR "の送信を選択された方は、WSJT-Xの動作がおかしいと感じていませんか?
通常、"RRR "を送信した後、QSO相手は "73 "を送信して、自分も"73"を送ってQSOを終了します。しかし、WSJT-X 2.4.0 -rc3では、相手から "73 "を受信しても、相手に "73 "を返しません。"RR73"と同様の動作をします。
私はJTDXユーザーですし、RR73を送る設定しているので何も問題はないのですが。
QSOを完了させるためには、"73"が必要だという人もいます。しかし、この新しいWSJT-X Auto Seqの動作が2.4.0 GA版でデフォルトとして採用された場合、そのような方々は無効で不完全なQSOであるため、きっと多くのQSOをログに付けないのでしょうね。その方達はもしGA版で採用されたらものすごく損をすると思いますが。まあ、RR73を送る設定にすれば何も問題はないですけれども。
あるWSJT-Xユーザーが、この動作の理由を尋ねたところ、開発チームのメンバーは、"あなたが送りたい余分な73メッセージの目的は何ですか?"と答えたそうです。 もしそうであれば、この動作はバグではなく、開発チームの意図であると考えられます。
皆さんはどのようにお感じになりますか?
ちなみにJTDX開発チームからのメールによると「一般的には、JTDXはこの変更に何の問題もありません。(RRRを送信して73を受信した後に)自分の最後の73メッセージを送信する1つのTx期間が失われるだけで、他の人に害を与えることはありません。WSJT-XはRRRとRR73を同じものとして解釈し、将来的には1つのメッセージタイプを他の意味に解放しようとしているようにみうけられる。」と回答しています。
この変更に対するアクションは、"RRR "の送信をやめて、"RR73 "に変更するだけです。全員が「RR73」を送信するように設定されていれば、何の問題もありません。しかし、中には「RRR」の送信にこだわる人もいて...。
どうしても「RR73」を送りたくない理由のひとつに、「RR73」というグリッドロケータがあるからというのがありますが、ここは北極点の近くで陸地がないので、実害はありません。

リリースされたばかりのrc4でも動作は同じでした。なのでこれはバグではなくて仕様変更だと思います。

------------------------------------
Many of you are using WSJT-X 2.4.0 -rc3 for FT8, I guess.
If you have chosen to send "RRR", do you feel that WSJT-X is behaving strangely?
Normally, after sending "RRR", the QSO partner will send "73", and then send "73" to end the QSO.
I'm a JTDX user, and I have "RR73" set to send, so there's nothing wrong with that.
However, WSJT-X 2.4.0 -rc3 does not return "73" to the other party after receiving "73" from the other party. It behaves just like "RR73".
Some people say that "73" is required to complete a QSO. However, if this new WSJT-X Auto Seq behavior is adopted as the default in the 2.4.0 GA version, I am sure they will not log many QSOs because those are what they call incomplete and invalid QSOs by their own definition.
I think those people will lose a lot of QSO if this adopted with the GA version. Well, there's no problem if you set it to send RR73.
When one WSJT-X user asked why this behavior was happening, a member of the development team replied, "What is the purpose of the extra 73 messages you wish top send?" If this is the case, then this behavior is not a bug, but the intention of the development team.
By the way, according to an email from the JTDX development team, "In general JTDX has no problems with this change, It just will lose one tx period sending own last 73 message (after sending RRR and receiving 73) and this will not harm others to.
Looks like they will interpret RRR and RR73 as same and try free one message type for other meanings in future. "
The action for this change is to stop sending "RRR" and just change it to "RR73". If everyone was set to send "RR73", there would be no problem. However, there are some people who insist on sending "RRR"...
One of the reasons they insist on not sending "RR73" is because there is a grid locator "RR73", but since it is near the North Pole and there is no land, there is no real harm.
The same thing happened with rc4. So I think this is a spec change and not a bug. If you have any doubts, go ahead and experiment. You can download rc4 from the official page: