【ガイガー】汚染地図作成手法確立プロジェクト２ [sc](★0)
-
- 1
- 地震雷火事名無し
- 2011/09/18(日) 18:05:08.08
-
汚染地図に関しては、既に科学者の方々が自主的に取り組んでおられますが、
今回の原発災害に向けてだけでなく、政府をあてにせず、いざという時に有志で
迅速に放射能汚染地図を作り、子供たちを守る為の手助けをしたい、そのための
「手法を確立する」プロジェクトです。
・汚染地図作成の為の手法の確立
・必要とされるプログラムの政策
・公開手法などの検討
・利用できる機材などの検討
などを行って参りたいと思います。
ある程度のものが確立した段階で、一度有志参加で災害に立ち向かっている方に
迷惑がかからない範囲で、現場テストと訓練をできたらナーと思います。
・機材購入レビューの人柱
・車込みで現場に行ってもいいという人
・プログラムの面からサポートしてもいいよという方々
などの合流を求めます。
既に汚染地図作成のプロジェクトも存在しますが、検討段階では色んな
アプローチがあって良いと思うので、特に「逸脱して全然合流できない方向」
に言ってしまわない限りは、２ちゃんねる有志の活動としてめとめまで頑張りましょう。
手伝ってね、みなさん。
前スレ：【ガイガー】汚染地図作成手法確立プロジェクト１
http://hato.2ch.net/test/read.cgi/lifeline/1307247719/
-
- 144
- 139
- 2011/10/22(土) 22:36:47.67
-
大佐殿
ガチャコン GPXデータで吐き出し必要時間
コピペで１つのcsvに PDS_MEAS_RT-Readingd_ C12345_111010_111020合体.csv
nmeaも当該分を書き出し
csvデータのみ7060行 吐き出し所要時間約12分25秒＝745秒 でした
cpuメーターが動いてたのでハングしてないと踏んでPC君にがんばってもらいました
-
- 145
- 2011/10/22(土) 22:57:42.43
-
>>143
現状の運営サイドの判断と見解のまとめなどは、この板の自治スレでまとめてあるので、
★緊急自然災害@超臨時板 自治議論スレッド★
http://hato.2ch.net/test/read.cgi/lifeline/1299835428/
方針が変わるまでは、このスレを有意義に使っておいて良いのではないかと？
いろいろと突っ込まれる前に先手と予防は打っておきましたし。
どうやら、最新の見解も>>140 のようです。
今はガチャコンに使っている各機種ごとのログ変換部分を単体化して汎用CSV にするのをやっています。
そっちに集中し始めると急にカキコが減って流し見だけになると思います。
板移動騒ぎ関連で集中できない日々なのですが・・・
プログラム的に参考になった部分内容を書けば、
ログスプリッター（元：ログカッター）に、
１/２ 〜 １/１０ぐらいまでの間引き機能など入れるとテキスト編集が楽になるカナ？
などですね
重複部分に関しては、ファジー（懐かしい言い方ｗ）判断はどうしてもプログラム的に LR 無理なので
人力（思考）に頼ることになりますが、
その日分の編集を行った上でプロット用に連結しカシミールなどに足していくしかないかと。
「こういう編集の仕方がある」とか「ここをこうすれば」などを論ずることは
ROM ってる多くの計測者さん達にもたいへん有意義かと
このスレの存在意義の１つなんで大いにくっちゃべってよかっべよ
-
- 146
- 2011/10/22(土) 23:25:03.39
-
>>144
あら？ 7060行も入れてハングせずに出ましたか、耐性高いな
それと、スレチ気味になりますが、PDS-100G/GN ID の関連物で
【スペクトル】放射性核種同定【解析】1MeV
http://hato.2ch.net/test/read.cgi/lifeline/1311864994/
ボールのパスは、PDS-100G/GN ID 持ちさん側に今、ボールがあるので
・・・・情報待ちというところですね。
基準線源の実データと適当なサンプリングデータが数種類あればいろいろ出来るんですけどね。
|
|ω･´)ﾉｼ ではでは
|
-
- 148
- 地震雷火事名無し
- 2011/10/23(日) 01:18:41.18
-
えっと、前スレをきちんと読んでみました
今日BluetoothでGammaRAE２のログ抜くことができました
いろいろ情報だして下さった方々
どうもありがとう
-
- 149
- DoseRAE2
- 2011/10/23(日) 23:01:23.15
-
実家から一時帰宅、来週より忙しくなりそうです
>>104
その値はコントロールパネル内の「地域と言語」設定に依存しないか検証が必要です
-
- 150
- DoseRAE2
- 2011/10/23(日) 23:41:00.95
-
間引きのタイミングですが
>>147 さんの
>nmeaもガチャコンに読み込ませる前に信号待ちなどで例えば5秒同一緯度経度ならdelって整形しておけば
などはかなり有効かと思いますが、私には低不可なアルゴリズムが見いだせないです
ファジー(高負荷なんでイヤン)では無くAIが有効かと思います
当然優先度「低低」の意見です
では、また実家に旅立ちまする
-
- 152
- 2011/10/24(月) 01:10:27.49
-
>>149
それは、PDS-100G/GN ID 所持者さんにしか検証できませんね、
私の方は出てきたモノでしか判断できないレベルです。
機器持ってないし〜 検証するのにソフトも受け取ってないし〜 サイトからダウンロードとかできないし〜
ツール対応作成時に関わっている人の環境と情報に依存することになるので、
後からあ〜だこ〜だと来られても、「このフォーマットに合わせてくれたら良いだけですヨ」
と「作成時の人の環境が鉄板構成となる」ということです。
>>150
アルゴリズムというか、何キロ/ｈ以下はフィルターカットとか
どこまでを 有用／無用 を判別するか？ は、プロット作業する人の判断ロジックになりますし
（たしか>>144 さんはＧＰＳデータに旅レコフォーマットを使っているのかな？）
旅レコフォーマットの時点で [秒]と[ミリ秒]と[衛星ロスト] はフィルタリングされてることになります。
速度情報も km/h でパラメータ最終位置にいるので m-241 であれば １０km/h 以下を削除なりすれば
信号待ちなどで量産される多重の地点情報をカットできるのではないかと？
|
|ω･´)ﾉｼ
|
-
- 154
- sage
- 2011/10/27(木) 15:37:50.41
-
若松の改変を作ってる者です。随分と御無沙汰してしまい申し訳ありませんです。。
メモリーが大量に確保できたので、懸案の DMDRT も作り込みました。
NMEA ファイルの中に DMDRT が入っててもカシミールとか普通に読んでくれるので、とても便利ですね
$DMDRT,155,271011,61649.500,20,0.123,*75
$GPRMC,061649.499,〜
$GPGGA,061649.499,〜
$DMDRT,156,271011,61650.500,20,0.123,*7E
$GPRMC,061650.499,〜
$GPGGA,061650.499,〜
こんな風に順番で落とそうかなと思ってます。
(チェックサムの計算は合ってるはず・・・)
DMDRT 〜 * の 「*」の前のカンマはバグじゃなくて、地上高は不明という意味で値を出してません。
その他に、累積カウント数とか出しておくと、移動平均化処理(μSV/hへの換算)をガイガー任せでなくて
PC側で、自由な平均か時間で切り出せて便利だと思うので是非とも出したいです。
「PCでμSV換算」という観点で言うと、若松のは cpm→μSV/h への計算係数が取得できるので
それも一緒に吐き出しておくと、
[累積カウント数] [係数] [オフセット] の３つの値から PC側でμSV/h 計算ができるようになるかなぁ〜と。
あと将来的なパラメータとして、測定時の温度・湿度・風向・風力・日照強度 とか
そーいう環境条件を入れる枠(仕様)だけ作っておくと、とても良い感じに思えました。
DMDRT の後ろを伸ばすか、別のセンテンスを付けるべきか悩むところですが。
以上、取り急ぎ書きたいことだけ書き連ねました。
-
- 155
- 地震雷火事名無し
- 2011/10/27(木) 15:43:27.15
-
sage間違えました・・
上の、よく見たら時刻が GPS から取得したまんまじゃなくて
勝手に変なとこで丸められちゃってますねぇ。
float で取ったものを、そのまま吐き出してるのに・・・
これは GPS 時計と一緒のものが出るように直します。
-
- 156
- ( ´･ω･)
- 2011/10/29(土) 01:20:27.99
-
>>154
現行のDMDRTですが、実の所手持ちの機材(DoseRAE2とTGS-111)で記録するに足る情報を
フォーマット化した様な物なので、その時点では将来的にどうする…って言う"含み"は持たされて
いなかったです。
実の所実現するかはさておいて、拙作GRにてパルスを受け取って…ってのを考え始めている所なので、
この辺りのパラメータ(累積カウント数とオフセット)をサポートするのは私的には問題ないんですが…どうでしょうね。
その他の環境パラメータ類はどちらかと言うとモニタリングポスト的な使い方に供するパラメータの様な
気がするので、別なセンテンスにしてもいいかなとも思います。
大佐殿のご意見も伺いたい所ですが。
-
- 157
- 2011/10/29(土) 04:28:52.11
-
>>154-156 はい、呼ばれました
こちらは
DMDRT で、現状の * のいる７番目までしか使っていないので
00) $DMDRT ：固定
01) 入力番号 ：0 〜 ｛ 入力用番号
02) 世界標準時 ：yyyyMMdd ｛ ８桁 西暦年 月 日
03) 世界標準時 ：HHmmss.fff ｛ 日本時JST を計算元に使用する場合 UTC = JST - 9:00 // JST = UTC + 9:00
04) 計測μSv/h ：(浮動小数点)
05) 計測cpm ：(整数 {浮動小数点 可で対処)
06) 係数 ：(浮動小数点) ｛ ○ 「変換係数」掛け率
07) 測定高さ ：単位 cm ｛
08) *チェックサム
09) [CR] ：0x0A
10) [LF] ：0x0D
$DMDRT,155,271011,61649.500,20,0.123,100,〜,〜,*cs と増えていくものには影響を受けませんですよ。
（個人的には最終位置のパラメータとチェックサムの * はセミカンマで分かれていると分離が楽カナ）
機器温度・周辺温度・ＣＰＳなどなど新センテンスを設けるのも別段、影響をうけません。
電子方位計に関しては、NMEA にもセンテンスが存在しますので、方位センサーを繋ぐ場合はそういった既存のものを使う手もあります。
GPHDG かな？ p.11
DescriptionNMEA.pdf
http://www.tronico.fi/OH6NT/docs/NMEA0183.pdf
あと、ガチャコンのテキストに各機器のログフォーマットを書いている通りなので
メーカー機器によってどういったデータがあるのか事前に考えておけるかと
（自作機が進化した時に備えて、・・別スレではスペクトル系の自作スレがあったりします）
>>154
>>56-58 な感じで酉を付けられてWeb などに書かれておかれたりすると、
２ｃｈでも配布したり、話したりする時に皆さんが安心して加われるかと
〜な者ですとか注釈も省けて楽ですよ。
-
- 158
- 154
- 2011/10/29(土) 08:25:18.02
-
>>156
実は若松ガイガーの場合、平均化させる時間を自由に指定できてしまうんですよ。
たとえば、「10分間の平均で cpm を求める」の「10分」のところを「5分」に
変えれたりする仕組みが備わってるんです。(公式ファームのときから)
たとえば「10分平均」の設定で、移動しながら測定したとき、
ある地点の線量というのは、その地点のピンポイントな線量というより
それまでの10分走行分(時速60キロのときは10キロ分)の平均値ということなので、
そういう前提のログファイルをパソコンが取り込むにあたり、
取込側のソフトを、より賢くしていこうとしたとき、
「過去どんだけ分の平均値なのか」という点を加味できる余地が必要かな、と感じる次第です。
そこら辺の細い動きをどう表現するかは取込側のソフトの仕事なんで私はノータッチの予定ですけど
ログファイルを落とす側としては、そういう用途に耐えうる情報を予め落としておく責任があるかな〜と
-
- 159
- 154
- 2011/10/29(土) 08:36:23.33
-
>>157
センテンスを分けることも含めて考えると
μSV/hへの変換係数は測定値というよりパラメータって風なので
DMDRT に入れるのは馴染まない気もしてきました。。
てことで累積カウント数だけ DMDRT の中に入れさせて貰うことにして
・平均化秒数(DMDRTのcpm項目を求めるにあたり何秒間で平均とったか)
・変換係数(cpm→μSV/hにするときの、cpmから割る値)
・オフセット(μSV/hへの下駄)
とかの測定条件系(毎回出力する必要もなさそうなもの)を
別センテンスで落とす、でいいですか？
Condition の C で、DMDRC とかどうですか？？
(DMDRCの具体案は、ちょっと考えてまた書き込もうと思います)
温度とか湿度も別センテンスがいいですね。
NMEA が、こんな応用性に富む規格とは思ってませんでした、すばらしい。
-
- 160
- 154
- 2011/10/29(土) 08:45:44.61
-
連続すみません。
DMDRT に落としたい「累積カウント数」ですが、なんでこれに拘ってるかと言いますと
たとえば(意図せず)10分平均の設定で作ってしまったログファイルを用いて
パソコンの取込側の工夫で「30秒平均の値」で再計算させる余地を確保しておきたいからです。
30秒分の DMDRT 行を抜き出してきて
その期間の最初と最後の累積カウント数の差を求めれば、「30秒分のカウント数」が出て
「30秒分のカウント数」×2 にしたら、その「30秒間のcpm数」が求まります。
そのcpm数に換算係数とオフセットを加味して「30秒間のμSV/h値」が出ます。
ここまだ拘るのは、若松ガイガーはスイッチがなくて
パソコンがないと途中で(気がついたときに)設定変更ができないからなんですよ。
「あ、10分平均のままだったー」とか
-
- 161
- 2011/10/29(土) 11:57:52.39
-
>>160 連投ジャンジャンＯＫｗ
若松ガイガーで先に１つ聞いておきたかった事があったのを忘れていました。
某スレ
【ガイガー】放射線計測器の自作 10CPM【PDシンチ】
http://kamome.2ch.net/test/read.cgi/denki/1317136019/
か、その前スレだかで
若松ガイガーの作者基公開ファームは カウントｘ係数＝μSv/h
若松ガイガー販売、 若松ファームは (カウント−ＢＧ)ｘ係数＝μSv/h
とか？
DMDRT での係数の所もなんとかしておかないといけないのかな？ と
今、他人様のソースをじっくりねっとりたっぷりと眺め廻す余裕が無いので確認できません。
たぶん「オフセット」との語句が、私の言うバックグラウンド数の事を指しておられると私は思うのですが。
（認識の齟齬埋めに書きました）
-
- 162
- 2011/10/29(土) 12:07:54.38
-
累積関連データに関してですが、例えば
１．DMDRT ＋拡張 計算に使ったカウント数 、計算に使った時間（秒）
２．新センテンス（総累積カウント 、総時間）
という感じにしてみる案はどうですか？（カウントの前後は一例）
出力時刻を同じにしておくと紐付けも容易かと
これでいくと必要範囲分の加算だけで済むかと。（除算が必要なくなる）
チェックサム確認する場合（私はしていないｗ）の比較用抜き出しも
最終位置確認は * があるか？で判断できますし
セミカンマでデリミッター（区切）って最初の１バイトをずらすだけで可能なのでは？
>平均化させる時間を自由に指定できてしまうんですよ。
もともとがモニタリング用として販売されていますから、１０分とかユーザー設定でも固定なのでしょう。
過去にカメコさんが書いていた内容と、Polimaster スレの話しで
PM1703M 系のすばやい線量変化対応と低線量下での誤差収束について
急激な線量上昇が検知されるとそれまでの平均を破棄、CPS など短時間計算に移行。
線量変動が落ち着くと長時間累積計算に移行していき誤差を減らしている・・感じ らしいです。
こういったアルゴリズムをうまく構築して可変型にできれば、
線量変化への追随が速くなる可能性を秘めています。
同時に線量変化の緩やかなモニタリングポストにも向くかと。
ログ出力も線量変化が無ければ次出力をスルーなどでもすると容量を減らせる可能性もあります。
-
- 163
- 2011/10/29(土) 12:54:17.41
-
>>159
連投ｗ 書き忘れ
>μSV/hへの変換係数は測定値というよりパラメータって風なので
パラメータです。
（たしか）これを入れるお願いをしたのは、１センサー＝１機器 ではなく
多センサー＆オール通信(ログ) を想定している布石です。
カウンタに使われている
01) 入力番号 ：0 〜 ｛ 入力用番号
と言わばペア状態で使う想定です。
例 ) 若松と仮定
１管−mbed− $DMDRT −> アプリ ← 現状
１管 ┐ ←可能かどうかの是非は棚上げ
１管 ┴ mbed− $DMDRT −> アプリ
１管−mbed − $DMDRT ┐
１管−mbed − $DMDRT ┼−> アプリ
１管−mbed − $DMDRT ┤
１管−mbed − $DMDRT ┘
要は仕様のバラバラな管や、多人数の別機器の混在対処用ですね。
-
- 164
- 地震雷火事名無し
- 2011/10/29(土) 13:46:02.68
-
>>161
>若松ガイガーの作者基公開ファームは カウントｘ係数＝μSv/h
>若松ガイガー販売、 若松ファームは (カウント−ＢＧ)ｘ係数＝μSv/h
そこら辺はパラメータファイルになってて、パソコン繋いでメモ帳で書き換えれるようになってます。
ちなみに作者さんが公開してたパラメータの間違いだったようで今は一緒になってます。
プログラム的には
μSV/h ＝カウント×係数＋オフセットになってます。
SBM-20のとき、
係数＝129.032
オフセット＝-0.032
が初期値でして、
μSV/h ＝cpm × 129.032 - 0.032
で求めてます。
２点キャリブさせた結果を登録しとくと、
それに応じて係数とオフセットが自動計算される仕組みです。(元々の仕様)
複数管も想定されているんですか。
ぱっと読んだだけで理解しきれていないので、また改めて返事かきますね
(これから泊まりがけで出かけるので明日かあさってになるかもしれませんが)
-
- 165
- 地震雷火事名無し
- 2011/10/29(土) 13:47:34.38
-
間違いでした
誤） μSV/h ＝カウント×係数＋オフセット
正） μSV/h ＝カウント÷係数＋オフセット
誤) μSV/h ＝cpm × 129.032 - 0.032
正) μSV/h ＝cpm ÷ 129.032 - 0.032
-
- 166
- 2011/10/29(土) 18:53:53.81
-
>複数管も想定されているんですか。
ストロベリーリナの方でCPM だけだったり、管を変えたり・・
Arduino 持ちさんの方で管を複数付けられるね〜 と言う話しが出たけどプログラムが組めなくて断念されたとか・・
複数接続したいとか・・ （幾つか作ってみたものの動作不良だったとかで断念されたとか・・）
・・・いろいろありまして
メモリー容量の制約でファームが複雑化できないなどの対処用
あとは、製作更新をβ版で中断しているマッパー用も含めてです。
複数の機器からデータが入力されて混ざったログが溜まると、
データの出所や最低限のパラメータが無いと、その後がムチャクチャになって分別できなくなるな・・・というところです。
若松の場合でも、管の種類を変えられる仕様だったと記憶していますので、
１人で複数所持してログを溜め込んだ場合、対応ツールで振り分けたり再計算させたりするには最低限何がいるか？
となります。
オフセットの件は理解しました。
μSV/h ＝カウント×係数 で進めたからなぁ・・・どうやるとうまく納まるやら・・・
-
- 167
- 地震雷火事名無し
- 2011/10/29(土) 21:45:26.59
-
センテンスが増えすぎると、使う側はアプリの設定画面で自分の環境がどのセンテンスが適切なのか？と言う疑問(壁)にぶちあたります
そもそもセンテンスってなんですか？と言うユーザーさんは作り手さんの意図全に反して判断が難しく、このプロジェクトに取り付く事ができません
適応機器を持ってない方には誠に申し訳有りませんが、その辺( ´･ω･) ◆CGOTBmWdi2 さんのGRのはよく考えられているとおもいます
-
- 168
- 2011/10/30(日) 05:38:47.26
-
>>167
そもそもこういったセンテンスは、使う人（エンドユーザー）は、深く考えなくて良いようにするための
各 製作者達が悩む方です。
〜機種対応 とかでみて「あぁ使えるんだな」程度にもっていくのに裏方が苦労する領分・・・ｗ
-
- 169
- 2011/10/30(日) 05:44:16.27
-
>>( ´･ω･) ◆CGOTBmWdi2 (福島県)さん 地震雷火事名無し(新疆ウイグル自治区)さん
>>77 から出た「栞「しおり」機能」について〜 >>90 まででまとまった内容。
DMDRT 準拠 フォーマットの方はとりあえずの「しおり」にパラメータ無しでおちついてます。
しおり：$DMDRT,*43
で
今後の汎用性を>>86 に提案してみています。
>例えば、$DMDRT,入力番号,世界標準時〜
>$DMDRT の２番目にくる「入力番号」に判別文字列でのパラメータ切り替えでも対処しやすいかもしれないです。
これまでのオーソドックスな $DMDRT はあまり弄らず
$DMDRT,〜通常〜
$DMDRT,判別文字列,上の通常と同じ群体を示す,〜判別文字列で規定したおニューのパラメータ〜
この方法で行くと
例 ）
$DMDRT,155,271011,61649.500,20,0.123,*75
$DMDRT,MARK2,155,〜判別文字列で規定したおニューのパラメータ〜,*cs
or
$DMDRT,MARK2_100,155,〜判別文字列で規定したおニューのパラメータ〜,*cs ← フォーマットバージョンも考慮例
で、紐付けできて
他の機種のツール作成者さんが参入されても別機種用固有のパラメータ打ち出しが可能になるかと。
「$DMDRT」で 放射線計測器関連でのデータと判別もできます。
対応形式以外はスルーするのが NMEA 形式の良いところ
( ´･ω･) ◆CGOTBmWdi2 (福島県)さんは、対応アプリの方はいかがですか？
数字かアルファベット込みの数値変換不能文字列か？ の判別コードを挟むだけで・・・というか
パラメータ無しの「しおり」と同様なすっ飛ばし（無視）処理にさせれば既存の物に影響を受けないかと
出力されたデータの アプリ/ツール 製作の表明って、まだ
私と( ´･ω･) ◆CGOTBmWdi2 (福島県)さん だけだったような気が
他の、このスレ見て作っている方がおられれば降臨してほしいナ
-
- 170
- ( ´･ω･)
- 2011/10/30(日) 23:20:04.27
-
なんか帰って来たら書き込みが伸びてた…
すみません、明日までに引っ越ししないといけないもので、なかなか反応出来ません。。
取り急ぎで申し訳ないですが
>>169
栞機能は次バージョンに組み込み済みです。
あと、"*"の前に","を入れるのも問題ありません。
今後の汎用性については、2番目の汎用文字列にて対応でもOKです。
それともNMEA0183みたいに
$GP*** ならGPS関連のセンテンス…と言う風に
$DM*** なら線量計(DosiMeter)関連のセンテンス…でも。
以下、一例です。
$DMDRT → DosiMeterDoseRaTe：主に線量計からの出力データ
$DMENV → DosiMeterENVironment：測定環境(気温・湿度・風向・降雨量・天候など…)
$DMCON → DosiMeterCONdition：パラメータなど(154さんの案をちょっと改名しました。)
とにかく、利用側や加工側が解りやすく扱いやすければOKと言うスタンスです。
-
- 171
- 2011/10/31(月) 04:56:39.77
-
>>170
はい、私もその２案での方向性で問題ありません。
新センテンス作成時は、１機種だけに捕らわれず汎用性が利くように策定できれば良いと思います。
MARK2 改造さん のご意見を待ちます。
寒くなってきてますから風邪などもお気をつけて。
-
- 172
- 地震雷火事名無し
- 2011/10/31(月) 13:57:40.35
-
質問です
ガーミンのサイコンを使用しています
GPXファイルの書き出ししかできないです。
GPAファイルをNMEAファイルに変換する方法ありますか？
-
- 173
- 地震雷火事名無し
- 2011/10/31(月) 13:58:21.83
-
訂正
GPA→GPX
-
- 174
- Mark2改
- 2011/10/31(月) 14:21:25.22
-
たぶん「累積カウント数」などという内部数値を取得できるのは、若松ほか自作ガイガー系だけですよね、きっと
そうなると、全体から見たらちょっと亜流になるんで、$DMDRT には入れないほうがいいかもしれませんね。
私が口出しする前の $DMDRT 仕様で１点だけ気にかかったのが
「cpm や μSV/h という数値が、何秒間の測定によって得られたのか？」という点が不明なところ。
市販のガイガーでも30秒とか60秒とか、色々と差違がありそうな気がしてまして
最終的に汚染地図をプロットするにあたり、何秒前から測定した分の平均値なのか？ってのは、割と重要な気がしました。
特に若松や自作ガイガーの場合は、使用者が自由に定義できる余地があるんで・・・
グダグタと書いててもアレなんで私案かきます。
■ $DMDRT の最後(地上高の次)に、「cpmやμSV/hを求めるにあたって使用した平均化秒数」のみ追加
省略時は未定義(不明)として扱い、具体的な取り扱いは取込側のソフトに一任
この項目は「分」じゃなくて「秒」がいいです。
■ 累積カウント数や換算パラメータなどの市販ガイガーにない自作系特有の情報は $DMDRT じゃなくて別センテンスに出す
汎用的な地図プロットソフトは $DMDRT だけを見て作図したらいいように
でどうでしょうか？
-
- 175
- Mark2改
- 2011/10/31(月) 14:36:15.99
-
つまりは、>>154 で書いたパターンで例を書きますと
$DMDRT,155,271011,61649.500,20,0.123,,60*cs
$GPRMC,061649.499,〜
$GPGGA,061649.499,〜
$DMDRT,156,271011,61650.500,20,0.123,,60*cs
$GPRMC,061650.499,〜
$GPGGA,061650.499,〜
と。(*csの前が平均化処理の秒数)
ほとんどの機種の場合は、「60」か「30」だと思いますけど。
この「平均化処理の秒数」をプロット結果に反映するかどうかは取込側のソフトの嗜好に任せる、と。
現地点の位置と線量を用いてGoogleMapに線量のピンを打つもよし、
「平均化処理の秒数＝60秒」だったら、60秒前の位置を探し出して現在地との中間地点に線量をピンを打つもよし
-
- 176
- Mark2改
- 2011/10/31(月) 14:58:41.21
-
いや待てよ
最初の仕様にあった $DMDRT の中の cpm って、それ単独ではあまり意味がないですよね
市販ガイガーを含めて色んな機種(管)が $DMDRT を吐き始めると、ますます意味のない数値に。
とはいえ、cpm とて測定値なんだから $DMDRT の中にあっても不思議じゃないし
わざわざ cpm のために別センテンスを作るのも非効率的
その流れで言ったら、累積カウント数(出力できない機種もあるけど)が
$DMDRT の中にあっても不自然ではない。
cpm と一緒で管の種類に依存したカウント値なんだから。
てことで、
$DMDRT,[連番],[GPS日付],[GPS時刻],[cpm],[μSV/h],[地上高],<平均化秒数>,<累積カウント数>*cs
[] は当初の仕様からある分、<> が追加分
それぞれ取得できない(値を落とせない)場合は空文字で(カンマ残して)詰める
じゃダメでしょうか？ とりあえず複数管は無視してますけど。
自作系で cpm→μSV/h の換算係数が明らかになってる管を使ってる場合は
$DMCON の中にそれらパラメータを書き出す
(これは普通は時間に応じて変動しないので、毎回落とす必要はない)
「平均化秒数」は、市販ガイガーでも自作ガイガーでも共通して「あればあったら多分つかえる項目」で
「累積カウント数」は、自作ガイガーのときにのみ「あれば使えるかもしれない項目」という位置づけですけど
市販ガイガーには「余計な項目」になりますが「累積カウント数」だけで別センテンスを落とすのは勿体ないので
$DMDRT の中に居候させていただく、と。
-
- 177
- 2011/10/31(月) 17:16:15.40
-
>>174
>「cpm や μSV/h という数値が、何秒間の測定によって得られたのか？」という点が不明なところ。
はっきり言い切って「そんなもん自作機作者かメーカー技術者しか判りませんｗ」いやマジで
( ´･ω･) ◆CGOTBmWdi2 さんや、DoseRAE2 ◆/BLnkBtCx6 さんの使う DoseRAE2 はメーカー製で
計算された値（μSv/h ）だけがシリアル接続でダラダラ流れてきます。
カメコさんのPM1703MB の通信ログを読んでも計算に使われた秒間のデータは乗っていなさそうですね。
その辺はメーカーのアルゴリズム系技術秘になってくるからおいそれと垂れ流しはしないでしょう。
もともとがマップに落とし込むのに最低限これだけは欲しいナと、
最初、DoseRAE2 用の 時間 μSv/h だけ（$DMDRT,YYYYMMDD,xxxx…）だった？のを
識別 CPM と（μSv/h）に（後で変換できるように変換係数の位置）高さをお願いしたんだったっけカナ？
前スレ>488 で現状になってます。
係数の所は・・ノーマル状態で CPM x 係数
/係数-Offset ← Mark2 タイプ
-BGx係数
という感じカナと考えてますがいかが？
-
- 178
- 2011/10/31(月) 17:21:56.31
-
>>176
>最初の仕様にあった $DMDRT の中の cpm って、それ単独ではあまり意味がないですよね
CPM が何故あるのか？ は、SE International,INC 系の（インスペクターなど）・苺リナ 問題があります。
あの系統のソフトなりのベースが CPM だからです。
α・β線のカウント値込みからのμSv/h 化は変になります。
同種の機器を同時使用した遮蔽有り無しでβ線カウントなどができる余地も入れています。
<平均化秒数> への異論はありませんが、<累積カウント数> はどうでしょう？
計算に使われた範囲分の<累積カウント数>なら私はかまわないかと、汎用性はありそうです。
ＳＷ-ＯＮからの総<累積カウント数>だと むむむ ちょっとなぁ という感じです。
どっちでしょう？
私の考え方の根底に、ベースデータは、その１センテンスデータで情報が成り立つか？ です。
$DMCON の方は、パラメータだけ書くと他機種さんが参入時（あるのかしらないけど）困るので
$DMCON の次にでも機種名（コード？）などを置くといった感じにされたらどうでしょう？
予約語というものです。
そうすれば、その機種コードに関しては Mark2改 さんのオレの天下！ になりますよね。
CS は最終パラメータの後ろにセミカンマ入れて単独化して欲しいと切に思っていたりします。
パラメータ数を可変化すると分離の手間が大変なのさぁ・・・
ＰＤを使ったパルスのみの低価格自作キットが発売になったようです。
放射線モニターきっと[RM-LM3900-KIT] http://www.aitendo.co.jp/product/3436
販売価格: 900円 (税込) か
・
・
まぁなんというか、放射線によるノイズを使う訳だから・・・もっと高感度な物が出たらセンサーとして繋ぐとか
-
- 179
- 2011/10/31(月) 17:27:57.94
-
>>172-173 GPX -> NMEA
使ったことが無いのでどういう風に操作するのかわかりませんが・・・
各種GPSデータを相互変換「GPSBabel」
http://www.moongift.jp/2008/07/gpsbabel/
GPSログコンバータ・編集ソフトの紹介
http://www11.atpages.jp/motolife/equipment/gps/soft.html
gpsbabel GPX の文字エンコーディングに注意
#9566 Re: カシミールGPX→NMEA-0183
http://www.kashmir3d.com/bbs/userboard/boardmsg.cgi?9566
GPSBabel日本語化
http://2nd.geocities.jp/hakidame_2nd/gpsbabel.html
というのが存在します。
-
- 180
- Mark2改
- 2011/10/31(月) 17:37:43.23
-
そうですか。
いやなに、ずーっと前にあった↓のデータファイル(NeutronRAE II)で
サンプリング秒数って項目があったので
それが平均化秒数のことかと錯覚してました。
Summary
------------------------------------------------------------
Unit Name NeutronRAE II
Unit SN 153-010393
Unit Firmware Ver V2.00
------------------------------------------------------------
Running Mode Safety Mode
Measure Type Real
Datalog Type Auto
Diagnostic Mode No
Stop Reason Event Full
------------------------------------------------------------
Begin 2011/07/17 07:35:01
End 2011/07/18 13:35:09
Sample Period(s) 30
Number of Records 3600
------------------------------------------------------------
Sample Period(s) ＝ データを落とす頻度 ≠ 平均化秒数
なんですね。
じゃ、市販機(平均化秒数が非公開になってるの)は、空文字で詰めてもらって
平均化秒数が明確になってる自作機系だけ、その秒数を $DMDRT の中で申告していただく、ってのは？
-
- 181
- Mark2改
- 2011/10/31(月) 17:50:08.96
-
>計算に使われた範囲分の<累積カウント数>なら私はかまわないかと、汎用性はありそうです。
>ＳＷ-ＯＮからの総<累積カウント数>だと むむむ ちょっとなぁ という感じです。
「計算に使われた範囲分の<累積カウント数>」だと通常は cpm と同値になるかと思うので
それであれば必要ないかなぁという気がします。
使えるシーンはかなりレアだとは思いますが
今のところ、若松(改)では手抜きしてて $GPRMC を受信したら
その前に $DMDRT を挿入して、ってやってます。よって間引きなしで1秒ごとに吐き出してます(笑)
感度のいい管を使われていることが前提になりますが、
累積カウント値と換算パラメータ(これは別センテンス)を出しておくことで
取込側のソフトの工夫次第で、「移動平均=10秒 で抜き出したμSV/h値」を利用することができるようになります。
また何らかの事情で数レコード欠落したところで、「累積カウント値」なら取込側で欠落分を補てんできるかな、と。
あとセミコロンですけど、個人的にはあってもなくてもどっちでもいいんですが、
「*」の前までがデータ領域と判断して、その中のカンマの数を数えると項目数が割り出せるので
特にセミコロンが必要な気がしないんですけど
(取込側の事情をよく分かってなくて書いてます、失礼があったらごめんなさい)
ぶっちゃけ、連番も取込時に(必要ならば)勝手に付番することにして
$DMDRTを出す側が付ける必要もない気もしなくもなく・・・
ただ連番も累積カウント値も、数年にわたりノンストップで運用されると
いつかどっかでオーバーフローしますよねぇ・・・
連番は「寿命が長い」けど、累積カウント値は早々に32ビット使い切りそうです(汗)
やっぱ止めといたほうが無難かなぁという気もしてきました。
-
- 182
- 2011/10/31(月) 18:00:07.50
-
>>180
NeutronRAE II は残念ながらリアル吐き出ししてきてくれないようです。
よってリアル接続そのものが成り立たないので意味をもちません。
RAE II などで出てこないかどうか試してもらいましたが無理だったようです。
あの系統の反応は１秒より反応が速い感じっぽいような話しですね。
なので
あくまでログ（最短１秒）と実挙動の表示（１秒以下？）に一致があるのかちょっとわかりません。
ログデータのパラメータだけで同列に見ない方がいいかと思います。
項目が増える事に関しては構わない旨、了承してます。
齟齬が発生しないように内容を詰めているだけです。
( ´･ω･) ◆CGOTBmWdi2 さんの降臨を待ちます。
肝心のアプリなどに通したらエラーで使えないという事態は避けたい。
-
- 183
- Mark2改
- 2011/10/31(月) 18:41:19.34
-
こちらもちょっと熱くなってすみませんでした。。
市販ガイガーも自作ガイガーも、どっちの基本的に
放射線のカウント数とその密度だけを頼りにしている点では一緒なのですが
市販ガイガーのほうはμSV/hへの換算の部分に各社のノウハウが注ぎ込まれているのに対し
自作ガイガーのほうはμSV/hへの換算は単純な割り算と引き算くらいの、素直というか何も装飾していないですね。
まぁ市販ガイガーの中にも自作ガイガーと全く同じものも多いですけれど(笑)
「(累積)カウント数」ってのはデジカメでいうところの RAW データで
「μSV/h」ってのはデジカメで言うところの JPEG に相当してて
市販ガイガーは「現像エンジン」の出来で競争してる、と思ってます。
市販ガイガーは RAW データ(生のカウント値) を出さない代わりに
各社各様の現像処理を施した JPEG データ(μSV/h値)が出てくるのに対し
自作ガイガーの JPEG 現像(μSV/hへの変換)は怪しい(信用しきれない)ので、
あくまで RAW データ(生のカウント値)が中心、と。
-
- 184
- 地震雷火事名無し
- 2011/11/01(火) 12:50:36.03
-
>>179 ありがとうございます。
早速ためしてみます
-
- 185
- ( ´･ω･)
- 2011/11/02(水) 00:08:13.36
-
はい、接続環境以外の環境は殆ど戻りました。
取り合えずは新居に移りましたが、全然片づかないorz
スクリーニングしなきゃいけない持ち出し品も山積みだったりとか。
家の中に放射線管理区域＆除染エリアを設置とか…なんでこんな羽目にorz
-
- 186
- 2011/11/02(水) 18:53:32.04
-
放射線計測マップ作成支援
ttp://www1.axfc.net/uploader/Sc/so/288948.zip&key=MustangENQ
PDS-100GN / PDS-100GN/ID 用 PdsMass ログをCSV 形式にします。
【 Manual Basic 手動入力 フォーマット 】csv 手動入力準拠
（通称：「ガチャコン」準拠です。）
ＧＰＳとのミックス前の編集や、表計算ソフトに取り込んで作業する為のコンバータです。
-
- 187
- 2011/11/02(水) 18:57:42.37
-
>>185
・・・大変・・・・ですね（としか返せないわ）
新居はフクイチから何キロほどになったのですか？
-
- 190
- 2011/11/03(木) 01:27:09.19
-
>>188
ベースを作るのに手間取っていたのでリリースが遅れていますが・・・
PDS-100GN の CSV 状態で実際にガチャコンで使うのはμSv/h の所までですが。
CPM は単純に cpsｘ60 です。
NeutronRAE/GammaRAE II R で苦しみそうです。
テキストデータ形式が２種類と、μSv/h μR/h の２種類に、セミカンマとタブの２種類・・・
CSV 一本化できれば後は、ログスプリッターをもう少し進化させれば単純な処理が出来ると思います。
１つおき〜１０飛ばし？ 検出値の下限上限でリミッターなど
GPS の方では指定速度以下＆速度超過は間引くなど出来れば、余分な量を減らせると・・・思います。
ちょっと、先の話になりそうですが。
-
- 191
- 2011/11/03(木) 02:29:15.12
-
>>189
・係数の所は・・ノーマル状態で CPM x 係数
/係数-Offset ← Mark2 タイプ CPM / 係数-Offset = μSv/h
-BGx係数 (CPM - BG)*係数 = μSv/h
という感じで記号込みの要素（素案）を考えてみてます。
*じゃなく半角x（エックス）を置いているのはアスタリスクのある位置をcs と誤認しないようにです。
DoseRAE2 では関係無い部分ですが、もう１個の方を繋がれるようになると関係してくるかも知れない部分でもあるので。
記号文字に準じた文字列が来てもエラーにならないようにしていただけたらと・・
何か良い方法があれば良いのですが、現状のガチャコンなどでは数値変換不能は飛ばすハズ・・たぶんｗ。
・cs のある位置のアスタリスクの前のパラメータとはセミカンマで分離してほしいという部分。
・累積カウント数の扱いです。 固定長期間の稼動だとInt 型でも範囲を超えるでしょうし、64bit など倍精度は避けたいカナ。
総累積時間（秒）に関しては、別センテンスで稼動開始日時(Date Time)込みパラメータを吐き出させれば、
$DMCON,機器名,稼動開始日時〜 とか、
個別のデータに載ってくる日時(Date Time)とでTime 型に放り込んでやれば差分は出せる逃げが効きますね。
その辺は新センテンスで機器名付ける作者さん次第でどうとでも出来る領分なので。
動的作業：$DMDRTの付けたしは、計算用の実カウントと実時間（秒）ならまずInt 型で足りる。エラー回避。
静的作業：累積カウント数は、ログ状態の時に頭から足していけば良い。加算による範囲オーバー判断はツール次第。
累積時間は上記のTime 型差分計算で出せる（単純に加算でも）。
という感じで考慮してみました。
累積の方はこれでエラー系の対処は可能だと思うのだけど
-
- 192
- 2011/11/03(木) 02:50:06.75
-
・累積カウント数の扱い部分の記述で・・・ちと保留化
動的作業：$DMDRTの付けたしは、計算用の実カウントと実時間（秒）
・・・というのも、計算に使うアルゴリズム次第で実カウントとして累積計算には使えないですね・・・
前回出力した時を０リセットとした累積量と置き換えてみます。
でもそうなると、累積量と計算用カウントと計算用実時間（秒）の３つが要る？
-
- 193
- Mark2改
- 2011/11/04(金) 20:07:33.04
-
自分で要望だした分はスルーして、とりあえず当初の規格に忠実に作ったつもりでしたが・・・
$DMDRT でバグ出しちゃいました。
UTC日付
当初） 西暦4桁＋月＋日
私の） 日＋月＋年２桁 ←$GPRMC の9個目を、そのまま出しちゃいました
cpmとμSV/h
当初） μSV/h,cpm
私の） cpm,μSV/h ←汎用ファイルのほうの順番にしちゃいました
まだ使ってる人は少ないと思うし
「仮実装」「仕様変更の可能性アリ」と大々的に書いたので、
次でコッソリ（告知はしますけど）修正かけようと思います。すみません。
-
- 194
- Mark2改
- 2011/11/04(金) 20:17:57.68
-
>>192
累積時間（秒）と累積カウント数と、２つだけで概ね何でも出来ると思ってるんですが
>>192
累積時間（秒）と累積カウント数と、２つだけで概ね何でも出来ると思ってるんですが
累積時間 累積カウント
000 000
060 019
120 034
180 054
240 070
300 083
360 104
420 123
こんなに並んでたとして
060 019
と
360 104
の２つを切り出して、
（104-19）÷（360-60）×60＝17 ←60秒目〜360秒目の5分平均のcpm値
という当初に想定してなかった「5分平均のcpm値」が割り出せます。
5分平均のμSV/h値 ＝ 17 ÷ [係数] ± [オフセット]
と。「○分平均」を自由に切り出すという発想は、携帯ガイガーでは馴染みたい値かと思いますが、
モニタリングポスト（定置測定）の場合は生の測定値をもとにして
「60分平均」「4時間平均」「24時間平均」とか、そーいういうにデータを再加工するのに便利なんです。
-
- 195
- Mark2改
- 2011/11/04(金) 20:19:36.65
-
誤字訂正
× 携帯ガイガーでは馴染みたい値かと思いますが
○ 携帯ガイガーでは馴染みない値かと思いますが
このページを共有する
おすすめワード