【ガイガー】汚染地図作成手法確立プロジェクト２

汚染地図に関しては、既に科学者の方々が自主的に取り組んでおられますが、
今回の原発災害に向けてだけでなく、政府をあてにせず、いざという時に有志で
迅速に放射能汚染地図を作り、子供たちを守る為の手助けをしたい、そのための
「手法を確立する」プロジェクトです。

・汚染地図作成の為の手法の確立
・必要とされるプログラムの政策
・公開手法などの検討
・利用できる機材などの検討

などを行って参りたいと思います。

ある程度のものが確立した段階で、一度有志参加で災害に立ち向かっている方に
迷惑がかからない範囲で、現場テストと訓練をできたらナーと思います。

・機材購入レビューの人柱
・車込みで現場に行ってもいいという人
・プログラムの面からサポートしてもいいよという方々

などの合流を求めます。

既に汚染地図作成のプロジェクトも存在しますが、検討段階では色んな
アプローチがあって良いと思うので、特に「逸脱して全然合流できない方向」
に言ってしまわない限りは、２ちゃんねる有志の活動としてめとめまで頑張りましょう。

手伝ってね、みなさん。

前スレ：【ガイガー】汚染地図作成手法確立プロジェクト１
http://hato.2ch.net/test/read.cgi/lifeline/1307247719/

>>100-101
ω･´)ﾉｼ カラー設定の意味了解です。　出来る範囲でやってみます。

質問：PdsMass　ソフトのバージョンは 1.00 とかで良いんでしょうか？
添付テキストに書いておくだけですが、メーカーver UP でもしフォーマット変わった場合の使用者混乱防止に。

>>102　大佐殿　遅くなりました

今回私が使っているのはVer2.1.0.0です。仕様が変わらなければソフトのverはログの
1行目の記述で良いかと
>MGP Instruments;PdsMass (2.1.0.0)

ニュースは世田谷の弦巻の空間線量率と横浜のストロンチウム検出で混乱しています
世間の関心も内部被曝に移っていますが、外部・内部に関わらず大佐殿がガチャコン
のreadmeに当初から書かれている下記のことの示唆が今更ながら重要であることに気
づかされます
>政府が全くアテにならない現在、有志による実測が非常に急がれます。
>それぞれの方の得意分野を僅かづつでも結集すれば大きな力となると思います。
>ささいなことから行動しましょう。

これからも無理なさらずに

>>103 素朴な質問です。
データの日付で
　10/10/2011-13:48:46;38;0.13;;0;0.4;;26;;
　10/10/2011-13:48:47;39;0.12;;0;0.4;;26;;

　月/日/年-　ですよね？英語圏のソフトだし。。。　違ったら書き込んでおいてください。
　10月10日だから・・・アレ？どっちだ？　と
　「月/日/年-」で進めてます。

>>96

>了解だ〜！　任意のキーを設定できる方が自由度が大きいカナ。
あんまりそうではなし、でっかいくて押しやすいのはEnterとSpaceくらいだけれどEnterキーは特別な意味を持つのでSpaceキーを選択しました

>>106 現在動作確認中＆バグ探し中です。

ガチャコン ver.0.16　今日中にＵＰできそうです。
PDS-100GN / PDS-100GN/ID 対応
アイコン色範囲の任意設定可変型モード搭載
（統合会見ウォッチしてるので終わってから数時間後かな・・）

>>106
余裕があればポートモニターで PdsMass の通信ログを採られると
なんらかのツールが作れるかもしれません。

>>111
ほい
ttp://www.shoshin.co.jp/c/digi/portmon/index.html

携帯電話にガイガーカウンター機能とGPS機能の装着を義務付けて
強制的にデータを吸い上げれば
かなり制度の高いマップが出来上がるんだろうが。

GPSとガイガーをパッケージしたものを大量に配布するんでもいいや。

景気回復にも効果ありそうなんだけど、民主党はやんねぇだろうなぁ。

>>113
義務付けは、また「管理される〜」とかプロ市民が湧くと思うな
それと http://www.synnex.co.jp/news/new-products/scosche-00001.html
納入遅延しているそうだし、コレ情報をＵＰすると世界中にバレるんだよな
高い線量の所測る人多いだろうし
ホットスポット側溝の線量をＵＰして、それがさもその都市の汚染のように受け取られる可能性があると思う。

昨日の統合会見でも日暮氏が発言 >>108 していたけど、
「住民関与での線量マップの作成などを勧告している。」で安全委がすっげー嫌そうな顔してる。

東京のホットスポット問題でもっとやるべきって話にも
福島県からじょじょに　という返答。
もう何ヶ月経ったと・・・恐らく多くのホットスポットがまだまだ発見もされずに被曝しつづけてると思う。

大量に配布してもその費用は税金だし、特定企業しか利潤に預かれないと・・・
・・・でエステーのエアカウンターで6000台行政が押さえてるような話が出てる
しかも監修が御用・・・・悪い予想しかできないです。

海外からの援助線量計の行方が追えない・乾電池を政府がガメてたという同じ轍を踏まないようにして欲しい訳だが・・・

>>111

DL先が

>>111

