グラフのセンスが無さすぎる

センサーごとのアジャストを行ったり、色の調整を少ししたら、

そういえば温度のメモリも１℃刻みでほしいよなとか、

温度、湿度、気圧と表示は気温しか出していなかったので、温度と湿度の軸を揃えてみようかなとか、

：

：

まずは温度の刻みを直してみると、グレーの濃さが微妙だなとか、、、きりがないｗ

私以外見ることが無いマイグラフなのでとにかく把握しやすいものということであえてｙ軸は温度、湿度、気圧と分けていたわけですが、phpのスクリプトは単純にそれぞれ独立して上限下限を決めてプロットしているだけなので、軸を揃えたければ単純に一致させてあげるだけでグラフも簡単にそろう作りになっていたので試しにやってみたところ

高湿度のこの時期はこんな感じに。温度の波が今までの半分程度になってしまうので結構寂しい感じに。

元々、温度を中心に考えて、湿度と気圧はおまけ的に表示させていたのですが、改めて見てみると、やっぱり軸を揃える意味は少ないようです。

温度に関しては、気温は0℃～40℃、Raspberry pi の温度が～60℃として考えても、20目盛ぐらい助長になっています。

軸の状態を元に戻してみると、、

高湿度なのでRaspberry piの温度と重なってしまう感じになっていますが、数字の重なりさえなければ実用的に問題ないかなぁ…グラフとしては上下に踊ってくれた方が楽しいし。

やはりほとんど波が無いグラフは面白くない。

正直、グラフなんてこだわったことがことがほとんどないのでセンスも何もないのが一番悲しいｗ

DHT11とBME280の差異は上下に数値を補正しただけで波形はほぼ一致しました。試しに湿度や温度をエアコンで変えてみましたが振れ幅も一緒なのでこの温度、湿度下ではいい感じです。冬場までこのままセンサーをつなげたままの状態を維持すれば少し違った結果が得られそうな感じはします。

ただ、驚くべきことに、安価なDHT11の湿度の方が反応が良いようです。温度の反応速度はどちらも一緒のような雰囲気です。

気になりだすと止まらないセンサーの精度

使っているスクリプトを色々な角度から確認してみたところこれ以上おかしな点はなさそうなので、さらに別の角度から考えてみようかと。

極論は温度、湿度、気圧計を横に並べて比べてみるしかないとおもいます。

ですが、手持ちに無いので、既に使わなくなってしまったDHT11を発掘してつなげてみました。

個人的には、DHT11は温度、湿度センサーで、精度も整数値しか取得できない上、センサー値を取得するときにどうしてもエラーが発生してしまうことからあまり信用していませんでした。

エラーに関しては仕様上の問題もありますが、レスポンスが確実に悪くなるのと、リトライが発生するので時間上不安定になりがちになります。いままで１０分間隔にロギングしていた理由の一つとして当初はDHT11も使用していて分刻みだと１分以内に処理が終わらなくなるかも？と考えていたからです。もうすこしエラー率が低くて、リトライもあまり発生していなければよかったのですが。あとは、分刻みだとログデータの発生量が結構インパクトありそうな気がしていたところです。ざっくりと計算すると、固定長のバイナリファイルに収めると１年間で10Mbyte程度になりました。これが大きいか小さいかというのは考え方次第です（が、他に本体の電源電圧やCPUクロックなどのログも取り入れていけばそれだけ大きくなってしまいます）。現状はいろいろ便利そうという理由だけでSQLite3を使ってデータを記録しているので、だいたい１日80Kbyte程度。これが365日なので約26Mbyte程度となります。（ざっくり昼間計算したら1年間で30Mbyteという数字が出てきたきがしますｗ）

まぁその他もろもろの事情で１０分間隔だったわけでが。

さて、少しロギングできたので様子を見てみると…

