Ja, das ist mir bewusst, darum ging es mir nicht, ebenso wenig um Nachkommastellen.
Im Nachbar Thread zum RadiaCode läuft aktuell eine Diskussion über einen Vergleich der Hintergrundstrahlung: RC Zero: 0,24 µSv/h vs. RC 103G: 0,11 µSv/h

Ich hatte als Anfänger von einem auf Cs-137 kalibrierten Geigerzähler, in meinem Fall von auf Cs-137 kalibrierter Software (Rad Pro 3.1.1), genauere Werte erwartet. Das scheint jedoch technisch nicht ohne Weiteres machbar zu sein. Wahrscheinlich hat Gissio genau aus diesem Grund die Quellvoreinstellungen eingeführt, also vorkonfigurierte Empfindlichkeitseinstellungen für gängige Strahlungsquellen (einschließlich Hintergrundstrahlung),
um das Problem der unterschätzten Dosisleistung bzw. allgemeiner Ungenauigkeiten zu umgehen.

Zitat von: Elektroniknerd am 02. Mai 2026, 19:47Man kalibriert solche Zähler ja aus gutem Grund auf Cs-137: 
* das ist, was man bei einem Störfall in einigem Abstand am wahrscheinlichsten hat.
* der Wert für Iod 131 (das andere Isotop, was man wahrscheinlich bekommt) ist dann auch ziemlich OK.
* es werden (praktisch) nie zu kleine Werte angezeigt.
Der Nachteil ist natürlich das z.B. Hintergrund dann deutlich zu hoch angezeigt wird.

Genau dies hatte ich mit dem GQ GMC-800 mit Zählrohr M4011 und potenter Cs-137 Strahlenquelle durchgeführt.
Der Werkskalibrierfaktor von 153 cpm / µSv/h unterschätzt die Dosisleistung von Cs-137 um 30 % bis 40 % vom tatsächlichen Wert. Erst die Anpassung auf 117,5 cpm / µSv/h erlaubte eine annehmbare Dosisleistungsabweichung von < 15 % des SOLL-Wertes. Mir ist es auch lieber, dass der natürliche Strahlungsuntergrund etwas höher angezeigt wird als z. B. bei den BfS-Sonden, dafür aber im mittleren Photonenenergiebereich die Messwerte genauer sind.

Norbert

Zitat von: Pinin am 02. Mai 2026, 19:25Ich vermute, dass dieser vergleichsweise niedrige Wert dazu führt, dass die natürliche Hintergrundstrahlung zu hoch angezeigt wird.

Dir ist aber schon klar, das eine Kalibrierung auf Hintergrund mit dem Zählrohr kritisch gesehen werden muss?

Man kalibriert solche Zähler ja aus gutem Grund auf Cs-137: 
* das ist, was man bei einem Störfall in einigem Abstand am wahrscheinlichsten hat.
* der Wert für Iod 131 (das andere Isotop, was man wahrscheinlich bekommt) ist dann auch ziemlich OK.
* es werden (praktisch) nie zu kleine Werte angezeigt.

Der Nachteil ist natürlich das z.B. Hintergrund dann deutlich zu hoch angezeigt wird.

Die x-Nachkommastellen gibt die Messphysik übrigens nicht her, die Fehler sind eher so im Bereich einiger 10%. (.. insofern sind 151, 154, und 160 praktisch das gleiche.) 

Wenn du weißt, was du misst, ist das korrekte Vorgehen aber durchaus, die Empfindlichkeit passend dazu einzustellen.

In Rad Pro 3.1.1 ist für die M4011-GM-Röhre ein Sensitivitätswert von 108,345 cpm/µSv/h hinterlegt.
Dieser basiert auf numerischen Simulationen mit Rad Lab unter Verwendung einer Standard-Gammaquelle (Cs-137).
Ich vermute, dass dieser vergleichsweise niedrige Wert dazu führt, dass die natürliche Hintergrundstrahlung zu hoch angezeigt wird.

In der alten Rad Pro 3.0.2 Version (& in der originalen FNIRSI-Firmware) ist vermutlich ein M4011 Sensitivitätswert von etwa
160 cpm/µSv/h  (ermittelt über Vergleich) hinterlegt. die damit deutlich näher (Abweichung  < 0,03 µSv/h) an der üblichen Hintergrundstrahlung (BfS) liegen.
Für Vergleichszwecke habe ich die Empfindlichkeit manuell auf 160 cpm/µSv/h eingestellt, anstatt die Rad Pro 3.0.2 Voreinstellung M4011 zu verwenden.
Hintergrundstrahlung war bei beiden Einstellungen identisch, ein Vorteil von Rad Pro ist, dass sich Änderungen leicht vergleichen lassen:
Sobald die Empfindlichkeit angepasst wird, wird auch der bisherige Durchschnittswert, Log entsprechend korrigiert.

