簡易通信用パケット

by K.I

Index


概要

簡易通信チップの改良版の作成を依頼されたので、改良版のパケット仕様を検討した。
[top]

仕様の検討

まず前回の仕様と問題点を基に、改良版の仕様を検討する。

前回の仕様について

以前作成した 簡易データ通信チップの特徴として、 問題点としては、

改良版仕様

前回の問題点についての改良を考えてみる。 考慮すべき点について、、、

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

フレーム検出を確実に行なうためには、以下のような条件が必要になる。 これらの性質を持つ符号列は何かというと、結果的に乱数が適当ということになる。

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

エラー訂正としては、ブロック符号と、畳み込み符号に大別される。 今回はリアルタイムで処理するため、ブロック符号であるハミング符号を選択した。 送信情報ビット数を8bitとしたので、データ部分の長さは、14bit。チェックサムも付けて16bitとした。 ハミング符号は、エラー訂正の基本として良く挙げられるが、アルゴリズムが簡単で、高速処理が可能。またエラー検出率も悪くないので、実用的な符号でもある。

ハミング・エンコーダ

元DATA TXDATA
0 00000000 00
1 00011110 1E
2 00101101 2D
3 00110011 33
4 01001011 4B
5 01010101 55
6 01100110 66
7 01111000 78
8 10000111 87
9 10011001 99
A 10101010 AA
B 10110100 B4
C 11001100 CC
D 11010010 D2
E 11100001 E1
F 11111111 FF

ハミング・デコーダ

以下は、この規則に従ってExcelで計算してみたもの。
RXDATA 訂正前 C0 C1 C2 訂正後
00 0000000 0 0 0 0000000 00
01 0000001 1 1 1 0000000 00
02 0000010 0 1 1 0000000 00
03 0000011 1 0 0 1000011 43
04 0000100 1 0 1 0000000 00
05 0000101 0 1 0 0100101 25
06 0000110 1 1 0 0010110 16
07 0000111 0 0 1 0001111 0F
08 0001000 0 0 1 0000000 00
09 0001001 1 1 0 0011001 19
0A 0001010 0 1 0 0101010 2A
0B 0001011 1 0 1 0001111 0F
0C 0001100 1 0 0 1001100 4C
0D 0001101 0 1 1 0001111 0F
0E 0001110 1 1 1 0001111 0F
0F 0001111 0 0 0 0001111 0F
10 0010000 1 1 0 0000000 00
11 0010001 0 0 1 0011001 19
12 0010010 1 0 1 0010110 16
13 0010011 0 1 0 0110011 33
14 0010100 0 1 1 0010110 16
15 0010101 1 0 0 1010101 55
16 0010110 0 0 0 0010110 16
17 0010111 1 1 1 0010110 16
18 0011000 1 1 1 0011001 19
19 0011001 0 0 0 0011001 19
1A 0011010 1 0 0 1011010 5A
1B 0011011 0 1 1 0011001 19
1C 0011100 0 1 0 0111100 3C
1D 0011101 1 0 1 0011001 19
1E 0011110 0 0 1 0010110 16
1F 0011111 1 1 0 0001111 0F
: : : : : :
: : : : : :
78 1111000 0 0 1 1110000 70
79 1111001 1 1 0 1101001 69
7A 1111010 0 1 0 1011010 5A
7B 1111011 1 0 1 1111111 7F
7C 1111100 1 0 0 0111100 3C
7D 1111101 0 1 1 1111111 7F
7E 1111110 1 1 1 1111111 7F
7F 1111111 0 0 0 1111111 7F

14B7Bは標準的な符号ではなく独自に定義したものである。DCオフセットを少なくするため3回以上連続した0,1を排除した符号になっているので、マンチェスタと同じ特性を持つ。
215bitはエラーを考えると、ちょっと短いがデータが14bitなのでこれぐらいで抑えておく。
3今回、フレーム検出は特に問題にならなかったので、実際にはエラーの許容はしていない。

[top]

プログラム構成について

マンチェスタ符号を2400bpsで送受信することを考える。 以上のことから、基本的に52μs(26μs)の割り込みにより全体のシーケンスをコントロールするように設計することにした。
[top]

送信回路

送信回路は、52μsのタイマ割り込み×4のタイミング4で、データにハミング符号を付加して、ヘッダを付けたパケットを送信する。

データフレーム

実際のデータフレームは、さらにIDLEを付加した5byteとした。 IDLE: データフレームとは無関係。通信時のDCオフセットを低減させるため HEADER,FOOTER: フレームヘッダ。フレーム認識を行なう DATAH,DATAL: 8bitデータを4bitづつに分けて、ハミング符号を付加したもの(x:ハミング符号、p:パリティ)

511PNジェネレータ

技適の評価用に511PN符号ジェネレータを実装した。
4或いは、26μs×8のタイミングで、タイマ割込みを発生させる。

[top]

受信回路

入力データはクロックに同期していないため、受信動作はクリティカルなものになる。

ノイズ除去回路

通信によるノイズ、特にバーストノイズの除去のために、シフトレジスタを使ったノイズ除去回路を実装した。

同期検出について

マンチェスタの場合、データに必ずクロックが含まれている反面、全てのエッジに意味があるわけではないので、意味の無いエッジを無視する必要がある。

フレーム検出

同期検出で読み込まれた2つのバッファの内容から、HEADERとFOOTERの一致を検出することで、有効データの判定とフレーム検出を同時に行う。

クロックについて

SystemClockを10MHz(約52μs毎に割込み)として、データ送受信が行えることを確認した。
5これは一般的なバーストエラーのことではなく、単にサンプリングでの話。データのバーストエラーをはじくためには、インターリーブとかしないといけない。
6この時点では、データが有効か無効かを判断出来ない。例えば1が永遠に続くデータの場合、どちらが有効なエッジかを区別するのは不可能であり、データが0なのか1なのかを区別することも出来ない。

[top]

問題点

プログラム上の問題点があって少し直した。忘れないようにメモ。→いずれも頻度が少ないので分かりにくいBUGだった
7ちゃんと考えたんだけど、忘れた。。。


comments powered by Disqus