IAUX Knowhow Document Part 1

IRCS-AUX（仮称）計画 第１期中間報告

～IRCSを利用した通信の実現の為の事前調査結果～

～でも通信理論講座になっちゃった。～

１．はじめに

ことの始まりは、９６年度頃、ＦＥＺ師匠がＩＲＣＳ（別記事参照）の試作版を完成させ、試験運用をしていた時でした。私が何気に「通信に使えますね」と言ってしまったのが泥沼に足を突っ込む羽目になるきっかけでした……。

２．原理（ＯＳＩ１層：物理層）

２．１．前置き

ＩＲＣＳは別記事に有るように、突き詰めれば赤外線の発光器と受光器であり、それを使ってリモコン信号を発信したり、受信したりします。

この時リモコンのどのボタンが押されたかと言う信号は０，１のディジタルで表されています。このどのボタンが押されたかと言う信号の代わりに、普通の文字コードやらバイナリデータやらを使えば、そのまま普通の通信になります。簡単ですね。

また、別の見方も出来ます。赤外線の送信器と受信機があるのだから、単純にディジタル変復調をかけてやれば、そのまま通信器になります。

ちょっと閑話。通信を行うには、電気的にどのような信号の送り方をするか、とか、送られた信号が正しいか間違ってるかどうやって判断しようか、とか、送られた信号の順番が合っているかな、とか、色々な問題があります。これを色々な段階に分けて考える方法として、ＩＳＯによるＯＳＩモデル、という分類法が有ります。

２．２．方式について

さて、実際に通信に使えるのではないか、という自信が出てきたので、次にどのような方式で赤外線を出すのか（どのような変復調方式を使うのか）、と言う問題を解かなくてはなりません。ＯＳＩモデルでは第１層とか物理層とか呼ばれています。

面倒な順に行きましょう。ＰＳＫ方式。これは１つ１つの波形毎に前の波形とどのくらい位相が変わったのか、によって信号を送ります（位相を切り替える：位相変調）。え、１つ１つ波形調べるの？面倒だ。それにＩＲＣＳの受信器の出力は前後との平均をとった感じ（積分なんですがね）で波形なんて分かりません。却下。

次。ＦＳＫ方式。これは１信号毎に周波数をぱちぱち切り替えます（周波数を切り替える：周波数変調）。でも、ＩＲＣＳの受信器は１つの周波数しか受信出来ないようになっています。却下。

最後。ＡＳＫ方式。これは、１信号毎に、赤外線を出すか出さないか、ぱちぱち切り替えます（振幅を切り替える：振幅変調）。ＩＲＣＳの受信器は 38.4kHz しか受信出来ないので、38.4kHz の信号がくれば１，何も信号がこなければ０、となります。いけそうですね。

さて、ＡＳＫ方式もまた細かく分けられます（厳密に言うと、ASK,FSK,PSK と同列に並んでいるので、ＡＳＫを細かく分ける訳では有りません。ただ振幅だけしか使わないからＡＳＫに似ている、と言うだけです）。

ＰＣＭ方式。一定時間毎に信号が有るか無いかで０，１を区別します（ちょっと違うけれど）。となると、送信側と受信側で「一定時間」と言うのをずれない様にしなければなりません。大変だ。もっと他にいい方法無いの？

ＰＮＭ方式。38.4kHz の信号が何回来るかで０，１を区別します。数えるの？ＩＲＣＳの受信器で平均をとられちゃってるから数がわからないよ。次。

ＰＷＭ方式。38.4kHz の信号がどのくらいの長さ続くかで０，１を区別します。これなら、０にしろ１にしろ、十分な長さ続けさせれば、ＩＲＣＳの受信器で平均を取られても平気だ。いけそうですね。

ＰＰＭ方式。38.4kHz の信号がぽこぽこやってきた時に、その信号と信号の間隔の長さによって０，１を区別します。……赤外線通信では、そういう事になっていますが、本来のＰＰＭは一定時間の中で、いつ信号が来るか、なんですけど、ま、いいや。ＰＷＭに似ていますね。やれそうだ。

以上のような訳で、ＰＷＭ方式か、ＰＰＭ方式が使えそうです。実際にどのような波形になるか、考えてみましょう。次のようになります。

