何となく落ち着いた感じと少しまとめ

値段以上に結構元を取れたと思うDHT22ですが、結局のところほぼDHT11と同じだったという感想。測定範囲だけはどうしてもDHT11だとダメなところはありますが。湿度の小数点は実用上ほぼ不要だと思いますし。

DHT11の時に記憶に残っている注意書きとかと同じ現象がDHT22も発生し、データシート上を見続けているとちゃんとそのことが記載されていたりします。そんなところでまとめ的な点として

・その時点の湿度と温度を取得したい場合は２回連続で読み出す必要がある。

・連続で読み出す場合は２秒間をあける必要がある。

この点が、やっぱりDHT11/DHT22が好きになれないところとなっています。

結局２連続で読み出す必要があるので、最低でも２秒もかかってしまいます。

これを無視して読み出そうとするとデータが欠けたりして正しく読み取れませんでした。成功することもあります。

DHT22の方が読出しの手順の時間が短くて済みますが、DHT11と同じタイミングでも普通に読み込みができます。

何度も書きますけど、再読み込みが必要なのでどんなにμs単位で短くしても、2秒という単位が大きすぎて差が出ませんｗ

センサーのまとめとしてはこんなところでしょうか。

そしてｃ言語でちょろっと書いて作ってみたプログラムはリトライやらコマンドラインの引数やらの対応までして小さかったソースが肥大化を始めました。どこまでやるかはあれですけど、やっぱりｃ言語は動作が軽かったです。

例外処理が書けないとか、結構痛いところはありますが、ループ中の処理を少し増やしても数μs単位で回ってくれるのは助かりました。

そんな感じでｃで書いてみたまとめとして…

pi@rasp3b:~ $ ./dht22 --pin 5 --debug
debug mode.
sampling_start_lev : 1
sampling_end_lev   : 1
length : 82
sampling data :
23 79 81 54 26 54 27 54 25 55 26 54 26 54 25 54 74 54 26 67 74 53 26 54 26 55 25 54 74 54 26 54 26 54 73 67 26 54 26 54 26 54 26 54 26 54 26 54 26 54 25 68 74 53 74 54 73 54 74 54 73 182 26 54 73 64 74 54 26 54 26 54 26 54 73 55 26 53 26 55 24 47
warn count : 1(61)
bitcount : 39
Retrying.

sampling_start_lev : 1
sampling_end_lev   : 1
length : 84
sampling data :
23 79 82 53 26 54 26 55 25 55 26 53 27 54 26 54 73 54 25 68 73 54 26 54 26 54 26 54 74 54 26 54 26 54 25 68 26 53 27 53 27 53 27 54 25 54 27 53 27 54 25 67 74 54 73 54 74 54 73 55 73 54 73 54 27 53 73 64 74 54 26 54 26 54 26 54 26 54 74 54 73 54 73 47
warn count : 0
bitcount : 40
data high '0' : 25 ～ 27
data high '1' : 73 ～ 74
data low : 53 ～ 68
data : 02 88 00 FD 87
sampling_start_lev : 1
sampling_end_lev   : 1
length : 82
sampling data :
22 79 81 54 26 54 26 55 25 54 26 55 26 54 26 53 74 54 25 68 74 53 26 54 26 54 26 54 74 54 26 54 26 146 26 55 25 54 27 54 25 55 26 54 26 53 27 53 26 67 74 54 73 54 74 54 73 54 74 54 73 55 26 54 25 64 74 54 26 54 26 53 27 54 26 54 74 53 74 54 25 47
warn count : 1(33)
bitcount : 39
2nd read retrying.

sampling_start_lev : 1
sampling_end_lev   : 1
length : 84
sampling data :
24 78 81 54 27 53 27 54 25 54 26 54 27 54 26 53 74 54 25 68 73 54 26 54 27 53 26 54 74 54 26 54 26 54 25 67 27 54 25 55 25 55 25 55 26 54 26 53 26 55 25 67 74 54 74 53 74 54 73 54 74 54 74 54 25 54 73 65 73 54 26 54 26 54 26 54 26 54 74 54 73 54 73 47
warn count : 0
bitcount : 40
data high '0' : 25 ～ 27
data high '1' : 73 ～ 74
data low : 53 ～ 68
data : 02 88 00 FD 87
temperature : 25.3
humidity : 64.8

エラーが発生していてリトライしている結果のコピペとなりますｗ

結局sudo cpufreq-set -g powersaveとしても、読み込み時に取りこぼしが発生するのが確定したので、処理落ちした回数も記録してwarnとして出力させてみました。ループで30μs以上かかる場合をカウントしています。

DHT11でもそうだったんですが、データの整合性チェックをただのCRCで行っているので、まれにとんでもない数値で正常終了することがあります。

その時に温度が70度を超えていたりして笑えますが、はっきりとわかるときはいいですけど、近い数値で化けてしまうこともあるのでデータの信頼性は低くなります。

もう少しだけソースを整理したらDHT11と共通化したり、他のソースと見比べたりしてみたいかな…。

てか処理落ちなんとかならないかな…raspberry piは安定しているけど、制御系は微妙なのかも。