Radioaktivität messen mit PocketGeiger App & Detector

Ich hab mal wieder meine PocketGeiger App ausgepackt und den (mittlerweile alten) Type 1 – Detector und mal auf dem Balkon für 20 Minuten gemessen. Ergebnis: 0.02 µSv/h

Mehr Infos dazu gibt es auf der Webseite des Projektes eine Initiative die nach Fukushima ins Leben gerufen wurde.

Bilder der Messung
Quelle: Eigene Aufnahmen auf dem Balkon

Dabei hab ich dann Lust bekommen mir eine Smart Watch zu bestellen.

Und ich bin auf eine aktualisierte Webseite des Bundesamtes für Strahlenschutz gestossen. Die haben neuerdings eine gute Webseite und eine bessere Karte des Gamma Ortsdosisleistungs Messnetzes.

In den USA gibts es vergleichbares offenbar sowohl als Freiwilligennetz als auch als staatliches Netz in Form des Nuclear Emergency Tracking Center und noch eines von der Umweltbehörde.

In Japan gibt es als Ergebnis der Bürgerinitiativen nach Fukushima die Japan Radiation Map.

This map shows ca 4,500 up-to-date radiation measurements, collected from various official sources. On roll-over information is provided for that particular location – radiation levels are visualized by the colored square’s size. Locations marked with the + sign reveal more locations on zoom-in. Logging since march 2011, the accumulated data contains now 100,000,000+ records, available for research.

Messnetzkarte des ODL Netzes
Quelle: ODL Messnetz Webseite des BfS

Ich hab dann mal eine Registrierung für deren API angefordert.

Die App

Diese App gibts übrigens hier:

App im AppStore

Weitere schöne Tracking Projekte

Geigerzähler von korrupt mit Beta/Gamma-Hintergrundstrahlung in Wuppertal-Elberfeld

Why do I blog this? Angesichts der Tatsache, dass ich weder Apples Apple Watch sonderlich „smart“ finde, noch ihre Bestrebungen den Standard-Audioanschluss des iPhone zu eliminieren (der für PocketGeiger die ultimative & einzige Schnittstelle ist), wollte ich das mal festhalten wie gut das funktioniert.

RealmExplorer – a piece of sample code for Realm DB

realmexplorer_01_smallFirst things first, look at the RealmExplorer github repo for the project.

Preface: CoreData

I have some history in using databases. From using Oracle, Frontbase, mySQL, PostgreSQL, sqlite etc. the last time I used a database was for a postcard app using CoreData. But I found CoreData to be a lot of overhead and boilerplate code to write.

Especially migrations are kind of not very intuitive to understand and if something goes wrong you are basically lost. While Xcode for a while had an Entity modelling tool (which had it’s roots in the WebObjects EOModeler), most of the time this tool did not work very well for me and had lots of bugs. In each Xcode version different bugs!

Also many people report running into issues when using CoreData with lots of objects, because it is easy to loose track of memory consumption with CoreData and if you do not actively check and work against that, you end up with a whole model graph being in memory. Not cool! So I wanted to try something different.


I found Realm by to be interesting enough to tinker with. So I started working with their sample code projects. But none of those projects came even close to some real world example. So I just started prototyping something I will need for a different project anyway.

Starting with a custom viewcontroller for adding & editing entities I recognized that this would soon become rather painful to provide e.g. inputfields for text and numbers and dates. So I grabbed FXForms to give it a try after I had already completed a viewcontroller to manage DBCaptain entities a bit.


Right from the start I wanted to know how migrations work. Because usually those are the weakest spot in every db operation taking place. With a live product you always „pray“ that nothing will go wrong during migrations on the customers device. And keeping track of changes to the db schema is very important to have a stable app.

So I built the sample around the process to „simulate“ an app in development. You can now iterate through different development steps (5 different app states & their migrations) and their needed migrations. This way I figured out how I can safely manage my migrations (i.e. always keeping a backup of the old schema). In the project the
DatabaseFactory.m class manages all that. It detects existing schemas using a precise naming scheme for each Realm-db created.

