facebook twitter hatena line google mixi email
★お気に入り追加


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

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

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

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

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

などの合流を求めます。

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

手伝ってね、みなさん。

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


ここまで見た
  • 127
  • DoseRAE2
  • 2011/10/16(日) 18:38:20.24
>>111

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

ここまで見た
  • 128
  •  
  • 2011/10/16(日) 19:02:15.70
>>126 指摘サンクスです!

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

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

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

ここまで見た
  • 129
  • DoseRAE2
  • 2011/10/16(日) 19:27:37.83
>> 128
了解でーす

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

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

ここまで見た
  • 130
  •  
  • 2011/10/17(月) 20:42:45.03
>>129
了解、レポ待っときます!

私の関わっている優先順位の基本姿勢を自分なりに
1.緊急的な被災者向けが本位
2.状況の変化にいち早く追従先行
3.使い勝手の向上
4.新規の予防的な懸案

 〜〜超えられない壁〜
低.お遊び

という感じでしょうか?
そういう感じで >>81 (福島県)さんの機種対応話は、まぁおいおいやってみるか・・・
だったのが、同? >>101 さんの「汚染状況重点調査地域」要望なんてのはズバリ上位なうえ、
(言い方は悪いが)汚染災害地帯と密接に関わる現場の人 なので緊急要件として急ぎました。

なので、ユーザビリティレポートというのは、
現場の人の使い勝手の向上に役立つと思ってますので(おちゃらけは低めで)ウェルカムです。

・・・ガチャコンでは、ボタン操作が多くて紛らわしいかもしれませんが、
確認に確認を重ねてデータを作成するという手順をわざとふんでいます。

p.s. 移行予定先の板スレ>>74 にDAT 落ち防止なんらかの情報で保守など適当に〜
  行政が行っている取り組みと現状とか〜レポートとか〜記事リンクとか〜
  1人しか書き込んでいないとか難癖つけられて削除対象になったりしたら、さてどうすっべ?になるので。

ここまで見た
  • 131
  • DoseRAE2
  • 2011/10/17(月) 22:30:15.73
>>130

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

ここまで見た
  • 132
  •  
  • 2011/10/17(月) 23:11:48.57
>>131
ですので絶賛ウェルカム中です。 ROMの人が多いようなのでまじめなレポは貴重なんです。

ここまで見た
  • 133
  • DoseRAE2
  • 2011/10/18(火) 19:42:47.60
このスレ的に私なりには

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

〜〜〜別途枠〜〜〜

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

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

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

うわ、揺れた

ここまで見た
  • 134
  • 地震雷火事名無し
  • 2011/10/18(火) 20:00:23.82
くなたは

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

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

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

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

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

ここまで見た
  • 136
  • ◆/BLnkBtCx6
  • 2011/10/18(火) 20:33:46.86
>俺が先に言ったとか、ワシが先だとか、じゃなく、私はこういうスタンスでやってるので・・という意思表示だけです。


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

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

知らぬ間に芋の解除キテタ━(゚∀゚)━!


ここまで見た
  • 137
  •  
  • 2011/10/20(木) 03:05:19.83
名前欄モドッター

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

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

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

ここまで見た
  • 138
  • [´・ω・`]
  • 2011/10/21(金) 20:34:29.44
週末レポの予定でしたが、今朝ほど実父が脳溢血で入院しました
IRCに入ってしまったので、おそらく2~3習慣ほど遅れます(そんなに心配しなくてもいい状態みたいです)

芋が再帰省でここ以外書けない(ノД`)シクシク

ここまで見た
会津走行線量率地図(2011/10/10〜2011/10/20)をアップしました。
データ作成には◆MustangENQ氏作成のGeigerMixGpsProject Ver0.16を使わせていただきました。ローカルで見ていたカシミール3Dの感覚で
全7040行をアップしたら重過ぎました orz  なので偶数行を削除してデータ行を半分にしました。
http://geigerdata2.appspot.com/plotter?id=agtnZWlnZXJkYXRhMnIbCxITZ2VpZ2VyZGF0YV9wbG90dGVyMhj1pQMM


