■MMvari（GMSK）開発プロジェクトについて

■MMvari（GMSK）の操作画面

■MMvari（GMSK）による1st QSO

■JE3HHT 森OMとのQSO
　40mBANDのPSKモードをモニターしていたら偶然森OMのCQ/JAvariを発見

■MMvari（GMSK）の調整（編集中）
S/Nディスプレイの詳細やclockずれetc.・・・
分からないことが多いです。
少しでも理解を深めるためマニュアルに沿って調整。

■MMvari（GMSK）運用レポート（編集中）

■

■

プロジェクトについて
2004.JAN.02 JE3HHT 森 誠
改訂 2004.JAN.12 JE3HHT 森 誠

◎はじめに
私は日本人なので日本語での会話が好きです。PSK31においても国内局同士であればできるだけ日本語で会話します。ご存知の通り、PSK31は素晴らしい伝送方式ですが、日本語を伝送する場合、若干の問題があることが気になっていました。そして他の東アジア系言語（ハングル、中国語）でも同じ問題を持つと考えられます。
　このプロジェクトは、この問題を低減する方法について考察し、それを実験することを目的とします。

◎文字コードと符号構成
東アジア系言語(日本語、ハングル、中国語)は文字数が多いので8Bitsコード単体で表現することができず、現在のところPSK31ではMBCS(Multibyte Character Set, 日本語の場合はShift-JIS)と呼ばれる２バイト文字を使って伝送されています（この方式を２文字連結方式と呼ぶことにします）。しかし伝送上は２文字で１文字になる訳ですから、以下のような不都合が生じます。

1)伝送速度が遅くなる。
2)文字の位相がずれるとまったく違う文字になり、その状態からしばらく回復できない。
3)異なる文字長の文字が混在するので、BS（バックスペース）の扱いが不透明になる。

(1)東アジア系言語の場合、取り扱う文字数が多いのである程度は仕方がないとは思いますが、MBCSの１バイト目が$81-$FEに割り当てられていることでPSK31ではより不利になっています。また日本語では出現頻度の高いひらがなの２バイト目が$9F-$F2に割り当てられているのも良くありません。これらの範囲はPSK31のVARICODEの中でも長い符号が定義されているからです。またMBCS１文字に対して２文字分のVARICODEを伝送するので、間に余分なGAP(00)が追加されます（合計すると24bits程度の符号になってしまう）。
実際に日本語でQSOをしてみれば判りますが、現在の速度はあまりにも遅過ぎ（熟練者同士の和文CWに負けてる）、QSOするのに相当な覚悟（？）が必要になります。伝送速度をもう少し速くできれば、気軽に運用できるようになるかも知れません。

(2)はQSBやQRNなどで発生し、実際に落としているのは１文字だけなのですが、受信側では位相がずれて何文字も連続した化け字になってしまいます。これはMBCS１文字目と２文字目に同じ範囲のコードが存在するために、両者の位相を確実に区別することができないからです。幸い日本語では$A0-$DFにはMBCS１文字目のコードが割り当てられておらずこの範囲でも位相を合わせることができますが、ハングルや中国語ではMBCS１文字目と２文字目のコードの重なり範囲が日本語より大きいので、位相の復帰がさらに難しくなると考えられます。

(3)アプリケーションから見た場合、１バイト文字と２バイト文字が１バイト単位で混在して伝送されるため、BSの取り扱いが難しくなります。日本語対応のPSK31のソフト（HALPSKやWINPSK/Jなど）では巧妙にこれを処理していますが、本来アプリケーション開発者はこのような処理に時間を使うべきではありません。

　これらの問題を低減する最も効果的な方法は、伝送符号の表現個数を増やし、取り扱う言語の１文字を必ず１つの符号単位で伝送できるようにすることです。PSK31で使われているVARICODEは原理上いくらでも符号の個数を増やすことができますから、これは不可能ではありません。