WSJT-XもLogger32のUDP BandMapの機能を使うことが出来ます。後述のWSJT-Xの設定が必要です。
WSJT-XのスタートUDP BandMapのStartメニューに登録しておけば、ここからスタートすることが出来ます。
Cherry-pickingとManual callingJTDXの場合と同様ですが、以下のような違いがあります。
・ 相手がCQを送信した場合のみCherry-pickingの対象になる。RR73とか73に対しては何もしない。(これはWSJT-Xの仕様)
・ WSJT-Xには基本的に自分で自動的にEnable TX"をOFFにする機能がないので、UDP BandMapによる"Enable TX"を使う。
CQを出した相手を呼んで応答がない場合は3回繰り返して呼び、それでも応答が無ければ"Enable TX"をOFFにする。(これは固定)
自分がリポートを送っても相手から応答が無い場合は、次の設定による回数だけ繰り返します。下図の例では4回繰り返します。
Logger32へのQSO自動ログWSJT-Xのログ画面が一瞬表示されますが、マウス操作無しで自動ログすることが出来ます。
WSJT-Xの設定
UDP BandMapの設定
スポンサーサイト
FTIによる工事の予定が2/25となりました。
・ ベランダに新たにマストを設置し、現在タワーに載せているR6000を移設
・ 基礎コンクリート部分は残してタワーを撤去
これで昨年から進めてきたダウンサイジング計画が終了します。
他のJAユーザーからもこの現象のリポートがありました。
私は通常、Logger32のCherry-picking機能を使い、もっぱら聞こえている相手を片っ端から呼びまくっています。想像するに、ほぼ同時に発生するTX HaltとEnable TXの微妙なタイミングでこの現象が起きるように思います。1～2時間に1回程度しか発生しませんが、突然無変調になるので慌てます。JTDX/WSJT-Xの手動操作によるテストは殆どやっていませんが、しつこく操作を繰り返せば起きる可能性があります。
JTDXの開発者チームにも相談していますが、彼らはまずsoudcardの設定を疑っています。特定のsoundcardだけで発生する訳でもなく、どうも私にはそのようには思えませんが。
現在次のような組み合わせで発生することを確認しています。
・ K3のオンボードのsoundcard
・ IC7300と内蔵のUSB audio codec
・ TS480とSignaLink (USB audio codec内蔵)
・ TS990と内蔵のUSB audio codec
OSはWindows 10(日本語、英語)、Windows 7
現象が発生した時、毎回でありませんが、無変調で送信した自分のメッセージがBandActivity windowに表示されることもあります。
同じ現象にお気づきの時はどうぞお知らせください。解決のヒントになるかも知れません。
昨日の記事にも書きましたが、送信状態になってもその15秒間は無変調、従って出力パワーもゼロになってしまうことがあります。次の送信時はOKになります。この時のシーケンスは下図のようになります。大別して2ツのケースがあります。
JTDXでもWSJT-Xでも起きます。また違うSoundcardを使うIC7300でもTS480でも起きます。このような現象を経験されたことはありませんか？ 海外からこのような事例を経験したという報告を全く聞かないので、或は日本語Windowsに限って起きるのかも、、、
JT65を始めた時からもっぱらJTDXを使ってきましたが、主な理由は次のようなことからの「総合的判断」です。
ＪＴＤＸいいところは、
・ 設定のオプションが多岐にわたり自分好みの設定ができる。
・ RR73、73に対応するUDP Reply messageを受け取ってくれる。これによってRR73、73を送信した相手を自動的に呼び始めることができる。
・ 送信メッセージのGridをSkipすることが出来る。その設定も保存される。
・ Band Activity windowが縦方向に大きい。最新のデコード信号のみ表示できる。
・ 更新が頻繁に行われる。
気にいらないところは、
・ 多岐にわたるオプションの意味がなかなか理解できないことがある。難しい、、、
・ Fox、HoundのFoxモードが非対応でHoundモードのみ (ほぼ使うことがないのでいいですが、、、)
WSJT-Xいいところは、
・ 設定のオプションが少なく簡単
・ Fox、Houndモードに対応、特定のコンテストにも対応
気にいらないところは、
・ 自分好みの設定が殆ど不可能
・ RR73、73に対応するUDP Reply messageを受け取ってくれない
・ GridのSkipは一時的にのみ可能
・ 更新頻度が少ない
・ Band Activity windowが縦方向に短い、状況によってはスクロール操作が必要
共通する問題・ ある相手を最初に呼ぶ時、Transceiverは送信状態になってもSound出力が出ず、従って送信出力もゼロになることがある。
・ 時々、第3者のcallsignでメッセージを送信することがある。相手のcallsignが標準でない場合に発生する可能性があるのか(？)
にっちもさっちもゆかなくなって、これは大変困る。
(例)
K4CY/PJ4 JA1NLX -10
JA1NLX K4CY/PJ4 R-10
K4CY/PJ4 XX0YY RR73 本来はK4CY/PJ4 JA1NLX RR73となるべき
SummaryFT8 ver1.06をリリースしました。テーブルとグラフを追加しました。
SummaryFT8のupdate版のテスト中です。
・ 160M Bandの追加
・ テーブルの表示方法の変更
近日中にリリースする予定です。
JS8CallでのQSOをLogger32に直接ログすることができます。 UDP BandMapを開く必要はなくUDP portがオープンになっていればOKです。(但し筆者は未確認)
JS8CallのQSOぶりを初めて見ました。まだアクティビティが殆どなく閑散としています。
昨年11月、紅葉が見ごろだった町田 薬師池公園です。今のシーズンはなかなか屋外スケッチも行きづらくて、どうしても写真を見てスケッチになってしまいます。
Logbook page windowで任意のQSOをクリックすると、結果が表示されます。この例ではEA8TLとのQSOをクリック、Lookup_HamQTH_ADIF画面に検索結果を表示しています。この画面の"Update QSO"をクリックすれば、このQSO内容が更新されます。"Overwrite"にチェックしておくと常に上書きされます。
更新の対象となるのは、Name、IOTA、Grid、State、County、Via(QSL_VIA)のデータになります。これらの機能はLookup_HamQTH_ADIF、Lookup_HamQTH_XML、Lookup_QRZ_XMLの各utilityに組み込まれます。Logger32の次期バージョンがリリースされた後でリリースする予定です。
ログ内容に不足のデータがある以前のQSOについて、不足のデータを補填する場合に便利に使えます。