書き込み途中でおしちゃった、失礼

DL先が変更になってます
http://technet.microsoft.com/ja-jp/sysinternals/bb896644

です

>>111
　↓　のリンク先からポートモニターを入手してインストールします。
>>116 誘導ドモドモ
　Portmon for Windows
　Windows NT/2000/XP

使い方（解説しているサイトを見つけましたのでこういう感じで）
http://www.shoshin.co.jp/c/digi/portmon/index.html

�@ PDS-100GN - PdsMass の通信ログをポートモニターでとります。
�A PdsMass のログも保存します。
�B PdsMass で行った操作を操作順に書き出します。

まとめてＵＰします。
�@は、PdsMass を起動させたあたりからプログラム終了まで採ります。
　今回の場合ですと、
１．PdsMass を起動、ロギング開始
２．PDS-100GN と接続、線量の受け取りスタート
３、PDS-100GN との接続解除
４、PdsMass ログセーブ
５、PdsMass 終了、Portmon ログセーブ

という流れです。
うまくいけば、ｍｓの速度変更操作などを途中に入れるなどです。
様は、PDS-100GN から流れてくる線量データのフォーマットが解ればリアルタイムマップだとかが出来ちゃいますねと

>>113

一般人に測らせたとしても精度や信頼性のないデータが貯まるだけで終わってしまうってのを
恐れてるんだと思いますね。

例えば、地上1cmなのか1mなのか、車や建物の中なのか、あるいは検出器むき出しなのかの条件もあるし
検出器の種類や特性等も効いて来る。ここらへんをきちんと管理しないと同じマップにプロットする事すら出来ません。
一般の人たちにそこらへんを気にしながら常時測定し続けるようにしてもらうのが非常に難しいと思いますね。

一般の人たちが測定条件を気にしなくてもよい測定方法が確立出来ない限り実現は難しいでしょう。

>>118
一般の人たちが測定条件を気にして通常計測できる様にしむけばいいんじゃないかなあ

ガチャコンで対応済みフォーマットの機種を順次、
単体ごとのガチャコン汎用ＣＳＶへのコンバートの補助プログラムを作り始めてます。

そうすればログスプリッターで分割させやすいし、
表計算ソフトでも扱いやすくなるだろうから（需要があるかは知らないけども）

>>120

それが徹底出来ないところに問題があるわけで。

信用して良いのか判らないデータが大量に集まっても、それをどう使うのか？って話になる。
例えば、1/3くらいはいい加減な測定のデータと思われるが、どれがいい加減かは人間が吟味しないと判らない、では
その吟味のための人員で測定して回った方がずっと効率が良いわけだし。
吟味して判るならまだしも、線量と位置情報だけ送ってくる程度じゃ吟味しようがないからね。

やっぱり、手元にある機械が個々の測定条件のばらつきを自動補正出来るのでもない限り難しいよ。

単体・固有の雑多なプロットというのは混乱初期には有用になるし、早期の疑い箇所警戒には使えるかと。

混乱期を脱しえば機種ごとや計測条件で統一したデータが有用になりますし
時期と捉え方ですよねぇ　としみじみ

機種特性も鑑みて、学区レベルや市町村レベルで同タイプごとのグループによるサーベイマップをやってけば
その地区で有用に〜（ry

>>122
このスレって
まぁそういう個々のも含めてより良い方法と手段を模索する為でもあるしネ
東京・横浜のホットスポット（今更）でそういう市民によるシラミツブシ・サーベイの重要性は増すかと
航空機モニタリングでなんて細かい所なんてわかりゃーしねーさ　あんな雑なの

>>123

関心のある連中が自分で調べる事自体を否定してるわけじゃない。
測定法や線量についての知識や関心の低い一般人を安易に使うことを問題としているだけ。
決められた手順をしっかり守って測定出来るか？と言われると、実は関心がある人や専門家だって意外と難しい。

だから、

> 携帯電話にガイガーカウンター機能とGPS機能の装着を義務付けて
> 強制的にデータを吸い上げれば

というのなら、どうやってその仕組みで同一条件のデータを吸い上げられるようにするかまでを
考えた上で提案した方が良いのではと。

シラミつぶしを効率よく進めるためにも、測定条件の統一が余計に必要になって来る。

>>124
まぁ　疑問・問題提議の１つとして受け止めて懸案しておく１例で良いんじゃないですかね？
学校関係で国（文科省）は児童に積算バッチ配って調査やったりしてるし・・・アレは言わば強制の部類。

行き当たりばったりを思いつきをやるのが今の政権なので（ちょっとマシになったか？）
そういった事をやられる前に考えておくのも別の手段が浮かぶヒントになったりするかも？しれませんよ。