DATE TIME	Board	Temp	Humi	Press	Temp3	Humi3	error3	Temp1-3	Humi1-3	B - T
2020-07-04 23:07	45277	28770	66309	1004054	29000	78000	0	-230	-11691	16507
2020-07-04 23:06	45277	28820	66196	1004140	29000	77000	0	-180	-10804	16457
2020-07-04 23:05	44790	28830	66111	1004193	29000	77000	0	-170	-10889	15960
2020-07-04 23:04	45277	28880	65887	1004181	30000	77000	0	-1120	-11113	16397
2020-07-04 23:03	45764	28920	65794	1004223	30000	77000	0	-1080	-11206	16844
2020-07-04 23:02	45277	28840	66079	1004174	30000	77000	0	-1160	-10921	16437

データは1000倍して整数値で格納しているので、温度のBME280とDHT11の差は1℃程度でしたが、気になっている湿度は10%以上の差が発生していました。同じBME280の別の個体との差が7%程度あったので、気になっていましたが、まさかの10%以上の差がでているとは…。

昨日の夜に天気HPの地点情報の湿度を比べてもBME280の湿度の数値はかなり低く、室内とはいえ窓を開けた状態で30%程度低かった記憶があります。

現時点でDHT11と比べると…HPでは89%、78%、BME280の湿度は…66%となってます。同じ部屋にあるもう一つのBME280は、73%と出ています。

結構な期間温度センサーを動かしていましたが、あまり細かいところは気にしていなかったとはいえ、BME280は気圧センサー以外はあまり正確な値ではないようです。ただ、センサー感度は悪くないので、ちょっとした変化はすぐに掴める気はします。

結構気に入ってBME280を買いそろえてしまいましたが、別の気温センサー探そうかな？

BME280のオーバーサンプリングを試してみた

どこかのライブラリを基にして、python3で使えるようにしてクラスっぽい実装にしたものを使っているので、データシートを見ながら１ステップづつ確認しているような状態ですが、モード値以外はほぼ問題なさそうというのが現時点での結論となっています。

そんなこんなで、まずはオーバーサンプリングを試してみましたが、結果から言えばほんとに小数点以下の誤差が若干落ち着くかな？といった感じでした。

フィルタリングに関しては、データシートの説明でノーマルモードで使用することが推奨されていて、よくよく読んでみると、設定のレジスタに書き込むと内部のフィルタメモリがクリアされる仕組みになっているので、現状の使い方（毎回初期設定して温度を読み取っている）ではあまり効果が期待できなさそうです。このへんはもう少し手を加えれば変えられそうですが、そこまでの精度の値が欲しいわけではないので踏ん切りがつきません。

データシートにはフィルタを有効にすると、気圧と温度の解像度（分解性能？）が上がると書かれているので、気になりますが、原文とグーグル翻訳を使って読んでいる限りドアの開閉や扇風機などの気流の乱れの誤差を減らすのが目的なようなので現状関係ないかも(笑)

オーバーサンプリングやフィルタ効果を見るために、同じ場所の２つのセンサーのグラフを実際に重ねて比較してみると、

気温

湿度(上部にCPU温度がかぶってます)

気圧

温度、湿度、気圧とものにほぼ同じ形になっているのでやっぱりオーバーサンプリングやフィルタリングの効果は少ないようです。

気圧に関しては、数値もほぼ同じになっていて気持ちがいい反面、温度は0.5℃、湿度は５％程度の差がありました。

やはりキャリブレーションデータの計算が間違っているのか、個体差か、劣化による誤差なのかは謎のままです…

コピー品が出回ってるかも？と検索したら、日本語版のデータシートが存在してました。

細かいスペックは英語の方がわかりやすかったりしますが、製品そのもののイメージを捉えるためには日本語で読めると全体がつかみやすいです。英語力ほとんどないからなぁｗ

と、いろいろとはっきりしたポイントとして、英語でも「ゲームモード」と書かれていて何に使うのかな？と引っかかっていましたが、気圧と温度で高度の差異を捉えて高精度の高度センサーとして利用するのが目的のようです。そのためにわざわざノーマルモードなるひたすらセンサー値をレジスタに書き込むモードがあるようです。実際に数Ｈｚ程度のサイクルで値が更新され続けるので、動態検知だけでなく、ヘッドマウントディスプレイなどに組み込めば加速度センサーとは違った実際の上下移動距離をリアルタイムで取得できそうです。

