2020年2月24日月曜日

FT8でコールサインが<>で囲まれているケースがあるのはなぜ?

みなさんがFT8をワッチしているときに、ときどき<>で囲まれたコールサインや<...>という表示が出てくることにお気づきかと思います。今日は、FT8がコールサインをどのようにエンコードして送受信しているかについて説明しながら、それら<>の意味を考えてみたいと思います。

6文字までの標準コールサインをアマチュア局のコールサイン割当の性質をうまく利用して28ビットのデータで表現していることをFT8のデータエンコードについて説明しました。では、6文字に収まらないコールサインはどのようにして送受信しているのでしょうか。

FT8ではコールサインを標準型、タイプ1複合型、タイプ2複合型の3通りに定義しています。

標準型コールサインとは、1文字か2文字のプリフィックス(そのうち少なくとも1つは英字)、数字、そして1文字から3文字のサフィックスで構成されるものをいいます。

タイプ1複合コールサインとは、標準型コールサインに数字のサフィックスがついたもの、たとえば、K1ABC/4 のような形です。さらに、あらかじめ定義されたプリフィックスがついたもの、たとえば、ZA/K1ABC のような形です。あらかじめ定義されたプリフィックスはWSJT-XのHelp → List of Type1 prefixes and suffixesで見ることができます。
これらのサフィックス、プリフィックスの情報は、メッセージの3番目のフィールド、すなわち、通常では、グリッドロケータやシグナルレポート、RR、73が入るフィールドを使って送信されます。したがって、
CQ ZA/K1ABC
CQ K1ABC/4
ZA/K1ABC G0XYZ
G0XYZ K1ABC/4
のようなメッセージは送ることができますが、
ZA/K1ABC G0XYZ -22
G0XYZ K1ABC/4 73 
のようなメッセージは送ることができません。-22や73が入るフィールドは、すでに、ZA/や/4で使われてしまっているからです。実際のQSOでは、どのようなメッセージが交換されるか、その例を下に示しました。
CQ ZA/K1ABC
                    ZA/K1ABC G0XYZ
G0XYZ K1ABC –19
                    K1ABC G0XYZ R–22
G0XYZ K1ABC RRR
                    K1ABC G0XYZ 73
1行目2行目では、タイプ1複合コールサインであるZA/プリフィックスがついています。したがって、グリッドロケータなどの情報は送っていません。3行目以降は、信号レポートやRRR、73を送っていますが、そのときは、プリフィックスが省かれていることがわかります。

タイプ2型複合コールサインとは、あらかじめ定義されたプリフィックス、サフィックスに無いプリフィックス、サフィックスがついたコールサインを言います。たとえば、W4/G0XYZ、K1ABC/VE6のような形です。タイプ2型複合コールサインを含む場合は、最初の語はCQか、DEか、QRZでなければなりません。下のようなメッセージになります。
CQ W4/G0XYZ FM07
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
メッセージにはタイプ2複合コールサイン1つしか入りません。したがって、QSOはこのような感じで進むことになります。
CQ K1ABC FN42
                    DE G0XYZ/W4 FM18
G0XYZ K1ABC –19
                    K1ABC G0XYZ R–22
G0XYZ K1ABC RRR
                    DE G0XYZ/W4 73
この例で、最初にCQを出していたK1ABCから/W4を含むメッセージは返ってきていませんが、K1ABCは/W4をきちんとコピーしています。FT8では、本コールサインだけコピーして、サフィックスだけ落とすということはないからです。