図１．ＰＷＭおよびＰＰＭ波形

ＰＷＭ波形       ０              ０              １              ０         
                ┌─┐          ┌─┐          ┌─────┐  ┌─┐      
              ─┘  └─────┘  └─────┘          └─┘  └─    
                                                                            
変形ＰＷＭ波形   ０  ０      １      ０  余計                               
                ┌─┐  ┌─────┐  ┌─┐                              
              ─┘  └─┘          └─┘  └─                            
                                                                            
ＰＰＭ波形           ０      ０          １          ０                     
                ┌─┐  ┌─┐  ┌─┐          ┌─┐                      
              ─┘  └─┘  └─┘  └─────┘  └──

本来のＰＷＭは「図１．上」の様に、信号が来ている部分の長さで０，１を区別しますが、図を見て分かる様に、やたら長くなります。そこで私が勝手に方式を考え、信号が来ていない部分の長さも利用してみたものが、「図１．中」です。短くはなりましたが、最後に余計に信号を出さなければなりません。でも短くなるので、通信速度を上げる事が出来ます。

ＰＰＭもそこそこ短くなります。それにもっとも重要な事は、全日本共通の規格として決められた家電製品協会フォーマット略して家製協フォーマットがＰＰＭを使っています。すなわち、ＰＰＭを使えば赤外線リモコンを使った家電製品が誤動作する確率を最小にする事が出来ます（詳細は後述）。

２．３．実装方法について

以上の考察により（いままでのは全部机上の空論だったんですね）、変形ＰＷＭ方式か、ＰＰＭ方式が使えそうだと言う事になりました。

さて、これを実際に使える様にするには決めなくてはならない事が幾つか有ります。

まず第１に、図１．で表した、線が上に上がったり（Ｈｉ）下に下がったり（Ｌｏｗ）しているのは、どうやって表すか。……。言うまでも無く、38.4kHz の信号が有ればＨｉ，無ければＬｏｗで問題有りません。

第２に、どのくらいの長さだったら０で，どのくらいの長さなら１なのか。これは重要な問題であり、直接に、通信速度や，実現のしやすさにかかわってきます。まず家製協フォーマットでは基準の長さＴを 0.35ms ＜Ｔ＜ 0.5ms と決め、ＰＰＭ波形のうち、Ｈｉの部分の長さをＴ、Ｌｏｗの長さは信号が０ならばＴ，１ならば３Ｔと決めています。これを前提にし、変形ＰＷＭでは、信号が０ならばＴ，１ならば３Ｔとして、実現可能か，どの程度の通信速度になるか考えて行きましょう。

２．３．１．実現の可能性

９８を使って実現させる訳ですから、９８のシリアルの構造を知らなければなりません。

シリアル（RS-232C）では、シリアルと言うくらいだから１ビットずつ信号が送られています。しかしながら、ＣＰＵがデータを扱う場合は１バイト＝８ビットずつの方が扱いやすいので、その様な変換を行うＩＣが積まれています。つまり、ＣＰＵから１バイトのデータが送られてくれば、１ビットずつ順番にシリアルに送信し、シリアルから１ビットずつ信号がくれば８ビット分まとめてからＣＰＵに送ります。

ＣＰＵからこのＩＣを経由してＩＲＣＳを操作する事になります。ここで、ＩＲＣＳの設計上の理由から、このＩＣの通信速度を 76.8kbaud にしなければなりません（ＦＥＺ師匠が別記事で解説していると思いますが）。そうなると、 104μｓ分の赤外線の送受信の状態が、１バイトにまとめられてＣＰＵで扱われます。ここで、ＣＰＵ側で１バイトのデータをまた１ビットずつに分解し、１３μｓごとの赤外線の送受信の状態を調べていけば、ＨｉやＬｏｗの連続した時間を、非常に細かく測定する事が出来ます。実際にＩＲＣＳドライバは１ビットずつ数え、細かく測定しています。

しかしここで重要な問題が発生します。ＩＲＣＳドライバは操作している人間が指定した時に、赤外線の状態を調べるので、パソコンの処理能力をすべて消費して数える事が出来ます。しかしＩＲＣＳを通信に使う場合はいつ信号が来るかわからないので、常に赤外線の状態を監視していなければなりません。となると、長さを測定する為の処理は、できうる限り高速にしなければなりません。したがって、１バイト分のデータを悠長に１ビットずつに分解して数える事をせず、１バイト分、つまり104μｓ分をまとめて数える事にしました。