ここまで見た
  • 140
  • 地震雷火事名無し
  • 2011/10/22(土) 17:31:26.01
削除依頼出てます。
次スレは放射能板へとの削除人からの回答。

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


ここまで見た
  • 141
  •  
  • 2011/10/22(土) 21:01:21.62
    。。
   ゚●゜ ペタ ッ

>>140 の先を抜粋

>http://qb5.2ch.net/test/read.cgi/saku/1300192031/185
>185 :削除屋@放浪人 ★:2011/10/22(土) 17:09:50.01 ID:???0
>重複スレッドは誘導してから再依頼下さい。
>一部様子見+保留で。

>・次スレで放射能板に移動するようにして下さい。
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> http://hato.2ch.net/test/read.cgi/lifeline/1316336708/  ← このスレ
> http://hato.2ch.net/test/read.cgi/lifeline/1314177830/
> http://hato.2ch.net/test/read.cgi/lifeline/1317064762/
> http://hato.2ch.net/test/read.cgi/lifeline/1307628158/
> http://hato.2ch.net/test/read.cgi/lifeline/1310226199/

──────────────────────────────

>>140
 ( ̄^ ̄*ゞ ビシッ! 了解! 「次スレは放射能板で」の指摘、重々承知しております!

 ( ̄^ ̄*ゞ ビシッ! 運営見解に沿って「次スレは放射能板で」を混乱なきよう勤めております!

 ( ̄^ ̄*ゞ ビシッ! 報告ありがとうであります!

ここまで見た
  • 142
  •  
  • 2011/10/22(土) 21:21:16.49
>>138
たいへんですね、回復に向かっているようでなによりです。
ご自身の生活モロモロをまず優先させるのは、とっても大事なので、気長に待ってます。

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

ここまで見た
  • 143
  • 139
  • 2011/10/22(土) 22:21:34.16
>>142 大佐殿 ここで続けてよいのかな? あっちに移ったほうがいいのかな?

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

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

ここまで見た
  • 144
  • 139
  • 2011/10/22(土) 22:36:47.67
大佐殿
ガチャコン GPXデータで吐き出し必要時間
コピペで1つの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 にするのをやっています。
そっちに集中し始めると急にカキコが減って流し見だけになると思います。
板移動騒ぎ関連で集中できない日々なのですが・・・

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

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

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

ここまで見た
  • 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 持ちさん側に今、ボールがあるので
・・・・情報待ちというところですね。

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

|
|ω・´)ノシ ではでは
|

ここまで見た
>>145 大佐殿
ふと気づきました! なんでもかんでもガチャコンに任せるのではなく下準備が重要だと
nmeaもガチャコンに読み込ませる前に信号待ちなどで例えば5秒同一緯度経度ならdelって整形しておけば
今回の私の7040行なんてならない筈ですね<(_ _)>  段取り8分。。。先人はよく言ったものです

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


ここまで見た
  • 149
  • DoseRAE2
  • 2011/10/23(日) 23:01:23.15
実家から一時帰宅、来週より忙しくなりそうです

>>104

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

ここまで見た
  • 150
  • DoseRAE2
  • 2011/10/23(日) 23:41:00.95
間引きのタイミングですが

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

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

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

ここまで見た
  • 151
  • 地震雷火事名無し
  • 2011/10/23(日) 23:46:05.99
>>150

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

マタライシュー

ここまで見た
  • 152
  •  
  • 2011/10/24(月) 01:10:27.49
>>149
それは、PDS-100G/GN ID 所持者さんにしか検証できませんね、
私の方は出てきたモノでしか判断できないレベルです。

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

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

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

(たしか>>144 さんはGPSデータに旅レコフォーマットを使っているのかな?)

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

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

|
|ω・´)ノシ
|

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

ここまで見た
  • 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 への計算係数が取得できるので
それも一緒に吐き出しておくと、
[累積カウント数] [係数] [オフセット]  の3つの値から PC側でμSV/h 計算ができるようになるかなぁ〜と。

あと将来的なパラメータとして、測定時の温度・湿度・風向・風力・日照強度 とか
そーいう環境条件を入れる枠(仕様)だけ作っておくと、とても良い感じに思えました。

DMDRT の後ろを伸ばすか、別のセンテンスを付けるべきか悩むところですが。


以上、取り急ぎ書きたいことだけ書き連ねました。

ここまで見た
sage間違えました・・

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

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

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

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

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

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



ここまで見た
  • 157
  •  
  • 2011/10/29(土) 04:28:52.11
>>154-156 はい、呼ばれました
こちらは
DMDRT で、現状の * のいる7番目までしか使っていないので

  00) $DMDRT :固定
  01) 入力番号 :0 〜 { 入力用番号
  02) 世界標準時 :yyyyMMdd { 8桁 西暦年 月 日
  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 と増えていくものには影響を受けませんですよ。
(個人的には最終位置のパラメータとチェックサムの * はセミカンマで分かれていると分離が楽カナ)

機器温度・周辺温度・CPSなどなど新センテンスを設けるのも別段、影響をうけません。

電子方位計に関しては、NMEA にもセンテンスが存在しますので、方位センサーを繋ぐ場合はそういった既存のものを使う手もあります。
GPHDG かな? p.11

 DescriptionNMEA.pdf
 http://www.tronico.fi/OH6NT/docs/NMEA0183.pdf

あと、ガチャコンのテキストに各機器のログフォーマットを書いている通りなので
メーカー機器によってどういったデータがあるのか事前に考えておけるかと
(自作機が進化した時に備えて、・・別スレではスペクトル系の自作スレがあったりします)

>>154
>>56-58 な感じで酉を付けられてWeb などに書かれておかれたりすると、
2chでも配布したり、話したりする時に皆さんが安心して加われるかと
〜な者ですとか注釈も省けて楽ですよ。

ここまで見た
  • 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 連投ジャンジャンOKw

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

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

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

ここまで見た
  • 162
  •  
  • 2011/10/29(土) 12:07:54.38
累積関連データに関してですが、例えば
1.DMDRT +拡張 計算に使ったカウント数 、計算に使った時間(秒)
2.新センテンス(総累積カウント 、総時間)

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

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

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


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

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

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

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

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

ここまで見た
  • 163
  •  
  • 2011/10/29(土) 12:54:17.41
>>159
連投w 書き忘れ

>μSV/hへの変換係数は測定値というよりパラメータって風なので
パラメータです。
(たしか)これを入れるお願いをしたのは、1センサー=1機器 ではなく
多センサー&オール通信(ログ) を想定している布石です。

カウンタに使われている
01) 入力番号 :0 〜 { 入力用番号
 と言わばペア状態で使う想定です。

例 ) 若松と仮定

