ガイガーボット


.jp
.au/.ca/.uk/.us
.at/.ch/.de
.ru
.it
.fr
.es
73%


15% 4% 3% 3% 2% <1%
最新の3つの更新の割合(%)
% of latest three updates



ガイガーボットとは?

What is Geiger Bot?

ガイガーボットは、ガイガーカウンターのスピーカーから出るクリック音やビープ音からCPM数を読み取って表示する無料のiOSアプリで、App Store からダウンロードできます。英語、日本語、ドイツ語、ロシア語、フランス語の各国語版があります。かなり以前からこのようなソフトウェアを構想していたのですが、福島第一原発の事故をきっかけに実際に制作してリリースすることにしました。

Geiger Bot is a free iOS app available on the App Store that displays a CPM reading from the clicks/beeps of a Geiger counter's speaker.  It is localized in English, Japanese, German, Russian, and French.  While I had intended to write something like this for quite some time, the Fukushima nuclear power plant incident motivated me to release an implementation of it.


どのように役立つものですか?

How is That Useful?

昔のガイガーカウンターの多くはクリック音、あるいはLEDや電球の光以外に放射線量を表示する機能がついていませんでした。この種のものは、比較的強めの放射線源を調べるのには役立ちますが、たとえばバナナのように線量が低い放射線源をバックグラウンドの放射から識別するためには、少なくとも何分間にもわたる間、クリック音を数えて累計を取らないといけません。これは、とても退屈で間違いやすい作業です。また、アナログのメーターがついた機種(例:CDV-700)でも、カウント数が少なめの領域では比較的精度が低いという問題があります。

Many older Geiger counters lack any sort of indication of relative radioactivity other than the clicks or perhaps a LED/bulb flashing.  This works well for surveying a moderately radioactive source, but in order to distinguish objects of low radioactivity (such as bananas) from background radiation, you must perform an integration count by counting the clicks over at least a minute of time.  This is a very tedious and error-prone process.  Also, the integration accuracy of analog meters is relatively poor at low counts (ie: the CDV-700).



New 2015-06-17 Update

Good news: The current version of the app still works fine.
  Bad news: The next one is still a ways off.


A New Geiger Bot Foundation: Analog + Digital Input

I've been working on a new app for Safecast, which will communicate to a Geiger counter over Bluetooth LE.  This has introduced additional complexities, such as handling data from multiple kinds of sensors, synchronizing them with GPS locations on the iOS device, storing, and uploading them.

Thus, I've chosen to use very flexible data models that will work with not only BLE devices, but any number of sensors built-in to the iOS device, or analog audio input.  I'll be integrating this into Geiger Bot.


The Problem With the Old Geiger Bot

For use cases where you have a Geiger or scintillation counter and don't mind running the app in the foreground, it does fairly well.  It is stable and I've ran it for weeks at a time without issue.  Not bad for an app that has been continuously updated in someone's spare time since iOS 3.1.1 and is relatively complex.

But it makes a number of assumptions about what kinds of data it's going to get, and how it's going to get them.  It's problematic to extend outside of those paradigms, for things such as digital input or different kinds of sensors.

The way the app components work together is also non-ideal.  The power and memory use is too high to run as a background app.  By fixing this, components can be unloaded to save memory, and when combined with BluetoothLE data can be continuously received without interrupting other tasks or using significant resources.


What This Does For You

1. Keep what you have now
2. Digital input - BLE + others TBD
3. Get more than just radiation data
4. Add configurations after release with dynamic models that eliminate hardcoding
5. Low-power background modes
6. Maintainable, codebase that will be shared with other projects via Safecast
7. Open source - you can contribute, or reuse things in your own project


More Info - Preliminary

  1. Hardware Interface
    • Data arrives from a hardware interface
    • (eg, CoreAudio for analog audio)
  2. HAL
    • This data is forwarded to the hardware abstraction layer (HAL), which unifies all data input
  3. Device Model
    • From the HAL, the data is pushed into raw buffers in the device data model
  4. Processing Graph
    • Any number of mathematical or meta operation nodes are executed on the raw data
    • This converts raw data to something useful
    • (eg: analog audio buffer -> CPM, uSv/h, stats)
  5. Output / Storage
    • All measurements are stored in an internal database
      • Database Exports
        • CSV
        • Upload to remote server
    • These measurements are also displayed on the device
      • Numeric display
      • Graph
      • Map

Data Models (simplified, preliminary)
         [HTTP REST    ](**NI)                                    
         [AVFoundation ](**NI)                                                   
         [DeviceBattery]                                                   
 [HAL]---[CoreAudio    ]
   |     [BluetoothLE  ]
   |     [CoreLocation ]
   |     [ExtAccessory ](**NI)
   |
[[App]]
   |
