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

**地震雷火事名無し**(dion軍) · 2011/09/18(日) 18:05:08.08

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

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

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

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

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

などの合流を求めます。

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

手伝ってね、みなさん。

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

**100**(福島県) · 2011/10/12(水) 20:26:43.58

大佐殿
低線量の放射線マップ作成用ガチャコン ver.0.15 いただきました！
とんでもない進化、ありがとうございます

設定線量上限を任意数値入力可能なオプションの検討をいただけるとありがたいです

または　□設定：最大値を0.23μSv/h (0.23μSv/h)
　　　　　0.08以下　0.11以下　0.14以下　0.17以下　0.20以下　0.23以下　0.23超
の追加が可能であればご検討をお願いします　お願いの理由は↓です

除染：「年１ミリシーベルト以上」政府基本方針案
　　　この基本方針に基づく除染作業は(中略)
　　　年間被ばく線量が１ミリシーベルト（毎時０・２３マイクロシーベルト）以上の
　　　地域は環境相が「汚染状況重点調査地域」に指定し、自治体が除染する区域や計
　　　画を立てて実施する（除染費用は国が負担）　(攻略)　↓ソース
http://mainichi.jp/select/jiken/news/20111011k0000e010044000c.html

**(`･ω･´)ﾉｼ大佐** ◆MustangENQ (長屋) · 2011/10/12(水) 21:44:54.44

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

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

**地震雷火事名無し**(福島県) · 2011/10/12(水) 23:56:59.19

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

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

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

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

**(`･ω･´)ﾉｼ大佐** ◆MustangENQ (長屋) · 2011/10/13(木) 04:20:39.90

>>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日だから・・・アレ？どっちだ？　と
　「月/日/年-」で進めてます。

**DoseRAE2** ◆/BLnkBtCx6 (芋) · 2011/10/13(木) 10:32:45.04

>>96

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

**103**(福島県) · 2011/10/13(木) 19:07:30.65

>>104　　大佐殿

Sc 283291　
検証用にご利用いただければ幸いです　　

**(`･ω･´)ﾉｼ大佐** ◆MustangENQ (長屋) · 2011/10/13(木) 19:22:41.85

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

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

**(`･ω･´)ﾉｼ大佐** ◆MustangENQ (長屋) · 2011/10/13(木) 20:27:06.66

2011年10月13日　統合対策会見より

記者：　「モニタリングポストを増やすなど。で対応して拡充で動いているのか、検討なのか」
文科省：「先程の拡充拡大、Srなどの汚染拡大について福島中心から拡充すると検討したいということ」

記者：　「住民関与での線量マップの作成などを勧告している。
　　　　　ICRPの求めていることを当事者それぞれに一回国民全員に共通理解の上で足りないところをしないとモグラ叩き状態になる。
　　　　　そうではなくするべきだと」

安全委：「1つの件、基本的に審議会なのでICRPの勧告の理解は重要だと思うが、
　　　　　説明業務というのはマンパワーや役割的に出来かねる。政府の指示があれば別」
　　　　　~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
役所対応だねぇ、「出来かねる」と言っても指示があれば [考える] とやる気はなさそうです。
まぁ「何」やるにしてもその予算は税金なので「勝手」にやったら問題なんですけどね。

**(`･ω･´)ﾉｼ大佐** ◆MustangENQ (長屋) · 2011/10/13(木) 22:32:02.48

放射線計測マップ作成支援：ガチャコン ver.0.16
　ttp://www1.axfc.net/uploader/He/so/342014.zip

更新内容：
　PDS-100GN / PDS-100GN/ID 対応
　アイコン色範囲の任意設定モード搭載（対、政府基本方針案「（毎時０・２３マイクロシーベルト）以上」）。
　可変設定型です。

　□任意設定：最大値を0.23μSv/h (0.23μSv/h) 例：デフォルト
　　0.08以下　0.11以下　0.14以下　0.17以下　0.20以下　0.23以下　0.23超

※ 何箇所か表示の上下位置が変わりましたので設定を注意して見直してください。
　↑高
　設定上下（上が高という感じになりました）
　↓低

応用例：
　例えば、多色分解能の↓を青、↑を黄、（Over は真紅、固定）に変更すると

安全圏は濃い青～線量が上昇すると黄色く変化し、「年１ミリシーベルト以上」の「汚染状況重点調査地域」が真紅で現れます。

　※ ただし車両などの中で計測する場合は、車が遮蔽物となり線量は低めで検出されることが多いそうなので目安と考えてください。

**(`･ω･´)ﾉｼ大佐** ◆MustangENQ (長屋) · 2011/10/13(木) 22:42:57.93

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