During app launch any necessary migrations are executed if necessary. Also, any errors happening while the app launches and gets into trouble activating the database, are nicely displayed.


I started with one entity DBCaptain which is basically a user entity. I just wanted to create user objects and populate them with different properties. I tested insertion with one and with many users on the main thread and on the background thread. I also took advantage of notifications coming from Realm as soon as an operation finished updating the db.

Deletion of objects came next. As always having the UI keeping track of all those changes is the more difficult task. So expect some „ugly“ code, because this was only me tinkering around. When i wanted to edit existing objects I recognized that I do not want to create all those textfields manually.


That was when FXForms came to the rescue. I started to recreate the already half done viewcontroller and created another based on FXForms. I needed some time to wrap my head around FXForms, because basically this is a quite sophisticated hack of providing compact descriptions of UITableViewCells and their content.

You describe what kind of structure your form should have and what kind of value types it should use. FXForms crafts the UITableView which makes all those inputfields come true. Things start to become a bit tricky if you want to control those UITableViewCells more directly. E.g. I needed a way to exclude certain properties of being edited at all. So I simply extended the FXForms protocol to allow for a denial of userInteractionEnabled on certain cells by adding the FXFormFieldEditable key. This is used on the CaptainFormViewController to exclude the information about the database schema and the encryption status to not be editable.


My first impression of Realm DB is quite positive. It is fast, it provides helpful error-messages and it is easy to setup and comprehensive in what it does and how it works. I never in my life had migrations up and running that quickly. Very, very helpful was the Mac app RealmBrowser to open a realm DB file directly. I used that while checking my migrations and the results of operations which added arbitrary data (e.g. image files).

What is actually really great is that encryption is supported for the db by just providing a 128 bit key. That is really helpful to protect user data and increase safety of the realm db file even if it gets backed up into some cloud somewhere else.

What’s next?

I think I missed something related to the KVO-thingy going on by Realm. But I had no time until now to figure that out. I suppose they actually track entities and changes via KVO. But I am not yet sure how exactly this works and how I can detect if an object has pending changes. That is why I added a hasPendingChanges BOOL-flag to both ViewControllers for editing entities. So help is welcome here!!

I did not have time to do some real hardcore performance testing, i.e. adding thousands of entities and relationships in a short time and crafting a rather complex model with complex relationships which define ownership and cascading deletions etc. Also doing sophisticated db queries is on my list to do next.

But having a prototype now to tinker with helps already a lot. Since I learn best from sample code, and I think I am not the only one learning new things this way, I hope it helps others to jumpstart with Realm, too.

Why do I blog this? I just wanted to give a bit of background info on the sample code I put on github. Have fun tinkering & I am really in need of getting more info on how I can detect changes to an object so I know WHEN to save changes to the db. Maybe someone who already grabbed the concept better can help me here?? Leave a comment or contact me via github.

Mein Wunsch-iPhone


