ブログ/こばさんの wakwak 山歩き Twitter

2011-09-20 若松ネットガイガー・機能改善ファームウェア公開!

若松ネットガイガー・機能改善ファームウェア公開!

| 若松ネットガイガー・機能改善ファームウェア公開!を含むブックマーク

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


 台風接近に伴う土砂降り(水浸し)のため、市内あちこち大渋滞の道路で、動くのを待ってる間にノートパソコン使いつつテストしてました。

 帰宅まで4時間強かかりましたが・・・


 たぶん致命的なバグはないと思うので、とりあえず公開いたします。

 ファームウェアと書くと敷居が高いですが、単にマイコンで初期起動するプログラムに過ぎません。

(パソコンのマザーボードのあれと違って、入れ損なっても壊れることはない)


 2011/09/20版 ファームウェア一式 です。  こちらの20110926版 をお使い下さい。



オリジナルとの機能比較

  • GPSとの通信速度を自由定義(4800/9600以外でも大丈夫)
  • 経度の計算が間違えているオリジナルの既存バグを修正
  • GPSとの通信方式を割り込みを用いて非同期処理(GPS待ちが発生しない)
  • 現在時刻をNTPのほかGPSからも取得
  • リチウム電池接続により、NTPもGPSも使えない場合でも正しい時計を保持
  • ADCモードの廃止(放射線の入射強度を調べる試みとしては面白いが、メモリー確保のため廃止)
  • ファームウェアのネット更新機能の廃止(同じくメモリー確保のため廃止)
  • 内蔵フラッシュディスクにログを記録する logging サービスの実装
  • 各サービス(twitter/pachube/logging)を同時実行可能に
  • twitter/logging サービスについて、それぞれに動作間隔(分)や出力書式を自由に設定

env.ini の仕様赤字は追加された項目)

項目名説明省略時の挙動制限
gpsBaudGPSとの通信速度GPS未利用4800/9600等の数値
ntpServer時計合せに使用するNTPサーバーNTP未利用最大30文字
twitterTwitter設定ファイルTwitterサービス未利用最大30文字
pachubePachube設定ファイルPachubeサービス未利用最大30文字
loggingLogging設定ファイルLoggingサービス未利用最大30文字
ipIPアドレスDHCPを利用xxx.xxx.xxx.xxx
netmaskサブネットマスクip指定時は省略不可xxx.xxx.xxx.xxx
gatewayデフォルトゲートウェイip指定時は省略不可xxx.xxx.xxx.xxx
dns参照DNSサーバーip指定時は省略不可xxx.xxx.xxx.xxx
gmtypeGM特性ファイル省略不可最大30文字
soundブザー鳴動フラグ1:放射線検知の度に鳴動0 または 1
timezone標準時刻からの誤差省略不可数値のみ
init_stabilize_time起動後に計測を待つ時間(秒数)30数値のみ
cpm_array_max移動平均の短時間分数101〜10
long_cpm_array_max移動平均の長時間分数601〜60

Twitter 設定ファイルの仕様

項目名説明制限
id もしくは IDTwitterアカウントのID最大60文字
pass もしくは PASSSuperTweetのパスワード最大60文字
formatツィート時の書式(使用できるパラメータは後述)最大140文字
intervalTwitterサービスの起動間隔(分)数値のみ

Pachube 設定ファイルの仕様

項目名説明制限
apikey もしくは PACHUBE_APIKEYPachubeのAPIKEY最大60文字
feedid もしくは PACHUBE_FEEDIDPachubeのFEEDID数値のみ
usv0直近10分間のuSV/hをFeedする場合の項目ID数値のみ(未使用時は-1)
nsv0直近10分間のnSV/hをFeedする場合の項目ID数値のみ(未使用時は-1)
cpm0直近10分間のcpmをFeedする場合の項目ID数値のみ(未使用時は-1)
usvlong0直近60分間のuSV/hをFeedする場合の項目ID数値のみ(未使用時は-1)
nsvlong0直近60分間のnSV/hをFeedする場合の項目ID数値のみ(未使用時は-1)
cpmlong0直近60分間のcpmをFeedする場合の項目ID数値のみ(未使用時は-1)
intervalPachubeサービスの起動間隔(分)数値のみ

Logging 設定ファイルの仕様

項目名説明制限
pathファイル名の書式(使用できるパラメータは後述)最大60文字
formatログ記録時の書式(使用できるパラメータは後述)最大140文字
intervalLoggingサービスの起動間隔(分)数値のみ

書式に使用できるパラメータ