1管−mbed− $DMDRT −> アプリ ← 現状

1管 ┐               ←可能かどうかの是非は棚上げ
1管 ┴ mbed− $DMDRT −> アプリ

1管−mbed − $DMDRT ┐
1管−mbed − $DMDRT ┼−> アプリ
1管−mbed − $DMDRT ┤
1管−mbed − $DMDRT ┘

要は仕様のバラバラな管や、多人数の別機器の混在対処用ですね。

ここまで見た
>>161
>若松ガイガーの作者基公開ファームは カウントx係数=μSv/h
>若松ガイガー販売、 若松ファームは (カウント−BG)x係数=μSv/h

そこら辺はパラメータファイルになってて、パソコン繋いでメモ帳で書き換えれるようになってます。
ちなみに作者さんが公開してたパラメータの間違いだったようで今は一緒になってます。

プログラム的には
μSV/h =カウント×係数+オフセットになってます。

SBM-20のとき、
  係数=129.032
  オフセット=-0.032
が初期値でして、
  μSV/h =cpm × 129.032 - 0.032
で求めてます。

2点キャリブさせた結果を登録しとくと、
それに応じて係数とオフセットが自動計算される仕組みです。(元々の仕様)

複数管も想定されているんですか。
ぱっと読んだだけで理解しきれていないので、また改めて返事かきますね
(これから泊まりがけで出かけるので明日かあさってになるかもしれませんが)