**106**(福島県) · 2011/10/14(金) 01:26:56.59

>>109　大佐殿　　ver0.16いただきました

PDS100GN対応、ならびに任意設定モード搭載ありがとうございました
前回の20111010のログデータをコピペで20111013に貼り付けてガチャコンしました
ログデータ数値は車内計測数値でしたので車内×1.3が車外と仮定して任意設定で
　　0.07以下　0.09以下　0.11以下　0.13以下　0.15以下　0.18以下　0.18超
として車内ログ数値を読み込ませてみました

世田谷や船橋の件もありますので、今後は歩くのも必要と感じました

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

お手数でも誘導をお願いします

**DoseRAE2** ◆/BLnkBtCx6 (芋) · 2011/10/14(金) 04:30:41.42

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

**かわぶた大王ninja**(新潟県) · 2011/10/14(金) 06:43:44.14

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

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

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

**(`･ω･´)ﾉｼ大佐** ◆MustangENQ (長屋) · 2011/10/14(金) 07:41:35.89

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

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

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

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

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

**地震雷火事名無し**(芋) · 2011/10/14(金) 08:14:43.76

>>111

DL先が

**DoseRAE2** ◆/BLnkBtCx6 (芋) · 2011/10/14(金) 08:16:20.52

>>111

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

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

です

**(`･ω･´)ﾉｼ大佐** ◆MustangENQ (長屋) · 2011/10/14(金) 23:26:05.10

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

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

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

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

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

**地震雷火事名無し**(アラビア) · 2011/10/14(金) 23:46:18.71

>>113

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

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

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

**(`･ω･´)ﾉｼ大佐** ◆MustangENQ (長屋) · 2011/10/16(日) 01:26:37.76

Option_Logger_r2.zip
　ttp://www1.axfc.net/uploader/Sc/so/284019.zip

内容：オプションプログラム
ver1.01：　Logger_Radiation01　＜　ロガー
ver1.00：　Log_Splitter　　　　　＜　ログ切り分け(名称変更

更新内容：
　キー入力で、栞「しおり」を挿めるようにした。デフォルトはスペースバー（任意変更可）
　名称がカッコよさそうなので変えただけなのはナイショ

**地震雷火事名無し**(芋) · 2011/10/16(日) 02:41:35.45

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

**(`･ω･´)ﾉｼ大佐** ◆MustangENQ (長屋) · 2011/10/16(日) 03:28:50.88

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

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

**地震雷火事名無し**(アラビア) · 2011/10/16(日) 06:31:21.77

>>120

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

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

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

**(`･ω･´)ﾉｼ大佐** ◆MustangENQ (長屋) · 2011/10/16(日) 07:24:20.27

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

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

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

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

**地震雷火事名無し**(アラビア) · 2011/10/16(日) 09:13:51.94

>>123

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

だから、

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

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

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

**(`･ω･´)ﾉｼ大佐** ◆MustangENQ (長屋) · 2011/10/16(日) 10:10:54.46

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

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

**DoseRAE2** ◆/BLnkBtCx6 (芋) · 2011/10/16(日) 12:55:34.15

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

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

**DoseRAE2** ◆/BLnkBtCx6 (芋) · 2011/10/16(日) 18:38:20.24

>>111

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

**(`･ω･´)ﾉｼ大佐** ◆MustangENQ (長屋) · 2011/10/16(日) 19:02:15.70

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

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

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

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

**DoseRAE2** ◆/BLnkBtCx6 (芋) · 2011/10/16(日) 19:27:37.83

>> 128
了解でーす

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

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

**(`･ω･´)ﾉｼ大佐** ◆MustangENQ (長屋) · 2011/10/17(月) 20:42:45.03

>>129
了解、レポ待っときます！

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

　～～超えられない壁～
低．お遊び

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

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

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

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

**DoseRAE2** ◆/BLnkBtCx6 (芋) · 2011/10/17(月) 22:30:15.73

>>130

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