[Model]       +--[ProcessingGraph]  +-[Graph]
   |          |         |           |
   [Device]   |      [Nodes]--------+-[Ratemeter]
      |       |         |           |
   [Sensor]   |         |           +-[Map]
      |       |     [Database]
   [Channel]--+         |
                        |
                   [DataExport]
                        |
                  +-----+--------+
                  |              |
             [CSV File]    [Data Upload]

Data Flow: (preliminary)
[Input] -> [HAL] -> [Model] -> [ProcGraph] -> { [DB] [Export] [Display] }


BLE Zero Configuration


Digital devices are a little trickier than analog in some ways, because they likely all require their own data models and processing graphs to turn raw input buffers into a measurement of some kind, and depending on the MCU + BLE hardware this can vary a lot.

What isn't shown above is that for known BLE device UUIDs, all that will automatically load from an internal database, so there's no configuration required.

For unknown devices, I'll implement the import and export of such profiles, likely in JSON/text format, which can also be edited on-device.  I also plan on making a standalone HTML5/JS GUI editor so it will be relatively simple to do this.


Cross-Platform Compatibility

The core data model is written in ANSI C and stores data using a fully normalized, relational database (SQLite) with strong typing.  It should be highly cross-platform.  The database code will be written in a combination of ANSI C and SQL.

The hardware abstraction layer and individual interface implementations are written in ObjectiveC, as it is necessary to use the iOS frameworks.  These will need to be almost entirely reimplemented on other platforms.

The UI components will also thus, by necessity, be written in ObjC.   See above note.

Where possible, I will implement data processing code in ANSI C with no platform or weird external dependencies.

*** end of 2015-06-17 update ***


In Development

The next major release will primarily be focused on native / optimized iOS 8 and iPhone 6/6+ support.  Significant portions of the codebase are being entirely rewritten to provide cleaner multiplatform support and extensibility.

  1. Already Done
    1. Maps
      1. Significant performance improvements
      2. Improved scaling of GIS raster data.
        1. RGBA tiles (PNG/JPEG)
          1. Can now be rescaled by XBR which is significantly superior for basemaps.  XBR is a novel scaling technique especially suited to non-photographic RGB raster data.
        2. Data tiles (Layers)
          1. Correction of scaling spatial error (currently shifted by half a source pixel to the origin)
          2. Use of thresholded Lanczos / bilinear bitmask for shape detection when zooming in.  (curves not blocks)
      3. Improved performance for postprocessing and downloading 3rd party basemap tiles.
      4. Improved offline basemap functionality via autoscaling of best available zoom level data cached to disk.
    2. Ratemeter
      1. Custom unit assignment
  2. Pending - High Priority
    1. iOS 8 and iPhone 6 / iPhone 6+ optimizations
    2. Refactoring of code and UI components for supporting iOS 6 - 8, OS X 10.9 - 10.10
    3. Support for live display of Safecast realtime sensor data
    4. New GIS datasets - JAEA
  3. Pending - Lower Priority
    1. UI design updates
    2. Simplification of settings
    3. Audio input status display to simplify device connections, with detection of common misconfigurations and help text.
    4. Automatic configuration for line input Geiger counters
    5. Refactoring of audio DSP code and abstraction to support different types of input (Bluetooth digital data, etc)
    6. Integral webserver with remote access



New iOS 8 Compatibility

There are no major issues with iOS 8.  Expect a later update to provide native support, but there's a good amount of code refactoring I need to do first to cleanly support iOS 6/7/8 and OS X at the same time.



New OS X App Release

While not Geiger Bot per se, Safecast is available from the Mac App Store and contains the mapping functionality present in Geiger Bot or Safecast for iOS.  It does not contain audio DSP (click counting) currently.

The OS X app is also used to generate the Safecast tile map.  In fact, that was the reason for its development; a new Safecast web map was needed, and I found I could export a PNG tileset quickly with little code from the iOS app.  However, having a couple gigabytes of PNG files on an iPad wasn't directly usable.

Eventually, the full map functionality was ported to a native OS X app to perform this task server-side daily, with a full UI added such that it also works quite well as a GIS content viewing app.

Incidentally, taking code that is highly performant and started life on a humble mobile device, and porting it to a server application ends up working relatively well; the performance is orders of magnitudes faster than other GIS solutions that were tested.





