JTTY:WSJT-X 3.2が弱い信号にRTTYのようなスピードをもたらす
WSJT-X 3.2.0-rc1では、キーボード同士でテキストをやり取りする新しいデジタルモード「JTTY」が導入された。RTTYの即時性と、弱い信号でもより確実に受信できるよう設計された符号化信号を組み合わせている。今回のリリースにはQ65、MAP65、QMAPの新機能も含まれ、開発チームは正式公開に先立って運用者にテストを呼びかけている。
デジタル無線に新しいリズムを
デジタルアマチュア無線は、この20年ほど、ある種の効率性を追求してきた。時間を固定された区間に分け、一方の区間で送信し、別の区間で受信し、最後にコンピューターで交信内容をデコードする方式だ。この方法によって、弱い信号での通信は驚くほど効果的になった。一方で、運用時の感覚も変わっている。FT8やFT4では、オペレーターがメッセージの流れを設定し、ソフトウェアが順番に処理するのを見守ることが多い。自分で文章を入力し、相手局の返答がリアルタイムに届くのを確認する方式とは異なる。
WSJT-X 3.2.0-rc1で登場したJTTYは、これとは異なるリズムを目指している。キーボード同士でテキストをやり取りする、リアルタイムかつ非同期のモードだ。オペレーターがメッセージを送れば、UTCの区切りや決められた送受信サイクルを待たずに送信を始められる。受信テキストは復元されるにつれて表示されるため、RTTYや会話型のデジタルモードを使った経験のあるオペレーターにはなじみやすい。
この操作感は、RTTYをそのまま再現しようとするものではない。JTTYは、ライブテキストやコンテストでおなじみの操作方法と、信号が弱いときや条件が悪いときにメッセージをより確実に届けるための符号化波形を組み合わせる。狙いは明確だ。RTTYコンテストの即時性や運用習慣を残しながら、デジタル信号処理によって従来のRTTYで起こりやすい受信ミスを減らす。
WSJT-X 3.2.0-rc1は、一般公開向けの最終版ではなくリリース候補版だ。WSJT開発チームは、アマチュア無線家にソフトウェアを試し、新機能を十分に動作確認し、問題や質問をプロジェクトの公開課題管理システム、ディスカッション欄、ユーザーフォーラムを通じて報告するよう呼びかけている。この違いは重要だ。リリース候補版は実際に使える段階にある一方で、現場からのフィードバックによって変更される可能性も残している。
JTTYは最も目立つ変更だが、今回のリリースはそれだけではない。WSJT-X 3.2.0ではQ65、MAP65、QMAPにも新機能が追加され、多くの改善や修正も含まれている。これらのプログラムは、一般的なトランシーバーを使ったデジタル通信から、広帯域VHFやEMEまで、弱信号運用の異なる領域を支えている。つまり今回のリリースは、新しいモードの実験であると同時に、WSJTソフトウェアファミリー全体の大規模な更新でもある。
JTTYの登場が注目されるのは、WSJT-XがすでにJTTYとはほぼ正反対のデジタル無線スタイルと強く結びついているからだ。FT8とFT4は、構造化されたコンピューター支援型の交信を世界中の多くのユーザーに広めた。JTTYは、同じソフトウェア環境で、オペレーターがより直接的に会話へ参加するモードも実現できるのかを試す。送信するタイミングを自分で決め、ファンクションキーでコンテストの交換を進め、届いたテキストをその場で読むという使い方だ。
その答えは、復調器の性能だけでは決まらない。JTTYの交換フォーマットが自分の運用習慣に合うか、マクロがテンポの速いコンテストで使いやすいか、提案された周波数で局同士が出会えるか、そしてサンプル録音以外の条件でも弱信号性能が発揮されるかを、運用者が確認する必要がある。そのため開発チームは、発表をゴールとせず、テスト用のリリースとして公開し、フィードバックを求めている。
時間制御されたシーケンスからライブテキストへ
従来のWSJT-Xモードは、厳密に調整されたタイミングを基盤としている。FT8の送受信サイクルは15秒、FT4は7.5秒だ。オペレーターのコンピューターと無線機は、この繰り返し構造に沿って動作する。ソフトウェアは予測可能な時間枠に信号を配置し、対応する受信時間内でその信号を探せる。この仕組みは、伝搬条件が厳しい状況でも信頼性の高い交信を自動化できる大きな理由の一つだ。
時間制御方式には避けられないトレードオフがある。コンピューターは適切な送信時間を待たなければならず、相手局も対応する受信時間に聞いている必要がある。通常、メッセージは連続した文字列として表示されない。ソフトウェアは符号化された送信全体を受信し、時間枠が終わったところでデコード結果を表示する。オペレーターが見るのは、文字が一つずつ届く文章ではなく、完了したメッセージの並びだ。
RTTYは歴史的に、より即時性の高い操作感を提供してきた。非同期の文字ストリームでは、一方の局が送信を始め、もう一方がメッセージごとに共通の時計へ合わせなくてもテキストを受信できる。オペレーターはキーボード、ファンクションキー、コンテスト用ログソフトを使って、おなじみの交換内容を送れる。コールサイン、信号レポート、シリアル番号に交信をまとめられ、速度もオペレーターが調整できるため、コンテストに適した形式だ。
その即時性には、別の技術的課題が伴う。一般的なコンテスト用RTTYは45.45ボーで、2つの周波数偏移キーイング音を使う。ノイズ、フェージング、干渉、あるいは低い信号対雑音比によって受信音が歪むと、デコーダーは誤った文字を出力することがある。コールサインやシリアル番号の一文字が間違っただけでも、再送が必要になる場合がある。その遅れによって、RTTYの魅力である速度の優位性が一部失われることもある。
JTTYは、この2つの方式の中間に位置しようとしている。非同期でキーボードを中心とする操作を維持しながら、4トーンのガウス周波数偏移キーイングを使って、情報を短いフレームに分けて送信する。フレーム化と符号化によって受信側は信号を処理しやすくなり、非同期設計によって固定UTC送信枠を待つ必要もなくなる。フレーム化されていないストリームのような連続送信ではなく、メッセージを作成して送信するたびに短いフレームを送る方式だ。
JTTYの1フレームは1.888秒で、占有帯域幅は約127 Hzだ。狭い周波数範囲に収まる一方、FT4でよく挙げられる約80 Hzより広く、一般的な45.45ボーRTTYの公称シフト幅170 Hzより狭い。ただし、これらの数値は異なる特性を表しており、実際のオンエア性能を総合的に評価する指標ではない。占有帯域幅、トーン間隔、シンボルレート、符号化方式、受信機の動作などが、混雑したバンドでの性能を左右する。
1.888秒のフレームは短い交換を行うには十分だが、一度に送れる任意のテキスト量には制限がある。1フレームに入る自由入力文字は5文字だ。キーボードモードとしては厳しい制約に見えるかもしれない。しかし、メッセージを通常の文章としてではなく、定型的な交換として捉えると設計の狙いがわかる。コンテストのやり取りは繰り返しが多い。コールサイン、レポート、シリアル番号、短い確認応答など、限られた組み合わせが使われる。プロトコルは、このような構造化されたメッセージを、任意の文字を一つずつ符号化するより効率的に表現できる。
ここが、JTTYの構造化されたコンテストメッセージと自由入力テキストの大きな違いだ。標準形式は限られたフレーム容量を効率的に使うため、5文字という制限から想像するより速くコンテストの交換を進められる。開発者の例「CQ CQ K1ABC CQ」は1フレームで送れるが、「W9XYZ 599 107」のような一連の交換には2フレーム必要だ。一方、自由入力テキストの速度は毎分約30語で、構造化形式のおよそ半分にとどまる。
この差は実際の運用にも影響する。独自のメッセージを使うと、オペレーターの速度が落ちる場合がある。多くのデジタルモードでは、マクロは基礎となるプロトコルの利便性を高めるものとして使われる。JTTYでは、どの形式のメッセージを選ぶかが、利用可能なフレームに情報をどれだけ効率よく詰め込めるかに直接影響する。簡潔なコンテストメッセージを、より詳細な独自の交換内容に置き換えると、フレーム数が増え、送信時間も長くなる可能性がある。
そのためJTTYは、簡潔で規律ある運用に向いている。短く一貫したコンテスト交換は、入力しやすいだけではなく、送信の構造にも合っている。自由入力テキストが無用という意味ではない。速度が最優先でないときには、短いメモや確認応答、会話にも使える。ただし、高速性の主張が最も当てはまるのは、あらかじめ定められたコンテスト形式であり、制約のない自由文ではない。
4つのトーンが重要な理由
JTTYの4トーンGFSK波形は、受信機に2つのトーンを選ぶだけではない処理の余地を与える。GFSK、すなわちガウス周波数偏移キーイングは、周波数状態間の遷移を整形し、急激なスペクトルの広がりを抑える。ガウスフィルターによって周波数変化が滑らかになり、占有帯域幅を抑えやすくなる。その結果、フィルター処理されていないキーイング信号に見られる鋭い遷移を避けながら、離散的なトーン群でシンボル情報を伝送できる。
複数のトーンを加えただけで、弱信号性能が向上するわけではない。受信機は信号のタイミングと周波数を推定し、送信されたシンボルをノイズから区別し、フレームに含まれる情報を復元しなければならない。符号化、同期、インターリーブ、信号処理、メッセージ構造のすべてが結果に影響する。波形の性能を決めるのは、「4トーン」といった呼び名ではなく、変調からデコードまでを含むシステム全体だ。
WSJTプロジェクトは長年、人の耳では聞き分けにくい信号から有用な情報を復元することに取り組んできた。そのモードは、コンピューターなら人間がノイズの多い音声信号から確実に取り出せない構造を活用できる、という考え方に基づいている。よく知られた例がFT8だ。短いメッセージ、厳密なタイミング規則、デジタルデコードを組み合わせ、音声通信が難しい状況でも短い交信を可能にする。JTTYはこの信号処理重視の考え方を、ライブのキーボード会話に近い操作感を目指すモードに取り入れている。
開発者によると、JTTYは標準的なRTTYより弱い信号での性能が大幅に高く、エラー率もかなり低いという。リリース資料では、新しいUser Guideに収録されたサンプル録音も紹介されている。開発チームは、この例のJTTY信号は、一般的な45.45ボーRTTYでは受信が不安定でエラーが起こりやすいほど弱いと説明している。モードを評価するうえで参考にはなるが、標準化された感度しきい値が公表されたことと同じではない。
リリース候補版に付属する資料には、JTTYの正式な信号対雑音比しきい値はまだ公表されていない。単一のデシベル値で各モードを比較したい人にとって、これは重要な点だ。弱信号感度は、測定方法、基準帯域幅、メッセージ長、許容エラー率、受信機の実装、試験条件によって変わる。こうした詳細を伴わないしきい値は、誤解を招く比較につながる可能性がある。
RTTYとFT4は異なる運用目的に適しているため、単純な優劣比較では不十分だ。FT4は短い同期時間と構造化されたメッセージを使い、高速な自動交換に最適化されている。RTTYの非同期テキストストリームは、なじみのあるコンテスト手順を支え、オペレーターが自分のペースで送受信できる点が魅力だ。JTTYは、その運用手順の一部と符号化信号を組み合わせようとしているのであり、どちらのモードの機能もすべて置き換えるものではない。
占有帯域幅127 Hzという数字も、実用上のバランスを示している。JTTYは比較的狭い音声帯域に収まる幅だが、狭い信号も、確実に同調・デコードできなければ役に立たない。運用者は混雑を避け、音声レベルを管理し、トランシーバーを適切に調整し、提案されたダイヤル周波数に合わせて運用する必要がある。実際のオンエア体験は、単一のクリーンな試験環境で生成された波形ではなく、実際に運用する局の振る舞いによって決まる。
周波数誤差はデジタル無線の基本的な課題の一つだ。送信機と受信機にはそれぞれ発振器があり、両者の周波数差によって、受信トーンがデコーダーの想定位置からずれる場合がある。最新のソフトウェアは一定の不確かさを見込んで探索できるが、周波数ドリフトの大きさと探索範囲によって信号の見つけやすさが変わる。非同期で送信を始められるコンテストモードでも、限られた周波数帯の中で局同士が見つけ合うには、周波数を正確に合わせる必要がある。
伝搬も別の課題を加える。HFでは、フェージングによって数秒、あるいはその一部の時間で信号の振幅が変化することがある。選択性フェージングは信号の各部分に異なる影響を及ぼす場合があり、空電ノイズ、局所的な電気ノイズ、隣接局の信号が送信の一部を覆い隠すこともある。符号化によって破損したシンボルから情報を復元できる場合はあるが、デジタルモードで伝搬の影響そのものをなくすことはできない。JTTYの性能は、バンド、時刻、アンテナシステム、伝搬経路、運用局の密度によって変わる。
そのため、現場でのテストは特に価値がある。サンプルのWAVファイルなら、既知の録音に対してデコーダーがどう動作するかを示せる。しかし、長距離伝搬で信号が強まったり弱まったりする状況、少し周波数を外して送信する局、混雑したバンド、干渉が起きた瞬間のコンテスト交信など、現実の運用条件の多様さをすべて再現することはできない。リリース候補版を使えば、そうした状況での動作を確認し、観察結果を開発者に伝えられる。
キーボードを手放さずにコンテスト運用
JTTYのファンクションキーは、テンポの速いコンテスト運用を望む人を意識している。F1からF8までのキーで、周波数を確保して呼び出す運用や、相手を探して呼びかける運用など、よく知られた手順を扱える。オペレーター自身のコールサイン、相手局のコールサイン、コンテスト交換情報、キューで次に待っているコールサイン用のマクロも用意されている。デジタルコンテストソフトを設定した経験がある人にはなじみやすい構成だ。
リリース候補版について説明されているマクロ記号には、オペレーター自身のコールサインを表す`%M`、相手局のコールサインを表す`%H`、交換情報を表す`%E`、次にキューに入っているコールサインを表す`%Q`がある。交換内容は現在、599レポートとシリアル番号に基づいている。送信中にもメッセージをキューに追加できるため、交信の進行が速いときに間を短縮できる。
キューは単なるユーザーインターフェース上の便利機能ではない。コンテスト中、オペレーターは受信、局の識別、ログソフトの操作、次に送る内容の判断へと注意を分けている。現在のメッセージを送信している間に次の返答を準備できれば、交換と交換の間の時間を縮められる。その結果、1通ずつ独立したメッセージを送るというより、楽器を演奏するような感覚に近づく可能性がある。
ただし、キューを使った送信も正しい状態管理に依存する。マクロには正しいコールサインと交換情報を設定し、ログソフトと無線機制御の設定が交信相手について一致していなければならない。また、キーを押したあとにソフトウェアが何を送信するのかをオペレーターが理解している必要もある。いずれも通常のコンテスト運用上の注意点だが、新しいモードは設定ミスの機会も増やす。初期テストでは各マクロを確認し、実際の交信で使う前に、電波を出さない方法かダミーロードを使って送信内容を確かめるべきだ。
JTTYを非同期にしたことは、想定される操作感の中心にある。FT8では、時間が決められたメッセージ種類の順に交換が進む。タイミングと形式が標準化されているため、ソフトウェアとオペレーターはその多くを自動化できる。JTTYでは、準備ができた時点でオペレーターが送信を始め、ファンクションキーを使って交換を進められる。オペレーターは引き続きソフトウェアに大きく依存するが、ソフトウェアがQSOのタイミングを決めるのではなく、それを支援する。
この違いは、コンテストのスピードを重視しながらRTTYの直接性も大切にする人を引きつけるかもしれない。運用周波数を見つけ、CQを出し、慣れたマクロの順序で応答を処理する戦術的なテンポを楽しむアマチュアもいる。一方で、キーボードを連続して操作する必要を減らす自動化とタイミングを理由に、FT8を好む人もいる。JTTYはこの好みの違いに決着をつけない。デジタルQSOを別の方法で組み立て、どのバランスが自分に合うかをオペレーターに委ねる。
文化的な課題もある。RTTYコンテストでは、運用上の慣習、マクロ、ログソフトとの連携、操作習慣が長い時間をかけて培われてきた。新しいプロトコルは、古いモードに似ているだけではそれらを引き継げない。予測可能な動作、十分なログソフト対応、使いやすい周波数計画、そして実際に相手局を見つけられるだけの運用局数によって、定着する必要がある。JTTYの仮のダイヤル周波数は出発点を提供するが、それが本当の集合場所になるかは利用者の広がりによって決まる。
コンテストモードでは、交換内容も明確でなければならない。JTTYが現在採用している599レポートとシリアル番号は、なじみのある形式だ。学習の負担を減らす助けにはなるが、コールサインの入力、キュー、再送、確認をアプリケーションがどう処理するのか、運用者は理解しておく必要がある。リリース候補版の段階は、ソフトウェアが想定する操作と、実際のコンテストでの運用とのずれを見つける機会でもある。
開発チームが最初に提案した周波数は、160メートルから2メートルまでのバンドをカバーする。JTTYの初期運用に向けた共通の集合場所として、20メートルバンドの14.090 MHzが提案されている。提案されたダイヤル周波数は、明確に暫定的なものとされている。モードが普及すれば、運用しやすい場所や他のバンド利用との干渉を避ける方法がわかるにつれ、一部またはすべての周波数が変更される可能性がある。
これらの数値はダイヤル周波数であり、送信されるすべてのトーンの正確なRF上の位置を示すとは限らない。サウンドカードを使うデジタルモードでは、トランシーバーのダイヤル周波数と無線機に入力する音声周波数によって、実際の送信RF周波数が決まる。したがって、ダイヤル周波数だけで信号のパスバンド内の位置がすべてわかると考えるのではなく、ソフトウェアの周波数設定に従い、送信音声の配置にも注意する必要がある。
リリースノートによると、Settings | Frequenciesの表でResetを使うと、提案周波数の多くがWSJT-Xの既定の周波数リストに表示される可能性がある。新しい局には便利だが、周波数表をリセットすると、オペレーターが手動で入力した値が置き換わることがある。周波数リストを丁寧に管理している人は、表全体をリセットするのではなく、必要なJTTYの周波数だけを追加するとよい。初期テストのために、それまでの設定作業を失う必要はない。
JTTYを既存のソフトウェア環境に組み込む
WSJT-XはJTTY専用のアプリケーションではない。WSJTのソフトウェアファミリーには、弱信号通信のさまざまな用途に合わせたモードやプログラムが含まれる。WSJT-XはHF、VHF、UHFなどで使われる複数のモードに対応する。MAP65はJT65とQ65の広帯域受信に最適化されており、特にEMEで使われる。QMAPはWSJT-Xと連携し、EMEのサブバンドにおけるQ65の広帯域受信を支援する。
そのため、3.2.0は独立した運用方式を持つ新しいプログラムを導入するのではなく、既存プラットフォームを拡張する。すでにオーディオ機器、無線機制御、ログ記録、デジタルモードのワークフローを設定しているアマチュアにとって重要な点だ。使い慣れたアプリケーション内の新モードなら、独立した新しいパッケージより試しやすいかもしれない。ただし、大きなバージョン変更は設定に影響する場合もあるため、リリースノートをよく読む必要がある。
リリースの発表によると、アップデートにはQ65、MAP65、QMAPの新機能や、その他多くの改善・不具合修正が含まれる。これらは、すぐにJTTYを使う予定のない運用者にとっても関係がある。Q65はEMEや電離層散乱など、厳しい弱信号通信に使われる。MAP65とQMAPは、専門的なシステムでの広帯域受信やバンドマップ機能を扱う。今回のリリースはJTTYだけに限られないため、これらのモードを利用する運用者は更新前に変更点全体を確認すべきだ。
バージョン3.2向けの新しいWSJT-X User Guideが公開された。JTTYの説明とサンプル録音は、設定や受信を始めるための最初の参考資料になる。開発チームは、ガイドがまだ更新中で、古いスクリーンショットや不足している説明文がある可能性を警告している。この注意書きは、リリース候補版を使う人にとって特に有用だ。現在のインターフェースと一致しない説明があっても、必ずしもオペレーターの誤りとは限らず、ガイドが未完成であることが原因かもしれない。
サンプルWAVファイルは、送信する前にデコーダーを試せるため、特に役立つ。録音を処理する際にJTTYのテキストがどう表示されるかを確認でき、メッセージのフレーム構造も把握しやすい。既知のファイルを聞くことで、設定上の問題とオンエア時の不確実性を分けて考えられる。サンプルがデコードされない場合、トランシーバーや伝搬経路を変数に加える前に、ソフトウェア設定やオーディオ構成を調べられる。
ログソフトについて、リリース資料ではN1MM Logger+ 1.0.11449以降に対応するMMTTY互換インターフェースが説明されている。記載された手順では、N1MMのコールサイン欄に「JTTY」と入力すると、WSJT-XがJTTYモードで起動する。JTTY固有のメッセージ形式を示すファンクションキー用のサンプルファイルも含まれる。コンテスト運用者にとって重要な連携だ。ログソフトは付随的な存在ではなく、コールサイン、交換内容、シリアル番号、コンテスト記録を管理する場所だからだ。
ただし、互換性に関する説明は特定バージョンを前提として読む必要がある。特定のN1MM Logger+に対して説明されたインターフェースは、設定の詳細に依存する可能性がある。また、いずれかのアプリケーションの将来のバージョンで動作が変わることもあり得る。コンテストの前には、最新のソフトウェア文書を確認し、連携動作をテストしておくべきだ。初期設定に、すでに動作しているFT8の設定を利用できる場合もあるが、FT8が動作しているからといって、JTTYのすべてのキー、マクロ、ログソフト連携が想定どおりに動くとは限らない。
推奨される手順は、慎重でなじみのあるものだ。まず既存のWSJT-XとN1MMの設定でトランシーバーを制御し、PTTを切り替えられることを確認する。次にJTTYを選び、無線機をダミーロードに接続した状態でファンクションキーを試す。ダミーロードを使えば、未確認のマクロを電波に乗せずに送信内容をチェックできる。設定を確かめた後、提案された集合周波数で聞き、運用局がいれば応答すればよい。
この手順の目的は、恥ずかしい送信を避けることだけではない。コンテスト局の信号経路には、コンピューターの音声出力、無線機の変調経路、CAT制御、PTT、送信音声レベル、アンプやアンテナシステムが含まれる。新しいモードによって、以前は気づかなかった設定上の問題が明らかになることもある。リスクを抑えて経路全体をテストすれば、JTTYのソフトウェアの問題と局側の設定の問題を区別しやすくなる。
JTTYは、送信・受信したテキストをWSJT-Xでおなじみの活動ログALL.TXTに記録できる。このファイルは、画面を一目見ただけではわからなかった内容も残るため、テストセッションの振り返りに役立つ。リリース候補版のテスト中は、この記録を使って再現可能な問題を報告できる。ソフトウェアのバージョン、OS、設定、関連ログを含む報告は、「メッセージに失敗した」という一般的な記述より、開発者にとって有用だ。
プロジェクトはオープンソースで、GNU General Public Licenseバージョン3に基づいて配布されている。公開リポジトリにはWSJTプロジェクトの開発履歴があり、課題報告、議論、コードへの貢献を行う場所も用意されている。プロジェクトは開発者とアマチュア無線家のコミュニティによって構築されてきた。今回の発表では、K1JT、K9AN、G4KLA、N9ADG、DL3WDG、W3SZ、KJ5HST、KD0BTOなどが貢献者として挙げられている。リリース候補版は、この共同開発の過程を見える形にする。ソフトウェアはオンエア実験に使える段階にありながら、フィードバックも開発の一部として続いている。
オープンであることは、技術に詳しいユーザーがJTTYのコードベース内での位置づけを理解する手段にもなる。プロジェクトの開発者向け案内では、必要なスキルを持つ人が貢献する方法を説明している。すべての運用者がソースコードを読んだり変更したりする必要はない。しかしコードと開発履歴が公開されていれば、研究者、ソフトウェア開発者、デジタルモードに詳しい利用者が設計を調べ、テストに参加できる。
最初の課題は局同士が見つけ合えるか
デジタルモードには、性能の高いデコーダーだけでなく、運用者が共通して使う場所も必要だ。共通周波数がなければ、最初の局は正常に送信できても、お互いの信号を受信できない可能性がある。これは、固定された時間枠や共通スケジュールで自動的に同期しない、新しい非同期モードでは特に重要だ。20メートルバンドの14.090 MHzというダイヤル周波数は、初期ユーザーが集まる目印となる。
リリース資料の周波数案は広い範囲をカバーしている。160メートルでは1838 kHz、80メートルでは3575 kHz、40メートルでは7090 kHz、30メートルでは10140 kHz、20メートルでは14090 kHzが提案されている。続いて、17メートルの18100 kHz、15メートルの21090 kHz、12メートルの24920 kHz、10メートルの28090 kHz、6メートルの50160 kHz、2メートルの144160 kHzが挙げられている。開発者は、これらが非常に暫定的な提案であり、運用状況に応じて変わる可能性があると説明している。
暫定的な周波数リストは役に立つが、恒久的なバンドプランや公的な周波数割り当てと混同してはならない。アマチュア無線バンドには、国や地域ごとの規則、定着したデジタルモードの運用、コンテストの慣習、ローカルな運用ルールがある。オペレーターは、自分の地域で適用される法規とバンドプランに送信が適合するよう、自ら確認する責任がある。提案されたダイヤル周波数は集合場所であって、その判断に代わるものではない。
20メートルは、広い距離の通信を支えやすく、デジタルモードのユーザーも多いため、最初の集合バンドとして妥当だ。ただし、HFの伝搬は一定ではない。太陽活動、現地時刻、アンテナ性能、ノイズ、局間の経路が、どのバンドが開いているかに影響する。ある日の午後に活発な周波数でも、時間帯や伝搬条件が変われば静かになることがある。
初期の運用では、交信と同じくらい、使い方を探ることも重要になるだろう。オペレーターはJTTY信号がパスバンドのどこに現れるか、デコーダーがどの程度の速さでテキストを表示するか、送信が重なったときに適切に処理できるか、周波数をどの程度離すべきかを確認する必要がある。また、提案された周波数に十分な運用スペースがあるか、別の配置のほうが実用的かも調べることになる。新モードにはよくある初期の疑問だが、高速で非同期の運用を目指すモードでは特に重要だ。
信号の重なりは重要な試験項目だ。リリースの説明では、信号の減算と適応型デコードが、重なりやフェージングがある状況で信号を復元する手法として挙げられている。信号減算では、デコードした信号を推定して受信音からその成分を取り除き、下に重なった信号を見つけやすくする。適応型デコードは、信号が完全に安定していると仮定するのではなく、変化する信号条件に応じて調整できる。こうした手法の有効性は、受信機がそれぞれの信号をどの程度正確に識別し、取り除く成分をどれだけ精密にモデル化できるかによって決まる。
混雑したコンテスト帯域では、意図的か偶然かを問わず、2局が同時に送信することがある。重なった信号を分離できるデコーダーは、特に同じ周波数付近で高速な交換が複数行われる場合に役立つだろう。ただし、信号減算は処理の複雑さも増やす。一つの信号の推定が不正確だと、残留成分が残ったり、別の信号が歪んだりする可能性がある。受信機は、信号をデコードするのに十分な証拠があるか、重なったデータの復元を試みると誤ったテキストが出る可能性があるかを判断しなければならない。
フェージングも別の課題をもたらす。HF信号は伝搬経路の変化に伴って強さが変わり、短く深いフェードによって送信の一部が失われることもある。フレーム化・符号化されたメッセージの冗長性が、元のテキストの復元に役立つ場合はあるが、結果は情報がフレーム内にどう分散されているか、どの程度失われたかによって変わる。運用者はメッセージがデコードされたかだけでなく、正確かつ一貫してデコードされるかにも注目すべきだ。
デコードできたことと、正確にデコードできたことの区別は極めて重要だ。デジタルモードでテキストが表示されても、それが誤りのないテキストとは限らない。コンテストでは、誤ったコールサインやシリアル番号が表示されないことよりも厄介な場合がある。誤りに気づかず受け入れた後で、訂正が必要になる可能性があるからだ。したがって、開発者が強調する低エラー率は、弱信号性能の主張と同じくらい重要だ。テストでは再送が必要になった頻度、誤った文字が表示された回数、受信が不確かなときにオペレーターがどう判断したかを記録するとよい。
実用性を評価するうえで、リリース候補版は適切な段階だ。サンプル録音一つがすべての状況を代表すると考えず、似た条件での自分のRTTY経験と比較できる。有用な報告には、バンドと周波数、おおよその信号強度、相手局のモードとソフトウェアバージョン、信号が重なったかどうか、デコーダーの表示内容などを記録できる。実験室レベルの測定がなくても、注意深く記述された観察は開発者が再現できる問題の発見につながる。
モードがうまく動作した場合も、同じように報告することが大切だ。ソフトウェア開発へのフィードバックは失敗に集中しやすいが、新しいモードの設計が成功する条件を示す証拠も必要になる。RTTYなら再送が必要になる信号レベルでJTTYが明瞭なテキストを受信できた場合や、マクロの流れによってコンテスト交換が自然に感じられた場合、そうした観察はモードの長所を定義する助けになる。テストの目的は、あらかじめ決めた評価を確認することではなく、システムの動作を把握することだ。
未完成の部分を残すリリース候補版
3.2.0-rc1という表記は、開発の特定段階を示している。リリース候補版は、未完成のドキュメントを受け入れ、新しい動作を試し、明確なフィードバックを送れる上級ユーザー向けだ。単なる宣伝用プレビューではなく、最終版とまったく同じ動作が保証されるものでもない。問題が起きる可能性を踏まえ、プロジェクトの公開リポジトリやユーザーフォーラムを通じて報告することが望ましい。
このステータスによって、使い方も変わる。大規模なコンテストに備える局は、新モードとログソフトの連携が十分にテストされるまで安定版を使うのが妥当かもしれない。デジタルモードの開発に関心がある運用者なら、リリース候補版をインストールして動作確認に時間をかけるかもしれない。どちらの選択も正しい。リリース候補版は、すべてが完成していると扱うのではなく、ユーザーにも評価への参加を求めているという点が重要だ。
User Guideの現状も、この点を裏付けている。プロジェクトによると、ドキュメントの更新が続いているため、一部のスクリーンショットが古く、説明文が不足している場合がある。わかりにくい手順を見つけたユーザーは、その状況を踏まえて更新を確認するとよい。ドキュメントへのフィードバックも役立つ。手順が不明瞭だったり説明が欠けていたりして、関心のある運用者がモードを試せない場合、それ自体がプロジェクトにとって有用な情報となる。
パッケージはWindows、macOS、Linux向けに提供される。Linux版にはx86_64とaarch64が含まれ、32ビットarmhf版も復活する。アマチュア無線局ではデスクトップワークステーションから小型のシングルボードコンピューターまで幅広い機器が使われるため、この対応範囲は重要だ。Raspberry Piユーザーは、ソフトウェアを自分でコンパイルする手間を減らせるarmhfパッケージに特に関心があるかもしれない。それでも、プラットフォームによってパッケージや依存関係が異なるため、インストール前に最新のリリースファイルとシステム要件を確認する必要がある。
新しいメジャーバージョンは、既存の設定ファイルにも影響する可能性がある。オペレーターは、使用中のモード、オーディオ機器、無線機制御、ログ記録の手順に関わる変更をリリースノートで確認すべきだ。局の設定に時間をかけて調整した人は、テスト前に設定のバックアップを取るとよい。通常のソフトウェア保守ではあるが、新しい運用モードと複数プログラムの変更を含むリリースでは特に重要になる。
Release Notesには、バージョン3.0.2以降の変更が詳しく記載されている。この記録は貴重だ。新機能の発表では当然ながら新しい点に焦点が当たるが、運用者はすでに使っている機能の変更も把握する必要がある。今回の広範な更新にはQ65、MAP65、QMAPの改善と多数の修正が含まれている。JTTY以外にもWSJT-X 3.2.0-rc1が自局に影響するかを判断するには、完全なリリースノートを確認するのがよい。
プロジェクトのフィードバック窓口もテストの一部だ。公開リポジトリで課題を登録したり、ディスカッションに参加したり、ユーザーフォーラムに問い合わせたりできる。調査に役立つ報告を作るには、リリース候補のビルド、OS、関連設定、無線機インターフェース、問題が起きるまでの手順などを具体的に記す。信号に関する問題なら、バンド、条件、サンプル音声で再現できるかどうかも説明するとよい。
新しいモードについて最初に役立つ報告は、簡単な質問への答えかもしれない。N1MM Logger+から呼び出したとき、ソフトウェアはJTTYモードで起動するか。ファンクションキーは期待どおりのメッセージを送るか。キューは正しく進むか。受信テキストはオペレーターが追いやすい形で表示されるか。提案周波数のリストを使って相手局を見つけやすいか。こうした点は、実際にモードが使われるかを左右するため、感度の代表値と同じくらい重要になる場合がある。
プロジェクトがオープンソースであることは、フィードバックの意味をさらに大きくする。再現可能な問題を見つけたユーザーは、開発者がプログラムを改善する手助けができる。プログラマーならソースコードを調べたり、修正を提供したりできる。コーディング経験がないアマチュア無線家も、実際のオンエア条件を明確に説明すれば貴重なテスト結果を提供できる。開発にはソフトウェアの専門知識と、運用現場の経験の両方が必要だ。
JTTYが変えられること、変えられないこと
JTTYの価値は単に「改良版RTTY」ということではない。その説明では、フレーム化、符号化、スループット、ソフトウェア連携の違いが見えなくなる。より正確には、キーボードによる無線通信の、人間のテンポに合わせた非同期の感覚を保ちながら、WSJTプロジェクトの弱信号モードに関連する信号処理手法を取り入れる試みだ。
このモードが成功すれば、通常のRTTYでは受信が不安定になる場面で、コンテスト運用者に高速交換の新しい選択肢を提供できる。符号化された送信によって再送を減らせる場合や、構造化メッセージがコンテストに必要な交換内容に合う場合に、効果が最もはっきりするだろう。コールサインとシリアル番号を初回の受信で正しくコピーできるほど、モードの公称速度が実際の運用率向上につながりやすくなる。
ただし、速度はビット毎秒や毎分の単語数だけでは測れない。コンテスト性能は、局の識別、交換開始、応答の受信、エラー修正、交信のログ記録にかかる時間に左右される。短い交換を速く送れても、設定が複雑だったり、頻繁に復旧操作が必要だったりすれば、実際には低速なモードを上回れない場合がある。同様に、ライブキーボード方式がより直接的に感じられたとしても、オペレーターによっては高度に自動化されたシステムのほうが効率的かもしれない。
JTTYの構造化形式は、意図的な妥協だ。よく使うコンテストメッセージを効率化する一方、任意のテキストを自由に送る能力には制約がある。長い会話をすることもできるが、自由入力テキストは毎分約30語で、1フレームに入る任意の文字は5文字だけだ。構造化されたコンテスト形式より遅く、長い会話では制約に感じる可能性がある。JTTYの最も適した用途は、自由なデジタルチャットではなく、短く標準化された交換だ。
キーボードモードが長い会話に向かないとしても、矛盾ではない。多くの無線モードは、コンテストの高速交換、弱信号DX、非常通信、キーボードによる会話、伝搬状況の自動報告など、特定の用途に最適化されている。JTTYは、弱信号性能とコンテスト運用の交点を狙っているようだ。長いメッセージを送りたい人は別のデジタルモードを使えばよい。JTTYはすべての用途を担わなくても、有用なモードになり得る。
コミュニティ内で安定して共有される周波数計画も必要になる。初期の提案は運用開始への招待だが、将来的には地域ごとの調整、コンテスト向けガイドライン、重複を避けるための慣習が求められるかもしれない。デジタルモードの普及はネットワーク効果に左右される。参加局が増えるほど全員にとって便利になる一方、初期ユーザーにも習得する価値があるだけの共通運用が必要だ。20メートルの共通集合周波数は、そのための現実的な第一歩となる。
Q65、MAP65、QMAPの新機能には、別のユーザー層が関心を持つ可能性がある。EME運用者、VHF弱信号通信の愛好家、広帯域SDRシステムの利用者は、HFのRTTYコンテスト運用者とは異なる課題を抱えている。同じリリースにこれらの変更が含まれることは、WSJT-X 3.2.0がJTTYの導入だけではないことを示している。さまざまなバンドや運用環境における弱信号通信の研究を、プロジェクトが幅広く続けている。
この広い文脈は重要だ。JTTYを孤立した新機能ではなく、成熟したモード群の一つとして位置づけているからだ。異なる伝搬経路、メッセージ構造、運用目的に合わせた複数のプロトコルが、一つのアプリケーション内で共存できることは、すでにこのプロジェクトが示してきた。JTTYはその幅に新しい選択肢を加える。オペレーターが即座に操作しながら、信頼性の高いデコードに必要な信号構造を維持するモードだ。
コンテストで定着するかどうかは、実際のオンエア運用で決まる。オペレーターは互いを見つけ、ソフトウェアを試し、経験を比較し、運用スタイルが狙いどおりの価値をもたらすか判断しなければならない。リリース候補版は、それを試す具体的な機会になる。実装、ドキュメント、運用上の慣習がまだ進化する余地を残したまま、ユーザーがモードを試せるようにしている。
最初に試す場合は、サンプル録音を確認し、ログソフトと無線機制御の設定を確かめ、ダミーロードでファンクションキーの動作を試したうえで、20メートルの14.090 MHzダイヤル周波数を聞くのが実用的だ。バグを見つけた人や質問がある人は、プロジェクトの課題管理、ディスカッション、ユーザーフォーラムで報告できる。提案されたバンド周波数は変更される可能性があるため、初期ユーザーは恒久的な割り当てではなく、実験のための集合場所として扱うべきだ。
JTTYの広い意味は、FT8やRTTYを置き換えることよりも、アマチュア無線でデジタル通信を使う方法を広げることにあるのかもしれない。FT8は、強く構造化され、時間同期された弱信号交信の魅力を示した。RTTYは今も、オペレーターが直接操作するコンテスト運用を提供している。JTTYは、両方の性質が必ずしも相反しないと提案する。ライブのキーボード交換でも、符号化フレームと適応型デコードを使って難しい信号に対応できる。
長期的にどのような位置を占めるかがまだ明らかでなくても、試す価値のある実験だ。新しいモードは、ソフトウェアが日常的になると見過ごしがちなトレードオフを浮き彫りにする。自動化とオペレーターの制御、自由なテキストと効率的な符号化、狭い帯域幅と堅牢な受信、固定タイミングと柔軟な通信のバランスだ。WSJT-X 3.2.0-rc1は、こうしたトレードオフを理論だけで決めず、実際に試すよう運用者に呼びかけている。
Image(s) used in this article are either AI-generated or sourced from royalty-free platforms like Pixabay or Pexels.
This article may contain affiliate links. If you purchase through these links, we may earn a commission at no extra cost to you.