なるほどねぇといった感じですが、、、実際に使うのはただの温度、湿度、おまけで気圧の観測記録だけなのですｗ

ちろっと、サンプルを見かけたと思ったんですが、やはり日本語です。はっきりと認識できました。

気象観測用のおすすめ設定は…

オーバーサンプリングは気圧、気温、湿度すべてｘ１。フィルターはオフ。強制モードで、サイクルは１分間隔とのこと。

理由はよくわかりませんが、一昨日から昨日までノーマルモード（毎回初期化してるので上記の想定からはやや離れているのですが、）１分単位で取得した温度の値が、百均の温度計との差が少なくなりました。

色々とスクリプトを見直していたら今まで使っていたものはどうもdouble型で簡易的に求めるもののようで、基準となる変数が本来は整数なのに対してdoubleのままになっていました。記憶はあまりないですが、BMP180のソースを基に自分で起こしたような気もしてきました。とはいっても、やはり小数点以下の誤差しか出てこないので、温度と湿度の個体差が予想以上に出ているという残念な結果が残りました。

BME280センサーの個体差が気になるので

いままで何回かバラバラで購入しているので結構個体差があります。

百均で温度計も購入して比べてみましたが、予想以上にズレがありました。とはいえ、±２℃程度ではあるので実用的には全く問題はありませんがｗ

センサーチップにキャリブレーションデータがあるので誤差の原因がその補正計算で問題があるのではないかと気になって仕方がなかったので、使っているソースとデータシートを見比べてみました。

結果としては、データシートの参考ソースから補正計算をさせた結果と、今までの結果の差は

今まで使っているライブラリの値

温度 28.008137599710608
気圧 1004.5331902330901
湿度 68.45038478114147

データシートから起こしたスクリプトの値

温度 28.01
気圧 1004.5329296875
湿度 68.4453125

誤差の根源は内部で使いまわしているt_fineという基礎数の計算時の誤差が由来のようです。

143401.6645105183

143401

データシートに記載されているソースは桁あふれが発生させないように整数で扱っているのに対して、今まで扱っているライブラリの方は誤差は演算処理任せにして演算している感じです。

その結果、今回データシートから起こしたスクリプトは気圧と湿度に関しては算出された値からさらに表示用にそれぞれ256と1024で割り算しているのでその誤差が出てきているだけの格好です。

ついでに細かいところでレジスタから取得している部分も見直してみたのですが、結局は問題ありませんでした。ビットで切り離している値などもあるので、怪しいと思ってアドレス計算とかまでして確認したんですけどね無駄でしたｗ

とはいえ、根本的なところで、

The “config”register sets therate, filter and interface options of the device. Writes to the “config” register in normal mode may be ignored.In sleep mode writes are not ignored.
「config」レジスタは、デバイスのレート、フィルタ、およびインターフェースオプションを設定します。通常モードでの「config」レジスタへの書き込みは無視される場合があります。スリープモードでは書き込みは無視されません。

という記述を発見。

ライブラリではノーマルモードのままとなっているので、若干心配ではあります。

あと、サンプリングの回数を１０分間隔から１分間隔に変更して様子を見ているのですが、１分間隔にしたら温度計の温度との差がかなり少なくなった感じがします。

と、すると、オーバーサンプリングうんたらかんたらでセンサーの値を拾ってあげると結果が変わりそうな気配がしますが…そのうち確認してみましょう。

China Post経由でようやく到着

一週間かからずに届くかも？と期待していましたがようやく到着しました。
出荷報告は翌日にあったのですが、China Postの伝票情報が表示されず正直不安でしたが六日経った一昨昨日ぐらいにようやく伝票状況が確認できて、9/1に空輸されている状況。
少し不安は減ったものの手元に届くまで内心不安でした(笑)