他の手段として、コールサインにハッシュをかけ、圧縮して表現する方法があります。ハッシュというのは、コールサインを表すデータから別の(より短い)データを生成することです。留意すべきは、あるコールサインが与えられたとき、そのハッシュ値は必ず決まるということです。加えて、複数の別のコールサインが同一のハッシュ値を持つ可能性があるということです。言い換えると、ハッシュ値だけから元のコールサインを復元することはできません。QSO例を見てみましょう。
① CQ PJ4/K1ABC
②                      <PJ4/K1ABC> W9XYZ
③ W9XYZ <PJ4/K1ABC> +03
④                      <PJ4/K1ABC> W9XYZ R-08
⑤ <W9XYZ> PJ4/K1ABC RRR
⑥                      PJ4/K1ABC <W9XYZ> 73
①でPJ4/K1ABCがCQを出しました。PJ4/はあらかじめ定義されたプリフィックスリストに載っていません。したがって、PJ4/K1ABCはタイプ2複合コールサインになります。それを受信したW9XYZが呼びます。しかし、上で説明したように、メッセージ内にタイプ2複合コールサインが含まれる場合、データサイズが大きくなりすぎて別のコールサインを入れることができません。そこで、W9XYZ側のWSJT-XプログラムはPJ4/K1ABCにハッシュをかけ、データを圧縮してメッセージに埋め込みます。生コールサインではなく、ハッシュ値であることは<>で囲まれていることでわかります。PJ4/K1ABCは自分のハッシュ値を知っていますから、自分が呼ばれたことがわかりますので、③で応答します。このとき、自分のコールサインは生のデータではなく、ハッシュ値としてメッセージに入れています。⑤⑥では、W9XYZが生データではなく、ハッシュ値としてやり取りされています。

では次に、このQSOをあたながワッチしていて、もし、①の電波が受信出来ていない場合を想定してみます。
②                      <PJ4/K1ABC> W9XYZ
③ W9XYZ <PJ4/K1ABC> +03
④                      <PJ4/K1ABC> W9XYZ R-08
⑤ <W9XYZ> PJ4/K1ABC RRR
⑥                      PJ4/K1ABC <W9XYZ> 73
②で受信されたPJ4/K1ABCのハッシュ値は受信できても、それがPJ4/K1ABCから計算されたハッシュ値であることがわかりません。したがって、WSJT-Xは<...>と表示します。
②                      <...> W9XYZ
③ W9XYZ <...> +03
④                      <...> W9XYZ R-08
⑤ <W9XYZ> PJ4/K1ABC RRR
⑥                      PJ4/K1ABC <W9XYZ> 73
⑤のW9XYZのハッシュ値はどうでしょう。②③④でW9XYZのコールサインを受信していますから、そこからハッシュ値を計算し、それと⑤の<W9XYZ>と照合することができるので、WSJT-XはW9XYZのコールサインを表示できます。

このような巧みな技を使って、少ないデータ量でQSOを成立させています。すごいですね。

2020年2月11日火曜日

FT8はなぜ飛ぶか? ー FEC 前方誤り訂正符号

FT8は、FEC (Forward Error Correction)、日本語で前方誤り訂正符号を使っています。FECとは送るデータに冗長性をもたせ、データをすべて正確に受信されない場合でも、元のデータを復元できる手法です。簡単な例として、PHONEやCWでコールサインを複数回送るというのもFECの一種です。1回目でラスト・レターが聞き取れなくても、2回目で聞き取れる、ということはよくあります。RS-232Cで用いられる(奇数/偶数)パリティも、このFECに近い手法ですが、たとえば8ビットデータ1ビットパリティの場合、9ビットのうち1ビットが間違って受信されたとき、そのデータが壊れているということが検出できます。しかし、どの1ビットが間違っていたかについては不明なため、元の正しいデータを復元することはできません。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箇所挿入しています。コスタス行列については後日取り上げたいと思います。




2020年2月9日日曜日

FT8のデータ圧縮(データエンコード)

データエンコードと聞くと何を連想しますか? データ圧縮でしょうか。インターネットで大きなファイルを送るとき、ZIPをかける、ということは、よくありますね。 画像データのフォーマットでよく使われるJPEGやPNGも元のビット毎データを圧縮してファイルサイズを小さくしています。動画ではMPEG、音楽データはMP3が有名ですね。いろいろな圧縮方法があるのは、そのターゲットであるデータの特性を考慮して、様々な技を使っているからです。圧縮方法には大きく分けて2通りあり、可逆圧縮と非可逆圧縮と呼ばれます。MP3は非可逆圧縮ですが、人間の聴覚の特性を巧みに利用し、たとえば、大きな音が入ったすぐ後は小さな音が聞き取れにくいので少し省略、みたいなことをやっています。