ここで別の方法も考えられます。受信する側は１ｍｓに１度とか、１０ｍｓに１度とか、一定時間毎に赤外線の状態を見て、信号が送られてきているようならば、受信の為の赤外線の状態監視を始め１ビットずつ数える、と言うものです。

また、組み合わせて、一定時間毎に状態を見て、信号が送られてきているようならば、１バイトずつ数えていく事も考えられます。

しかしながら、一定時間毎にしか信号が送られているか否か調べると言うことは、送信側では、その一定時間以上の長さだけ続けて信号を送る、と言うダミーの信号を送らなければ、受信側ではデータを取りこぼしてしまいます。すると、そのダミーの信号を送る分だけ、通信速度が落ちてしまいます。

そんなわけで、一定時間毎に監視する事をせず、常に104μｓ分まとめて監視する事にしました。

しかしながら、後でわかる事なのですが、家製協フォーマットを採用した場合、一定時間毎に監視するので構わないのです（本当にダミー信号送っていたのであった）。いや～、家電メーカーが集まって知恵を絞って(?)決めた規格だけ合って良く出来ているわ～。はっはっは～。

さて、104μｓ分を１バイトとしてまとめて監視する場合、前述の "Ｔ" の長さとの兼合いはどうなるでしょう。最短のＴの長さ 0.35ms ならば３．４バイト、最長のＴの長さ 0.5ms ならば４．８バイトとなります。よって約０．４ｍｓとすれば、ちょうど４バイトでぴったりです。

また、104μｓ分をまとめると言うことは、ＬｏｗからＨｉに変わった瞬間や、ＨｉからＬｏｗに変わった瞬間は、ＣＰＵに送られるデータが変になってしまい、数えそこなう事が考えられます。

また、シリアルのＩＣを 76.8kbaud で動かすと、そのＩＣからＣＰＵには、 104μｓに１回データが送られてくると言う、猛烈な速度になり、ＣＰＵが取りこぼす事が考えられます。

以上の様に、Ｌｏｗ→Ｈｉ，Ｈｉ→Ｌｏｗでの数えそこないをそれぞれ１バイト分ずつ、ＣＰＵの取りこぼしを４バイトにつき１バイトとして、合計すると、４バイトの内３バイトをこぼしますが、残りが１バイト有り、０にはならず、ちゃんと観測出来ると考えられます。３Ｔならば、１２バイトにつき５バイトこぼし、残り７バイトで、１Ｔの４バイトより十分長いので、区別がつきます。

よって、Ｔ＝０．４ｍｓであれば実現可能であると考えられます。

２．３．２．予想される通信速度

次に通信速度です。実現可能でも恐ろしく遅いのであれば、使いませんからね。

まず、変形ＰＷＭから考えましょう。

送受信するデータでは、１と０が均等に現れると考え、１ビットのデータの平均の長さは、

（１Ｔ＋３Ｔ）／２＝２Ｔ式にするまでも無いですね。そして、Ｔ＝０．４ｍｓですから、最高で１２００ｂｐｓ＝１５０ｃｐｓとなります。

つぎにＰＰＭ。

これまた１と０が均等と考え、１ビットの平均の長さは

１Ｔ＋（１Ｔ＋３Ｔ）／２＝３ＴＰＰＭでは最初のＨｉの分だけ変形ＰＷＭより長くなります。よって、最高で８００ｂｐｓ＝１００ｃｐｓとなります。

この通信速度は最近の有線モデムの 28.8kbps やらその上やらには全くかないませんが、実は初期の有線モデムの 1200bps とか 2400bps とかと大差無いレベルです。また、アマチュア無線を利用したディジタル通信である、パケット通信（一般名詞が固有名詞になっちゃった）の現在の主流は 1200bps です。