Laut DFRobot/Gravity-Modul (eine der gängigsten Referenzen) liegt der passende Wert für die M4011-GM-Röhre bei 153,8 cpm/µSv/h.
In der Arduino-Community werden häufig etwa 151,5 cpm/µSv/h genannt.

Wenn morgen das wetter passt könnt ich mal hin radeln, heute ists sich leider zeitlich nicht ausgegangen.

Gibt es denn keinen neugierigen Münchner der etwas Erde aus dem Englischen Garten braucht Radio-Caching 

...wenn man die Startseite klickt, sieht mans sofort. Wenn man von hinten nach vorne klickt und nicht bis unten ließt, sich auch noch auf gehörtes verläßt, eben nicht. EGAL!
@Steffen: solche Fehler darfst Du gerne ausbessern. Ich bin ja nicht unfehlbar...

Zitat von: DG0MG am 01. Mai 2026, 10:41Ich lese da den 26.6., also den Freitag raus?

Ja, steht hier auch so:

https://www.wissenschaftsnacht-dresden.de/

26.Juni 2026 17:00 bis 24:00 Uhr

da läuft auch der Counter schon, wie zu Silvester 

Das könnte man, falls vorhanden, mit einem Am-241 (59,5 keV) Ionisationsrauchmelder testen.
(Aber nur an einem I-Melder, der betriebsbereit an der Decke hängt... )

Norbert

Hallo,

ich bin weiterhin damit beschäftigt, Messergebnisse und LTspice-Simulationen zur Deckung zu bringen.

Versuch 1:

PMT und Divider, aber keine Last am Signalausgang. Das HV-Netzteil wird mit Akkus betrieben, hat also keine Erde, die mit dem Oszilloskop eine Erdschleife bilden könnte. Da ich keinen Differentialtastkopf zur Verfügung habe, habe ich einen 100x-Tastkopf (100MHz, max. 2 kV, CH1), an beiden Enden des Lastwiderstandes angeschlossen. Ich habe mehrere Pulse  aufgezeichnet und als csv-Datei exportiert.

Diese csv-Dateien habe ich in LTspice importiert. Dann habe ich versucht mit den Parametern der Stromquelle so lange zu spielen, bis die simulierten Kurven sich den gemessenen angenähert hatten. Damit dies überhaupt möglich war, musste ich den Wert von C0 von 10 auf 0,22 bzw. 0,27 pF reduzieren. Ein Papier des PMT-Herstellers rät für Simulationen zu einem C0-Wert < 10 pF.

Versuch 2:

PMT, Divider, BNC-Kabel 0,5m und PMT-Adapter. Einen 10x-Tastköpfe (150 MHz, max. 300 V) am Divider-Ausgang und ein BNC-Kabel zwischen PMT-Adapter-Ausgang und Oszilloskop. Ein Datensatz mit einem ,,normalen" Puls, ein Datensatz mit einem Puls der so hoch war, dass er die OpAmps über ihre Rail-to-Rail-Charakteristik hinaus beansprucht hat.

In der Simulation habe ich das Divider-Ausgangssignal als Eingang für den PMT-Adapter verwendet. Der simulierte PMT-Adapter-Ausgangspuls entspricht recht gut dem aufgezeichneten.

Versuch 3:

Nun wollte ich die ersten beiden Versuchsergebnisse zusammenführen. Das hat leider nicht geklappt. Die ermittelten Parameter für die EXP-Funktion der Stromquelle führen im Gesamtschema zu einem simulierten Output, der ersichtlich nicht zu den aufgezeichneten Kurven passt. Ich bekomme den PMT-Adapter-Output nur in die Nähe der gemessenen Kurve, wenn ich die Amplitude kräftig erhöhe, FallTau reduziere und (FallDelay-RiseDelay) erhöhe.

Mein Eindruck: Der Strompuls der Anode ist sehr abhängig von der Last! Und zwar nicht nur in der Höhe der Amplitude, sondern auch in der Charakteristik von Rise und Fall.

Gruß Andreas