**(`･ω･´)ﾉｼ大佐** ◆MustangENQ (長屋) · 2011/10/17(月) 23:11:48.57

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

**DoseRAE2** ◆/BLnkBtCx6 (芋) · 2011/10/18(火) 19:42:47.60

このスレ的に私なりには

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

～～～別途枠～～～

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

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

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

うわ、揺れた

**地震雷火事名無し**(禿) · 2011/10/18(火) 20:00:23.82

くなたは

◆MustangENQ (長屋) · 2011/10/18(火) 20:17:59.32

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

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

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

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

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

◆/BLnkBtCx6 (芋) · 2011/10/18(火) 20:33:46.86

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

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

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

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

**(`･ω･´)ﾉｼ大佐** ◆MustangENQ (長屋) · 2011/10/20(木) 03:05:19.83

名前欄ﾓﾄﾞｯﾀｰ

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

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

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

**[´・ω・｀]** ◆/BLnkBtCx6 (芋) · 2011/10/21(金) 20:34:29.44

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

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

**地震雷火事名無し**(福島県) · 2011/10/22(土) 00:13:47.71

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

**地震雷火事名無し**(千葉県) · 2011/10/22(土) 17:31:26.01

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

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

**(`･ω･´)ﾉｼ大佐** ◆MustangENQ (長屋) · 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
　(￣^￣*ゞﾋﾞｼｯ!　了解！　「次スレは放射能板で」の指摘、重々承知しております！

　(￣^￣*ゞﾋﾞｼｯ!　運営見解に沿って「次スレは放射能板で」を混乱なきよう勤めております！

　(￣^￣*ゞﾋﾞｼｯ!　報告ありがとうであります！

**(`･ω･´)ﾉｼ大佐** ◆MustangENQ (長屋) · 2011/10/22(土) 21:21:16.49

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

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

**139**(福島県) · 2011/10/22(土) 22:21:34.16

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

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

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

**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君にがんばってもらいました

**(`･ω･´)ﾉｼ大佐** ◆MustangENQ (長屋) · 2011/10/22(土) 22:57:42.43

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

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

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

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

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

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

**(`･ω･´)ﾉｼ大佐** ◆MustangENQ (長屋) · 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　持ちさん側に今、ボールがあるので
・・・・情報待ちというところですね。

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

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

**地震雷火事名無し**(福島県) · 2011/10/22(土) 23:27:50.91

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

**地震雷火事名無し**(米) · 2011/10/23(日) 01:18:41.18

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

**DoseRAE2** ◆/BLnkBtCx6 (芋) · 2011/10/23(日) 23:01:23.15

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

>>104

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

**DoseRAE2** ◆/BLnkBtCx6 (芋) · 2011/10/23(日) 23:41:00.95

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

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

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

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

**地震雷火事名無し**(芋) · 2011/10/23(日) 23:46:05.99

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

ﾏﾀﾗｲｼｭｰ

