若松ガイガー 20130128版公開 - ブログ／こばさんの wakwak 山歩き

　本記事には古い情報が含まれている場合があります。まとめページを作成しましたので併せて御覧下さい。

追記(2013/05/03)
　NMEA関係で重大なバグを発見し緊急修正しています。
　20130503版をどうぞ

　半年ぶりの更新で、ちょっと緊張してます。。。
　新たな環境測定デバイスへの対応と、高感度管むけチューニングが主な内容となっております。
　固定モニタリングポスト(lcdLayout=0、savePower=0)で運用されている方にとってはこれといった変更箇所はないですが、mbed ベースライブラリも最新版に差し替えましたので、未知のバグが修正されているかもしれません。

~~20130128版ファームウェア一式~~ 20130503版をお使い下さい。

20120819版との機能比較　(20120819版の仕様はこちらを参照ください)

気圧センサーMPL115A2 に対応(気圧+気温)
光センサー(CDS) に連動してバックライト輝度を自動調整する機能を追加
線量付き位置情報(nmea互換)をUDP送信する機能(SYSLOG互換)を追加
lcdLayout=2(ホットスポット捜索モード)の表示仕様を変更
非同期割込み処理で液晶表示する機能を追加
毎秒255カウントまでだったものを(理論上)毎秒65535カウントまで拡大
毎分65535カウントまでだったものを(理論上)毎分4億カウントまで拡大
ブザー鳴動条件(sound_cpm)に255までの値しか指定できなかったものを65535まで拡大
放射線検知時のLED/ブザーを間引きできる機能を追加
recommendCountのデフォルトを100から200に変更
高精度温度センサーLM61 向けパラメータを同梱(LM35/LM60も)

注意

　以前に本家のオリジナルファーム Ver1.0 を利用されていた方の mbed 内に GEIGER-2.bin というタイムスタンプ 2008/01/01 のファイルが出来ている場合があります。

　2012/1/7頃に実施された自動アップデートによってダウンロードされたプログラムのようですが、mbed の中に拡張子 BIN のファイルが複数あると意図せぬ誤作動が起きやすくなりますので、私のファームを導入する前に GEIGER-2.BIN は予め削除しておいて下さい。

　特にタイムスタンプが変な（新しいのに古い日付の） BIN　ファイルが混じると理解困難な不可解な現象（意図したファームが動いてくれない）が起きやすくなりますので、そんなときには、全てのファーム（拡張子が BIN）を削除して再起動させ、その後に目的の BIN を1つ入れて再起動し直して下さい。

　タイムスタンプが変なファームによって mbed の内部で行われているバージョン管理が狂ってしまったとき、BINファイルがひとつもない状態にして起動させることで狂った管理テーブルがクリアされるようです。

気圧センサーMPL115A2 に対応(気圧+気温)

　温度計や湿度計のような単純なアナログ出力なセンサーを利用する環境測定は、スプライン補間機能とも相まって概ねカバーできたかなと思いますが、今回は I2C 通信という方法で計測値を取得する気圧センサー MPL115A2 に対応させます。

　基本的にはリファレンス回路のままです。
　上記のような結線をしたうえで、env.ini 内に

MPL115A2=i2c　　※大文字小文字は問わず

という行を追記するだけで MPL115A2 を認識します。
　Twitter・Logging・UdpSend 等々設定ファイルの中の書式（format）に気圧＝%PRESSURE%、気温＝%TEMPERATURE% というパラメータでそれぞれ用いることができます。
　WebPost は全項目を Post 形式で送信する仕様ですので、特に設定することはありません。

　Cosm（旧Pachube）へ Feed する場合は、COSM設定ファイル中で

pressure=
temperature=

と書いて下さい。

　気温に関しては外国の方の計算式を参考にしつつ、手持ち LM35 に合わせて +2℃ほど補正しました。

外国の人の計算式	私の計算式
T = (temp − 498.0) ÷ -5.35 ＋ 25.0	T = temp ÷ -5.35 ＋ 120.0

　これもスプライン補間を定義できるようにすれば確かに完璧ではありますが・・・(汗)

光センサー(CDS)に連動してバックライト輝度を自動調整する機能を追加

