http://www.mi-ra-i.com/cgi-local/hw_wforum.cgi?mode=allread&no=794&page=0
では皆さんにお世話になりました〜。

早速と思いながら、数日立ってしまいましたが今日は半日ほど時間があるので
http://www.sharp.co.jp/ecg/pdf/unit/is1u60.pdf の３８Khzの赤外線モジュールと
http://www.sharpsma.com/datasheets/displays/scm/book1.pdf のLCDを使って
RCX用のリモコンが送っているコマンドを表示するものを作ろうかと思っております。 （＾＾）

LCD画面は割と書き換えとかが遅いし、それでいて、リモコンから送られてくる
コマンドはLCDの表示スピードに比べて速いので、この辺の処理を如何するかなど
昨日、布団に入って寝ながら考えておりました。 （そのまま、寝てしまいましたが）

赤外線モジュールで受信した内容を、バッファリングして、特定のタイミングで
表示するような感じになりそうでね。

こうして、マイコンや簡単なデバイスなどを触り始めると、それぞれのデバイスの
持っている時間的な特性なども考えて作るんだな〜などと改めて勉強になるな〜
と思い始めております。 （＾＾）
ということで、製作前の与太話でした。

今ごろになってですが、LCDを使って実験をしています。

表示に関しては、問題も無くなり、遅いと思っていたこともどうも、
IS1U60 を使って、メッセージを受けている時の取りこぼしが
あり、結果として遅く感じていたようです。

現在 IS1U60 と Cのライブラリーを使って、2400bpsのデーターを受け取って
いるのですが、メッセージの初めの１Byte目の 0x55 を取りこぼす場合が
非常に多いようです。

現在は、
while(1){
data = GetCh(); // Cについてくる関数を利用
if ( data != 0x55 ) continue;
....
}

みたいにしてポーリングしているのですがタイミングが合わない場合が多いようです。
（スタートビットの処理が GetCh()は甘いのかな〜 ？）

やはり、アッセンブラーで書いたほうがいいのかな〜と思っているところです。

ということで、近況報告です。

> みたいにしてポーリングしているのですがタイミングが合わない場合が多いようです。

原因を解明するため、0x55をなんと読んでいるのか見るとよいでしょう。
0x55,0xff,0x00と来ているのですから。
s01234567pes01234567pes01234567pe
110101010101111111110010000000010
ですよね。

ずれた様子を解析すれば、どうずれたかは、簡単に想像できると思います。
もしパリティチェックで跳ねるようになっていれば、
これは止めておき強引に読みます。
0xaaとか、0xd5とか読んでいませんか？

mac さん 何時も有難うございます〜。

> > みたいにしてポーリングしているのですがタイミングが合わない場合が多いようです。
>
> 原因を解明するため、0x55をなんと読んでいるのか見るとよいでしょう。
> 0x55,0xff,0x00と来ているのですから。
> s01234567pes01234567pe s01234567pe
> 110101010101111111110010000000010
> ですよね。

そうか、ビット列で考えていくと分かりやすいですね。

RCXやリモコンからのメッセージは、Kekoaさんのページの中、Daveさん
のポストで
http://graphics.stanford.edu/~kekoa/rcx/protocol.html

2400 baud, NRZ, 1 start, 8 data, odd parity, 1 stop bit と解析されているので
そのとおりにしたいところなのですが、1 Stop Bitのオプションが Cのライブラリー
にはなくて、その辺が怪しいと思っていました。
（一応、Cのライブラリーの方、 9Bit でもためしては見たんですが、あまり
効果は無かった感じです）


> ずれた様子を解析すれば、どうずれたかは、簡単に想像できると思います。
> もしパリティチェックで跳ねるようになっていれば、
> これは止めておき強引に読みます。
> 0xaaとか、0xd5とか読んでいませんか？

ちょっと研究室（地下室）に行って過去に取ったデーターからビット列を
みて、 1010101010 のパターンが無いか見てみます〜。

何時もありがとう〜＞ mac さん。

> 2400 baud, NRZ, 1 start, 8 data, odd parity, 1 stop bit と解析されているので
> そのとおりにしたいところなのですが、1 Stop Bitのオプションが Cのライブラリー
> にはなくて、その辺が怪しいと思っていました。

原因はこれでしょう。
2 stopを1 stopで読むのは何ら問題ないですが、
1 stopを2 stopで読むと、都築さんがご指摘の通り、
次のcharのstart bitを食ってしまい、次に出現するデータ−の1を、
start bitと誤読します。

Libを自作する必要がありますね。

汎用ルーチンだとこの辺はいろいろ制約が出ますね。
1 stopがないのは、受信したデータ−の後始末に、
多少時間がかかり取りこぼすのを恐れた様に思えますが、
これは、2400bpsでなく、さらに高速のデーターを想定してだと思います。

データーがでたらめになるのは、この後データーを加工したり、
LCDに出力したりしている間に次の数charが通過してしまっているのでしょう。

割り込み無しに処理するなら、リモコンの場合11 byte、
Messageなら9 byteはメモリーに読みこんでから、
処理しないと間にあわないような気がします。

でも、そうするとデーターの切れ目がずれたら、
永久に戻ってこない危険性があるので、
実用にするには、0x55で始め、タイムアウトで逃げる対策が要ります。