項目名説明出力例
%SEQ%初回起動時からの連番00000001
%DATE%日付(timezoneで補正後)2011/09/20
%TIME%時刻(timezoneで補正後)12:24:31
%YEAR%日付の西暦年2011
%MONTH%日付の月09
%DAY%日付の日20
%HOUR%時刻の時12
%MINUTE%時刻の分24
%SECOND%時刻の秒31
%CPM%直近10分間のcpm値19
%uSV%直近10分間のμSV/h値0.118
%L_CPM%直近60分間のcpm値17
%L_uSV%直近60分間のμSV/h値0.105
%LONGITUDE%正確な経度138.728635
%LATITUDE%正確な緯度35.360444
%R_LONGITUDE%アバウトな経度138.73
%R_LATITUDE%アバウトな緯度35.36
%HEIGHT%高度(ジオイド高)3776
%SPEED%速度(km/h)180

 メモリー節約のため、文字数のチェックとか一切を省いていますので、簡単にバッファオーバーラン起こします(笑)

 特に書式を利用する場合、置換後の文字数が150文字以上となると確実に暴走します。

 ツィッターの仕様は140文字までなので、置換後の文字数が140文字以内に納まるように気をつけて設定して下さい。


 ちなみにオリジナル版も、文字数や妥当性は全くのノーチェック状態です。


 ログファイルのファイル名も書式で設定できますが、置換後が 8文字+3文字 を超えるとエラーが出ます。

 使っていけない記号とかもありますので、あまりにトリッキーなファイル名は避けた方がいいです。

 ファイルへは append モードで書き足してます。


既知の問題(仕様制限)

  • (予告していた)自宅サーバー等の cgi への POST(GET) 機能が出来ていません。検証に使えるサーバーを探してます。
  • loggingサービス(内蔵フラッシュディスクにログ記録)がフラッシュディスクの残容量を見ずに書き込みしているので、もしマンタンになったら、きっと動作が停止します。出力書式や間隔を見直して、早々マンタンにならないように工夫ください。
  • パラメータの値には指定できる長さに上限がありますが、そのチェックは行ってません。あまり長い文字列を入れると暴走します。(壊れるわけではないですけど)
  • 数字項目に文字を入れたり、といった妥当性チェックも行っていません。気をつけて設定ファイルを作って下さい。
  • 漢字には未対応です。(mbedの世界に漢字という概念はない気がする)
  • Twitterサービス使用中に、稀に SuperTweet から ErrorCode:6 が返されツィートが失敗することがあります。たぶん SuperTweet 側の事情だと思うのですが、原因がよく分かりません。無視して放置しておくと勝手に直ります。
  • ソフトじゃなくてハードの問題ですが、ポン付けしたGPS(GT-723F)の感度が著しく悪くロスト多発です。たぶん高圧発生回路の高周波ノイズの影響をモロに受けていると思われ。改善策を模索中です。

 何かバグが見つかればコメントください。


追記(お願い)

 私のファームウェアを用いて Pachube される方、できましたら Feed の Tag 欄に「wakwak_koba」を追加してやって下さい。

 私のファームを使われている方の測定結果(送信品質)の検証ができればと思ってます。

 また、私のファームに何かバグがあって挙動がおかしくなったときに、オリジナルと違うファームを使っての結果であること(オリジナルの作者さんが原因でない旨)を明示する目的もあります。

 どうぞ、よろしくお願いいたします。


追記(2011/09/26)

microSD や WebPost に対応した 2011/09/26 版を公開しました

カメコカメコ 2011/09/21 15:14 無改造のmark2にインストールして、μSv/h nSv/h CPMとTwitterを併用して発信しています。今のところどれも問題なく発信されているみたいです。ノーマルのファームではpachubeで時々データが更新されなくなることがあるので、それが起こらないとうれしいなぁ、と思っています。ありがとうございます!feedは上のホームページに貼っておきました。

こばさんこばさん 2011/09/21 15:41 >ノーマルのファームではpachubeで時々データが更新されなくなることがあるので

pachubeは元々あったライブラリ(公開ライブラリぽい)を、そのまま流用してますので、たぶん同じかと・・・
私の環境だと、時々ツィート(SuperTweet)時に Error=6 が戻ります。

HTTPクライアントは、mbed が提供しているぽい共通ライブラリを使っているのですが、サイト側が重くて一定秒数内にレスポンスが来ないとエラーで落ちるのかもしれません。「一定秒数」の閾値を弄れるのかは調べてみます。

パソコンのUSBに繋いで mbed のサイトから仮想シリアルをインストールして、テラタームあたり 460800bps で監視してると、Pachube や Twitter でエラーが出たときの番号を捕捉できますので、一度お試し下さい。
(デバッグ情報がグチャグチャで大変に見にくいですが)

>feedは上のホームページに貼っておきました
投入直後の波形の乱れが気になりますねぇ
「1時間移動平均」といいつつも、その1時間分のデータが集まっていないときは、どうすんべ?と。起動して1時間後に初回送信が走るのは、なんか精神的に良くないですよねー

こばさんこばさん 2011/09/21 18:16 私のテストFeedは
https://pachube.com/feeds/35872
です。
仕事中は車載したまま、駐車場から Pachube と ツィートされてます。

カメコさんと全く同じ時間(日本時間の17時ごろから)から横線ツーになってますねー。
時々更新されなくなるのは、Pachube 側の障害な気がします。