ここまで見た
間違いでした

誤) μ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 持ちさんの方で管を複数付けられるね〜 と言う話しが出たけどプログラムが組めなくて断念されたとか・・
複数接続したいとか・・ (幾つか作ってみたものの動作不良だったとかで断念されたとか・・)

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

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

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

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

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

ここまで見た
  • 167
  • 地震雷火事名無し
  • 2011/10/29(土) 21:45:26.59
センテンスが増えすぎると、使う側はアプリの設定画面で自分の環境がどのセンテンスが適切なのか?と言う疑問(壁)にぶちあたります
そもそもセンテンスってなんですか?と言うユーザーさんは作り手さんの意図全に反して判断が難しく、このプロジェクトに取り付く事ができません

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



ここまで見た
  • 168
  •  
  • 2011/10/30(日) 05:38:47.26
>>167
そもそもこういったセンテンスは、使う人(エンドユーザー)は、深く考えなくて良いようにするための
各 製作者達が悩む方です。

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


ここまで見た
  • 169
  •  
  • 2011/10/30(日) 05:44:16.27
>>( ´・ω・) ◆CGOTBmWdi2 (福島県)さん 地震雷火事名無し(新疆ウイグル自治区)さん

>>77 から出た「栞「しおり」機能」について〜 >>90 まででまとまった内容。

DMDRT 準拠 フォーマットの方はとりあえずの「しおり」にパラメータ無しでおちついてます。
しおり:$DMDRT,*43


今後の汎用性を>>86 に提案してみています。
>例えば、$DMDRT,入力番号,世界標準時〜
>$DMDRT の2番目にくる「入力番号」に判別文字列でのパラメータ切り替えでも対処しやすいかもしれないです。

これまでのオーソドックスな $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と言うスタンスです。

ここまで見た
  • 171
  •  
  • 2011/10/31(月) 04:56:39.77
>>170
はい、私もその2案での方向性で問題ありません。
新センテンス作成時は、1機種だけに捕らわれず汎用性が利くように策定できれば良いと思います。
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 仕様で1点だけ気にかかったのが
「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 という数値が、何秒間の測定によって得られたのか?」という点が不明なところ。
はっきり言い切って「そんなもん自作機作者かメーカー技術者しか判りませんw」いやマジで

( ´・ω・) ◆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 化は変になります。
同種の機器を同時使用した遮蔽有り無しでβ線カウントなどができる余地も入れています。

<平均化秒数> への異論はありませんが、<累積カウント数> はどうでしょう?
計算に使われた範囲分の<累積カウント数>なら私はかまわないかと、汎用性はありそうです。
SW-ONからの総<累積カウント数>だと むむむ ちょっとなぁ という感じです。
どっちでしょう?
私の考え方の根底に、ベースデータは、その1センテンスデータで情報が成り立つか? です。

$DMCON の方は、パラメータだけ書くと他機種さんが参入時(あるのかしらないけど)困るので
$DMCON の次にでも機種名(コード?)などを置くといった感じにされたらどうでしょう?

予約語というものです。
そうすれば、その機種コードに関しては Mark2改 さんのオレの天下! になりますよね。

CS は最終パラメータの後ろにセミカンマ入れて単独化して欲しいと切に思っていたりします。
パラメータ数を可変化すると分離の手間が大変なのさぁ・・・


PDを使ったパルスのみの低価格自作キットが発売になったようです。
放射線モニターきっと[RM-LM3900-KIT] http://www.aitendo.co.jp/product/3436
販売価格: 900円 (税込) か
 ・
 ・
まぁなんというか、放射線によるノイズを使う訳だから・・・もっと高感度な物が出たらセンサーとして繋ぐとか

お絵かきランド
フリック回転寿司
ここまで見た

★お気に入り追加

このページを共有する
facebook twitter hatena line google mixi email
おすすめワード