簡易通信用パケット

Index

• 概要
• 仕様の検討
  • 前回の仕様について
  • 改良版仕様
  • PN符号によるフレーム検出
  • ハミング符号によるエラー訂正
  • ハミング・エンコーダ
  • ハミング・デコーダ
• プログラム構成について
• 送信回路
  • データフレーム
  • 511PNジェネレータ
• 受信回路
  • ノイズ除去回路
  • 同期検出について
  • フレーム検出
  • クロックについて
• 問題点

概要

• 前回はエラー対策を殆ど行っていなかったが、今回は回線品質が悪い場合を想定して、パケット構成とプログラム構成の全面的な見直しを行った。
• それによりある程度の効果が得られたため、パケット構成とプログラムの概要をまとめた。

仕様の検討

前回の仕様について

• NRZIなので、データ極性を考慮する必要がない。
• ボーレート自動追従機能があったので、通信ボーレートの変更が可能。
• 4B5B或は、4B7B¹変換を行なって、マンチェスタと同等のDCオフセットに抑えた。

• データフレームの開始の検出の問題
• 単にヘッダとしてアイドル信号を置いていただけなので、開始位置の検出が難しい。
• ヘッダ部分が、一部でも壊れると受信を開始出来ない。
• エラー検出やエラー訂正を全く行なっていなかったので、データの信頼性が低い。
• 割り込みを使わずにプログラムしたので、ボーレートの調整が難しかった。
• 内蔵CR発振による通信と、ボーレート自動追従のため、エラー率が多かった可能性がある。→少なくともエラー原因の特定が難しかった。

改良版仕様

• 15bit²PN符号によるフレーム検出
• エラーを許容することで、³フレーム検出率を上げる。
• 8bitデータを4bit+4bitに分割し、それぞれ3bitの訂正ビットを付加して14bitとする。
• それぞれ、1bitのエラー訂正と、2bitまでのエラー検出が可能になる。
• DCオフセットを少しでも少なくするため、マンチェスタに変更する。
• ボーレート自動追従は止めて、セラロックで固定ボーレートとする。

• マンチェスタへの変更
• ビットレートは低下するが、前回もDCオフセットを抑えるため4B7Bとか無理矢理に使っていたので、あまり大きな変化はない。
• データ極性を考える必要があるが、今回は固定で構わないので大丈夫だろう。
• NRZIは全てのエッジがクロックであり、意味を持っているが、マンチェスタは無意味なエッジが多く含まれている冗長な符号になっている。復号化については全面的に書直す必要があるが、無効エッジの取扱いが難しいと思われる。
• ボーレート自動追従は出来なくなったが、その代わりエラー原因は特定し易くなるだろう。

PN符号によるフレーム検出

• 繰返し部分の無い、ある程度の長さを持つ
• データと取り違えが起こらないようなコード
• エラーが発生しても、上記の性質が出来るだけ守られる事が望ましい

• フレーム検出には上記の理由から、M系列のPN符号を使うことにする。
• フレーム検出率を上げるために、ビットエラーがあっても許容とする。
• 何ビットまで許容するかは、ヘッダ長や、データ部分のビット長により検討が必要だろう。

ハミング符号によるエラー訂正

• ブロック符号 →1区切りのデータ（現在のデータ）のみでエラー訂正を行なうので、アルゴリズムが簡単で高速処理が可能。
• 畳み込み符号 →過去のデータの情報も含めて検討しエラー訂正を行なうので、時間が掛かるが、エラー訂正能力が高い。

ハミング・エンコーダ

• 7bitデータがx1x2x3x4x5x6x7である時、以下が全て0になるように x5,x6,x7を選ぶ。
• Ex-OR演算で行なう

          c0 = x1+x3+x5+x7
          c1 = x2+x3+x6+x7
          c2 = x4+x5+x6+x7
  