　何台か作った若松ネットガイガー（Mark2 互換機）のうちの１台をモバイルルーターと共に常時車載していてメーターパネル辺りに鎮座させておりますが、3.3V液晶を繋いで輝度可変にしてあるものの、昼間は暗すぎ（輝度を上げた設定じゃないと見えない）、夜は明るすぎ(輝度を下げないと眩しい)という風で、なかなかうまくいきません。
　自室に置いてる人も、昼間に合わせて輝度設定すると夜は照明代わりになるくらいに眩しいことでしょうから、安い光センサーを繋いで、こいつで輝度調整を自動化させることにします。

　これは20番ピンを用いた例ですが、アナログ入力ができるピンならばどれでも大丈夫です。
(若松ガイガー純正機は 16/17/18 を利用済みなので15/19/20 のどれか)
　env.ini 内に

adjBacklight=20

と、輝度調整に使用するピン番号を指定して下さい。

　ピンに入力される信号(電圧)と輝度の関係は、0V = 0％、3.3V = 100％という至ってシンプルな仕様にしましたので、CDS 以外のデバイスで輝度調整する仕組みにしても構いませんし、車のイルミ配線を判定入力に使っても構いません。
(イルミ配線は電圧オーバーなのと条件が反対なので、トランジスタを用いて反転させる必要がありますが)

　CDS は(物にも依りますが)明るさに応じて (明)10k〜(暗)1MΩくらいで抵抗値が可変する素子で、分圧した電圧を取り出して利用しますが、3.3V の電源を基準にして CDS と抵抗とで分圧させると 3.3V(輝度100％) は出ないので、mbed の入力ピンが 3.3V 超え(〜5V) を 3.3V と見なすことを利用して 5V を基準にして分圧させるようにしています。

　いちお上記の回路図では分圧比率の調整に用いる可変抵抗を 50kΩ としましたが、手持ち GL5528 という素子との組み合わせの場合、約 7kΩ 付近がベターな感じになりましたので、20kΩ な可変抵抗のほうが調整がラクかもしれません。

　env.ini 内に minBacklight・maxBacklight を記述している場合には、その範囲内で可変します。
　minBacklight の記述を省略したときは「5」になるようになってますので、真っ暗なときでも 5％の輝度は維持します。
(minBacklight・maxBacklight ともに未指定のときは 5〜100％で可変)

　なお、バックライトを輝度調整できるようにするための必要機材・配線については以前の記事の「液晶バックライト輝度制御」をご覧くださいませ。

線量付き位置情報(nmea互換)をUDP送信する機能(SYSLOG互換)を追加

　GPSロガーみたいな NMEA 形式の線量付き位置情報データは、歩いて作ろう汚染地図のサイトなどを利用して、測定線量を地図にプロットさせるのに最適なフォーマットなのですが、モバイルルーターを車載していると microSD カードの抜き差しも億劫になってきます。

　microSD に出力するときと同じように５秒おきくらいにデータ送信しようと思うと、HTTP(TCP)はプロトコル的に重すぎて付いていけません。
　じゃあ軽い(送達確認のない) UDP で投げっぱなしにしちゃえ(欠落上等！)ってことで、過去に作成した UdpSendサービスを応用して、NMEA形式のデータも UDP 送信する機能を追加しました。

　受け側は一般的な SYSLOG サーバーで大丈夫にしてありますので、適当にフリーな SYSLOG サーバーソフトを拾ってきてインターネット側から見えるように立てれば準備万端になりますが、認証という概念がない SYSLOG サーバーをインターネット空間に公開設置してよいものかどうか、かなり迷えるところではありますねぇ。

　ポートスキャンしてるロボットに見つかると変なパケット飛ばされそうですが、果たしてどんなもんだか。。
　自宅はヤマハのRT58iなので、可変IPなプロバイダであっても Netvolante-DNS 使って動的ドメイン名を名乗れるので、いちお SYSLOG サーバーは建てられる環境ではありますが・・・

　UdpSend 設定ファイルと同じように、NMEA設定ファイルの中に

host=<送信先のホスト名>　　　※例) syslog.wakwak-koba.jp　　　←実在しませんので要注意
port=<送信先のポート番号>　　※省略すると 514

