赤外線で通信する（その２）受信部

 【受信部】

受信部は赤外線を受信モジュール（OSRB38C9AA）で37.9KHzの赤外線キャリヤを受信しPICのEUSARTの受信部に渡す。今回は次のステップを考えてPICにはEUSARTを2セット内蔵するPIC16F15325を選んだ。基本的な回路は次のようにしたがLEDを光らせる条件は後で決める。

ここで私が使った基板にはLEDを正論理で光らせるように予めパターンが作ってあったのでそれに従った回路とした(R1の接地側パターンが接地せず浮いていたのがワゴンセールの理由かな)。なお電源電圧が3Vしかないので青色LEDなど順方向電圧降下(Vf)が大きいLEDはこの回路では光らない。

なおLEDを光らせるのに一般的にはTTLと同様に電流を出力端子に流し込む方式（負論理で光らせる）を使うが、これはTTLの電流ソースとしての能力がLEDを光らせるには低過ぎる為である。一方TTLと違ってPICの電流ソースとしての能力は20mAほどあり普通のLEDを光らせるには十分ある。

 PICでこの配線図の定義を行う次の行（RX1を5番ピンに割り当てる）をコンパイルしようとするとエラーとなる。EUSART1の受信部の名称RX1をコンパイラが受け付けない。

 RX1PPS   = 0x15; // EUSART1

 xc8コンパイラのPIC16F15325の定義ファイルを覗くとRX1ではなくRX1DTとして登録されているようだ。つまり、

  RX1DTPPS  = 0x15; // EUSART1

と記述するとコンパイルできる。この不整合がバグなのか歴史的経緯なのかは定かでない。Microchip社のデータシートでは一般に受信部の記号はRXn（nは数字）となっているが、xc8の書式ではRC1STAなど何故かRCnを使うことが多く紛らわしい。しかしこれをPPSに適用してRCnPPSとするとCポートのビットnに対する割り当てと定義が重なるのでPPSに対してだけはRCn以外の名前を使う必要がありRXnやRXnDTが使われているようだが全てをRXnに統一できないものか。
私はあくまでMicrochip社のデータシート通りのRX1を使いたい。そのため次の小細工でこの問題を回避することとした。

 #define RX1PPS  RX1DTPPS
RX1PPS   = 0x15; // EUSART1

 

この回路を送信部と同じく秋月でワゴンセールしていたPICの試作/実験用基板に作成した。 この回路の消費電流は2.4mAほどである。

実際の回路（下図）ではEUSART2をデバッグ用のシリアルインターフェイスとして使ようにした。これを秋月のFT234Xモジュール＋USBケーブルを通じてPCに接続、TeraTerm を使ってデータを表示させている。

  幾つかの細かいトラブルはあったがこの受信部は送信部から送信されたデータを次の様に受信できるようになった（送信部では"0123456789\n"という文字列を100msの間隔を空けながら繰り返し送信させている）。

 しかし、データを連続送信させると途中から動作がおかしくなる。次の例では次の文を50msの間隔を空けながら連続送信しているが途中でおかしくなっている。

<QuickBrownFoxJumpedOverTheLazyDog>

このエラーの原因は赤外線受信モジュール（OSRB38C9AA）の特性にあるようだ。一旦赤外線を障害物で遮断すると復活するが数行で再び駄目になる。以前リモコンチェッカーを作った時のモジュールのクセ（違和感）はこれだったんだ。

受信モジュール（OSRB38C9AA）のデータシート（秋月より入手）には時間的な制約の記載は無いが、SHARP製の似たような受信モジュール（GP1UXC4xQS）には下図の記載があり、ここではそれに準じて考えたい。即ちGP1UXC4xQSでは1ブロック送信時間Tは100ms以下、休止時間Toffは25ms以上、Tonは250us以上（伝送速度に換算して4Kbps以下）とされている。

これにを参考に改めて送信する信号の仕様を考える。先ずS/Nを考えて伝送速度を2400bpsとする。これは非同期通信では240Byte/sとなる。その速度で75ms（=100ms-25ms）で送信できるデータ長は最大18byte(=240*75/1000)である。この仕様に従って改めてプログラミングすると、

とデータが上手く通るようになった。実際には各バイト毎にエラーチェックのためにビット反転したバイトを追加して送り、9文字分18byte毎に30msの停止時間を設けている。受信側でデータをチェックしてエラーがあれば？と表示するようにしているが、5mくらい離してもエラーは無かった。