何と読んでいるか調べる目的では、そこまでする事はなく、
0x55のチェックは抜き、
リモコンボタンは、1 shotで押すことにして、もし、戻ってこなければ、
もう1 shot押してやればよいと思います。

> 割り込み無しに処理するなら、リモコンの場合11 byte、
> Messageなら9 byteはメモリーに読みこんでから、
> 処理しないと間にあわないような気がします。

手軽に実験するのには、これも結構面倒な話なので、
もっと手を抜いて、8bit目を読んだら、parityは無視して、
後処理に入ってしまったらどうでしょうか？

次のスタートビットまで、8 bit目の残り半分とparity, stopの分、
2.5 bitあるので2400 bpsなら1msとれます。
逆に1.5 bit 0.6msは最低間をおいてから次のstartを探さないとだめですが...

自己レスです

ということで、簡単な実験をしてみました。
その結果、なんだか自信がなくなってきました。 というのは、0x55、0xff、0x00 というデーター
が出現するのは、リモコンの場合、１５〜６Byte目からで、まったくでない場合もあるという
感じです。

取り込んだデーターをBit列で読んでも有効と思える並びはあまり無く、
リモコンから同じコマンドを送っても、同じパターンにならない場合があるのです。

コンデンサーなども変えたり抵抗なども変えてみたりする必要もありそうです。
また、シリアルデーターを読む為のルーチン、やはり自作したほうがよさそうかな〜
なんて、最近思い始めています。

ななしのです。