と書くだけで動作します。
　「送信先のホスト名」は 192.168.1.1 みたいな LAN 内のIPアドレスでも大丈夫なので、インターネットに SYSLOG サーバー置く代わりに、SYSLOG サーバーを車載すれば余計な心配は要らないかもしれません。

　複数の若松ネットガイガー(もしくはMark2互換機)を同一の SYSLOG サーバーに送信する場合、サーバー側に送信元の IPアドレスが記録されるとは言え、モバイルルーターからインターネット経由で飛ばすと IP アドレスは通信キャリアのアドレスになって、どのガイガーからのデータなのか判別困難なので、先頭に MAC アドレスを付加するオプションも用意してあります。
　ただ MAC アドレスが先頭についていると、そのままでは NMEA 仕様じゃなくなって一般的な地図ソフトでも読めなくなるので、加工前にMACアドレスを外すなどの前準備が必要になりますが、とりあえず MAC アドレスを先頭に付けたい人は NMEA 設定ファイルの中で enableMac=1 としてください。

lcdLayout=2(ホットスポット捜索モード)の表示仕様を変更

　これまで lcdLayout=2 の表示モードを勝手にホットスポット捜索モードと名付けて、上段に1分平均値、下段に10分平均値、とそれぞれ cpm/μSV と表示していました。
　16文字×2段しかない液晶だもんで、時刻が表示できないという致命的な問題があり私自身も滅多に使わないモードでしたけど最近になって「そもそも cpm/μSV の両方の表示がいるか？」ということに気がつきました。

　ということで、lcdLayout=2 の表示を大きく変更いたしました。

使用管は J209γ。1/31に写りの良い写真に差替え。上に載ってるの左がCDSで右が温度センサー。グルグル巻きの線はszPartsで買ったGPSの余り線

　lcdLayout=1 にそっくりですが、月/日を日だけにして、代わりに秒を表示させるようにしています。
　「あれ？今日は何日だっけ？？」ってことは多いと思いますが、「今月は何月だっけ？」ってことはまずないので、月の表示をバッサリ切り捨てました。

　校正パラメータ(cpm→μSv/h)の入ってない場合は cpm のまま、校正パラメータがあるときは μSV/h で左右に表示されるようにしました。
　cpm か μSV/h か、どちらか片方が見えればホットスポットは分かるでしょ(両方はいらんでしょ)、ってことで。

　測定値は、これまで1分平均と10分平均と固定で出していましたが、SBM-20 のような低感度管だと低線量地域での1分平均値はバラツキが多すぎてホットスポット探しは非常に困難。
　J209 や J106 といったクラスの高感度管でないと実質的にホットスポットは探せない、という結論に達し平均化処理の仕組みを高感度管むけに見直しました。

　周辺線量に応じて平均化秒数を自動可変するレコメンドモードで動作するようにしました。
　(デフォルトでは)200カウントが得られた秒数で平均化させる処理になっており、この数値を左側ほ、その５倍の秒数(200カウント×5にかかった時間ではない)で平均化させた値を右側に表示させています。

　ダッシュボードに J209γ 設置した車で、先日みつけた中央道高架下のプチスポット程度の濃さの場所を時速30〜40km/h程度で走ってて捉えることができるくらいのチューニング度合いです。

　左側が右側に比べて ±10〜15％くらいの揺らぎは日常的なので、その程度は無視するとして、経験則的には、３秒以上に渡り20％を超えを維持した場合、何かあるかも!? って疑ってよいかなと思います。
　その上で、可能であれば引き返し数分間停車させて右側の値も上がり出したらビンゴ！でいいかと思います。

　名二環の引山付近など、停車させられない場所は、何回か走って同じ傾向かどうかで判別できるかと思います。
　新東名で反応があった地域も再測定に出向きたいところですが、ガレキ焼却終了したらしいので、次回も同程度の反応を示せば鉱物由来だと推測できそうです。

非同期割込み処理で液晶表示する機能を追加

　上で書いたように、lcdLayout=2 のホットスポット捜索モードの仕様を変更しましたが、かなりの高感度管とは言えども「何かある」そのポイント瞬間には反応せず、数秒から十数秒くらい遅れて数値として反応が見えてくるので、線量の数値とセットで「秒針」が重要な判断要素になります。