>>119 (`･ω･´)ﾉｼ 大佐殿

なんかスペースでしおりってくれません
要設定ですか？確認してみてください

>>111

>>117 の説明�@の作業前にPortmon for Windowsを動かしとかないとログが取れないです

>>126 指摘サンクスです！

原因が判りました！　申し訳ないです。
TLOG_R01 0x14 ■　Alpha□
の■を弄って 0x20 にしてもらえますか？
[↑]
[↓]

当初１０進数表記で32にしてたのを１６進数の２０に変えた際
設定が無い初期状態でのデフォルト値が２０（１０進数）で0ｘ１４ （16進数にして表示）にしてしまってました。
一度設定して終了させると設定保存されるのでしばしの間、それで。

今、別のことやってるので近々更新します。
他に何か気がついた事があれば指摘お願いします。あれば、まとめてやるようにしますので。

>> 128
了解でーす

遠征は月いちくらいしか行けないので問題ないです
ちなみにRAE2_SerialPort_ver104 は良好でーす。っが、
RAE2_SerialPort もGeigerRecorder もちまちまお願いがありますので、週末まとめてレポします

今日はPortmonとMtail立ち上げっぱなしでしたｗ

>>130

異論反論はそれなりにありますが、私自身は「おちゃらけた」要望してないつもりですが

>>131
ですので絶賛ウェルカム中です。　ＲＯＭの人が多いようなのでまじめなレポは貴重なんです。

このスレ的に私なりには

１．緊急的な被災者向けおよび「早急に」被災者救済に関与してくれる方が本位
２．実体験から来たアイディアの反映
３．使い勝手の向上（あらゆるケースの考慮、しかし作り手さんには低不可考慮）

〜〜〜別途枠〜〜〜

こんな事聞いたり頼んだりしてもいいのかなオロオロ　←大歓迎！！

で参加させて頂いてます、ですので大佐殿の基本姿勢には賛同〜

しかし時に発言はおちゃらけさせて頂きます()

うわ、揺れた

くなたは

>>133
・・・いやいや・・スレとかじゃなくて、
単に「私の関わっている優先順位の基本姿勢を自分なりに」で
今回の緊急災害に対して私個人での優先順位の位置づけを自分に課してるダケです。

要望やなんかがバッティングしたり実生活もありますから、
俺が先に言ったとか、ワシが先だとか、じゃなく、私はこういうスタンスでやってるので・・という意思表示だけです。

結構くどい言い回しを書いてしまう癖があるのは自覚しているので、誤解を与えてしまって申し訳ないです。

運営板の方で結構モメているらしく、このスレも何時スレストが掛かるか混沌としてきてます。
災害と同じく、慌てず落ち着いてをやっていきましょう。 > all
現時点で板のスレ数が、６７３スレに拡大中。　ちょっとこれは「危険があぶない」w

※ トリップのみの表示は、「何か」書き込もうとすると[名前が長い]など、なんらかの規制？が始まった？

>俺が先に言ったとか、ワシが先だとか、じゃなく、私はこういうスタンスでやってるので・・という意思表示だけです。


重々分かったとりやす！！を書かんがためなんで誤解もなにもしてませんよ
自分も時間有るときにしか発言してないしｗ

ROMさん多いのでちょっと目安な発言でも書いとこなってだけでした m(_ ._)m

知らぬ間に芋の解除ｷﾃﾀ━(ﾟ∀ﾟ)━!

名前欄ﾓﾄﾞｯﾀｰ

今更ながら汚染マップということで「地図」スレを探しに徘徊してみるとｗ

地理学・人類学＠2ch掲示板　無し？
地理・お国自慢＠2ch掲示板　無し？
登山・キャンプ・アウトドア＠2ch掲示板　２スレ
ソフトウェア＠2ch掲示板　２スレ
モバイル＠2ch掲示板　１スレ

無いなぁ・・・・カーナビとかならあるけど

週末レポの予定でしたが、今朝ほど実父が脳溢血で入院しました
IRCに入ってしまったので、おそらく２~３習慣ほど遅れます(そんなに心配しなくてもいい状態みたいです)

芋が再帰省でここ以外書けない(ﾉД`)ｼｸｼｸ

削除依頼出てます。
次スレは放射能板へとの削除人からの回答。

http://qb5.2ch.net/test/read.cgi/saku/1300192031/185

>>138
たいへんですね、回復に向かっているようでなによりです。
ご自身の生活モロモロをまず優先させるのは、とっても大事なので、気長に待ってます。

>>139
ふむ [地図・写真] にしてみると、川でもくぼ地でもないような箇所で急激に上がったりと・・
ほう
7040行かぁ
なるほど
そうね
あれをあーしてこうか
参考になりましたっ！
乙です！

>>142　大佐殿　ここで続けてよいのかな？　あっちに移ったほうがいいのかな？