Very Later Development
  • Open source code release
    • Mostly depends on getting code cleaned up and refactored such that it can be easily understood, maintained, extended and reused.
    • Codebase is primarily ANSI C with UI and Apple frameworks in ObjC.  Heavy SIMD vectorization with native support for NEON and SSE.
      • There are few 3rd party frameworks used.  Portions of the app in ObjC are being rewritten in ANSI C where possible.  ANSI C with no 3rd party framework dependencies is fast and highly portable.
    • Some of the code has been ported and refactored into open source subprojects
      • Retile (GitHub link)
        • Very similar code is used by Geiger Bot / Safecast to create updated Safecast data tiles, and zoom in past the max native resolution of raster data.
        • High-performance, SIMD vectorized, multithreaded implementation.
        • Basically similar to gdal2tiles, but the input source is a raster tileset, not a monolithic raster.
        • 100% ANSI C
          • Will take advantage of Apple's Accelerate framework and GCD if present.
      • bitstore.js (GitHub link)
        • Port and adaptation of the GIS tile indexing used by Geiger Bot / Safecast to significantly improve disk read performance when displaying map data.
        • Used live by your web browser on the Safecast tilemap.
        • Relatively high-performance implementation with typed arrays, HTML5 local storage, and multithreading via background web workers.  Hinting for just-in-time JS compilation (Google V8, etc).
        • 100% vanilla JavaScript
  • Possible Windows / Android ports (unlikely due to time constraints)
    • OSX/Windows: if you just need basic microphone sensor use and Pachube uploading, consider Osamu Higuchi's free GeigerRobo







ローカライゼーション
Localizations

ガイガーボットをほかの言語に翻訳していただけますか?もしよろしければ、私にご連絡ください。私から翻訳していただきたい文字列をお送りして、 翻訳してくださった文字列を次のバージョンに埋め込ませていただきます(ただし、ヘブライ語やアラビア語など、右から左へ書く言語は問題があるかもしれま せんので、少々お時間をいただくかもしれません)。また、あなたのお名前をAbout画面に掲載させていただきます。このソフトで使っている用語の中には かなり技術的なものが含まれており、またUI上、表示するスペースにも制限があることにご留意ください。
(機械翻訳も試していますが、たいてい英語をそのまま残しておいたほうがましな結果になるようです。)

Would you like Geiger Bot available in your native language?  If so, contact me and I will send you a strings file to translate, and incorporate it into the next version.  (note: there may be issues with right-to-left languages; ie, Hebrew and Arabic, that could cause delays)  I will also credit you on the about screen.  Note that some of the terms are highly technical and there are space considerations in the UI.

(machine translation has generally produced results worse than keeping it in English)



フィードバック
Feedback

私にご質問やご意見をお送りください私はあなた助けるために最善を尽くします。

I welcome all feedback.  If Geiger Bot is not adapting to your set-up with at least 95% accuracy, please let me know.

For any questions, complaints, localization corrections, rants, etc please email:



(日本語の翻訳のための樋口の功績)
(credit to Osamu Higuchi for Japanese translations)

ガイガーボット, プリピャチで
Гейгер Бот в Припять
Geiger Bot in Pripyat
(photo credit: Ihor Kolodyuk)


放射線マップ
  Radiation Maps


グローバル放射線地図投影法
Global Radiological Projection
(フルスクリーンマップのクリック)
(click for full map)

(
Global Data: Safecast,
North America: DOE/USGS/GSC (NURE),  NGA (DEM*),
Japan: US DOE/NNSA (AMS))

*(DEM used for cosmic ray dose rate correction)






日本米国線量当量率
Japan vs. US Dose Equivalent Rate


(normalized map scales and units to Japan.
USGS/GSC data corrected for cosmic radiation.
Japan data: Safecast, US DOE/NNSA
  NA Data: USGS, GSC, NGA)






用量
の暴露:福島対核実験(I- 131)

Doses: Fukushima vs. Nuke Tests (I-131)

(comparison of Iodine-131 dose from Fukushima and US atmospheric nuclear testing.  US color legend and dose equivalent units converted to match Japan map.  Note I-131 has a half-life of  8 days so this reflects historical exposure in either case.  I-131 is generally considered to be the most directly harmful fission product.)

(US Data: National Cancer Institute
Japan Data: MEXT)



顧客
のアクションの
写真
User Action Shots
 
NaIシンチレーション サーベイメータの作成

NaI scintillation probe by Shintaro Funabasama.  This supports gamma spectroscopy.


 
Ludlum3GSの近くにiPad1.1.1ドラックスによる)

Version 1.1.1 on an iPad, next to a Gamma Scout and calibrated Ludlum 3 by Drax.

 
CDV700近くiPad1.1.1Apotheounによる)

Version 1.1.1 on an iPad, next to a CDV-700 by Apotheoun.  (YouTube)

 
ヘッドセット入力回路図樋口による) 彼はこう書いている。
- 0.1V9Vp- Pについてこの場合出力電圧を分周
- 出力iPhoneマイク入力切り離すしないでください iPhoneのマイク入力ドロップDCバイアスしましょう


Schematic for using the headset input by Osamu Higuchi.  He notes:
"- Divide the output voltage (in this case, about 9Vp-p) down to about 0.1V
- Do not decouple the output and iPhone mic input. Let the DC bias on iPhone mic input drop" (more)

 
ヘッドセットマイク修正ローランリーベン

Headset mic mod by Laurent Lieben.  No soldering required.  (more...)




























Comments