なお、注意を要する事として、8bps は 1cps なのか、と言う問題があります。 RS-232C ではスタートビット，ストップビットがあるので 8bps は 1cps より小さくなりますが（ストップビットが 1bit ならば 10bps=1cps）、ＩＲＣＳでは 1cps ＝8bps となります。有線モデムは詳しい規格を知らないので分かりませんが、パケット通信では少々特殊なデータ変換を行っているので（正式にはスクランブル、と言う）、8bps は 1cps より小さくなりますが、特定は出来ません。（閑話：パケット通信でも 2400bps や 9600bps や 19200bps もちょっと詳しい人レベルならば簡単に扱えますが、規制ガジガジで免許を取るのがちょっとだけ面倒です。それに玄人集団や研究グループなどでは 384kbps とかＭｂｐｓ単位とかそれ以上も行われています。それに、ＮＴＴも電話回線の途中路に無線回線を使っているし）

よって、この位ならば、バイナリ大量転送や長文の転送を除外し、チャットや負荷の軽めのネットゲームに限定すれば、十分実用になると考えられます。

２．３．３．理論の実地での確認

以上の事をふまえ、変形ＰＷＭおよびＰＰＭを利用した通信ソフトを書き、モデムのループバック機能を使い、実地で理論の確認を行いました。

ここで重要な事は、ＩＲＣＳを使っていない為に生ずる、現実との差です。

まず、モデムがタコだった為に、ループバックの速度は９６００ｂｐｓまでしか上げられません。よって、転送速度は実物の１／８になり、その分、プログラムの甘さの発見ができなくなります。

次に、論理が違っています。モデムは送受信共にアクティブＨｉ（ＣＰＵレベルでは）ですが、ＩＲＣＳは、送信がアクティブＬｏｗで，受信がアクティブＨｉです。これは大した手間がかからずに対応出来ます。（でも最初は知らずにしばらく悩んでいた）

最後に、モデムではデータの透過性が保証されています。つまり、送信したデータは、無くなったり、他のデータに化ける事無く、送り返されてきます。

以上の事より、変形ＰＷＭ，ＰＰＭの理論、および変復調プログラムの作りが正しいか否かの判定くらいしか出来ませんが、今の段階ではそれで十分なので、実際に試してみました。

まず最初の感想は、「遅い」。チャットはいつも 1200bps だったのですが、その１／８ですから、やっぱり遅いです。76.8kbaud に期待しましょう。また、変形ＰＷＭとＰＰＭでは大した速度の差は感じられませんでした。変形ＰＷＭの方が気持ち速い、程度でした。

逆に、遅い事がわかったと言うことは、正常に動いている、と言うことであり、理論が正しい事が証明されました。

２．３．４．家製協フォーマットへ

実地確認により、変形ＰＷＭとＰＰＭで大きな差は無い事がわかったので、周囲への影響がより少ない、家製協フォーマットを採用する事にしました。

まず、家製協フォーマットはＰＰＭ（変形ＰＰＭだと思うんだけど……）を使用しています。これは前述のとおりです。

また、データの最初と最後を区別する為に、データの最初にリーダーと呼ばれる信号を付け、最後にトレーラーと呼ばれる信号を付けています。また、データの部分をデータ・コード部と呼びます。

図２．リーダー、トレーラー

リーダー                     ８Ｔ                    ４Ｔ                    
                ┌───────────────┐                           
              ─┘                              └────────           
                                                                             
トレーラー       Ｔ                                                          
                ┌─┐                   ８ｍｓ以上                          
              ─┘  └──────────────────────

ここまでは、家製協フォーマットが出来る前に赤外線リモコンを作ったメーカーが使用したフォーマットと大して変わらず、また、家製協フォーマットに対応させても、各メーカー，団体ごとに同じになってしまい、誤動作の原因となります。そこで、リーダーの後、データ・コードの前にカスタム・コードと呼ばれる、各メーカー，団体ごとに異なった１６ビットのデータを付け、その次に４ビットのカスタム・コードのパリティを付けています。カスタム・コードは登録制で、重複しない様に割り当てているので、誤動作の確率は非常に小さくなります。

家製協フォーマット対応と言うからには、リーダー，トレーラー，カスタム・コードとそのパリティを付けなければなりません。しかしカスタム・コードは登録制であり、登録が面倒だったし、また、まだ実験レベルなので、てきとうなカスタム・コードを使用しています（本当は、まずい）。実験用カスタム・コードがわからなかったので、家製協フォーマットの前身になったと思われる、ＮＥＣフォーマットでの実験用カスタム・コードの 00FFh を使用しています。