7040行をアップし表示させたら固まった私の骨董品ＰＣ
ガチャコンで吐き出されたものをエクセルで読み込んで単純に「偶数行数になってしまった行」をDelしました
まぁ40Km/hで走行だったとして(^^ゞ　50ｍ間隔データポイントを間引いたことになるのかな
間引かない全ポイントが表示されるカシミール３Ｄとはかなり印象が異なります
盆地内で標高が低いところが少し高めです。ピンポイントで高いところは夏も同じ傾向でした。

全7040行は重複して走ってるポイントもありますので。。。一筆書きで走ることを目指したんですがめんどいです

大佐殿
ガチャコン　GPXデータで吐き出し必要時間
コピペで１つのcsvに　PDS_MEAS_RT-Readingd_ C12345_111010_111020合体.csv
nmeaも当該分を書き出し
csvデータのみ7060行　吐き出し所要時間約12分25秒＝745秒 でした
cpuメーターが動いてたのでハングしてないと踏んでPC君にがんばってもらいました

>>143
現状の運営サイドの判断と見解のまとめなどは、この板の自治スレでまとめてあるので、
★緊急自然災害@超臨時板 自治議論スレッド★
http://hato.2ch.net/test/read.cgi/lifeline/1299835428/

方針が変わるまでは、このスレを有意義に使っておいて良いのではないかと？
いろいろと突っ込まれる前に先手と予防は打っておきましたし。
どうやら、最新の見解も>>140 のようです。


今はガチャコンに使っている各機種ごとのログ変換部分を単体化して汎用CSV にするのをやっています。
そっちに集中し始めると急にカキコが減って流し見だけになると思います。
板移動騒ぎ関連で集中できない日々なのですが・・・

プログラム的に参考になった部分内容を書けば、
ログスプリッター（元：ログカッター）に、
１/２　〜　１/１０ぐらいまでの間引き機能など入れるとテキスト編集が楽になるカナ？
などですね

重複部分に関しては、ファジー（懐かしい言い方ｗ）判断はどうしてもプログラム的に LR 無理なので
人力（思考）に頼ることになりますが、
その日分の編集を行った上でプロット用に連結しカシミールなどに足していくしかないかと。

「こういう編集の仕方がある」とか「ここをこうすれば」などを論ずることは
ROM ってる多くの計測者さん達にもたいへん有意義かと
このスレの存在意義の１つなんで大いにくっちゃべってよかっべよ　

>>144
あら？　7060行も入れてハングせずに出ましたか、耐性高いな

それと、スレチ気味になりますが、PDS-100G/GN ID　の関連物で

【スペクトル】放射性核種同定【解析】1MeV
http://hato.2ch.net/test/read.cgi/lifeline/1311864994/

ボールのパスは、PDS-100G/GN ID　持ちさん側に今、ボールがあるので
・・・・情報待ちというところですね。

基準線源の実データと適当なサンプリングデータが数種類あればいろいろ出来るんですけどね。

|
|ω･´)ﾉｼ　ではでは
|

えっと、前スレをきちんと読んでみました
今日BluetoothでGammaRAE２のログ抜くことができました
いろいろ情報だして下さった方々
どうもありがとう

実家から一時帰宅、来週より忙しくなりそうです

>>104

その値はコントロールパネル内の「地域と言語」設定に依存しないか検証が必要です

間引きのタイミングですが

>>147 さんの
>nmeaもガチャコンに読み込ませる前に信号待ちなどで例えば5秒同一緯度経度ならdelって整形しておけば
などはかなり有効かと思いますが、私には低不可なアルゴリズムが見いだせないです

ファジー(高負荷なんでイヤン)では無くAIが有効かと思います
当然優先度「低低」の意見です

では、また実家に旅立ちまする

>>150
は
>>145
へのレスです書き損じすみません

ﾏﾀﾗｲｼｭｰ

>>149
それは、PDS-100G/GN ID　所持者さんにしか検証できませんね、
私の方は出てきたモノでしか判断できないレベルです。

機器持ってないし〜　検証するのにソフトも受け取ってないし〜　サイトからダウンロードとかできないし〜

ツール対応作成時に関わっている人の環境と情報に依存することになるので、
後からあ〜だこ〜だと来られても、「このフォーマットに合わせてくれたら良いだけですヨ」
と「作成時の人の環境が鉄板構成となる」ということです。

>>150
アルゴリズムというか、何キロ/ｈ以下はフィルターカットとか
どこまでを 有用／無用 を判別するか？　は、プロット作業する人の判断ロジックになりますし

（たしか>>144 さんはＧＰＳデータに旅レコフォーマットを使っているのかな？）

旅レコフォーマットの時点で [秒]と[ミリ秒]と[衛星ロスト] はフィルタリングされてることになります。

速度情報も km/h でパラメータ最終位置にいるので m-241 であれば １０km/h 以下を削除なりすれば
信号待ちなどで量産される多重の地点情報をカットできるのではないかと？

|
|ω･´)ﾉｼ
|

>>146　大佐殿
こんなので少しは役に立つのであれば　基準線源はもってないです　あっち読んだけどチンプンカンプン
Sc_286429.zip

sage間違えました・・

上の、よく見たら時刻が GPS から取得したまんまじゃなくて
勝手に変なとこで丸められちゃってますねぇ。
float で取ったものを、そのまま吐き出してるのに・・・

これは GPS 時計と一緒のものが出るように直します。

>>154
現行のDMDRTですが、実の所手持ちの機材(DoseRAE2とTGS-111)で記録するに足る情報を
フォーマット化した様な物なので、その時点では将来的にどうする…って言う"含み"は持たされて
いなかったです。

実の所実現するかはさておいて、拙作GRにてパルスを受け取って…ってのを考え始めている所なので、
この辺りのパラメータ(累積カウント数とオフセット)をサポートするのは私的には問題ないんですが…どうでしょうね。