• さらに、送信データは8ビットの方が切りが良いので、チェックサムも付加する。

        c4 = x1+x2+x3+x4+x5+x6+x7

• つまり送信データは以下の16通りのデータになる。これは変換テーブルを使って簡単に変換可能である。

ハミング・デコーダ

• 受信データについても、c2 c1 c0を求める。全て0であればエラー無しになるはず。
• 0以外の場合は、c2c1c0番目のビットを反転すれば、訂正が可能になる。

• これも変換テーブルを使って復号化する。
• チェックサムを計算すれば2bitのエラーを検出可能だが、今回はエラー時の処理を特に考えていないので、無視する。

プログラム構成について

• マンチェスタ符号は1bitで1周期になるから、最大2400Hz。
• 1周期は416μs、0或は1の時間は半分の208μsになる。
• サンプリングの時間は、最低その半分だが、通常は1/4の52μs、或は1/8の26μsで行なった方が良いだろう。
• PICの場合、SystemClockが4MHzだと52cycleなので、あまり処理時間を取れない。
• つまり最低限その倍の10MHz、出来れば20MHzで動作させる必要がある。

• 送受信ファームウェア

送信回路

• 送信間隔は約50msとした。
• 技適の対応として、送信動作は以下の制限を設けている。
• 連続送信は、50ms×100=約５秒で制限される。
• また、データ送信後は、約２秒の停止期間を設ける。
• Randomを押しながらResetすることで、テストモードとなる。テストモードでは以下のような動作となる。
• 連続送信が可能になる。
• Tx/Rx=1とすることで、キャリアの停止を行わない。

データフレーム

• フレーム検出部を２つに分離してHEADER,FOOTERにした理由は、同期検出でクロックを取り損ねてシフトしたデータを取得してしまう確率を減らすことを考慮したため。

511PNジェネレータ

• 511PNは9bitのM系列であり、以下のようなシフトレジスタによる構成で、適当なタップを指定することで生成することが出来る。

• しかし、今回のプログラムではPN符号が割込み時間内に生成することが出来なかったので、テーブルによる簡易生成方法をとった。

受信回路

• そのためタイマ割込み処理中に最優先でおこなう。
• データ受信は、ノイズ除去回路→同期検出→フレーム検出→ハミング復号の順に行われる。
• これを、割込み期間（52μs或いは26μs）以内に全て完了する必要がある。

ノイズ除去回路

• １〜２bit程度のバーストエラー⁵はこれで除去できる。

同期検出について

• 最初はIDLE信号で同期エッジだけが入るようにして、無用なエッジをスキップするようにコーディングしたが、エラーが多くて使いものにならなかった。
• そのため全てのエッジを検出、さらに変化のない場合も検出して、交互にデータを取得するようにした。
• 有効なデータと、無効なデータ⁶を、それぞれ32bitのシフトレジスタで構成されたバッファに読み込む。

フレーム検出

• フレーム検出さえ出来れば、データ部をハミング・デコードしてデータ復号すれば良い。

クロックについて

• 通信クロックの４倍でサンプリングしているので、必要条件は満たしていると思われるが、サンプリング後のデータを観察すると、かなり揺れがみられる。
• この揺れは、データの読取りには直接影響しないはずであるが、波形がナマッた場合にクロックの検出に影響を与える可能性はある。
• サンプリングを８倍（約26μs毎に割込み）とすると、かなり揺れが少なくなることから、実用的にはSystemClockを20MHzとして、26μsサンプリングでの動作が望ましいと思われる。

問題点

• デューティが極端に⁷狂った場合にも対処出来るように、ノイズ除去回路の最後の２ビットもチェックするようにした。→ノイズ除去で同じになるので２ビット目だけチェック。
• 50msカウント用のカウンタをリセットするIF文は割込み禁止にする、或は50ms以上とすることで、ここで割込みが起きないようにする。→メインルーチンと割込みルーチンで共通の変数に同時にアクセスしてはいけないという原則を忘れてた。