また、リーダー部は２．８～４ｍｓくらい連続してＨｉになり、また実データを持たないので、受信側ではおおよそ２ｍｓに１回、赤外線の状態を監視し、リーダーが来たか来ないかを調べるだけでも、きちんとデータを受信出来る事が分かります。

２．３．５．再び実地試験

以上の事をふまえ、家製協フォーマット完全対応版（カスタム・コードの登録を除く）にて動作試験を行いました。

方法は相変わらずモデムのループバックです。

はっきり言って、問題が出るわけ無いです。いくらかのデバッグをしておわりました。

ただし、前回の実地試験の時より、リーダー部，トレーラー部が増えているので、その分実通信速度が下がります。一連の送信で、256 bytes のデータを送るとした場合、一連の送信時間は

（８Ｔ＋４Ｔ）＋３Ｔ＊２５６＋（Ｔ＋２０Ｔ）

＝８０１Ｔとなり、実通信速度は７６７ｂｐｓ＝９６ｃｐｓとなります。

３．またもや原理（ＯＳＩ２層：リンク層）

以上により、物理層は完成しました。次に、送られてきたデータが正しいか、どういう手順でデータを送ったり、間違ったデータの回復を行うか、という、リンク層の問題を解決しなければなりません。

ここで１つ付け加えておきますが、家製協フォーマットのカスタム・コードは物理層に関する規定ではなく、リンク層に関する規定かもしれません。

リンク層のプロトコルには、有名なところでＨＤＬＣ，ＬＡＰＢ，ＡＸ．２５リンク層，などが有ります。また、もっと上位の層にはＸ．２５，ＡＸ．２５（リンク層より上位はまだ決まっていない），ＩＰ，ＴＣＰ／ＩＰ，ＮＥＴ／ＲＯＭなどが有ります。（ＮＥＴ／ＲＯＭは別の話だったかもしれない）

さて、ＩＲＣＳでの通信には既存の規格を使わずに、独自規格を作る事も考えられますが、規格の整合性など、困難な問題が山積しているので、やめた方がいいでしょう。となると、既に有る規格の中から最適なものを探す事になります。

1997年２月現在、どの規格を使用するかは決定していません。

３．１．試験的にリンク層を実装、実地試験

リンク層、及びさらに上位をどうするかはまだ決定していませんが、いつまでもモデムのループバック試験で済ます訳にはいきません。

そこで、試験的に、エラー検出コードを付加するだけのリンク層を実装し、実際にＩＲＣＳで動作試験を行う事にしました。

まず、エラー検出コードにはＣＲＣを使う事とし、カスタム・コード及びそのパリティからデータ・コードまでの、ＣＣＩＴＴＸ．２５勧告の右シフトのＣＲＣ計算をし、データ・コードの最後尾に 16bit のＣＲＣを付加する事にしました。なお、この方法は、ＨＤＬＣや、その派生のＡＸ．２５で採用されているエラー検出方法とまったく同一のものです。

次に、ＩＲＣＳで通信を行った際に、このエラー検出方法で本当にエラーを検出できるのか、と言う問題があります。そこで、まずどのようなノイズが入るのか調べる為に、ＩＲＣＳにて受信しっぱなしの状態にしてみました。その結果、数分に１回程度、はば数１０μｓ程度のスパイク上のノイズが入る程度である事が分かりました。

この程度であれば、４万ビットに１ビット程度、ただし常に最高速度が出る訳ではないので、まぁ５千ビットに１ビット程度であり、16bit ＣＲＣで十分に検出出来ます。それ以前に、前後数１０μｓで平均を取ればノイズを消去する事も出来ます。