その他の環境パラメータ類はどちらかと言うとモニタリングポスト的な使い方に供するパラメータの様な
気がするので、別なセンテンスにしてもいいかなとも思います。

大佐殿のご意見も伺いたい所ですが。

>>156
実は若松ガイガーの場合、平均化させる時間を自由に指定できてしまうんですよ。
たとえば、「10分間の平均で cpm を求める」の「10分」のところを「5分」に
変えれたりする仕組みが備わってるんです。(公式ファームのときから)

たとえば「10分平均」の設定で、移動しながら測定したとき、
ある地点の線量というのは、その地点のピンポイントな線量というより
それまでの10分走行分(時速60キロのときは10キロ分)の平均値ということなので、
そういう前提のログファイルをパソコンが取り込むにあたり、
取込側のソフトを、より賢くしていこうとしたとき、
「過去どんだけ分の平均値なのか」という点を加味できる余地が必要かな、と感じる次第です。

そこら辺の細い動きをどう表現するかは取込側のソフトの仕事なんで私はノータッチの予定ですけど
ログファイルを落とす側としては、そういう用途に耐えうる情報を予め落としておく責任があるかな〜と

>>157
センテンスを分けることも含めて考えると
μSV/hへの変換係数は測定値というよりパラメータって風なので
DMDRT に入れるのは馴染まない気もしてきました。。

てことで累積カウント数だけ DMDRT の中に入れさせて貰うことにして

・平均化秒数(DMDRTのcpm項目を求めるにあたり何秒間で平均とったか)
・変換係数(cpm→μSV/hにするときの、cpmから割る値)
・オフセット(μSV/hへの下駄)

とかの測定条件系(毎回出力する必要もなさそうなもの)を
別センテンスで落とす、でいいですか？

Condition の C で、DMDRC とかどうですか？？
(DMDRCの具体案は、ちょっと考えてまた書き込もうと思います)


温度とか湿度も別センテンスがいいですね。
NMEA が、こんな応用性に富む規格とは思ってませんでした、すばらしい。

連続すみません。
DMDRT に落としたい「累積カウント数」ですが、なんでこれに拘ってるかと言いますと
たとえば(意図せず)10分平均の設定で作ってしまったログファイルを用いて
パソコンの取込側の工夫で「30秒平均の値」で再計算させる余地を確保しておきたいからです。

30秒分の DMDRT 行を抜き出してきて
その期間の最初と最後の累積カウント数の差を求めれば、「30秒分のカウント数」が出て
「30秒分のカウント数」×2 にしたら、その「30秒間のcpm数」が求まります。
そのcpm数に換算係数とオフセットを加味して「30秒間のμSV/h値」が出ます。


ここまだ拘るのは、若松ガイガーはスイッチがなくて
パソコンがないと途中で(気がついたときに)設定変更ができないからなんですよ。
「あ、10分平均のままだったー」とか

>>160 連投ジャンジャンＯＫｗ

若松ガイガーで先に１つ聞いておきたかった事があったのを忘れていました。
某スレ
【ガイガー】放射線計測器の自作 10CPM【PDシンチ】
　http://kamome.2ch.net/test/read.cgi/denki/1317136019/

　か、その前スレだかで
若松ガイガーの作者基公開ファームは　カウントｘ係数＝μSv/h
若松ガイガー販売、　若松ファームは　(カウント−ＢＧ)ｘ係数＝μSv/h
とか？
DMDRT での係数の所もなんとかしておかないといけないのかな？　と

今、他人様のソースをじっくりねっとりたっぷりと眺め廻す余裕が無いので確認できません。
たぶん「オフセット」との語句が、私の言うバックグラウンド数の事を指しておられると私は思うのですが。
（認識の齟齬埋めに書きました）

累積関連データに関してですが、例えば
１．DMDRT ＋拡張　計算に使ったカウント数　、計算に使った時間（秒）
２．新センテンス（総累積カウント　、総時間）

という感じにしてみる案はどうですか？（カウントの前後は一例）
出力時刻を同じにしておくと紐付けも容易かと

これでいくと必要範囲分の加算だけで済むかと。（除算が必要なくなる）

チェックサム確認する場合（私はしていないｗ）の比較用抜き出しも
最終位置確認は　* があるか？で判断できますし
セミカンマでデリミッター（区切）って最初の１バイトをずらすだけで可能なのでは？


>平均化させる時間を自由に指定できてしまうんですよ。
もともとがモニタリング用として販売されていますから、１０分とかユーザー設定でも固定なのでしょう。

過去にカメコさんが書いていた内容と、Polimaster スレの話しで
PM1703M 系のすばやい線量変化対応と低線量下での誤差収束について
急激な線量上昇が検知されるとそれまでの平均を破棄、CPS など短時間計算に移行。

線量変動が落ち着くと長時間累積計算に移行していき誤差を減らしている・・感じ　らしいです。

こういったアルゴリズムをうまく構築して可変型にできれば、
線量変化への追随が速くなる可能性を秘めています。
同時に線量変化の緩やかなモニタリングポストにも向くかと。

