RTCLでRTTYコンテストを始めてみよう(入門編)
9. その他
9.1 RTTY信号の文字化けについて
RTTYの信号は雑音などの影響で文字化けすることがあります。ここでは、RTCLのレター/フィギュア変換機能を用いて文字化けを回避できる例を紹介します。
そのために、RTTYの信号構成、RTTYの文字コードおよび回避できる文字化けの例の順で説明します。
- RTTYの信号構成
RTTYの一文字は5 bit(ビット)で構成されています。この符号形態をBaudot(ボドー)と呼びます。ビットがONの状態をMark(マーク)、OFFをSpace(スペース)と呼びます。このマークとスペースに別々の周波数を割り当てて、shift(シフト)させながら符号を送信します。マーク周波数は2125Hz、シフト幅は170Hzがデフォルト値で、ダウンシフトを用いています。
実際に送信する時には、スタートビットとストップビットを前後につけます。通信スピードは45.45Baud(ボー)ですので、ストップビット以外のビットの長さは22m秒になります。ストップビットについては長さの制限がありません。
RTTYの信号構成
b0 | b1 | b2 | b3 | b4 | b5 | b6 |
Space | Mark or Space | Mark |
スタートビット | データビット | ストップビット |
- RTTYの文字コード
下表に示すようにRTTYの文字コードでは、一つの符号に二通りの意味をもたせています。
一文字は5ビットですので、表現できる文字数は32(2^5 = 32)種類です。アルファベット26文字と数字10文字で36種類になりますので、これらを表現するためには文字数が不足するためです。
二通りの意味の切り換えに、下表の「Letters(LTRS)」と「Figures(FIGS)」を送信します。
「LTRS」を受信したらそれに続く文字はアルファベットとして処理し、「FIGS」を受信したらそれに続く文字は数字や記号として処理します。
RTTYの文字コード
LTRS | FIGS | DATA BIT | LTRS | FIGS | DATA BIT |
A | - | 11000 | Q | 1 | 11101 |
B | ? | 10011 | R | 4 | 01010 |
C | : | 01110 | S | BELL | 10100 |
D | $ | 10010 | T | 5 | 00001 |
E | 3 | 10000 | U | 7 | 11100 |
F | ! | 10110 | V | ; | 01111 |
G | & | 01011 | W | 2 | 11001 |
H | # | 00101 | X | / | 10111 |
I | 8 | 01100 | Y | 6 | 10101 |
J | ' | 11010 | Z | " | 10001 |
K | ( | 11110 | Blank | 00000 |
L | ) | 01001 | Space | 00100 |
M | ・ | 00111 | Car. Ret. | 00010 |
N | , | 00110 | Line Feed | 01000 |
O | 9 | 00011 | Figures | 11011 |
P | 0 | 01101 | Letters | 11111 |
注記:1 : Mark、0 : Space
- 文字化けの回避(RTCLの「Shift」+「クリック」機能)
雑音などで「LTRS」あるいは「FIGS」を受信しそこなうと、それに続く文字は「文字化け」を起こします。
RTCLでは、受信画面上で文字化けがある場合にその文字列をマウスで「Shift」キーを押しながらクリックすると、前後のスペース間の文字(CR/LFとスペースを区切りとする最大20文字)をレター/フィギュア変換をします。もう一度「Shift」+「クリック」すると再変換して元に戻ります。
この機能により文字化けを回避できる場合を下表に示します。
文字化けの回避例
正常受信 | 文字化け | LTRS/FIGS変換 | 再変換 | 備考 |
JA1XUY | JAQXUY | '-1/76 | JAQXUY | 1が文字化け、Qが1を確認 |
599 03 03 | TOO PE PE | TOO 03 PE | TOO PE PE | 全体が文字化け、PEが03を確認 |
599-25-25 | TOOAWTAWT | 599-25-25 | TOOAWTAWT | 全体が文字化け、ナンバー確認 |
- MMTTYのUOS(Unshift On Space)機能
MMTTYはUOS(Unshift On Space)機能を持っています。
通常のQSOでは数字や記号よりもアルファベットをやり取りする確率が高いので、「LTRS」を受信しそこなった時に速やかにアルファベットとして認識するために、受信側で設定する機能です。この機能をONにするとRTTY信号にスペースが入った後は強制的にLTRS(文字)として解読します。
UOSの設定はMMTTYの「コントロールパネル」の「Control UOS」をONにします。
下表の1番目のケースではUOSが有効ですが、コンテストナンバーのケースではUOSの効果が有りません。
コンテストのQSOではLTRS(文字)よりFIGS(数字や記号)をやり取りする確率が高いので、UOSはOFFにしておきます。
文字化けの回避例
正常受信 | 文字化け | UOSがON | 備考 |
CQ CQ DE | :1 :1 $3 | :1 CQ DE | 文頭の「LTR」を受信しそこない |
599 599 599 | TOO TOO TOO | TOO TOO TOO | 文頭の「FIG」を受信しそこない |
599 25 25 | TOO WT WT | TOO WT WT | 文頭の「FIG」を受信しそこない |
599-25-25 | TOOAWTAWT | TOOAWTAWT | 文頭の「FIG」を受信しそこない |
- MMTTYのTX UOS機能
MMTTYはTX UOS(Unshift On Space)機能を持っています。
コンテストナンバーを送受信する事例で、TX UOSを説明します。この時、符号を次のように表示します。
<L>: Letters(アンシフト)
<F>: Figures(シフト)
<S>: Space
また、送信内容は次のとおりとします。
TU 599 001 001 BK
TX UOSと送受信される文字列の関係
TX UOS | 送信される文字列 | 受信される文字列 |
UOS OFF | UOS ON |
OFF | <L>TU<S><F>599<S>001<S>001<S><L>BK | TU 599 001 001 BK | TU 599 PPQ PPQ BK |
ON | <L>TU<S><F>599<S><F>001<S><F>001<S><L>BK | TU 599 001 001 BK | TU 599 001 001 BK |
TX UOSがOFFの場合には、受信側のUOSがONになっていると、<S>は<L>と同じ効果がありますので、文字化けして受信されます。
一方、TX UOSがONの場合には、受信側のUOSがOFFおよびONのいずれで受信しても文字化けはしません。
このように、<S>を送出した後にFIGSケースの文字を送出する場合は、必ず<F>を送出するのがTX UOSの機能で、受信側のUOSに対応した保険送信が行なわれます。
コンテストナンバーをハイフンでつなげて送信すると文字化けした場合に、全部がつながり判読ができなくなる可能性があります。
599-001-001 -> TOOAPPQAPPQ
一方、TX UOSをONにしてスペースでつなげた場合には、シフトミスによる文字化けの可能性は低下しますが、余分に符号を送信しますので、送信時間が若干余計にかかるようになります。
599 001 001 -> TOO 001 001
確実性を選ぶか、送信時間の短縮を選ぶかは、使われる方の判断によりますが、
・TX UOSをON、コンテストナンバーはスペースつなぎ「599 001 001」
・UOSをOFF
とすることをお勧めします。