前回までいろいろ解析してきたが、どうもシリアルのパラメータ自体間違っているのではないかと。

本物のRS-232Cはデータの0, 1に対して電圧は逆になる。それをさらにRS-485にしているのでややこしいのだが、今回のUSB-RS232C変換の出力はTTLレベルなので電圧は逆転してないはず。

で、思ったのだが、今までRS-485のデータを読むことしかしてなかったのだが、逆に自分でデータを出力してその電圧確認してみれば、どっちがRS-485の+かはっきりするはず。これなら現場に行かなくてもここでも確認できる。

で早速やってみた。

1の信号はTTLレベル出力のRS-232Cの信号、2の信号はRS-485(-)の信号。0x31をデータとして送っている。 ストップビットは0、データは下位ビットが先に出力されるので 0100011001というデータになる。ちなみにRS-485(+)の出力も2の逆相になるので1の信号と同相になる。やっぱりストップビットはRS-485の+でもLowに落ちるという解釈であってるんだが。

でパワコンデータ取得の準備の時の画像をもう一度みてみる。

あ、2の信号が最初にデータ0でLowに落ちていると思ってたけど、違う。最初はアイドル状態で、アイドル解除の一瞬LowになってそのあとHighに立ち上がっている波形なんだ。なので最初にストップビットのデータ0でLowに落ちているのは1の信号が正解。よく見れば一番最初のパルス幅が短い。

うーんやられた。

データにはストップビットとスタートビットが一定間隔でかならず入るので、信号の立ち下がりが100us前後で絶対入るはずなのだが、2の信号だとそれがない部分がある。で1の信号で0, 1の並びをよくみてみる。0 0100 0000 1 10 0000 0010 1 10・・・ 立ち下がりの間のデータ数を見ると明らかにもう1ビット多い。パリティ有りか。

もっと長いデータの画像だと目で0, 1を追うのはキツイのでVisioに画像を貼り付けて定間隔で立ち下がりを調べて見る。やはりパリティありで間違いない。1のデータが奇数しかないところは立ち下がりの部分のパルス幅が広くなっている。ということで、パリティは偶数パリティらしい。

で、正しいデータは 0x02, 0x40, 0x0C, 0x09・・という並びっぽい。

しかしパリティ使うかねぇ。エラーデータを受け取ったら誤動作するようなシステムはパリティチェックで防ぐのはオススメできない。偶数奇数の判定しかしないパリティ程度ではエラーは大して回避できない。例えば1/100でエラーが起こるような環境だと、そのまた1/100の確率の1万回に1回は間違えたデータが間違ってないふりして抜けてくるわけで絶対市場で障害が出る。結局、障害再現しないといけなくなってそんな微妙な再現確率だとテスターさんとかにすごく迷惑かかるぞ。

誤動作しないシステムだったらそもそもパリティチェックなんかいらない。データが化けて困るんだったららそもそもハード的に対策するか、もっと強力なエラー訂正使うべき。

さて、それは置いておいて、データ取り直しは決定。これで変な可変長なのは治るかな。

ただしテキスト表示だと解析しにくいので、次回は流れてくるデータをバイナリで表示できるプログラムを用意していこう。データを見てすぐ理解できることはないと思われるので、リモコンの表示を変更しながら流れてくるデータの対応がわかるようにして記録を結構長時間記録する必要がある。それぐらいしかヒントになる数値を取る方法はないし。でも積算電力は10分以上データとってないと変化しないだろうから、表示切り替えボタン押し続けるの面倒だなぁ。

今までの経緯はこんな感じ。

電流センサー
パワコンデータ取得の準備
パワコンのデータを取得してきた
パワコンのデータ解析1
パワコンのデータ解析2

にほんブログ村
太陽光発電ランキング

• « 前の記事へ
• 次の記事へ »