**(`･ω･´)ﾉｼ大佐** ◆MustangENQ (長屋) · 2011/10/24(月) 01:10:27.49

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

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

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

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

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

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

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

|
|ω･´)ﾉｼ
|

**地震雷火事名無し**(福島県) · 2011/10/24(月) 16:38:56.17

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

**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 の後ろを伸ばすか、別のセンテンスを付けるべきか悩むところですが。

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

**地震雷火事名無し**(チベット自治区) · 2011/10/27(木) 15:43:27.15

sage間違えました・・

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

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

**( ´･ω･)** ◆CGOTBmWdi2 (福島県) · 2011/10/29(土) 01:20:27.99

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

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

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

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

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 などに書かれておかれたりすると、
２ｃｈでも配布したり、話したりする時に皆さんが安心して加われるかと
～な者ですとか注釈も省けて楽ですよ。

**154**(新疆ウイグル自治区) · 2011/10/29(土) 08:25:18.02

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

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

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

**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 が、こんな応用性に富む規格とは思ってませんでした、すばらしい。

**154**(新疆ウイグル自治区) · 2011/10/29(土) 08:45:44.61

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

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

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

2011/10/29(土) 11:57:52.39

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

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

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

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

2011/10/29(土) 12:07:54.38

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

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

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

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

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

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

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

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

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

2011/10/29(土) 12:54:17.41

>>159
連投ｗ　書き忘れ

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

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

例 )　若松と仮定

１管－mbed－ $DMDRT　－> アプリ　←　現状

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

１管－mbed － $DMDRT ┐
１管－mbed － $DMDRT ┼－> アプリ
１管－mbed － $DMDRT ┤
１管－mbed － $DMDRT ┘

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

**地震雷火事名無し**(新疆ウイグル自治区) · 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
で求めてます。

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

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

**地震雷火事名無し**(新疆ウイグル自治区) · 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

2011/10/29(土) 18:53:53.81

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

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

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

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

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

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

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

**地震雷火事名無し**(芋) · 2011/10/29(土) 21:45:26.59

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

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

2011/10/30(日) 05:38:47.26

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

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

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

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

**( ´･ω･)** ◆CGOTBmWdi2 (福島県) · 2011/10/30(日) 23:20:04.27

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

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

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

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

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

2011/10/31(月) 04:56:39.77

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

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

**地震雷火事名無し**(庭) · 2011/10/31(月) 13:57:40.35

質問です

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

**地震雷火事名無し**(庭) · 2011/10/31(月) 13:58:21.83

訂正

GPA→GPX

**Mark2改**(新疆ウイグル自治区) · 2011/10/31(月) 14:21:25.22

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

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

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

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

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

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

でどうでしょうか？

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

**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 の中に居候させていただく、と。

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

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

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

というのが存在します。

**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 の中で申告していただく、ってのは？

**Mark2改**(新疆ウイグル自治区) · 2011/10/31(月) 17:50:08.96

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

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

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

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

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

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

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

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

2011/10/31(月) 18:00:07.50

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

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

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

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

**Mark2改**(新疆ウイグル自治区) · 2011/10/31(月) 18:41:19.34

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

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

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

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

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

**地震雷火事名無し**(庭) · 2011/11/01(火) 12:50:36.03

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

**( ´･ω･)** ◆CGOTBmWdi2 (空) · 2011/11/02(水) 00:08:13.36

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

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

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 手動入力準拠
（通称：「ガチャコン」準拠です。）

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

2011/11/02(水) 18:57:42.37

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

**地震雷火事名無し**(福島県) · 2011/11/02(水) 20:45:07.31

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

**( ´･ω･)** ◆CGOTBmWdi2 (空) · 2011/11/02(水) 21:13:51.85

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

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

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

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 型差分計算で出せる（単純に加算でも）。

という感じで考慮してみました。
累積の方はこれでエラー系の対処は可能だと思うのだけど

2011/11/03(木) 02:50:06.75

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

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

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

**Mark2改**(新疆ウイグル自治区) · 2011/11/04(金) 20:07:33.04

自分で要望だした分はスルーして、とりあえず当初の規格に忠実に作ったつもりでしたが・・・
$DMDRT でバグ出しちゃいました。

UTC日付
　　当初）　　　西暦4桁＋月＋日
　　私の）　　　日＋月＋年２桁　　　←$GPRMC の9個目を、そのまま出しちゃいました

cpmとμSV/h
　　当初）　　　μSV/h,cpm
　　私の）　　　cpm,μSV/h　　　←汎用ファイルのほうの順番にしちゃいました

まだ使ってる人は少ないと思うし
「仮実装」「仕様変更の可能性アリ」と大々的に書いたので、
次でコッソリ（告知はしますけど）修正かけようと思います。すみません。

**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時間平均」とか、そーいういうにデータを再加工するのに便利なんです。

**Mark2改**(新疆ウイグル自治区) · 2011/11/04(金) 20:19:36.65

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

**Mark2改**(新疆ウイグル自治区) · 2011/11/04(金) 20:38:45.42

とはいえ、携帯ガイガーではカウント数などの「生データ」を出せる機種は皆無だと思うので
「生データ」が出せる自作ガイガーの人がカウント数などの生データを出したいときには
「$DMRAW」みたいな別センテンスで出すのもありかな、という風に考えが変わってきました。

GPSのNMEAだって重複した情報を別センテンスで出してたりしてるので、$DM～も、
汎用的なデータは$DMDRTで、（主に）自作ガイガーは $DMDRT のほかに $DMRAW でも出したかったら出す、と

もし $DMRAW だとしたら機種というよりも管の種類を含んだほうが都合がいいので
$DMRAW,<管の種類>,<管数>,<起動秒数>,<累積カウント>,<係数>,<オフセット>,<予備>・・・・*<チェックサム>

<管の種類>
　　SBM20、J408、LND712 等々、「文字-数値」の「-」は原則省略、「数値-数値」の「-」は省略せず

<管数>
　　通常は「1」

<起動秒数>,<累積カウント>
　　読み込み側は、ログの途中で起動秒数が小さい値になったら、そこで再起動させたと判定して
　　累積カウントの扱いも、再起動前後で混ざらないように頑張って工夫する

<係数>
　　cpm×0.00666 の「0.00666」を使うよりも cpm÷150 の「150」を使ったほうが
　　人間のイメージとして扱いやすい（小数点以下の0の数を気にする必要ない）ので
　　原則として cpm から割る数を入れる

<オフセット>
　　通常はバックグランドを引くことが多いので、引く値を正数で入れてもいいのですが
　　「計算結果から差し引いている」ということを分かりやすくするため
　　あえてマイナス値で入れるようにしたほうがいい気がする

<予備>
　　とりあえずの予備
　　受信側は最初にカンマの数を数えておいて「項目数は可変」の前提で取り込む

複数管、同じ種類の管が複数のときは、２本を足した値をカウント値に
係数やオフセットは１管時の２倍を入れたら多分いいと思う。

違う種類の管のときには、$DMRAW を管の種類分だけ出してもらって
後は読み込み側が頑張る、と。

**Mark2改**(新疆ウイグル自治区) · 2011/11/04(金) 20:44:12.74

連投すみません、訂正

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

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

**( ´･ω･)** ◆CGOTBmWdi2 (空) · 2011/11/04(金) 23:04:54.53

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

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

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

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

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

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

2011/11/06(日) 22:01:25.54

>>194-195 Mark2改さん
>累積時間　　累積カウント
了解です。

>携帯ガイガーでは馴染みない値かと思いますが
携帯ガイガーではフリスクなんかの画面表示では CPS とμSv/h
プロ（有料）版ではパルスのエネルギー値みたいなグラフも出ているようなので
ソフトの製作者次第かと
（フリスクの方はあれだけ数値やら表示させているのに LOG の話しを聞かない・・・）

>>196-197
今のところは Mark2改さんしかそっち系の作り手が直接降臨しておられませんので
他の方などが来られたら調整していってもらえれば良いのではないかと、
え～と・・・複数機が混ざくった場合の見分け方（分離方法）は？　どうやるんでしょう？という１点が・・・

2011/11/06(日) 22:23:44.33

>>198 ( ´･ω･) ◆CGOTBmWdi2 さん
そういう感じでいきましょう。

・ * が居る場所が最終位置という感じでデータ量可変型センテンス。
・ソフトで使う位置で読み込みを終えるか * が居たら最終位置。
・パラメータとチェックサムは出来るだけ分ける。
・できれば * の前に数値などが存在していれば分離する処理を念のために設ける。
高さなども使わない機種＆設定の場合は詰めていっても大丈夫になります。

GPS NMEA で言えば、GSV なんかが衛星数に応じてブロックの増減があるデータ長可変型なので、
増減対処の方法をここで明示していっているから今後の人（が居れば）
可変長で作っていけば、ソフトも柔軟になるでしょう。

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) 係数：(浮動小数点) ｛ ○　「変換係数」掛け率　or　計算式方式
　07) 測定高さ：単位 cm ｛
　08) 累積時間（秒）
　09) 累積カウント　：(整数）
　08) *チェックサム
　09) [CR] ：0x0A
　10) [LF] ：0x0D

計算式方式（アプリ側で式判別を組む：数値以外の計算用文字判別）
・係数の所は・・ノーマル状態で CPM x 係数
　/係数-Offset　← Mark2　タイプ　　CPM / 係数-Offset = μSv/h
　-BGx係数　　(CPM - BG)*係数 = μSv/h

155番　2011年11月06日　世界時間13時21分35秒半　0.123μSv/h　20cpm ～～
$DMDRT,155,20111106,132135.500,0.123,20,/129.032-0.032,100,60,20,*cs　← フルの例？
$DMDRT,155,20111106,132135,0.123,*cs　← μSv/h だけの記録の場合
$DMDRT,155,20111106,132135,,20,*cs　← ＣＰＭだけの記録の場合
$DMDRT,155,20111106,132135,0.123,,,100,*cs　← μSv/h と計測高さの記録の場合
こんな感じ