ログ出力も線量変化が無ければ次出力をスルーなどでもすると容量を減らせる可能性もあります。

間違いでした

誤） μSV/h ＝カウント×係数＋オフセット
正） μSV/h ＝カウント÷係数＋オフセット

誤)　μSV/h ＝cpm × 129.032 - 0.032
正)　μSV/h ＝cpm ÷ 129.032 - 0.032

>複数管も想定されているんですか。

ストロベリーリナの方でCPM だけだったり、管を変えたり・・
Arduino 持ちさんの方で管を複数付けられるね〜　と言う話しが出たけどプログラムが組めなくて断念されたとか・・
複数接続したいとか・・　（幾つか作ってみたものの動作不良だったとかで断念されたとか・・）

・・・いろいろありまして

メモリー容量の制約でファームが複雑化できないなどの対処用
あとは、製作更新をβ版で中断しているマッパー用も含めてです。

複数の機器からデータが入力されて混ざったログが溜まると、
データの出所や最低限のパラメータが無いと、その後がムチャクチャになって分別できなくなるな・・・というところです。

若松の場合でも、管の種類を変えられる仕様だったと記憶していますので、
１人で複数所持してログを溜め込んだ場合、対応ツールで振り分けたり再計算させたりするには最低限何がいるか？
となります。

オフセットの件は理解しました。
μSV/h ＝カウント×係数　で進めたからなぁ・・・どうやるとうまく納まるやら・・・

センテンスが増えすぎると、使う側はアプリの設定画面で自分の環境がどのセンテンスが適切なのか？と言う疑問(壁)にぶちあたります
そもそもセンテンスってなんですか？と言うユーザーさんは作り手さんの意図全に反して判断が難しく、このプロジェクトに取り付く事ができません

適応機器を持ってない方には誠に申し訳有りませんが、その辺( ´･ω･) ◆CGOTBmWdi2 さんのGRのはよく考えられているとおもいます

>>167
そもそもこういったセンテンスは、使う人（エンドユーザー）は、深く考えなくて良いようにするための
各 製作者達が悩む方です。

〜機種対応　とかでみて「あぁ使えるんだな」程度にもっていくのに裏方が苦労する領分・・・ｗ

>>( ´･ω･) ◆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 (福島県)さん　だけだったような気が

他の、このスレ見て作っている方がおられれば降臨してほしいナ

なんか帰って来たら書き込みが伸びてた…
すみません、明日までに引っ越ししないといけないもので、なかなか反応出来ません。。

取り急ぎで申し訳ないですが
>>169
栞機能は次バージョンに組み込み済みです。
あと、"*"の前に","を入れるのも問題ありません。

今後の汎用性については、2番目の汎用文字列にて対応でもOKです。
それともNMEA0183みたいに
$GP*** ならGPS関連のセンテンス…と言う風に
$DM*** なら線量計(DosiMeter)関連のセンテンス…でも。

以下、一例です。
$DMDRT　→　DosiMeterDoseRaTe：主に線量計からの出力データ
$DMENV　→　DosiMeterENVironment：測定環境(気温・湿度・風向・降雨量・天候など…)
$DMCON　→　DosiMeterCONdition：パラメータなど(154さんの案をちょっと改名しました。)

とにかく、利用側や加工側が解りやすく扱いやすければOKと言うスタンスです。

>>170
はい、私もその２案での方向性で問題ありません。
新センテンス作成時は、１機種だけに捕らわれず汎用性が利くように策定できれば良いと思います。
MARK2 改造さん のご意見を待ちます。

寒くなってきてますから風邪などもお気をつけて。

質問です

ガーミンのサイコンを使用しています
GPXファイルの書き出ししかできないです。
GPAファイルをNMEAファイルに変換する方法ありますか？

訂正

GPA→GPX

たぶん「累積カウント数」などという内部数値を取得できるのは、若松ほか自作ガイガー系だけですよね、きっと
そうなると、全体から見たらちょっと亜流になるんで、$DMDRT には入れないほうがいいかもしれませんね。

私が口出しする前の $DMDRT 仕様で１点だけ気にかかったのが
「cpm や μSV/h という数値が、何秒間の測定によって得られたのか？」という点が不明なところ。

市販のガイガーでも30秒とか60秒とか、色々と差違がありそうな気がしてまして
最終的に汚染地図をプロットするにあたり、何秒前から測定した分の平均値なのか？ってのは、割と重要な気がしました。
特に若松や自作ガイガーの場合は、使用者が自由に定義できる余地があるんで・・・

グダグタと書いててもアレなんで私案かきます。

■ $DMDRT の最後(地上高の次)に、「cpmやμSV/hを求めるにあたって使用した平均化秒数」のみ追加
　省略時は未定義(不明)として扱い、具体的な取り扱いは取込側のソフトに一任
　この項目は「分」じゃなくて「秒」がいいです。

■ 累積カウント数や換算パラメータなどの市販ガイガーにない自作系特有の情報は $DMDRT じゃなくて別センテンスに出す
　汎用的な地図プロットソフトは $DMDRT だけを見て作図したらいいように

でどうでしょうか？

