変更点アナウンス日本語訳はこちら
https://www.qsl.net/ja7ude/wsjt/wsjt-x-2.3.0-announcement.html
2020年11月17日火曜日
2020年9月30日水曜日
WSJT-X 2.3.0のユーザーガイド日本語訳
WSJT-X 2.3.0のユーザーガイドが公開されました。
http://physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.3.0-rc1_en.html
日本語訳を公開しました。
新しいモードFST4/FST4Wのクイックスタートガイド和訳
新しいモードFST4/FST4Wのクイックスタートガイド（http://physics.princeton.edu/pulsar/K1JT/FST4_Quick_Start.pdf）が更新されていましたので、合わせて日本語訳を更新しました。
https://www.qsl.net/ja7ude/wsjt/
2020年9月12日土曜日
2020年6月22日月曜日
2020年6月20日土曜日
WSJT-XのUIの日本語化
WSJT-X 2.2.0が公開されました。
http://physics.princeton.edu/pulsar/K1JT/wsjtx.html
日本語Windowsをお使いの方は、なにも設定しなくても、UI（ユーザーインターフェース）が日本語表示になります。元の英語表示にしたいときは、--language=enオプションを付けて起動します。
例： wsjtx.exe --language=en
http://physics.princeton.edu/pulsar/K1JT/wsjtx.html
日本語Windowsをお使いの方は、なにも設定しなくても、UI（ユーザーインターフェース）が日本語表示になります。元の英語表示にしたいときは、--language=enオプションを付けて起動します。
例： wsjtx.exe --language=en
2020年2月24日月曜日
FT8でコールサインが<>で囲まれているケースがあるのはなぜ？
みなさんがFT8をワッチしているときに、ときどき<>で囲まれたコールサインや<...>という表示が出てくることにお気づきかと思います。今日は、FT8がコールサインをどのようにエンコードして送受信しているかについて説明しながら、それら＜＞の意味を考えてみたいと思います。
6文字までの標準コールサインをアマチュア局のコールサイン割当の性質をうまく利用して28ビットのデータで表現していることをFT8のデータエンコードについて説明しました。では、6文字に収まらないコールサインはどのようにして送受信しているのでしょうか。
FT8ではコールサインを標準型、タイプ1複合型、タイプ2複合型の3通りに定義しています。
標準型コールサインとは、１文字か２文字のプリフィックス（そのうち少なくとも１つは英字）、数字、そして１文字から３文字のサフィックスで構成されるものをいいます。
タイプ1複合コールサインとは、標準型コールサインに数字のサフィックスがついたもの、たとえば、K1ABC/4 のような形です。さらに、あらかじめ定義されたプリフィックスがついたもの、たとえば、ZA/K1ABC のような形です。あらかじめ定義されたプリフィックスはWSJT-XのHelp → List of Type1 prefixes and suffixesで見ることができます。
これらのサフィックス、プリフィックスの情報は、メッセージの3番目のフィールド、すなわち、通常では、グリッドロケータやシグナルレポート、RR、73が入るフィールドを使って送信されます。したがって、
タイプ2型複合コールサインとは、あらかじめ定義されたプリフィックス、サフィックスに無いプリフィックス、サフィックスがついたコールサインを言います。たとえば、W4/G0XYZ、K1ABC/VE6のような形です。タイプ2型複合コールサインを含む場合は、最初の語はCQか、DEか、QRZでなければなりません。下のようなメッセージになります。
他の手段として、コールサインにハッシュをかけ、圧縮して表現する方法があります。ハッシュというのは、コールサインを表すデータから別の（より短い）データを生成することです。留意すべきは、あるコールサインが与えられたとき、そのハッシュ値は必ず決まるということです。加えて、複数の別のコールサインが同一のハッシュ値を持つ可能性があるということです。言い換えると、ハッシュ値だけから元のコールサインを復元することはできません。QSO例を見てみましょう。
では次に、このQSOをあたながワッチしていて、もし、①の電波が受信出来ていない場合を想定してみます。
このような巧みな技を使って、少ないデータ量でQSOを成立させています。すごいですね。
6文字までの標準コールサインをアマチュア局のコールサイン割当の性質をうまく利用して28ビットのデータで表現していることをFT8のデータエンコードについて説明しました。では、6文字に収まらないコールサインはどのようにして送受信しているのでしょうか。
FT8ではコールサインを標準型、タイプ1複合型、タイプ2複合型の3通りに定義しています。
標準型コールサインとは、１文字か２文字のプリフィックス（そのうち少なくとも１つは英字）、数字、そして１文字から３文字のサフィックスで構成されるものをいいます。
タイプ1複合コールサインとは、標準型コールサインに数字のサフィックスがついたもの、たとえば、K1ABC/4 のような形です。さらに、あらかじめ定義されたプリフィックスがついたもの、たとえば、ZA/K1ABC のような形です。あらかじめ定義されたプリフィックスはWSJT-XのHelp → List of Type1 prefixes and suffixesで見ることができます。
CQ ZA/K1ABCのようなメッセージは送ることができますが、
CQ K1ABC/4
ZA/K1ABC G0XYZ
G0XYZ K1ABC/4
ZA/K1ABC G0XYZ -22のようなメッセージは送ることができません。-22や73が入るフィールドは、すでに、ZA/や/4で使われてしまっているからです。実際のQSOでは、どのようなメッセージが交換されるか、その例を下に示しました。
G0XYZ K1ABC/4 73
CQ ZA/K1ABC1行目2行目では、タイプ1複合コールサインであるZA/プリフィックスがついています。したがって、グリッドロケータなどの情報は送っていません。3行目以降は、信号レポートやRRR、73を送っていますが、そのときは、プリフィックスが省かれていることがわかります。
ZA/K1ABC G0XYZ
G0XYZ K1ABC –19
K1ABC G0XYZ R–22
G0XYZ K1ABC RRR
K1ABC G0XYZ 73
タイプ2型複合コールサインとは、あらかじめ定義されたプリフィックス、サフィックスに無いプリフィックス、サフィックスがついたコールサインを言います。たとえば、W4/G0XYZ、K1ABC/VE6のような形です。タイプ2型複合コールサインを含む場合は、最初の語はCQか、DEか、QRZでなければなりません。下のようなメッセージになります。
CQ W4/G0XYZ FM07メッセージにはタイプ2複合コールサイン１つしか入りません。したがって、QSOはこのような感じで進むことになります。
QRZ K1ABC/VE6 DO33
DE W4/G0XYZ FM18
DE W4/G0XYZ -22
DE W4/G0XYZ R-22
DE W4/G0XYZ RRR
DE W4/G0XYZ 73
CQ K1ABC FN42この例で、最初にCQを出していたK1ABCから/W4を含むメッセージは返ってきていませんが、K1ABCは/W4をきちんとコピーしています。FT8では、本コールサインだけコピーして、サフィックスだけ落とすということはないからです。
DE G0XYZ/W4 FM18
G0XYZ K1ABC –19
K1ABC G0XYZ R–22
G0XYZ K1ABC RRR
DE G0XYZ/W4 73
他の手段として、コールサインにハッシュをかけ、圧縮して表現する方法があります。ハッシュというのは、コールサインを表すデータから別の（より短い）データを生成することです。留意すべきは、あるコールサインが与えられたとき、そのハッシュ値は必ず決まるということです。加えて、複数の別のコールサインが同一のハッシュ値を持つ可能性があるということです。言い換えると、ハッシュ値だけから元のコールサインを復元することはできません。QSO例を見てみましょう。
① CQ PJ4/K1ABC①でPJ4/K1ABCがCQを出しました。PJ4/はあらかじめ定義されたプリフィックスリストに載っていません。したがって、PJ4/K1ABCはタイプ２複合コールサインになります。それを受信したW9XYZが呼びます。しかし、上で説明したように、メッセージ内にタイプ２複合コールサインが含まれる場合、データサイズが大きくなりすぎて別のコールサインを入れることができません。そこで、W9XYZ側のWSJT-XプログラムはPJ4/K1ABCにハッシュをかけ、データを圧縮してメッセージに埋め込みます。生コールサインではなく、ハッシュ値であることは＜＞で囲まれていることでわかります。PJ4/K1ABCは自分のハッシュ値を知っていますから、自分が呼ばれたことがわかりますので、③で応答します。このとき、自分のコールサインは生のデータではなく、ハッシュ値としてメッセージに入れています。⑤⑥では、W9XYZが生データではなく、ハッシュ値としてやり取りされています。
② <PJ4/K1ABC> W9XYZ
③ W9XYZ <PJ4/K1ABC> +03
④ <PJ4/K1ABC> W9XYZ R-08
⑤ <W9XYZ> PJ4/K1ABC RRR
⑥ PJ4/K1ABC <W9XYZ> 73
では次に、このQSOをあたながワッチしていて、もし、①の電波が受信出来ていない場合を想定してみます。
② <PJ4/K1ABC> W9XYZ②で受信されたPJ4/K1ABCのハッシュ値は受信できても、それがPJ4/K1ABCから計算されたハッシュ値であることがわかりません。したがって、WSJT-Xは<...>と表示します。
③ W9XYZ <PJ4/K1ABC> +03
④ <PJ4/K1ABC> W9XYZ R-08
⑤ <W9XYZ> PJ4/K1ABC RRR
⑥ PJ4/K1ABC <W9XYZ> 73
② <...> W9XYZ⑤のW9XYZのハッシュ値はどうでしょう。②③④でW9XYZのコールサインを受信していますから、そこからハッシュ値を計算し、それと⑤の<W9XYZ>と照合することができるので、WSJT-XはW9XYZのコールサインを表示できます。
③ W9XYZ <...> +03
④ <...> W9XYZ R-08
⑤ <W9XYZ> PJ4/K1ABC RRR
⑥ PJ4/K1ABC <W9XYZ> 73
このような巧みな技を使って、少ないデータ量でQSOを成立させています。すごいですね。
2020年2月11日火曜日
FT8はなぜ飛ぶか？ ー FEC 前方誤り訂正符号
FT8は、FEC (Forward Error Correction)、日本語で前方誤り訂正符号を使っています。FECとは送るデータに冗長性をもたせ、データをすべて正確に受信されない場合でも、元のデータを復元できる手法です。簡単な例として、PHONEやCWでコールサインを複数回送るというのもFECの一種です。１回目でラスト・レターが聞き取れなくても、２回目で聞き取れる、ということはよくあります。RS-232Cで用いられる（奇数/偶数）パリティも、このFECに近い手法ですが、たとえば8ビットデータ１ビットパリティの場合、９ビットのうち１ビットが間違って受信されたとき、そのデータが壊れているということが検出できます。しかし、どの１ビットが間違っていたかについては不明なため、元の正しいデータを復元することはできません。FECとは、ざっくり言うと、このパリティビットをたくさん付加して、（元データ＋パリティビット全体の）データの一部が正しく受信できない場合、他のビットから復元しようとするものです。
FT8の基本メッセージ長は相手のコールサイン28ビット、自分のコールサイン28ビット、グリッドロケータ15ビット、その他6ビットの合計77ビットです。これに14ビットのCRC（Cyclic Redundancy Check）を加えます。CRCとは、奇数/偶数パリティのように、誤りを検出する手法で、元データから14ビットのCRCデータを計算し、元データにつなげます。WSJT-Xのソースコード(crc14.cpp)を見ると、多項式係数が0x2757となっているので、x^14+x^13+x^10+x^9+x^8+x^6+x^4+x^2+x+1の多項式を使っているようです。77ビットの元データから14ビットのCRCを作りますから、同じCRCを持つ別の元データが複数あるわけですが、なるべく同じCRCにならないように工夫します。思い切りざっくり言うと、元データの77ビットのうち、1ビットだけ異なる2つのデータがあったとして、その2つのデータから全然違うCRCが生成されるようにします。
次に、パリティビットを作って付加しますが、パリティを作るにはいろいろな方法があります。FT8ではLDPC（Low Density Parity-check Code）- 低密度パリティ検査と呼ばれる手法を用います。LDPCが考案されたのは、1960年と古く、エラーフロアが低く、コーディング効率が良いということで、注目されましたが、エンコード・デコードの計算量が多く、当時の遅いコンピュータでは扱いきれないものでした。しかし、1990年代後半になり、マイコンの計算能力の向上と並列に演算できるという性質から、その特長が見直され、現在では衛星テレビ、イーサネット、WiFiなど色々な分野で使われています。FT8では、元データ77ビット＋CRC14ビット＋パリティ83ビットの合計174ビットをひとつのメッセージとして送ります。実際に空に送信されるデータは、同期を取るための7x7のコスタス行列を、最初、中間、最後の3箇所挿入しています。コスタス行列については後日取り上げたいと思います。
FT8の基本メッセージ長は相手のコールサイン28ビット、自分のコールサイン28ビット、グリッドロケータ15ビット、その他6ビットの合計77ビットです。これに14ビットのCRC（Cyclic Redundancy Check）を加えます。CRCとは、奇数/偶数パリティのように、誤りを検出する手法で、元データから14ビットのCRCデータを計算し、元データにつなげます。WSJT-Xのソースコード(crc14.cpp)を見ると、多項式係数が0x2757となっているので、x^14+x^13+x^10+x^9+x^8+x^6+x^4+x^2+x+1の多項式を使っているようです。77ビットの元データから14ビットのCRCを作りますから、同じCRCを持つ別の元データが複数あるわけですが、なるべく同じCRCにならないように工夫します。思い切りざっくり言うと、元データの77ビットのうち、1ビットだけ異なる2つのデータがあったとして、その2つのデータから全然違うCRCが生成されるようにします。
次に、パリティビットを作って付加しますが、パリティを作るにはいろいろな方法があります。FT8ではLDPC（Low Density Parity-check Code）- 低密度パリティ検査と呼ばれる手法を用います。LDPCが考案されたのは、1960年と古く、エラーフロアが低く、コーディング効率が良いということで、注目されましたが、エンコード・デコードの計算量が多く、当時の遅いコンピュータでは扱いきれないものでした。しかし、1990年代後半になり、マイコンの計算能力の向上と並列に演算できるという性質から、その特長が見直され、現在では衛星テレビ、イーサネット、WiFiなど色々な分野で使われています。FT8では、元データ77ビット＋CRC14ビット＋パリティ83ビットの合計174ビットをひとつのメッセージとして送ります。実際に空に送信されるデータは、同期を取るための7x7のコスタス行列を、最初、中間、最後の3箇所挿入しています。コスタス行列については後日取り上げたいと思います。
2020年2月9日日曜日
FT8のデータ圧縮（データエンコード）
データエンコードと聞くと何を連想しますか？ データ圧縮でしょうか。インターネットで大きなファイルを送るとき、ZIPをかける、ということは、よくありますね。 画像データのフォーマットでよく使われるJPEGやPNGも元のビット毎データを圧縮してファイルサイズを小さくしています。動画ではMPEG、音楽データはMP3が有名ですね。いろいろな圧縮方法があるのは、そのターゲットであるデータの特性を考慮して、様々な技を使っているからです。圧縮方法には大きく分けて２通りあり、可逆圧縮と非可逆圧縮と呼ばれます。MP3は非可逆圧縮ですが、人間の聴覚の特性を巧みに利用し、たとえば、大きな音が入ったすぐ後は小さな音が聞き取れにくいので少し省略、みたいなことをやっています。
FT8はアマチュア無線の交信の特性を考慮した可逆圧縮を行っています。PC上では６文字のコールサインをASCIIコードで表現するために、１文字あたり８ビット使いますので、８ｘ６＝４８ビット必要です。FT8では、これを２８ビットに圧縮しています。圧縮と言うより、巧みにエンコードしていると言ったほうが正確かもしれません。
標準のアマチュア無線局コールサインは、１文字か２文字のプリフィックス、そのうち少なくとも１つは英字、数字、そして１文字から３文字のサフィックスで構成されます。この構成から得られる組み合わせ数は、３７✕３６✕１０✕２７✕２７✕２７で、およそ２億６千万通りになります。３７または２７という数が出てくるのは、最初と後ろの３文字が、ブランクか英字か数字になるためです。２の２８乗は２億６千万より大きい値になりますから、２８ビットあれば標準のコールサインを一意に表現できます。さらに、このなかでも６百万程度コールサインとして使われていない組み合わせがあります。たとえば、０から始まるコールサインや、Q符号と重なるコールサインは使われません。その空いているスペースにCQやDEやQRZを割り当てています。
４桁のグリッドロケータは１８０✕１８０＝３２，４００通りあります。２の１５乗が３２，７６８ですから、グリッドロケータはは１５ビットで表わすことができます。シグナルレポートはグリッドロケータ部分に埋め込まれます。
W6/K1JTやK1JT/1のようなプリフィックス、サフィックスは上に述べた使われていないい６百万の組み合わせかグリッドロケータ部分に埋め込まれます。
このように、アマチュア無線局のコールサインの特性をうまく利用しながら、少ないビット数でコールサインやレポートなどの情報を送っています。すごいですね。トータルとして、FT8の１つのメッセージは（相手の）コールサイン２８ビット＋（自分の）コールサイン２８ビット＋グリッドロケータ１５ビットの７１ビット、FT8のDXpeditionモードのメッセージ、コンテスト、非標準コールサインを表現するための５ビット、そしてオプションの1１ビットを加えた７7ビットで構成されています。
この７７ビットに強力なFEC（Forward Error Correction）前方誤り訂正符号をかけて電波として送り出します。
FT8はアマチュア無線の交信の特性を考慮した可逆圧縮を行っています。PC上では６文字のコールサインをASCIIコードで表現するために、１文字あたり８ビット使いますので、８ｘ６＝４８ビット必要です。FT8では、これを２８ビットに圧縮しています。圧縮と言うより、巧みにエンコードしていると言ったほうが正確かもしれません。
標準のアマチュア無線局コールサインは、１文字か２文字のプリフィックス、そのうち少なくとも１つは英字、数字、そして１文字から３文字のサフィックスで構成されます。この構成から得られる組み合わせ数は、３７✕３６✕１０✕２７✕２７✕２７で、およそ２億６千万通りになります。３７または２７という数が出てくるのは、最初と後ろの３文字が、ブランクか英字か数字になるためです。２の２８乗は２億６千万より大きい値になりますから、２８ビットあれば標準のコールサインを一意に表現できます。さらに、このなかでも６百万程度コールサインとして使われていない組み合わせがあります。たとえば、０から始まるコールサインや、Q符号と重なるコールサインは使われません。その空いているスペースにCQやDEやQRZを割り当てています。
４桁のグリッドロケータは１８０✕１８０＝３２，４００通りあります。２の１５乗が３２，７６８ですから、グリッドロケータはは１５ビットで表わすことができます。シグナルレポートはグリッドロケータ部分に埋め込まれます。
W6/K1JTやK1JT/1のようなプリフィックス、サフィックスは上に述べた使われていないい６百万の組み合わせかグリッドロケータ部分に埋め込まれます。
このように、アマチュア無線局のコールサインの特性をうまく利用しながら、少ないビット数でコールサインやレポートなどの情報を送っています。すごいですね。トータルとして、FT8の１つのメッセージは（相手の）コールサイン２８ビット＋（自分の）コールサイン２８ビット＋グリッドロケータ１５ビットの７１ビット、FT8のDXpeditionモードのメッセージ、コンテスト、非標準コールサインを表現するための５ビット、そしてオプションの1１ビットを加えた７7ビットで構成されています。
この７７ビットに強力なFEC（Forward Error Correction）前方誤り訂正符号をかけて電波として送り出します。
次回、FECへ続く。。。
2020年2月5日水曜日
FT8ーその技術を紐解く
FT８大人気です。FT8を使えば、コンディションが良くないときでも、ローパワーで、大きくないアンテナでも、遠くとQSOできます。雑誌やネット、いろいろなところで、WSJT-X、JTDXなどのソフトのインストール方法、設定方法、QSOの手順が紹介されています。でも、FT8は何故飛ぶのか？その裏にある工夫について探ってみたいと思います。
まず、FT8の特徴をリストアップしてみます。
まず、FT8の特徴をリストアップしてみます。
- FECを使った誤り訂正符号
- アマチュア無線のコールサインや普段使うメッセージを考慮したエンコードとデータ圧縮
- コスタス行列を用いた同期処理
- QRMを少なくする狭い占有帯域（GFSK）
- マルチパスデコード
- DXペディションモードで採用された複数のQSOの同時並行処理
他にもありますが、順々に中身を見ていきたいと思います。
WSJT-X日本語訳
WSJT-X関連の文書を和訳して公開しています。ここに掲載している日本語訳は営利目的ではない個人での利用に限定します。また、インターネット上での再配布はお控えください。 (2019年7月18日記)
登録:
投稿 (Atom)
-
先日、PCに載っているマイクロプロセッサがAVX対応かどうか確認するツールとしてCPU-Zを紹介しましたが、別のツールもご紹介します。本家インテルが出しているツール、その名も「 Intel Processor Identification Utility 」です。Exeファイル... -
みなさんがFT8をワッチしているときに、ときどき<>で囲まれたコールサインや<...>という表示が出てくることにお気づきかと思います。今日は、FT8がコールサインをどのようにエンコードして送受信しているかについて説明しながら、それら＜＞の意味を考えてみたい... -
WSJT-X 2.6.1 2023年1月16日 WSJT-X 2.6.1は、おもにQ65に関係するバグ修正版です。2.6.0からの変更点は以下の通りです。 Q65モードにおいて、送受信時間を選択するスピナーの表示を修正。 デコードメッセージのフォントを正確に表示するよう修正。 ...