　よって lcdLayout=2 では重要度が低い「月」を削除して「秒」を新設した次第ですが、ネットワーク系のサービス(Twitter/Cosm/WebPost)も利用している場合、通信環境やサーバーの状態によっては10秒近く処理が止まることがあります。
　lcdLayout=0 でお使いの方も、液晶を監視してると稀に数値の更新が遅くなるタイミングを発見できると思いますが、あれです。

　ネットワーク系の処理遅延で液晶の表示更新が追いついてなくなっても、ピコーンの検知など「重要な部分」は独立した割込み処理で動いているため測定値への影響は全くないのですが、液晶に「秒」が表示されるようになると、より遅延が目立つようになってしまい、なんか不安になってきてしまいます。

　そこで一定条件が重なったとき、液晶表示も主たるプロセスと独立させた非同期モードで動作するようにしました。
　

　デフォルトで非同期処理になる条件とは

起動時にLAN線が繋がっていてネットワーク系のサービスが動いている
　　　かつ
ボタンが繋がってる　または　lcdlayout=2

です。
　ぶっちゃけ、「秒針が止まる」のがバレてしまう可能性がある条件のときに非同期処理としました。
　逆に、表示更新が止まる原因となるネットワーク系のサービスが動いていないときや、秒の表示のない lcdLayout=0/1（かつボタンで切り替えされることがない）のようなときは、わざわざ非同期処理とせず、これまでどおりの同期処理で動作します。

　なんで全ての場合で非同期にしなかったかというと、この手の処理によって発生する不具合がなかなか発見しにくく現時点でバグが絶対にない自信がありません。
　モニタリングポストで使用されている方の優先順位は安定性が第一で、液晶の見え方くらいはどーでもいいと思いますので、こんな風な動作にしました。

　lcdLayout=0（または省略時）では若松ネットガイガーのオリジナル版の状態を限りなく踏襲すべき（勝手にいじるべきじゃない）というポリシーでおりますんで。。。

　とはいえ、どーしても、って人には env.ini の中に lcdAsync=1 と書くと常に非同期表示になります。
　逆に lcdAsync=0 と明記すると、条件に関わらず常に同期処理(従来どおり)となります。

　今回のバージョンは1週間くらいランニングテストしてからリリースしてますが、もし万一不安定になってしまったら lcdAsync=0 で試してみて頂きたいです。

カウント数の拡張関係

　最近は J209γ という、BG で 400〜500cpmをたたき出す高感度管を用いていますが、こいつは蛍光灯に反応するため近づけて遊んでいたところ、10000cpm を超えたあたりで逆に下がり始めたり・・・という挙動を発見。
　中途半端に下がるわけないので、なんで？と調べてましたら、どうやらピコーンのカウントが多すぎて桁あふれを起こしていた模様。。。

　オリジナル版から 255cps（CountPerSecond）が限界なのですが、1秒間に 255カウントまでなら正常に計数するものの、255 から 1 カウントオーバーしたら、0 に戻ってしまうんです。
　C言語で言うところの unsigned char 型の配列に cps を格納しているのですが、これを unsigned short 型に・・・と単純に変更すると複数管(最大4管)のときにメモリー不足に陥るため、もうひと工夫しました。

　接続管が２本までのときは最大で 65535cps まで、３本以上のときは最大 255cps まで、しかも、そのカウントを超えたときでも桁あふれして 0 に戻ることがないようにしました。
　9割以上の人は１本だと思うし、J209×4本なんて人は私を含めて居ないでしょうから、恐らくは無問題かと思われ。。

　私は Mark2互換機では LED やブザーを付けずに使っているのですが、試しに J209 なガイガーに繋げてみたらトンでもないことになることに気がつきました。

　500cpm なんてほとんど鳴りっぱなしじゃないですか！

　ということで、LED やブザーの鳴動を間引く signalInterval というパラメータを新設しました。
　signalInterval=20 とすると、ピコーン20回につき1回 Lチカさせブザーを鳴らします。
　env.ini の中、もしくは GM管定義ファイルの中に書いて下さいませ。
　(両方に記述したときは後者が優先されます)