Ich hab jetzt berufsbedingt das iPhone 6s kaufen müssen. Ich sage „müssen“, weil ich es mir freiwillig nicht gekauft hätte. Im Vergleich zu den vorherigen Modellen hat es so viele Unzulänglichkeiten die mich langsam anfangen zu nerven, dass ich es eigentlich niemals in Erwägung zog es zu kaufen. Bis Touch 3D um die Ecke kam, tja.

  • Es ist zu groß. Man kann mit dem Daumen nicht die linke obere Ecke des Screen erreichen. Man kann es nicht mehr einhändig bedienen, weil man dann entweder riskiert das Gerät aus der Hand zu verlieren oder eben nur einen Teil des Screens bedienen kann. Der Doppeltap auf den Homebutton, um unerreichbare Ecken oben am Bildrand zu erreichen ist einhändig nicht möglich.
  • Es hat extrem glatte zudem noch abgerundete Kanten, das ist aus einigen Gründen extrem bescheuert. Grund 1: Es fällt viel leichter aus der Hand, insbesondere, wenn man trockene Hände hat, z.B. in der kalten Jahreszeit. Grund 2: Man kann es nicht mehr auf dem Tisch gegen irgendwelche Gegenstände schräg hinstellen, z.B. weil man einem video folgen möchte, da es keine griffige Kante mehr hat rutscht es permanent weg.
  • Der Lock-Button ist jetzt rechts, was die idiotischste Idee aller Zeiten ist. Grund 1: Man kan den Lock-Button nicht bedienen ohne im Gegenzug den Lautstärke-Button ebenfalls zu bedienen. Grund 2: Man kann den Lautstärke-Button nur bedienen um im Gegenzug den Lock-Button zu bedienen. Ganz große Scheiße! Das muss mal gesagt werden. Grund 3: Es weicht ab von dem was man gewohnt ist und was absolut in Ordnung war: Lock-Button OBEN!
  • Touch ID ist zu schnell. Okay, ja, ich gebe es zu, ich nutze Touch ID, in der Hoffnung, dass diese Daten tatsächlich auf dem Gerät bleiben und nicht in einer Apple Datenbank… das mag naiv sein. Auf dem iPhone 5s hat Touch ID gut funktioniert. Bei nassen Fingern hat es ein Problem, damit kann man aber leben. Auf dem 6s ist Touch ID, ich mag das kaum schreiben, zu schnell!!! Auch wenn man nur mal eben die Uhrzeit vom Lockscreen ablesen will, hat man das Gerät aus versehen entriegelt.

Ich verstehe einfach nicht, wie dieser ganze Mist bei Apple niemandem auffallen kann. Lesen die keine Forschungsergebnisse zu User Experience bei Apple?

Forschung hilft!

Zum Beispiel Mobile Interface Design: „Thumb Zones“ for the new iPhones:


Oder Rule Of Thumb: Will The Taller iPhone 5 Be A Reach For Users?:


Oder Which smartphone best fits YOUR hand?:


und es gibt Unterschiede zwischen Männer- und Frauenhänden…




Oder A polite rant on mobile UX:


Mein Wunsch iPhone

Weil mich das so kolossal annervt, weil ich das Gerät täglich nutzen möchte und mich somit solche Dinge JEDEN TAG annerven… hier mal mein ratschlag wie mein Wunsch iPhone aussehen möge:

  1. Kanten-Design wie beim 4S, insbesondere die RUNDEN Lautstärke-Buttons und den Lock-Button oben und den Mute-Button so dass er eben nicht aus Versehen beim in die Hose stecken an geht.
  2. Vorder- und Rückseiten-Design wie beim 4S, also aus Glas.Die Rückseite des 5s war in kürzester Zeit verkratzt, mein 4S schaut dagegen nach intensiver Nutzung aus wie am ersten Tag.
  3. Die Abmessungen des Screens wie beim 5s, also 4 Zoll Screen. Weil ein bissel höherer Screen tatsächlich passend war und auch noch mit dem Daumen alles erreichbar.
  4. Die Dicke wie beim 4S. Nicht weil dick schön ist, sondern weil man den ganzen Platz dann mit Batterie vollstopfen kann. Und Batterie ist was man will! Und weil man dann so einen Mist wie eine rausguckende Kamera im 6s, die verhindert das Gerät eben auf den Tisch legen zu können, auch bleiben lassen kann. Damn it!
  5. Oh und hier noch ein Featurewunsch… falls dieses Gerät gebaut werden sollte… und noch Platz im Gerät übrig ist… stopft den voll mit Umwelt- und Medizinsensorik zur Messung von z.B. Außentemperatur, CO2, CO, NOx, Luftfeuchte, Gehirnwellen, Radiowellen, Stromleitfähigkeit, Radioaktivität, UV-Einstrahlung, EKG-Funktion durch Auflegen auf Brust, Blutzuckermessung, Atemluftanalyse, etc.)

Why do I blog this? Weil mir mein 6s mit all diesen nervigen Unzulänglichkeiten tierisch auf die Nerven geht. Im Vergleich zum 5s ist es ein massiver Rückschritt. Ich mag das Gerät nicht und würde ich nicht Touch 3D und das Barometer für die Entwicklung benötigen hätte ich es niemals gekauft.