HIJACKER ― 2021年04月13日 17時41分50秒
FT8 DF乗っ取りをする人の常套手段。
1. CQを出している局をオンフレで呼ぶ
2. リターンがあってもずっとコールし続ける
3. CQを出していた人が諦めた瞬間にCQに切り替えてそのまま居座る。
なんてのをFacebookの自分のタイムラインに書いていました。
先程 20m でCQを出していたらオンフレで呼ばれました。
なかなかですな。
わざとやっているんですよね。
こういう愚か者には辟易します。
CQに対してON FREQUENCYで呼んできて、こちらは応えているのに受信できないふりをして、そのままその周波数に居座ってCQをコールし始める。
こういうハイジャック行為が一番嫌われるっての分かってやっているんでしょうね。
お人柄が分かる。
I'm fed up with these fools.
He call ON FREQUENCY to my CQ, I answer, but he pretend he can't receive, and then he stay on that frequency and start calling CQ.
I guess he know that this kind of hijacking behavior is the most hated.
It shows his personality.
JTDX 開発進捗状況 ― 2021年04月13日 09時26分19秒
現在 JTDX は 2.2.156-rc11 を開発チームと試用チーム内でテスト中です。
一番大きな変更は使用できるCPUスレッド数が24まで増やされている点ですが、その他も数多くの改良点があります。
もうすぐリリースできるかなと言うところまで来ている感じです。 楽しみにしてください。
𝗕𝗲 𝗮 𝘄𝗶𝗻𝗻𝗲𝗿 𝗼𝗳 𝗙𝗧𝟴! ― 2021年04月12日 00時52分18秒
The choice of software and its configuration is crucial to the operation of FT8.
𝟭. 𝙏𝙝𝙚 𝙤𝙣𝙡𝙮 𝙨𝙤𝙛𝙩𝙬𝙖𝙧𝙚 𝙩𝙤 𝙪𝙨𝙚 𝙞𝙨 𝙅𝙏𝘿𝙓.
Some of my friends may be WSJT-X enthusiasts. However, there is a clear difference in the decoding capability of FT8 between WSJT-X and JTDX decoding. Please try JTDX once, whether you like it or not.
𝟮. 𝘾𝙝𝙚𝙘𝙠 𝙩𝙝𝙚 𝙥𝙤𝙬𝙚𝙧 𝙨𝙚𝙩𝙩𝙞𝙣𝙜𝙨 𝙤𝙛 𝙮𝙤𝙪𝙧 𝙋𝘾.
Make sure the power setting of your PC is set to "High(Best) Performance". If it is set to "balanced" or "energy saving", you will not get the full performance of your CPU. The decoding of FT8 is instantaneous. It goes without saying that it is better to have a higher clock from the beginning, rather than a higher clock after the load is applied. This is a setting that works quite well and is worth a try. (Even with WSJT-X, of course).
𝟯. 𝘾𝙝𝙚𝙘𝙠 𝙮𝙤𝙪𝙧 𝙅𝙏𝘿𝙓 𝙨𝙚𝙩𝙩𝙞𝙣𝙜𝙨.
The FT8 thread should match the number of logical cores of the CPU, not AUTO. If you have a problem, try -1 or -2 logical cores.
For 𝘥𝘦𝘤𝘰𝘥𝘪𝘯𝘨 𝘤𝘺𝘤𝘭𝘦𝘴, select 2. If you are using a high performance CPU, 3 is also fine.
Select high for 𝘘𝘚𝘖 𝘙𝘟 𝘧𝘳𝘦𝘲 𝘴𝘦𝘯𝘴𝘪𝘵𝘪𝘷𝘪𝘵𝘺.
For 𝘥𝘦𝘤𝘰𝘥𝘦𝘳 𝘴𝘦𝘯𝘴𝘪𝘵𝘪𝘷𝘪𝘵𝘺, select use subpass.
Put a check mark in 𝘸𝘪𝘥𝘦𝘣𝘢𝘯𝘥 𝘋𝘟 𝘤𝘢𝘭𝘭 𝘴𝘦𝘢𝘳𝘤𝘩.
If you find that the decoding is too slow with these settings and the Lag value is actually too high, try changing the decoding cycles value and decoder sensitivity to use low thresholds to see what works best.
An upper limit of 3100 for the wide graph is sufficient. It is unlikely that any station will come out above that. It is not recommended to use a value smaller than 3000, because only the range shown in the wide graph will be decoded.
𝟰. 𝘼𝙙𝙙 𝙖 𝙫𝙚𝙧𝙩𝙞𝙘𝙖𝙡 𝙢𝙤𝙣𝙞𝙩𝙤𝙧 𝙙𝙚𝙙𝙞𝙘𝙖𝙩𝙚𝙙 𝙩𝙤 𝙅𝙏𝘿𝙓.
The number of stations that can be decoded at one time should have increased dramatically with the settings so far. With a normal horizontal monitor, some stations will scroll out. To avoid losing your chances, be sure to install a vertical monitor.
Even for stations with large antennas, the number of decodes may be small depending on the PC and software settings.
In FT8, if you can't see (decode) the other station, you can't QSO.
Please use a more advanced setting and make many QSOs.
This article is a reprint of my Facebook post.
とれませーん わかりませーん ― 2021年04月06日 00時06分38秒
先日の神奈川非常訓練コンテスト、430FMでのこと。
私はモニターしていただけですが。
ある局がナンバーの再送をリクエストしました。 このコンテストは郵便番号を神奈川県内局は送ります。
例えばA局の番号が2300001だとしましょう。
A 2300001 です。
B 0001はわかりました。最初の3文字がわかりません。
A 230 230 230 → 全て にぃさんぜろ と言っています。
B わかりません。再度お願いします。
A 230 230 230 2300001 2300001 どーぞー → また にいさんぜろ の繰り返しです。
B わかりません・・・ 252ですか?
A にーさんーぜろーー にいさんぜろー
B わかりません。 再度お願いします。
A にーーーーさんーーーー ぜろーーーー .......省略
230を にぃさんぜろ と言って通じないんだから他の言い方で言えばいいのに、ずっと にいさんぜろー の繰り返し。
コールサインならばフォネティックコードを違う言い方で言ったりしますよね? なんで数字も違う言い方しないんでしょうかねぇ・・・?????
とぅー すりー ゼロー とか わんつー わんつーすりー ぜろー とか
つー とぅりー ゼロ ふた さん まる
結局相手に伝えようとする熱意の問題なのかなと思いました。
送ってもらっている B局も、違う言い方でとか言えばいいのになぁ・・・ と思いました。
Phoneでの応答の仕方 ― 2021年04月03日 11時09分56秒
コンテストでも移動運用でも、CQを出している局が呼んできた局に対して応答する場合の応答方法で、とても違和感を覚えるやり方があるのですが・・・
通常の移動運用で、CQを出して呼んできた局が私 JP1LRT だったとします。
CQを出している局 "CQ こちらは ********"
私 "JP1LRT(フォネティックコードで)" 一発で完全にとれたとします
CQを出している局 "JP1LRT局どーぞー" コールバックだけ・・・
「コールバックだけ」というのに違和感を感じます。なぜQSOを進めないのでしょうか?
相手局に先に話をさせたいのでしょうか?
例
"JP1LRT (QTH******)から(レポート)ですどーぞー" とレポートまで送れば非常に効率が良いのではと思うのですが。レポートに限らずQSOを進めれば良いのにと思います。
特にコンテストの場合は
例
"JP1LRT 5925M(どーぞ)" とナンバーまで送らないとやり取りが増えて非常に非効率です。
まぁどうでもいい話なのですが、コンテストのときはちょっとイラッとしますね。なんでコールサインを完全にコピーしているのにナンバー送らないの? と。
FT8用国際標準周波数とJAのSSB通常交信の混信 ― 2021年04月01日 12時44分09秒
40m bandのFT8用国際標準周波数は言わずもがな 7074kHz です。
USBで運用されていますので 7074-7077kHz が使用されています。 LSB 7077kHz で通常のSSB運用を行えば 「もろ被り」 になるのは考えなくても分かることだと思います。
JA同士の日本国内QSOはバンドブランによって 7074kHz ではできないので 7041kHz でデジタルの国内通信が行われています。 7041kHz には国内のSSB QSOは被りません。 7045kHz 以上が狭帯域の電話となっているため、実質 7048kHz より下では LSBの運用ができないからです。
一方で 7074kHz は「狭帯域の電話」の中に存在するため、通常のLSB QSO の混信を受けてしまいがちです。
昼間は40m bandでは外国からの電波は届かない、と思い込んでいるのか、はたまたFT8用国際周波数の存在を知らないのかQRMを与えて運用する方が多数存在ます。
日本の東には近隣諸国はありませんが、西にはFT8運用も許可された近隣諸国が存在します。その国の方々にも多大な迷惑をかけているのですが。
40m band は昼間でも外国の電波が飛んできます。たとえ弱くてもデジタルであれば交信できる強さで入ってきます。そこに強力な国内LSB電波が入ってくればマスクされて交信どころではありません。彼らのLSBの電波も当然海外に飛んでいるわけで、世界中から笑い者、邪魔者扱いを受けることに繋がります。
現状のままだとバンドプランそのものを見直せという議論にも発展しかねません。
2m bandで月が上っている間、EMEを楽しもうとしている局に対して144.150MHzより下でSSBを運用しQRMを与えているという構造によく似ています。
そんなの関係ねー という発想が見え隠れしていてとても残念です。
再びやる気が出てきました ― 2021年04月01日 11時06分36秒
しばらく更新していなかったソーラー発電絡みのノイズ問題、また記事を書く気が湧いてきました。少しずつ書いていこうと思います。
電波法第82条 †
（免許等を要しない無線局及び受信設備に対する監督）
第八十二条 総務大臣は、第四条第一号から第三号までに掲げる無線局（以下「免許等を要しない無線局」という。）の無線設備の発する電波又は受信設備が副次的に発する電波若しくは高周波電流が他の無線設備の機能に継続的かつ重大な障害を与えるときは、その設備の所有者又は占有者に対し、その障害を除去するために必要な措置をとるべきことを命ずることができる。
２ 総務大臣は、免許等を要しない無線局の無線設備について又は放送の受信を目的とする受信設備以外の受信設備について前項の措置をとるべきことを命じた場合において特に必要があると認めるときは、その職員を当該設備のある場所に派遣し、その設備を検査させることができる。
３ 第三十九条の九第二項及び第三項の規定は、前項の規定による検査について準用する。
電波法第101条 †
（無線設備の機能の保護）
第百一条 第八十二条第一項の規定は、無線設備以外の設備（前条の設備を除く。）が副次的に発する電波又は高周波電流が無線設備の機能に継続的且つ重大な障害を与えるときに準用する。
Faustoさん I4EAT SK ― 2021年04月01日 10時58分07秒
情報によると6mでアクティブだった Faustoさん I4EAT が COVID-19 でお亡くなりになられたとのこと。
私も6mでQSOしていただいておりました。 残念です。 ご冥福をお祈りします。
NICTの新ツール ― 2021年03月28日 16時18分40秒
FT8 CQing Refuses to Send 73 After Receiving 73 ― 2021年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:
最近のコメント