つまりは、>>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秒前の位置を探し出して現在地との中間地点に線量をピンを打つもよし

いや待てよ
最初の仕様にあった $DMDRT の中の cpm って、それ単独ではあまり意味がないですよね
市販ガイガーを含めて色んな機種(管)が $DMDRT を吐き始めると、ますます意味のない数値に。

とはいえ、cpm とて測定値なんだから $DMDRT の中にあっても不思議じゃないし
わざわざ cpm のために別センテンスを作るのも非効率的

その流れで言ったら、累積カウント数(出力できない機種もあるけど)が
$DMDRT の中にあっても不自然ではない。
cpm と一緒で管の種類に依存したカウント値なんだから。

てことで、

$DMDRT,[連番],[GPS日付],[GPS時刻],[cpm],[μSV/h],[地上高],<平均化秒数>,<累積カウント数>*cs

[] は当初の仕様からある分、<> が追加分
それぞれ取得できない(値を落とせない)場合は空文字で(カンマ残して)詰める

じゃダメでしょうか？　とりあえず複数管は無視してますけど。
自作系で cpm→μSV/h の換算係数が明らかになってる管を使ってる場合は

$DMCON の中にそれらパラメータを書き出す
(これは普通は時間に応じて変動しないので、毎回落とす必要はない)


「平均化秒数」は、市販ガイガーでも自作ガイガーでも共通して「あればあったら多分つかえる項目」で
「累積カウント数」は、自作ガイガーのときにのみ「あれば使えるかもしれない項目」という位置づけですけど
市販ガイガーには「余計な項目」になりますが「累積カウント数」だけで別センテンスを落とすのは勿体ないので
$DMDRT の中に居候させていただく、と。

>>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係数
という感じカナと考えてますがいかが？

>>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円 (税込) か
　・
　・
まぁなんというか、放射線によるノイズを使う訳だから・・・もっと高感度な物が出たらセンサーとして繋ぐとか

>>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

というのが存在します。

