いずれの場合も次の特徴が見られる;
①SNR値が-24dB程度と低く表示されていること
②リポート値「R-**」が前回のシーケンスと異なること
過去、この二つの条件が重なった状況で「73」まで辿り着いたケースは殆どなかった気がする。後からCLUBLOGなどでチェックしてもNIL(Not in Log)となることが大半であり、何局かにメールで問い合わせて返事をいただいた場合も結果は同じであった。以下、Falseではないか..という返信の一例。
I was working JA at that time, but I never heard you nor replied to you. The claimed QSO is not in log. The message you decoded is not from me but an false decode made by your software. This is a known "artifact" of FT-8 programs, as they are doing their best to decode. Unfortunately the software sometime use the information you have entered DX call and your call to do "qualified guessing" and do wrong. This results in false decodes.
Hope to work you next time.
FT8 の挙動として先方がこちらの「RR73」が受信できない場合は、手動で数値を変えない限り「R-**」のシーケンスは同じレポートが繰り返されるのが基本。以下のケースでは先方局は「R-06」を4回送信しており、先方側のQRMでこちらの「RR73」が受信できないと判断し、Tx Freqを50Hz QSYした次のシーケンスで「73」を受領している。
There are unavoidable false ‘Hint’ decodes caused by high sensitivity of the ‘Hint’ decoders, all of them have really existing callsigns in the decoded message. Similar to CW/SSB weak signal reception it is up to user to make own decision if received message is the wrong one.
「Hintデコーダーの高い感度ゆえ、デコードメッセージ内にあるコールサインを誤ってデコードしてしまうことは避けられないので、CW/SSBの弱い信号を受信する時と同じように、正しいかどうかはご自身で判断してください・・」といったところ。
②リポート値「R-**」が前回のシーケンスと異なること
過去、この二つの条件が重なった状況で「73」まで辿り着いたケースは殆どなかった気がする。後からCLUBLOGなどでチェックしてもNIL(Not in Log)となることが大半であり、何局かにメールで問い合わせて返事をいただいた場合も結果は同じであった。以下、Falseではないか..という返信の一例。
-------------------------------------------
Hi Ken-sanI was working JA at that time, but I never heard you nor replied to you. The claimed QSO is not in log. The message you decoded is not from me but an false decode made by your software. This is a known "artifact" of FT-8 programs, as they are doing their best to decode. Unfortunately the software sometime use the information you have entered DX call and your call to do "qualified guessing" and do wrong. This results in false decodes.
Hope to work you next time.
--------------------------------------------
FT8 の挙動として先方がこちらの「RR73」が受信できない場合は、手動で数値を変えない限り「R-**」のシーケンスは同じレポートが繰り返されるのが基本。以下のケースでは先方局は「R-06」を4回送信しており、先方側のQRMでこちらの「RR73」が受信できないと判断し、Tx Freqを50Hz QSYした次のシーケンスで「73」を受領している。
各バンドをワッチしている時も、ごく稀にコールサインが文字化けしたりDTが大きくズレたものが見受けられるが、やはり厄介なのはリターンシーケンス(R-**)のFalse Decodeであり、見た目は通常のシーケンスと何ら変わらず、また得てしてNEWエンティティ局などをコールしている時に起きるため「今回のリターンはホンモノかも..」との期待もあり、仕切り直すには躊躇するところ。
しかしながら、未だ信号が届いていない相手に「RR73」を送り続けていると思うと、やはり徒労であり「RR73」を5回送出でタイムアウトすることは理に叶っていると考える。なお、SNRが比較的高く同じ値のリターンシーケンス(R-**)を繰り返した後で尻切れになった場合は、相手局のポリシー次第だが In-Logの可能性はある。
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
False Decodeの原因は”Hint” デコード機能に因ると考えられ、JTDXユーザーズガイドにも以下の記載がある。
There are unavoidable false ‘Hint’ decodes caused by high sensitivity of the ‘Hint’ decoders, all of them have really existing callsigns in the decoded message. Similar to CW/SSB weak signal reception it is up to user to make own decision if received message is the wrong one.
「Hintデコーダーの高い感度ゆえ、デコードメッセージ内にあるコールサインを誤ってデコードしてしまうことは避けられないので、CW/SSBの弱い信号を受信する時と同じように、正しいかどうかはご自身で判断してください・・」といったところ。
微弱なデジタル信号の処理による通信という "scientific"なモードではあるが、最後はヒトの経験と勘で判断ーというアナログ的な要素もFT8の魅力ではあるが..
JTDXの現行バージョンでは ”Hint” ボタンはデフォルトでOnとなっており、疑わしい場合は上記2つの特徴から見極めていくしかない。特にSNRが低くデコードレベルギリギリで入感する局をコールしている時に起きる傾向があるため、早めに仕切り直しすることが肝心であろう。
0 件のコメント:
コメントを投稿