以上をふまえ、受信したデータに前後数10μｓで平均を取り、かつ 16bit ＣＲＣを付加する様にし、まずＩＲＣＳに近い状態として、同期転送モード，76.8 kbaud でのリバースケーブルでの動作試験を行ってみました。ただし、ＣＲＣは付加するだけで、受信側では人力で確認しています。(^^;;; プログラムカクヒマナカッタシ……

その結果、通信に成功はしたものの、おおよそ１／３程のデータがエラーを含んでいる事が分かりました。しかもこのエラーが、ＣＲＣで検出するレベルのものではなく、受信したデータが物理層で使用している、ＰＰＭ方式から外れている、と言うものでした。しかも、一連のデータの送信時間よりも、受信時間の方が長いと言うものです。すなわち、送信と受信の間で余計なデータが入り込んでいる事になります。調べた結果、送信の時に 76.8kbaud の速さでＣＰＵからシリアルのＩＣにデータを送らなければならないのに、ＣＰＵの処理速度が追い付かず、シリアルのＩＣが自動的に「データは無い」を意味するデータ（ＳＹＮＣキャラクタ）を送っていたのでした。（シリアルＩＣの仕様）

この実地試験にて、送信処理をもっと軽く高速にしなければならないと言う問題が、明確に浮かび上がってきました。しかしながら、それ以外には問題は発生しませんでした。

追記．1997 Feb.27 Thr.現在、高速化には成功した模様です。

４．今後の課題

まず最初に、送信処理をもっと軽く高速にしなければなりません。

次に、どのようなリンク層を使用するか、と言う問題があります。

３つ目に、このＩＲＣＳを利用した通信ドライバのユーザープログラムとのデータの受け渡しの方法を決めなければなりません。

４つ目に、ドライバがユーザープログラムと受け渡しをするデータの内容を決めなければなりません。

リンク層を決定する要因として、ＩＲＣＳの性格を考えてみました。

まず通信路は、電話や Ethernet の様に確実なものではなく、パケット通信のように時々刻々変化し、不安定です。通信相手は、電話回線の様に１対１ではなく、Ethernet やパケット通信のように複数対複数です。また、電話回線，Ether net，パケット通信のどれもそうですが、送信，受信が固定されず、時間によって送受信が変わります。通信速度は、電話回線や Ethernet の様に高速にする事は出来ず、非常に状態の悪い時のパケット通信のように、遅いです。

以上のように、ＩＲＣＳはパケット通信に似ているので、パケット通信で使われている、ＡＸ．２５を使おうかとも考えていますが、ＡＸ．２５には、番号制フレームの制御が甘すぎる，中継がなってない、と言う問題があります。

ユーザープログラムと受け渡しをするデータの内容ですが、物理層のデバイスドライバとリンク層のデバイスドライバを分けた方がいいのではないか、と考えているので、物理層のデバイスドライバとはＫＩＳＳによりデータの受け渡しを行い、リンク層とのデバイスドライバとは、ごく普通のＡＵＸのようにベタでデータの受け渡しを行おうかと考えています。

ユーザープログラムとのデータの受け渡し方法は、ごく単純に、一番メジャーな(?)ＡＵＸドライバである、ＭＣＤと同じにしてしまおうかと考えています。

５．ＮＥＸＴ

こんなもんでいいっすか～、ＦＥＺ師匠。（←ＩＲＣＳ関連を一手にまとめている御仁です）うおー、疲れたぁ、１日中ワープロ打っていました。精神力を使い果たしたので、しばらくプログラミングや、回路設計や、難しい事出来ません。おれにＶＦ－Ｘやらせろ～。お肌もすべすべ～。（以下編集部カット）

６．参考文献＆すぺしゃるさんくす

バイブル本こと「パケット通信ハンドブック」秦　正人，山内　雪路

ＣＱ出版社 1987年５月10日初版，1990年２月20日第７版

バイブル本の続編「パケット通信ネットワーク」

人の借りて読んだので、諸元は分かりません(._.)

秀和の解析マニュアルとか、トラ技ＳＰとか、テクニカルデータブックとか……

ＦＥＺ師匠、thomas仙人、うぼうぼ、えーと後は……(^^;

執筆：1996年10月某日～1997年２月10日、 1997 Feb.28 Fri.

web 用に修正：1998年９月３日

Last modified on Wed,09 Sep,1998.
↑ FENIX ほめぱげ
← G-HAL ほめぱげ
→ ソフトヱアに関するウダウダ
→→ IAUX に関するウダウダ
↓ Mail to, メールはこちらへ
↓ Suggestion Box, 投書箱
↓ BBS, 掲示板 UserName:BBS、Password:BBS
(C) 1996 G-HAL