そうですか。
いやなに、ずーっと前にあった↓のデータファイル(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 の中で申告していただく、ってのは？

>計算に使われた範囲分の<累積カウント数>なら私はかまわないかと、汎用性はありそうです。
>ＳＷ-ＯＮからの総<累積カウント数>だと　むむむ ちょっとなぁ　という感じです。

「計算に使われた範囲分の<累積カウント数>」だと通常は cpm と同値になるかと思うので
それであれば必要ないかなぁという気がします。

使えるシーンはかなりレアだとは思いますが
今のところ、若松(改)では手抜きしてて $GPRMC を受信したら
その前に $DMDRT を挿入して、ってやってます。よって間引きなしで1秒ごとに吐き出してます(笑)

感度のいい管を使われていることが前提になりますが、
累積カウント値と換算パラメータ(これは別センテンス)を出しておくことで
取込側のソフトの工夫次第で、「移動平均=10秒 で抜き出したμSV/h値」を利用することができるようになります。
また何らかの事情で数レコード欠落したところで、「累積カウント値」なら取込側で欠落分を補てんできるかな、と。

あとセミコロンですけど、個人的にはあってもなくてもどっちでもいいんですが、
「*」の前までがデータ領域と判断して、その中のカンマの数を数えると項目数が割り出せるので
特にセミコロンが必要な気がしないんですけど
(取込側の事情をよく分かってなくて書いてます、失礼があったらごめんなさい)

ぶっちゃけ、連番も取込時に(必要ならば)勝手に付番することにして
$DMDRTを出す側が付ける必要もない気もしなくもなく・・・

ただ連番も累積カウント値も、数年にわたりノンストップで運用されると
いつかどっかでオーバーフローしますよねぇ・・・
連番は「寿命が長い」けど、累積カウント値は早々に32ビット使い切りそうです(汗)

やっぱ止めといたほうが無難かなぁという気もしてきました。

>>180
NeutronRAE II は残念ながらリアル吐き出ししてきてくれないようです。
よってリアル接続そのものが成り立たないので意味をもちません。
RAE II などで出てこないかどうか試してもらいましたが無理だったようです。

あの系統の反応は１秒より反応が速い感じっぽいような話しですね。
なので
あくまでログ（最短１秒）と実挙動の表示（１秒以下？）に一致があるのかちょっとわかりません。
ログデータのパラメータだけで同列に見ない方がいいかと思います。

項目が増える事に関しては構わない旨、了承してます。
齟齬が発生しないように内容を詰めているだけです。
( ´･ω･) ◆CGOTBmWdi2 さんの降臨を待ちます。

肝心のアプリなどに通したらエラーで使えないという事態は避けたい。

こちらもちょっと熱くなってすみませんでした。。

市販ガイガーも自作ガイガーも、どっちの基本的に
放射線のカウント数とその密度だけを頼りにしている点では一緒なのですが
市販ガイガーのほうはμSV/hへの換算の部分に各社のノウハウが注ぎ込まれているのに対し
自作ガイガーのほうはμSV/hへの換算は単純な割り算と引き算くらいの、素直というか何も装飾していないですね。

まぁ市販ガイガーの中にも自作ガイガーと全く同じものも多いですけれど(笑)


「(累積)カウント数」ってのはデジカメでいうところの RAW データで
「μSV/h」ってのはデジカメで言うところの JPEG に相当してて
市販ガイガーは「現像エンジン」の出来で競争してる、と思ってます。

市販ガイガーは RAW データ(生のカウント値) を出さない代わりに
各社各様の現像処理を施した JPEG データ(μSV/h値)が出てくるのに対し
自作ガイガーの JPEG 現像(μSV/hへの変換)は怪しい(信用しきれない)ので、
あくまで RAW データ(生のカウント値)が中心、と。

>>179 ありがとうございます。
早速ためしてみます

はい、接続環境以外の環境は殆ど戻りました。

取り合えずは新居に移りましたが、全然片づかないorz
スクリーニングしなきゃいけない持ち出し品も山積みだったりとか。
家の中に放射線管理区域＆除染エリアを設置とか…なんでこんな羽目にorz

放射線計測マップ作成支援
　ttp://www1.axfc.net/uploader/Sc/so/288948.zip&key=MustangENQ

PDS-100GN / PDS-100GN/ID 用 PdsMass ログをCSV 形式にします。

【 Manual Basic　手動入力 フォーマット 】csv 手動入力準拠
（通称：「ガチャコン」準拠です。）

ＧＰＳとのミックス前の編集や、表計算ソフトに取り込んで作業する為のコンバータです。

>>185
・・・大変・・・・ですね（としか返せないわ）
新居はフクイチから何キロほどになったのですか？

>>186　大佐殿　いただきました　ありがとうございます
表計算ソフトで一旦読み込んでシコシコすれば良いのでしょうが、ワンクリックで出来るのはありがたいです
PDS100専用ではなくガチャコンで事前準備されている各機種の読込convertが可能であれば利便性があがるかと思います

>>187
会津なので100km程離れていますかね。
ホントは西日本に行きたいんですが、まだ全部の私物を持ち出せてないんですよね。。。
なので暫くは留まってるかも。

それはそれとして、早いところ$DM系センテンスの策定をしなきゃいかんですね。
目下の懸案事項は、累積カウント数の取扱いをどうするか…ですか？
他に摺り合わせておきたい物とかありますか？

>>188
ベースを作るのに手間取っていたのでリリースが遅れていますが・・・
PDS-100GN　の CSV 状態で実際にガチャコンで使うのはμSv/h の所までですが。
CPM は単純に　cpsｘ60 です。

NeutronRAE/GammaRAE II R　で苦しみそうです。
テキストデータ形式が２種類と、μSv/h　μR/h の２種類に、セミカンマとタブの２種類・・・

CSV 一本化できれば後は、ログスプリッターをもう少し進化させれば単純な処理が出来ると思います。
１つおき〜１０飛ばし？　検出値の下限上限でリミッターなど

GPS の方では指定速度以下＆速度超過は間引くなど出来れば、余分な量を減らせると・・・思います。
ちょっと、先の話になりそうですが。

・累積カウント数の扱い部分の記述で・・・ちと保留化

動的作業：$DMDRTの付けたしは、計算用の実カウントと実時間（秒）
・・・というのも、計算に使うアルゴリズム次第で実カウントとして累積計算には使えないですね・・・
前回出力した時を０リセットとした累積量と置き換えてみます。

でもそうなると、累積量と計算用カウントと計算用実時間（秒）の３つが要る？

誤字訂正
×　携帯ガイガーでは馴染みたい値かと思いますが
○　携帯ガイガーでは馴染みない値かと思いますが

連投すみません、訂正

誤
$DMRAW,<管の種類>,<管数>,<起動秒数>,<累積カウント>,<係数>,<オフセット>,<予備>・・・・*<チェックサム>

正
$DMRAW,<UTC日付>,<UTC時刻>,<管の種類>,<管数>,<起動秒数>,<累積カウント>,<係数>,<オフセット>,<予備>・・・・*<チェックサム>

>>191
・係数
計算式をそのまま載っける訳ですね？
*→xで問題ないのではないと思います。

・cs
これはGRでも対応済みです。"xx,*cs"で良いんですよね？

・累積カウント
累積カウントは基本的にログ開始からの加算処理で、これを以て累積カウントとする…
アレでしたら$DMCONを使って一定スパン(24hとか…)に前日の累積カウントを出力。
※$DMCONはパラメータなので最初に出力した方が良いと思われるのと、int型であれば
24h位の累積カウント数は賄えるかなと。


…と書いた所でMark2改さんが沢山書かれているのに気が付いた。。。
反応が遅れてしまい、申し訳ないです。なにぶん、まだそれ程時間が取れないのがもどかしい所でして。


平均化秒数は"ソレ"を解釈するソフト側で持っていれば良いような気がするので、センテンスに
入れなくても問題無いかなとも思うんですが、どうでしょう。

明日、またOK町に一時帰宅して来ます。
朝から反応出来ません。。。

　07) 測定高さ ：単位 cm ｛
　08) 累積時間（秒）
　09) 累積カウント　：(整数）
　10) *チェックサム
　--) [CR] ：0x0A
　--) [LF] ：0x0D