FT8はアマチュア無線の交信の特性を考慮した可逆圧縮を行っています。PC上では6文字のコールサインをASCIIコードで表現するために、1文字あたり8ビット使いますので、8x6=48ビット必要です。FT8では、これを28ビットに圧縮しています。圧縮と言うより、巧みにエンコードしていると言ったほうが正確かもしれません。

標準のアマチュア無線局コールサインは、1文字か2文字のプリフィックス、そのうち少なくとも1つは英字、数字、そして1文字から3文字のサフィックスで構成されます。この構成から得られる組み合わせ数は、37✕36✕10✕27✕27✕27で、およそ2億6千万通りになります。37または27という数が出てくるのは、最初と後ろの3文字が、ブランクか英字か数字になるためです。2の28乗は2億6千万より大きい値になりますから、28ビットあれば標準のコールサインを一意に表現できます。さらに、このなかでも6百万程度コールサインとして使われていない組み合わせがあります。たとえば、0から始まるコールサインや、Q符号と重なるコールサインは使われません。その空いているスペースにCQやDEやQRZを割り当てています。

4桁のグリッドロケータは180✕180=32,400通りあります。2の15乗が32,768ですから、グリッドロケータはは15ビットで表わすことができます。シグナルレポートはグリッドロケータ部分に埋め込まれます。

W6/K1JTやK1JT/1のようなプリフィックス、サフィックスは上に述べた使われていないい6百万の組み合わせかグリッドロケータ部分に埋め込まれます。

このように、アマチュア無線局のコールサインの特性をうまく利用しながら、少ないビット数でコールサインやレポートなどの情報を送っています。すごいですね。トータルとして、FT8の1つのメッセージは(相手の)コールサイン28ビット+(自分の)コールサイン28ビット+グリッドロケータ15ビットの71ビット、FT8のDXpeditionモードのメッセージ、コンテスト、非標準コールサインを表現するための5ビット、そしてオプションの11ビットを加えた77ビットで構成されています。

この77ビットに強力なFEC(Forward Error Correction)前方誤り訂正符号をかけて電波として送り出します。

次回、FECへ続く。。。



2020年2月5日水曜日

FT8ーその技術を紐解く

FT8大人気です。FT8を使えば、コンディションが良くないときでも、ローパワーで、大きくないアンテナでも、遠くとQSOできます。雑誌やネット、いろいろなところで、WSJT-X、JTDXなどのソフトのインストール方法、設定方法、QSOの手順が紹介されています。でも、FT8は何故飛ぶのか?その裏にある工夫について探ってみたいと思います。

まず、FT8の特徴をリストアップしてみます。

  1. FECを使った誤り訂正符号
  2. アマチュア無線のコールサインや普段使うメッセージを考慮したエンコードとデータ圧縮
  3. コスタス行列を用いた同期処理
  4. QRMを少なくする狭い占有帯域(GFSK)
  5. マルチパスデコード
  6. DXペディションモードで採用された複数のQSOの同時並行処理

他にもありますが、順々に中身を見ていきたいと思います。

WSJT-X日本語訳

WSJT-X関連の文書を和訳して公開しています。ここに掲載している日本語訳は営利目的ではない個人での利用に限定します。また、インターネット上での再配布はお控えください。 (2019年7月18日記)

WSJT-X 2.1.2 公開アナウンス(最終更新2019年12月2日)

WSJT-X 2.1.2 ユーザーガイド 日本語訳最終更新2019年12月2日

FT8 Dxpeditionモード 日本語訳最終更新2018年5月22日



FT8でコールサインが<>で囲まれているケースがあるのはなぜ?

みなさんがFT8をワッチしているときに、ときどき<>で囲まれたコールサインや<...>という表示が出てくることにお気づきかと思います。今日は、FT8がコールサインをどのようにエンコードして送受信しているかについて説明しながら、それら<>の意味を考えてみたい...