使っているライブラリのシリアル信号の仕様の極性って確認しました？
すでに確認済なら無視して下さい。(気になったもので...(^^;)

ななしのさん、ありがとう〜。

> 使っているライブラリのシリアル信号の仕様の極性って確認しました？

はい、ライブラリーのオプションを変えるだけなので、随分前にためしてみました。

で、結果は Bit列が反転したものが出てきていました。

元に戻して、テストをしていますが、時々ちゃんと 0x55、0xff、0x00、 と読めるときも
有るみたいなんで、やはり 汎用ライブラリーの Stop Bitの関連だと思っています。

> はい、ライブラリーのオプションを変えるだけなので、随分前にためしてみました。
既に確認済でしたか〜

> 有るみたいなんで、やはり 汎用ライブラリーの Stop Bitの関連だと思っています。
原因の切りわけの為に「HyperTerminal」でIR towerのつながっているCOMポートを開いて一文字一文字ゆっくり入力すればstop bitの問題って発生しませんよね？それで正しく受信できているかを確認してみるのはどうでしょうか？

ななしのさん、お付き合い有難う〜

> 原因の切りわけの為に「HyperTerminal」でIR towerのつながっているCOMポートを開いて
>一文字一文字ゆっくり入力すればstop bitの問題って発生しませんよね？それで正しく
>受信できているかを確認してみるのはどうでしょうか？

お〜、目から鱗のテスト方法ですね〜。 これから研究室（ピンクの地下室）
にすっ飛んでいって実験してみます。 ....

> > 原因の切りわけの為に「HyperTerminal」でIR towerのつながっているCOMポートを開いて
> >一文字一文字ゆっくり入力すればstop bitの問題って発生しませんよね？それで正しく
> >受信できているかを確認してみるのはどうでしょうか？

その手がありましたね。

> お〜、目から鱗のテスト方法ですね〜。 これから研究室（ピンクの地下室）
> にすっ飛んでいって実験してみます。 ....

今そちらは何時ですか(^^;

Jinです。　みなさんお付き合い、ありがとうございます。
ただいま、ピンクの研究室です。　（なんだか、危ないキーワードだな〜）

> > >一文字一文字ゆっくり入力すればstop bitの問題って発生しませんよね？それで正しく
> > >受信できているかを確認してみるのはどうでしょうか？

　ということで、非常に面白い結果になりました。　　a,b,c,d,e,f　と1秒間隔、3秒間隔、5秒間隔で
2400BPS,8-N-1 と　8-O-1 と　8-E-1 また、StopBitを1.5や２、また、データーも７Bitなどと
変更して実験した結果、なぜか、同じ値を読んできます。
a=0x40　　　
b=0x40
c=0x42
d=0x40
e=0x40
f=0x44

という風に、a は　0x40で　OK　なんですが、それに続くｂ　がまた、0x40　となりました。
念のため、IR-Towerの電池も新しくしてみたのですが、変化なしでした〜。
ちなみに、IR-Towerはいつもファームウエアーの転送など行っている物です。

ということは、なんだか、StopBitがうんぬん以前の問題なような気がしてきました。
ライブラリーがこけてるのかな〜。　　でも、CCSのコンパイラは多分ユーザーも多いから
こんなバグは無いんじゃないかと思いますが〜　.........

> 今そちらは何時ですか(^^;

　へへ、夜更かしなんです、まだ、2時半です（夜中の）　今日は少し早く寝ないと　....

　寝ながら考える必要がありそうです。　（＾＾）
　

ももいろの部屋に閉じこもっておられるＪｉｎさんへ。
ちょっと気になることが有りまして。
この結果は再現性有ります？
> a=0x40　　　
> b=0x40
> c=0x42
> d=0x40
> e=0x40
> f=0x44
もし、そうだとするとbitに分解していただければわかると思いますが
２bit連続して１が続く部分しか１と認識していないようなんです。
と、すると、信号の立ち上がりがひどくなまっているのでは無いでしょうか。
たとえば、負荷が容量性を持ってしまっているとか。
失礼とは思いますがあえて書かせていただきますと、
たとえば、電源に対して入れるコンデンサが間違って
出力につながっていませんか？
（おこらないでください）http://www.sharp.co.jp/ecg/pdf/unit/is1u60.pdfの中程の
Internal　Block　Diagramを見ますと＋電源に対しては抵抗が入っていますが
GNDに対してはトランジスタだけですから容量性の負荷が付くと
正方向の信号の立ち上がりが遅れます。
お使いのコンパイラのライブラリがどのように正方向のパルスを
検出しているのかわかりませんので何ともいえませんが
可能性の一つとしてお考えいただければ幸いです。

Jinです。 亀レスですみません

> ももいろの部屋に閉じこもっておられるＪｉｎさんへ。
> ちょっと気になることが有りまして。
> この結果は再現性有ります？
> > a=0x40　　　
> > b=0x40
> > c=0x42
> > d=0x40
> > e=0x40
> > f=0x44
> もし、そうだとするとbitに分解していただければわかると思いますが
> ２bit連続して１が続く部分しか１と認識していないようなんです。

これは、再現性が100%あります。

> と、すると、信号の立ち上がりがひどくなまっているのでは無いでしょうか。
> たとえば、負荷が容量性を持ってしまっているとか。
> 失礼とは思いますがあえて書かせていただきますと、
> たとえば、電源に対して入れるコンデンサが間違って
> 出力につながっていませんか？

この辺は何度か確認しているんですが、間違っていないと思います。
都築 さんから書き込んでいただいてから、いままで、まだ触る時間がなくて
テストをしていないんですが、ふと思ったのは PICの作動が遅くて
（LCDに表示とかをしているので）それで、タイミングがずれてしまって、そのまま
変な値を表示しているのかもしれないなんて思い始めています。

１０Byteほど、配列に値を入れて、Timerを使って１秒間隔に
値を表示してみようかと最近考えております。

サーバーの設定が終わったらテストを再開したいと思ってます。

> テストをしていないんですが、ふと思ったのは PICの作動が遅くて
> （LCDに表示とかをしているので）それで、タイミングがずれてしまって、そのまま
> 変な値を表示しているのかもしれないなんて思い始めています。

波形ひずみとOverrunについては、前にあげたパターン、
01010101 55 U
01100110 66 f
00111000 38 8
00111100 3C <
00111110 3E >
00111111 3F ?
01111111 7F DEL
で大体片付くと思います。

> > a=0x40　　　
> > b=0x40
> > > c=0x42
> > > d=0x40
> > > e=0x40
> > > f=0x44
> > もし、そうだとするとbitに分解していただければわかると思いますが
> > ２bit連続して１が続く部分しか１と認識していないようなんです。
>
> これは、再現性が100%あります。

> > テストをしていないんですが、ふと思ったのは PICの作動が遅くて
> > （LCDに表示とかをしているので）それで、タイミングがずれてしまって、そのまま
> > 変な値を表示しているのかもしれないなんて思い始めています。
>
> 波形ひずみとOverrunについては、前にあげたパターン、
> 01010101 55 U
> 01100110 66 f
> 00111000 38 8
> 00111100 3C <
> 00111110 3E >
> 00111111 3F ?
> 01111111 7F DEL
> で大体片付くと思います。

以前、電気的な事だけ考えていたのでスタートビットが最下位ビットに
与える影響で違うパターンを読むのでは、という投稿(No.892)をさせて
いただきましたが、
スタートビットの検出が遅れる、
スタートビット検出からデータビット取り込みまでに時間がかかっている、のではないかと考えるとその通りになりますね。

とすれば、ｍａｃさんの言われるパターンを試してみると確認ができると
思います。

01010101 55 U -> 00000000 00
01100110 66 f -> 01000100 44 D
00111000 38 8 -> 00110000 30 0
00111100 3C < -> 00111000 38 8
00111110 3E > -> 00111100 3C <
00111111 3F ? -> 00111110 3E >
01111111 7F DEL -> 01111110 7E ~

このように化けるんじゃないでしょうか。

Jinです、ただいまピンクの壁の研究室からです。　


> 以前、電気的な事だけ考えていたのでスタートビットが最下位ビットに
> 与える影響で違うパターンを読むのでは、という投稿(No.892)をさせて
> いただきましたが、
> スタートビットの検出が遅れる、
> スタートビット検出からデータビット取り込みまでに時間がかかっている、のではないかと考えるとその通りになりますね。
>
> とすれば、ｍａｃさんの言われるパターンを試してみると確認ができると
> 思います。
>
> 01010101 55 U -> 00000000 00
> 01100110 66 f -> 01000100 44 D
> 00111000 38 8 -> 00110000 30 0
> 00111100 3C < -> 00111000 38 8
> 00111110 3E > -> 00111100 3C <
> 00111111 3F ? -> 00111110 3E >
> 01111111 7F DEL -> 01111110 7E ~
>
> このように化けるんじゃないでしょうか。

　ということで、これから仕事に行くというのに実験してみました。
でなんと、　mac さんの予想したとおりの　Bit　パターンでした。

　すなわち
01010101 55 U -> 00000000 00
01100110 66 f -> 01000100 44 D
00111000 38 8 -> 00110000 30 0
00111100 3C < -> 00111000 38 8
00111110 3E > -> 00111100 3C <
00111111 3F ? -> 00111110 3E >

　のとおり出てきました。　　　
こうなると、次の一手はやはり、汎用ライブラリーの利用をあきらめるか事かな〜と
思い始めております。

　ということで、仕事にいってきま〜す。

> でなんと、　mac さんの予想したとおりの　Bit　パターンでした。

私じゃないです。
都築さんの大予言です。

> こうなると、次の一手はやはり、汎用ライブラリーの利用をあきらめるか事かな〜と
> 思い始めております。

もし、使い方に誤りがないなら、そのIR Receiver Moduleは、
波形ひずみが大きすぎて、2400bpsは、苦しいと言う事です。

1 bitの1でも多分まったく反応がないのではなく、
start bitを検出してからn+1/2 bitのところでsamplingすると、
0になってしまうらしいことが分かったので、
このタイミングを調整しないと駄目ですね。

n+1/4, n+1/8とやれば引っかかるんじゃないかな？
汎用ライブラリーにこの調整がなければあきらめですね。

素人考えなんですが、

> もし、使い方に誤りがないなら、そのIR Receiver Moduleは、
> 波形ひずみが大きすぎて、2400bpsは、苦しいと言う事です。

　現在、Vout　を　そのままPICのI/Oにつないでいますが、途中に　７４HTC００
のCMOSのICを入れて、In　と　Outは反転しないように　！NOTのようにしてやる
事でひずみをとれないかな〜なんて思っています。
　手元に石が無いのですぐ実験できないのがつらいところです。　

> 　途中に　７４HTC００
> のCMOSのICを入れて、In　と　Outは反転しないように　！NOTのようにしてやる
> 事でひずみをとれないかな〜なんて思っています。

bufferをいれると立下り立ち上がりは、速くなりますが、
これは波形政界です。

波形成型しても、時間軸でひずんでしまった信号は元に戻りません。

Jinです。

> > 　途中に　７４HTC００
> > のCMOSのICを入れて、In　と　Outは反転しないように　！NOTのようにしてやる
> > 事でひずみをとれないかな〜なんて思っています。
>
> bufferをいれると立下り立ち上がりは、速くなりますが、
> これは波形政界です。
>
> 波形成型しても、時間軸でひずんでしまった信号は元に戻りません。

お、そうでした、ここで問題になっているのはタイミングでした〜 （＾＾）
しかし、波形がおかしいときは Buffer を入れることで波形はある程度
直せるんですよね〜。
（ん〜、すこし電子工作の世界に足を入れてきて分かってきました）

Jin です。 帰ってきました〜。 （仕事から）

> > でなんと、　mac さんの予想したとおりの　Bit　パターンでした。
>
> 私じゃないです。
> 都築さんの大予言です。

し、失礼しました〜、都築さん mac さん。

>
> > こうなると、次の一手はやはり、汎用ライブラリーの利用をあきらめるか事かな〜と
> > 思い始めております。
>
> もし、使い方に誤りがないなら、そのIR Receiver Moduleは、
> 波形ひずみが大きすぎて、2400bpsは、苦しいと言う事です。

それは凄く残念です。 というのは手元に沢山あるんですよね〜。
それだったら、センサーとして使うか １２００とか３００ｂｐｓ で使うかですかね〜

> 1 bitの1でも多分まったく反応がないのではなく、
> start bitを検出してからn+1/2 bitのところでsamplingすると、
> 0になってしまうらしいことが分かったので、
> このタイミングを調整しないと駄目ですね。
>
> n+1/4, n+1/8とやれば引っかかるんじゃないかな？
> 汎用ライブラリーにこの調整がなければあきらめですね。

この部分の調整はないですね〜。 しかし、４８００ｂｐｓ とかのオーバーサンプリング
と言う方法もあるかもしれませんね。

> それだったら、センサーとして使うか １２００とか３００ｂｐｓ で使うかですかね〜

まあ、スタートビットを安定して検出しているのだから、
タイミング調整さえできれば使えますね。

> > n+1/4, n+1/8とやれば引っかかるんじゃないかな？
> > 汎用ライブラリーにこの調整がなければあきらめですね。
>
> この部分の調整はないですね〜。 しかし、４８００ｂｐｓ とかのオーバーサンプリング
> と言う方法もあるかもしれませんね。

Serial DriverをCで書いちゃったらどうでしょう。
RB7にS-inがあるものとして、

i = 8;
data = 0;
while(RB >= 0) ;
delay(/* 1/2400 sec + α　*/);
while(i--) {
data = (data >> 1) | (RB & 0x80);
delay(/* loopが1/2400 secになるよう */);
}

でいいんでしょ、とりあえず。
RBは、CCSでRPBを8bitそのまま読む命令にして、
dalayは適当に調整と言うことで...

負論理なら全部ひっくり返して、

i = 8;
data = 0;
while(RB < 0) ;
delay(/* 1/2400 sec + α　*/);
while(i--) {
data = (data >> 1) | (RB & 0x80);
delay(/* loopが1/2400 secになるよう */);
}

data = ~data;

で、1/2400secをどうするかといえば、'U'が正しく読めればOKとか(^^;

> Serial DriverをCで書いちゃったらどうでしょう。

あ、そうか、Driver と言うとアッセンブラと言うイメージが体にしみついていたので、
そういわれてしまうと、そのとおりですね。

単に Bit 操作とタイミングだけになるからそれほど難しいわけでもないですよね。
ちょっと、気分を作ってからやってみたいと思います。

> 私じゃないです。
> 都築さんの大予言です。

勘違いの積み重ねでたまたま当たっただけのようです。
すみません。またまた勘違いがありました。
ＰＩＣの入り口で言えばスタートビットはLow、データは1がHighでしたよね。
ですからスタートビットの影響で必ず最下位Bitが０になるようです。

もう一つ、サンプル開始が遅れると書きましたが、考えてみると遅れた場合
連続した２bitで拾えるのは下位側です。
上位を拾っているのは見かけ上サンプルが早いと言うことになります。

こうなるとどうしてもアナログ的なところ（信号の立ち上がりがなまっている）
を疑いたくなるのですが、もしかするとライブラリーが n+1/2 のタイミングではなく
単に n のタイミングでサンプルしているのではないでしょうか。
つまり、信号の真ん中でなく、信号が変化しだすぎりぎりのところで。
そうすると以前にも書きましたが立ち上がりがわずかに遅れるので
このような現象が出ます。

いずれにしろサンプリングのタイミングの問題とするとｍａｃさんが書かれたように
ドライバーを書いてしまうのが一番ですね。

出しなおそうと思って関係ない記事を消してしまいました。
no.920はなんでしたっけ(^^;

> ＰＩＣの入り口で言えばスタートビットはLow、データは1がHighでしたよね。

ありゃ、いつのまにか混乱して私のソースもごちゃごちゃ混ざってますね。

> ですからスタートビットの影響で必ず最下位Bitが０になるようです。
>
> もう一つ、サンプル開始が遅れると書きましたが、考えてみると遅れた場合
> 連続した２bitで拾えるのは下位側です。
> 上位を拾っているのは見かけ上サンプルが早いと言うことになります。

01100110 66 f -> 01000100 44 D

~~~~|____|____|~~~~|~~~~|____|____|~~~~|~~~~|____|~~~~|原波形

~~~~|____|____|__~~|~~~~|____|____|__~~|~~~~|____|__~~|歪波形

~~~~|____|_^__|_^__|_^__|_^__|_^__|_^__|_^__|_^__|____| samplingとなっているのでしょう。
立ち上がりが遅れ、立下りは速いのでhighが削られているんだと思います。先の+αを3/4*(1/2400)ぐらいでしょうか？

Jinです。 今日はそろそろ寝てしまいますが〜。

> 出しなおそうと思って関係ない記事を消してしまいました。
> no.920はなんでしたっけ(^^;

｜ あ、いま、メールLOGをみたら、ライブラリーのソースが入ってないCコンパイラは
｜組み込みのものには向かないな〜というお話でした。

MSCなどを昔から使っていた自分は、コンパイラメーカーがライブラリーのソースを
つけないのになれていましたので、あまり不自然は感じませんでしたが、
今回のような感じになるとコードがあったら、タイミングをずらせるのにな〜と
思いました。 GNU などを普通に使っていると今度はライブラリーのコードが無いのは
空気の中に酸素が入っていないくらいの感じになるのかもしれませんね。

CCSの場合は、一応、LSTを出してくれて、どのようなインプリメンテーションがされるかは
分かるようになっていますが、さすがに、ハンドオプティマイズする気にはなれないですね。
それだったら、やはりスクラッチから書いた方が自分もすっきりします。

ところで



> 01100110 66 f -> 01000100 44 D
>
> ~~~~|____|____|~~~~|~~~~|____|____|~~~~|~~~~|____|~~~~|原波形
>
> ~~~~|____|____|__~~|~~~~|____|____|__~~|~~~~|____|__~~|歪波形
>
> ~~~~|____|_^__|_^__|_^__|_^__|_^__|_^__|_^__|_^__|____| samplingとなっているのでしょう。
> 立ち上がりが遅れ、立下りは速いのでhighが削られているんだと思います。先の+αを3/4*(1/2400)ぐらいでしょうか？

この図のお陰で随分すっきりしますね。Bitの立ち上がりが遅いという感じが。
これ、 いまケミコンの 47μFのコンデンサー と 0.1μF程度のセラコンを
並列に入れてあるんですが、入れているのがひよっとしたら問題なのか
とふと思ってしまいました。 （mac さんの [761]よりのサジェスチョン）

http://www.sharp.co.jp/ecg/pdf/unit/is1u60.pdf の５ページ目の接続例
に習って 47μF にしてあるんですが、今、回路図を見直すと、コンデンサーの
部分、斜め線が入っていないですね。 （斜め線が入っているのは電解コンデンサーと
昔覚えたようなきがします） しかし、47μFみたいなものだと、電解コンデンサー
見たいな物しかないような気がします。
ひよっとしたら、この辺のあやふやな知識が、この波形の乱れとタイミングが
合わないというのの根本的なもんだいじぁないかとすこし恐ろしくなってきました。

もしも、コンデンサーを変えてみるとしたら、どのタイプのに変えてみたらよいでしょうね〜。

> > 01100110 66 f -> 01000100 44 D
> >
> > ~~~~|____|____|~~~~|~~~~|____|____|~~~~|~~~~|____|~~~~|原波形
> >
> > ~~~~|____|____|__~~|~~~~|____|____|__~~|~~~~|____|__~~|歪波形
> >
> > ~~~~|____|_^__|_^__|_^__|_^__|_^__|_^__|_^__|_^__|____| samplingとなっているのでしょう。
> > 立ち上がりが遅れ、立下りは速いのでhighが削られているんだと思います。先の+αを3/4*(1/2400)ぐらいでしょうか？

あれ、stop bitが間違っているみたい(^^;


> この図のお陰で随分すっきりしますね。Bitの立ち上がりが遅いという感じが。

自分で見て思ったんですが、
専用リモコンは、このディーティー比を加減していないかなあ。

VishyのIRMもIS1U60よりは小さいけど、同様にHighが削られる傾向があるんですね。

同じような強さでIR signalが届いているのに、Message Ballより、専用リモコンのほうが、RCXは、よく拾う話しましたよね。

あとで、Message Ballにパッチしてみよう(^^)

> > > 01100110 66 f -> 01000100 44 D
> > >
> > > ~~~~|____|____|~~~~|~~~~|____|____|~~~~|~~~~|____|~~~~|原波形
> > >
> > > ~~~~|____|____|__~~|~~~~|____|____|__~~|~~~~|____|__~~|歪波形
> > >
> > > ~~~~|____|_^__|_^__|_^__|_^__|_^__|_^__|_^__|_^__|____| samplingとなっているのでしょう。
> > > 立ち上がりが遅れ、立下りは速いのでhighが削られているんだと思います。先の+αを3/4*(1/2400)ぐらいでしょうか？
>
> あれ、stop bitが間違っているみたい(^^;

stop bit 実際はもう少し長くて、極性が反対側ですよね〜
（我ながら ↑、ちょっと自信ないかんじです）


> > この図のお陰で随分すっきりしますね。Bitの立ち上がりが遅いという感じが。
>
> 自分で見て思ったんですが、
> 専用リモコンは、このディーティー比を加減していないかなあ。

というのは？、 '1' の部分をすこし長くしているとか？。

> VishyのIRMもIS1U60よりは小さいけど、同様にHighが削られる傾向があるんですね。
>
> 同じような強さでIR signalが届いているのに、Message Ballより、
>専用リモコンのほうが、RCXは、よく拾う話しましたよね。

そうなんですよんね〜。 特に、MessageBall3 のメッセージは RCXはなかなか
拾ってくれません。 単に出力と 赤外線LEDの頭の削り方が悪かったのかと
自分では思っていたんですが〜。

> あとで、Message Ballにパッチしてみよう(^^)

それは、嬉しいです。 （＾＾）

> MSCなどを昔から使っていた自分は、コンパイラメーカーがライブラリーのソースを
> つけないのになれていましたので、あまり不自然は感じませんでしたが、
> 今回のような感じになるとコードがあったら、タイミングをずらせるのにな〜と
> 思いました。

IARのH8/500,300 C compiler使ってますが、
商用でも、lib source fileがついているし、
linkしたばあいのbinaryにはロイヤリティ不用になってます。

> ひよっとしたら、この辺のあやふやな知識が、この波形の乱れとタイミングが
> 合わないというのの根本的なもんだいじぁないかとすこし恐ろしくなってきました。

コンデンサーは電源とGNDピンの間ですね。
ひょっとして間違って、出力ピンとGNDの間に入ってないか心配されてましたが。
間違いなく電源、GND間でしたら、立ち上がりに影響を与えることはありません。

それとケミコンであることを明示する必要がなければ、記号に斜線は不用です。
もし気になる場合、47uFケミコンに、0.1uFセラコンを並列にしておけば、十分です。

> 出しなおそうと思って関係ない記事を消してしまいました。
> no.920はなんでしたっけ(^^;

CCSはLibのソースがないんですか？
安物のGrich RC Inc. PicCにもついているのにという話でしたね。
まいっか(^^;

どうも 都築 さん〜。

> もう一つ、サンプル開始が遅れると書きましたが、考えてみると遅れた場合
> 連続した２bitで拾えるのは下位側です。
> 上位を拾っているのは見かけ上サンプルが早いと言うことになります。
>
> こうなるとどうしてもアナログ的なところ（信号の立ち上がりがなまっている）
> を疑いたくなるのですが、もしかするとライブラリーが n+1/2 のタイミングではなく
> 単に n のタイミングでサンプルしているのではないでしょうか。
> つまり、信号の真ん中でなく、信号が変化しだすぎりぎりのところで。
> そうすると以前にも書きましたが立ち上がりがわずかに遅れるので
> このような現象が出ます。

なるほど！！。 目には見えない（オシロがあれば、みれるか）ところでも
こういう風にいろいろ考えられるのは勉強になります。

このような問題が有ったからこそ、学べるんだな〜と思ってます。

> いずれにしろサンプリングのタイミングの問題とするとｍａｃさんが書かれたように
> ドライバーを書いてしまうのが一番ですね。

いま、ふと悪いことを思ってしまいました。 というのは、出来るかどうか分かりませんが
ソースコードの初めの部分にクロックを定義する部分があります。
いまは１０Mhzなのでその部分をわざと、１１Mhz 程度にしてやってコンパイラにDelayの
コードをジェネレートする部分を操作するという方法です。 （＾＾）
もっとも、この場合も、全体的にタイミングが変化するだけなので、うまく合うか分かりませんが。
でも、まあ、そういうのは根本的な解決じゃないから、そういう労力を使うくらいならば
スクラッチから書いた方が、よいとは思いますが。

> いま、ふと悪いことを思ってしまいました。 というのは、出来るかどうか分かりませんが
> ソースコードの初めの部分にクロックを定義する部分があります。
> いまは１０Mhzなのでその部分をわざと、１１Mhz 程度にしてやってコンパイラにDelayの
> コードをジェネレートする部分を操作するという方法です。 （＾＾）
> もっとも、この場合も、全体的にタイミングが変化するだけなので、うまく合うか分かりませんが。
> でも、まあ、そういうのは根本的な解決じゃないから、そういう労力を使うくらいならば
> スクラッチから書いた方が、よいとは思いますが。

おもしろいですね。
クロックを早く定義してやると言うことはサンプルのタイミングを遅らせて
やることになりますから。
ストップビットまでぎりぎり引っかける事のできる周波数の計算は。。。

またまた自己レスです。
ああどうして送った後に気づくのでせう。
> たとえば、負荷が容量性を持ってしまっているとか。
IS1U69の負荷のことです。
それともう一つ'a','c','e'の場合スタートビットが有るから
41,43,41となるはずですよね。

Jinさん遅くまでごくろうさまです。
あまり無理しないように...って言いながらコメント付ける自分(^^;

> という風に、a は　0x40で　OK　なんですが、それに続くｂ　がまた、0x40　となりました。
細かいことですが'a'=0x61ですよね？それとも'A'の間違かな。
それだとしても'A'=0x41ですよね。

結果をみるとボーレートが合ってるかちょっと気になりますね。
使っているセラロックの周波数とソフト中で宣言している周波数はあってるでようか？既に確認済ならすみません。

どうも、ななしのさん〜

> Jinさん遅くまでごくろうさまです。
いえいえ、本人は楽しんでおります〜。 ただ、さすがに昨日は寝てしまいました。

> あまり無理しないように...って言いながらコメント付ける自分(^^;
みなさんにコメントをつけていただけるお陰で、投げ出さないでやっていられる
感じです、ありがとう〜ございます。

> > という風に、a は　0x40で　OK　なんですが、それに続くｂ　がまた、0x40　となりました。
> 細かいことですが'a'=0x61ですよね？それとも'A'の間違かな。
> それだとしても'A'=0x41ですよね。

あ、本当だ。 ＡＳＣＩＩ ＣＯＤＥも確認してませんでした。
（昔、ＡＳＣＩＩ ＣＯＤＥの入った Ｔシャツがありましたね〜そういえば）

> 結果をみるとボーレートが合ってるかちょっと気になりますね。
> 使っているセラロックの周波数とソフト中で宣言している周波数は
>あってるでようか？既に確認済ならすみません。
はい、一応この辺は確認しております。 ちなみに、10Ｍｈｚのセラロック使っています。

しかし、簡単な回路ですが、ハードとソフトの両方をデバッグしていくと言うのは
面白い（苦しい）ですね〜。 今、自分がしている事は初めてのことばかりなので
みんな珍しいことばかりです。

> 結果をみるとボーレートが合ってるかちょっと気になりますね。

私は、波形ひずみがうんと大きいような気がします。
IS1U60の規格は600us brist波に対し±200usのエラーですので、
2400 bpsの1 bit 417usの半分ぐらいは、規格上は行きますね。
Manualのp.5 Fig.5辺りを見ると近距離でパワーが強いと特にひずむ様です。

試しに、直接IRTを向けず、天井に反射させるとどうでしょう？
また、Pull up対抗が内蔵されてますが、念のため、1〜3.3kΩで、
IS1U60の出力端子を+5VにPull upすると状況が変わりませんか？

> > 結果をみるとボーレートが合ってるかちょっと気になりますね。
>
> 私は、波形ひずみがうんと大きいような気がします。
> IS1U60の規格は600us brist波に対し±200usのエラーですので、
> 2400 bpsの1 bit 417usの半分ぐらいは、規格上は行きますね。
> Manualのp.5 Fig.5辺りを見ると近距離でパワーが強いと特にひずむ様です。
>
> 試しに、直接IRTを向けず、天井に反射させるとどうでしょう？

早速ためしてみましたが、結果は同じみたいでした。
（もっとも、すぐそばにおいてやったから、側面から出ているのを拾っている
可能性も大きそうですが）

> また、Pull up対抗が内蔵されてますが、念のため、1〜3.3kΩで、
> IS1U60の出力端子を+5VにPull upすると状況が変わりませんか？

なるほど〜。 そうやってPull Upする事で波形を引っ張る（正しい表現か
分かりませんが)みたいなことをするんですね〜。 勉強になります。

それで、早速 手元に、1.2KΩの抵抗が転がっていたのでためしてみまし
たが、あんまり状況は変化無しでした。
これから、Bitパターンを見てみます。

また、後閑 哲也さんの 「http://www.picfun.com/」 の中
http://www.picfun.com/pic14.html に、アッセンブラで書いた 受信処理プログラム
の例がありましたので、こちらを使わせてもらって実験をしてみたいと思います。

色々本当に、ありがとうございます。

key boardから直接打てる文字で、シリアル信号の試験に便利なものは、

01010101 55 U
01100110 66 f
00111000 38 8
00111100 3C <
00111110 3E >
00111111 3F ?
01111111 7F DEL

などいろいろあります。
「文字」でなく「パターン」で追いかけるほうが、
この辺りは糸口がつかみやすいと思います。

mac さんへ

> key boardから直接打てる文字で、シリアル信号の試験に便利なものは、
>
> 01010101 55 U
> 01100110 66 f
> 00111000 38 8
> 00111100 3C <
> 00111110 3E >
> 00111111 3F ?
> 01111111 7F DEL
>
> などいろいろあります。
> 「文字」でなく「パターン」で追いかけるほうが、
> この辺りは糸口がつかみやすいと思います。

なるほど！！。 これはいい手ですね。 早速実践してみたいと思います。
有難うございました。

> 使っているライブラリのシリアル信号の仕様の極性って確認しました？
> すでに確認済なら無視して下さい。(気になったもので...(^^;)

そうですねちょっと気になりますね。
TTL LevelはRS-232Cの負論理で扱うことが多いですからね。

LCDの書きこみ40μs, binary-hex変換2桁では、
Cで書いたってそんなに時間はかからないでしょうから、
でたらめになっているのは、
オーバーランが原因と見てbufferingを検討する前にまだ、
やるべきことがありますね。

bit列をみたのでは有りませんがRS232CモニターをIrタワーにつないで
リモコンのデータを見た結果を報告させていただきます。
A↑　　55 ff 00 d2 2d 00 ff 08 f7 da 25
A↓　　55 ff 00 d2 2d 00 ff 40 bf 12 ed
B↑　　55 ff 00 d2 2d 00 ff 10 ef e2 1d
B↓　　55 ff 00 d2 2d 00 ff 80 7f 52 ad
C↑　　55 ff 00 d2 2d 00 ff 20 df 2a d5
C↓　　55 ff 00 d2 2d 01 fe 00 ff d3 2c
P1 55 ff 00 d2 2d 02 fd 00 ff d4 2b
P2 55 ff 00 d2 2d 04 fb 00 ff d6 29
P3 55 ff 00 d2 2d 08 f7 00 ff da 25
P4 55 ff 00 d2 2d 10 ef 00 ff e2 1d
P5 55 ff 00 d2 2d 20 df 00 ff f2 0d
STOP 55 ff 00 d2 2d 40 bf 00 ff 12 ed
BELL 55 ff 00 d2 2d 80 7f 00 ff 52 ad
1 55 ff 00 d2 2d 00 ff 01 fe d3 2c
2 55 ff 00 d2 2d 00 ff 020fd d4 b2
3 55 ff 00 d2 2d 00 ff 04 fb d6 29

メモ・書き間違いが有るかもしれませんがチェックサムでごかくにんねがいます。
これで見ますとすべて１１バイトになります。
また、ボタンを押している間このメッセージが連続して出力されています。
と、いうことで、STOP bitを２として読む場合、次のバイトの頭を
STOP bit　と思いこんでいるかもしれません。
そうだとすると、初押しの５５はとれますが、その後のデータが取れません。

しかし、
> その結果、なんだか自信がなくなってきました。 というのは、0x55、0xff、0x00 というデーター
> が出現するのは、リモコンの場合、１５〜６Byte目からで、まったくでない場合もあるという
> 感じです。
とのことですから数が合わないことと全く出ないことから考えますと
リモコンに問題があるようにも思えます。
（まさか電池がお釈迦様。。ではないですよねえ）
そうでなければライブラリーですか

あと、bitの並びですがｍａｃさんが書いておられますように
下位から出力されます。
つまり５５は２進で０１０１ですからシリアルデータでは１０１０になりす。
（そんなこと知ってるわい！ということでしたらごめんなさい）

参考になりますでしょうか。

都築 さんどうもありがとう、
私もリモコンが出しているデーターのダンプリストは作ってました。
リモコンの場合、同時に押している場合もあるので、１６Bitのデーターを
送るようになっていますね〜。

リモコンも、複数持っているので２つでテストしているのですが、同じような
結果でした。
今度はちょっとライブラリーを使わないで、アッセンブラでその部分を書いてみて
テストしてみようかと考えています。

> つまり５５は２進で０１０１ですからシリアルデータでは１０１０になりす。

自己レスです。
馬鹿なことを書いてしまいました。
５５は０１０１０１０１です。
ですからシリアルデータは１０１０１０１０になります。

> LCD画面は割と書き換えとかが遅いし、それでいて、リモコンから送られてくる
> コマンドはLCDの表示スピードに比べて速いので、この辺の処理を如何するかなど

表示は遅いけど、書きこみコマンド自体は、40μsで終了してますんで、
カラムが一杯にならない程度に詰めて表示すればOKでしょう。

> > LCD画面は割と書き換えとかが遅いし、それでいて、リモコンから送られてくる
> > コマンドはLCDの表示スピードに比べて速いので、この辺の処理を如何するかなど
>
> 表示は遅いけど、書きこみコマンド自体は、40μsで終了してますんで、
> カラムが一杯にならない程度に詰めて表示すればOKでしょう。

いま、すこしプログラムをしていたんですが、やはり、ライブラリーなどを利用して
いると、提供されている関数などがどのように動くか確認が大変ですね〜。

いまのところ、ようやく 16進数を表示できるところにきました〜。