Seit dem Reaktorunglück von Tschernobyl im April 1986 ist Radioaktivität in aller Munde – und die Frage, was um uns herum tatsächlich an Strahlung vorhanden ist, beschäftigt viele bis heute. Gerade in Zeiten, in denen sich Meldungen über angebliche oder tatsächliche Strahlenbelastung überschlagen, ist es beruhigend, sich ein eigenes Bild zu machen: Statt sich allein auf öffentliche Quellen zu verlassen, kann man einfach selbst nachschauen, was da in der Umgebung passiert.
Genau das war der Hintergrund dieses Projekts: ein eigener Geigerzähler, der rund um die Uhr misst und die Werte direkt auf dem eigenen Server auswertet – nachvollziehbar, unabhängig und mit der gewohnten Technik im Hintergrund (das komplette Setup läuft bei mir auf dem Hausserver).
Aufgestellt habe ich den Zähler im Keller, direkt im Bereich der Wasserversorgung. Zugegeben: Wer die klassischen Empfehlungen kennt, wird einwenden, dass so ein Messgerät eigentlich eher im Freien aufgehängt gehört, um die saubere Umgebungsstrahlung zu erfassen. Doch der Kellerstandort hat durchaus seine Logik: Wasser ist im Ernstfall einer der ersten Wege, über die sich radioaktive Stoffe ausbreiten können – wer das eigene Trinkwasser im Blick hat, hat schon viel gewonnen. Und so überwacht der Zähler genau den Ort, an dem eine mögliche Belastung für den Haushalt am direktesten spürbar würde.
Dass sich der Standort trotz der räumlichen Trennung realisieren ließ, verdankt das Projekt einer einfachen, aber bewährten Lösung: Zwischen Geigerzähler und USB-Schnittstelle des Servers liegt eine Strecke von rund sechs Metern, die mit einem handelsüblichen Telefonkabel überbrückt wird (4-adrig, 3 belegt) – mehr Technik braucht es nicht, um die Messwerte zuverlässig in die Auswertung zu bringen.
Eine wichtige Einschränkung sei an dieser Stelle erwähnt: Bei einem Selbstbau-Gerät handelt es sich selbstverständlich nicht um ein genormtes, kalibriertes Messinstrument. Die angezeigten Werte sind daher nicht als absolute Strahlungsbelastung im wissenschaftlichen Sinne zu verstehen – sie geben vielmehr einen verlässlichen Vergleichs- beziehungsweise Differenzwert wieder. Was wirklich zählt, ist die relative Veränderung: ob die gemessene Aktivität im Tagesverlauf oder im Wochenvergleich auf ihrem gewohnten Niveau bleibt oder messbar ansteigt. Genau dafür ist das Setup ideal geeignet – als Frühwarn- und Beobachtungsinstrument, nicht als Präzisionsmessgerät.
Der Bausatz
Das Herzstück ist der Geiger Counter Bausatz von MightyOhm (Produktseite). Auf der Platine sitzen ein ATtiny2313-Mikrocontroller und eine Hochspannungsversorgung, die die Geiger-Müller-Röhre mit 300 bis 600 Volt versorgt. Die verbaute SBM-20-Röhre erfasst Beta- und Gammastrahlung; jede Registrierung eines Teilchens wird über eine LED und einen Piezo-Summer signalisiert. Einen guten Überblick über die verschiedenen SBM-20-Röhren-Varianten gibt übrigens der Spotter’s Guide im MightyOhm-Blog.
Geigerzähler Bausatz
RS 232 Baustein
Praktischer Tipp aus meinem Aufbau: Den Piezo-Summer würde ich beim nächsten Mal nicht einbauen beziehungsweise einfach abkleben – er piept bei jedem einzelnen Impuls und ist auf Dauer ziemlich nervig. Die LED genügt als stiller Indikator völlig. Das Kit hat zwar eine Stummschaltfunktion, aber ganz ohne Piezo ist es am angenehmsten.
Neben der Anzeige bietet der Bausatz eine serielle Schnittstelle (9600 Baud), über die er kontinuierlich Messdaten ausgibt – genau diese Schnittstelle ist der Einstieg in die automatisierte Auswertung. Das offizielle Daten-Logging-Tutorial beschreibt die serielle Anbindung im Detail.
Anbindung an den Server
Damit die Messdaten im Server landen, wird der Zähler über einen USB-Seriell-Adapter angeschlossen. In meinem Fall ist es ein PL2303-Adapter – zu erkennen am Chip-typischen Eintrag 067b:2303 in der USB-Geräteliste. Der MightyOhm arbeitet mit TTL-Pegel, ein entsprechender Adapter beziehungsweise ein FTDI-Kabel (wie in der offiziellen Doku empfohlen) ist daher die richtige Wahl. Zwischen Zähler und Adapter hängt die bereits erwähnte RS232-Verlängerung über sechs Meter – in meinem Fall ein handelsübliches Telefonkabel mit vier Adern, von denen drei belegt sind.
Das richtige USB-Gerät finden: Nach dem Einstecken lässt sich der Adapter leicht identifizieren – unter Linux zum Beispiel mit lsusb (dort erscheint der PL2303 als Prolific) oder über den stabilen Gerätenamen in /dev/serial/by-id/. Ebenfalls hilfreich: ein Blick in die Kernel-Logs (dmesg) direkt nach dem Einstecken.
Da sich die Nummerierung der seriellen Geräte beim Booten ändern kann, ist eine udev-Regel empfehlenswert, die dem Gerät über seine USB-Kennung einen festen Namen zuweist – in meinem Fall /dev/ttyGEIGER. Die Regel liegt auf dem System unter /etc/udev/rules.d/93-geiger.rules und ist weiter unten aufklappbar.
Das serielle Datenformat ist denkbar einfach: Der Zähler sendet etwa einmal pro Sekunde eine CSV-Zeile im Stil von CPS, 1, CPM, 22, uSv/hr, 0.12, SLOW – also Zählrate pro Sekunde (CPS), pro Minute (CPM) und die rechnerische Äquivalentdosis in Mikrosievert pro Stunde. Interessantes Detail: Während die MightyOhm-Dokumentation 8 Datenbits vorsieht, empfange ich das Gerät mit 7 Datenbits und Even-Parity (7E1) – offenbar sendet die verbaute Firmware in diesem Format. Beim Nachbau also auf das tatsächliche Ausgabeformat des eigenen Geräts achten.
Software
Die Messwerte werden von einem Python-Skript eingelesen und an die Zeitreihendatenbank VictoriaMetrics übergeben. Das Skript öffnet die serielle Schnittstelle, liest die CSV-Zeilen, erkennt und zählt fehlerhafte Zeilen (Garbage) und mittelt die Messwerte über 60 Sekunden, bevor ein Datenpunkt geschrieben wird – so entsteht eine ruhige, aussagekräftige Zeitreihe mit einem Wert pro Minute.
Geschrieben wird im Influx-Line-Protocol, das VictoriaMetrics direkt versteht – pro Minute entsteht ein Messpunkt im Measurement Geiger mit den Feldern usievert (µSv/h) und int-error (Anzahl verarbeiteter Fehlerzeilen). Der Dienst läuft als systemd-Service (geiger.service) unter dem Telegraf-Nutzer und startet bei einem Absturz automatisch neu. Die Abhängigkeiten (pyserial) stehen in einer requirements.txt; wer sauber isolieren möchte, legt ein virtuelles Python-Environment an und passt den ExecStart des Dienstes entsprechend an – in meinem Fall läuft das Skript direkt mit dem System-Python.
Der vollständige Code zum Nachbauen – geiger.py, die udev-Regel und die systemd-Unit – ist hier aufklappbar dokumentiert:
geiger.py (komplettes Reader-Skript, VictoriaMetrics)
#!/usr/bin/python3
# -*- coding: utf-8 -*-
#
# Geigerzaehler-Reader (MightyOhm Geiger Counter) -> VictoriaMetrics
#
# Liest die serielle Ausgabe des Zaehlers, mittelt die Messwerte
# ueber 60 Sekunden und schreibt einen Datenpunkt pro Minute im
# Influx-Line-Protocol an VictoriaMetrics.
import sys
import time
import urllib.request
from serial import Serial
# ---- Einstellungen ----
TTY = "/dev/ttyGEIGER" # serielles Geraet (udev-Symlink)
BAUD = 9600 # Baudrate des Geigerzaehlers
DATA_BITS, PARITY, STOP = 7, "E", 1 # 7E1 (je nach Firmware auch 8N1)
AVG = 60 # Mittelung ueber 60 Messungen (~ 1 min)
VM_URL = "http://192.168.10.4:8428/write?db=geiger"
MEASURE = "Geiger" # Measurement-Name in der Datenbank
# ---- globale Zaehler ----
err_cnt = 0 # fehlerhafte Zeilen (Garbage)
cnt = 0 # Messungen im aktuellen Mittelwertfenster
sum_val = 0.0 # Summe der uSv/h-Werte
def write_vm(usievert, errors):
"""Schreibt einen Messpunkt per Influx-Line-Protocol an VictoriaMetrics."""
ts = int(time.time() * 1e9) # Zeitstempel in Nanosekunden
line = f"{MEASURE} usievert={usievert},int-error={errors} {ts}"
try:
req = urllib.request.Request(VM_URL, data=line.encode(), method="POST")
urllib.request.urlopen(req, timeout=5)
except Exception as e:
print(f"VMWrite-Fehler: {e}", file=sys.stderr)
# ---- serielle Schnittstelle oeffnen ----
try:
ser = Serial(TTY, BAUD, DATA_BITS, PARITY, STOP, timeout=10)
except Exception as e:
print(f"Serial-Fehler: {e}", file=sys.stderr)
sys.exit(2)
# ---- Hauptschleife ----
while True:
line = ser.readline().decode("utf-8")[:-2] # Zeile ohne Zeilenende
if not line.strip(): # leere Zeilen ignorieren
continue
# Erwartetes Format: CPS, 1, CPM, 22, uSv/hr, 0.12, SLOW
parts = line.split(",")
if len(parts) != 7 or "SLOW" not in parts[6]:
err_cnt += 1
continue
cnt += 1
sum_val += float(parts[5]) # parts[5] = uSv/hr-Wert
if cnt >= AVG:
write_vm(sum_val / AVG, err_cnt)
cnt = 0
sum_val = 0.0
err_cnt = 0
93-geiger.rules (udev-Regel für /dev/ttyGEIGER)
SUBSYSTEMS=="usb", ATTRS{idVendor}=="067b", ATTRS{idProduct}=="2303", OWNER=="telegraf", GROUP=="root", MODE=="0660", SYMLINK+="ttyGEIGER"
geiger.service (systemd-Unit)
[Unit]
Description=IoT Radioactivity Logging Geiger Prozess
After=syslog.target network.target
#
##
[Service]
Type=simple
Restart=always
RestartSec=10
GuessMainPID=yes
ExecStart=/usr/apps/services/geiger/geiger.py
User=telegraf
Group=root
WorkingDirectory=/usr/apps/services/geiger
[Install]
WantedBy=multi-user.target
Daten-Einbindung und Auswertung
Der Datenfluss sieht in meinem Setup so aus: Geigerzähler (seriell) → geiger.py → VictoriaMetrics. Ausgewertet wird in Grafana, das als Frontend auf die Zeitreihendatenbank zugreift.
In der Datenbank landet pro Minute ein Messpunkt im Measurement Geiger mit den Feldern usievert (µSv/h) und int-error. Damit lässt sich in Grafana eine Zeitreihe über die Umgebungsstrahlung aufbauen – inklusive Tagesmittel und einem Blick auf die Schwankungen im Tagesverlauf.
Auswertung in Grafana
Fazit
Der Geigerzähler von MightyOhm ist ein lehrreicher Bausatz, der mit wenig Aufwand zu einem dauerhaften Beobachtungsinstrument für die eigene Umgebung wird. Die Werte sind bewusst nicht als absolute Strahlungsmessung zu verstehen, sondern als zuverlässiger Vergleichs- und Frühwarnindikator – und genau dafür ist die Kombination aus Bausatz, Serveranbindung und grafischer Auswertung ideal. Wer selbst einen Blick auf seine Umgebung werfen möchte, bekommt hier eine bewährte Blaupause.