こばさんこばさん 2011/09/21 19:32 Pachubeが悪いんじゃないか、って書きましたが自分の車載ガイガー、バッテリー切れで落ちてました。
充電系の不良で鉛蓄電池の開放電圧が 6V に・・・

再充電してもダメだろうなぁ

カメコカメコ 2011/09/21 23:09 クイックなレスありがとうございます。

ここに3つフィードがありまして
https://pachube.com/feeds/35764
https://pachube.com/feeds/35445
この2つはノーマルファーム

https://pachube.com/feeds/35953
そしてこれがこばさんのファームになります。

みるとこばさんのファームがロストしてるのが多いように見えて、実は数日前には上の2つもたびたびロストしていました。
現在はいずれも自宅でテスト中で接続環境はLANケーブルまで全て同じです。なので、たぶん問題はPachubeにあるのではないかと思います。
ただ問題なのはロストしても復帰してくれたらいいのですが、時々ロストしたままという事もありました(ノーマルファーム)。

一方Supertweetは夜になってから安定して発信されるようで、もしかしたらtwitterの混み具合によるのかもしれません。特に今日はTwitter大繁盛だったみたいですし。

ただ実はこれとは別にガイガーカウンターをネットカメラで撮ってメールでtwitterに送るというパターンを
http://twitter.com/#!/Gumyoji_Geiger
こちらでやっています。これはFlickr経由のポストなんですが、こちらはミスをするという事が無いみたいです。
Flickrの前にlockerzでやっていたときも同様でした。もしかしたらFlickrの方でポストできるまでしつこくトライしているのかもしれないのですが、もし目標到達ごお手隙だったら、メール経由のポストも検討いただけると幸いです。

でももしかして次に原発が飛んだりしたら、Twitter限界でやっぱり発信できなくなっちゃったりするのかしら、と思ったりもして。

こばさんこばさん 2011/09/22 01:48 こんばんは。

WebPostサービス実装に伴う今晩の大改修で、SuperTweetとPachubeの送信モジュールも全面的に作り替えました。
ついに、オリジナルから残ってるソースは、移動平均の算出ロジックのみになってしまいました。

更に内部の深いところを解析した結果、私が出してたエラー6は HTTPのレスポンスコード 403 の時に発生すると判明しました。(相手サイトから拒否られてるとき)
カメコさんの送信失敗時のエラーコードも何とか捕捉して頂けると嬉しいです。

今晩、新しいコードを使って耐久試験してみます。

カメコカメコ 2011/09/22 01:50 了解です。明日ちょっと忙しいですが、時間が空き次第エラーチェックします。ありがとうございます!

こばさんこばさん 2011/09/22 01:54 >自宅でテスト中で接続環境はLANケーブルまで全て同じです

1つのIPで並行してPostしてるんですか?
送信間隔が分からないですけど、もしかして、PachubeのFeed受信制限に引っかかってませんかね。

中をみたら、項目が3つあると、3回Postします。
3台(3FEED)が3項目ずつPostすると、合計で9回Postされます。

確か無料版の上限は5回/分だと思うんで、各機の稼働周期によってこれに引っかかってるとか?

カメコカメコ 2011/09/23 00:20 一応自分の故郷周辺の所にずらずらと設置しようと思っているので、有料にしてあるんですよ。今のところ4個(うち1個はGeigerbot)、9フィード運用して、ディリーで630だと思います。こばさんファームの1機はPachubeの間隔が13分、Twitterの間隔が20分にしてあります(しろうと考えですが、なるべく重ならないように半端な数にしてあります)。今のところ、どうも夜になるとPachubeもTwitterも調子が良くなるので、おそらく単純にトラフィックの問題ではないかなと(でも海外では昼なんですが・・・)

http://twitter.com/#!/kamakura_geiger

これがTwitterの方です。

ところで、今日昼、Pachubeが盛大に落ちてましたね。
明日時間を作ってシリアルチェックしてみます。反応遅くてすみません。

カメコカメコ 2011/09/23 01:02 でも、明日こばさんのファームに全機入れ替えて、更新スピードを落として見ます。

こばさんこばさん 2011/09/23 07:59 昨日に見つかったバグを夜に直して、今朝の未明から、友人に作って貰ったデバッグサイト(データが飛んでくると反射的にメール打つ)をターゲットにWebPostの強負荷テストやってます。
1分毎でグルグル回してます。(TwitterとPachubeも数分おき)
恐ろしい量のメールが飛んできてます(汗)

それと並行にmicroSD記録も試してるんですが、no disk のエラー出て落とせてません。
クラスタサイズが512KBを超える1GB超のものはワケアリで、みなさん苦労なさってるみたい。
それでかつ簡単に使えるメーカーと使えないメーカーがあるとか。。。(自分のは上海問屋のNBディスクなんで・・)
512MBとか低容量のは大丈夫らしいんですけど、こんなの今さら入手できないし。
何とかSD記録まで済ませてから次期版を公開したいなと思ってます。。