Crowdsourced Data mit dem Geigerzähler

[opengeiger.de]

So und nun hab ich hier mal noch den Aufbau für die vorgeschlagene crowdsource data basierte Messung der Ansprechempfindlichkeit am Beispiel des chinesischen Joy-It Geigerzählers gemacht und dies Nachgemessen (sie ist bei dem Gerät ja sogar spezifiziert). Ich habe allerdings wieder meine Kerzenwachsscheibe als ,,Betablocker" verwendet. Ich kenne ja die Gußlunker bei Schlackesteinen, aber wenn man Kerzenwachs gut warm macht, wird es ja dünnflüssig wie Wasser und Luftbläschen sind so schnell oben, wie in einem Glas Leitungswasser ohne Kohlensäure. Daher bin ich der Meinung, dass eine Inhomogenität durch Luftbläschen ein wenig weit hergeholt ist. Aber ich gebe zu, ein 10mm dickes Plexiglas ist sicher etwas robuster fürs Händling als ne Scheibe aus Kerzenwachs. Aber das Plexiglas muss man in den meisten Fällen zurecht sägen, und das kostet etwas Fleiß oder ne gute Säge und beides hat ich jetzt nicht gerade um den Weg ...
 
Aber nun zum Spannenden Teil, wie performt der Joy-It im Vergleich? Also zunächst mal hat man es etwas schwer, den Abstand zum Uran-Erz Stück so einzustellen, dass die Anzeige genau 1.0uSv/h beträgt. Dabei bemerkt man auch, dass das Zählrohr entlang der rechten Längsseite sitzen muss, denn von der Seite her sind di Zählraten höher. Irgendwie hat auch die Anzeige eine gewisse Granularität, die wohl aus einer einfachen Rechnung stammt, und sie hampelt rum wie beim Gammascout, was man auch im Verlaufsdiagramm erkennen kann. Aber mit Hilfe des Verlaufsdiagramms kann man das zumindest mit dem Auge mitteln und so dann den Abstand grob passend justieren.

Für einen gemittelten Zahlenwert kann nun einfach etliche Messwerte die er in Folge anzeigt aufschreiben und darüber mitteln, dann bekommt man auch so was wie einen Mittelwert über eine längere Messzeit. So kam ich also auf 0.788uSv/h, also doch etwas weniger als ich mit dem Auge aus dem Verlaufsdiagramm gepeilt hatte.  Jetzt muss man in den Einstellungen aber auf cpm umstellen (cps ist vielleicht zu ungenau) und die Messung nochmal machen. Da kam ich dann auf 168.29 cpm. Verrechnet man das nun, ergeben sich 213.56 cpm/(uSv/h) oder 3.56cps pro uSv/h. Und das ist mehr als was der Gammascout von der her Front zeigt. Es verwundert aber auch nicht, denn eigentlich müsste man beim Gammascout die Gammamessungen von der Seite her machen, dann da sieht man mehr Wandfläche des Zählrohrs als durch das Fenster. Aber das gehört zu den Unsauberkeiten des Gammascout Designs.

Jetzt sind die hier bestimmten 213.56 cpm pro uSv/h auch mehr als die in der Anleitung angegebenen 80 cpm pro uSv/h. Aber wir erinnern uns die Angabe in der Anleitung bezieht sich auf das Co-60, also Gammas mit 1173 und 1332keV an Energie. Unat ist zwar ein ganzer Blumenstrauß an Gamma-Energien aber der Schwerpunkt liegt dos so eher unter 300keV. Was man daher hier sieht ist vermutlich die deutlich höhere Energieeffizienz des Zählrohrs für Energien unter 300keV. Die Effizienz des J321 Zählrohrs hab ich im Internet zwar nicht gefunden, aber wenn ich mir mal so bei Wikipedia ein ZP1320 anschaue, dann sieht man da schon so einen Faktor von bis zu 8 zwischen den Co-60 Energien und den Energien unter 300keV. Von daher würd ich jetzt sagen, die hier 3.56cps pro uSv/h passen durchaus noch ins Bild (Peter hat mal 2.9cps pro uSv/h für ein SBM-20 angegeben). Das heißt der Joy-It kommt bei dieser von der Strahlungsgeometrie vielleicht nicht so ganz perfekten Messung mit einer Ansprechempfindlichkeit raus, die besser ist als die des Gammascout (vom Frontfenster) und etwas besser als ein Durchschnitts SBM-20 GM-Zählrohr. Der Gammascout kostet bei Reichelt im Augenblick 476 Euro der Joy-IT bei Conrad 70Euro (inkl. MwSt, hat aber keinen Messwert-Speicher!).

Die Messgenauigkeit habe ich versucht am Referenzpunkt in der Kapelle zu bestimmen, siehe (https://www.geigerzaehlerforum.de/index.php/topic,1960.msg24589.html#msg24589).

[kater]

Der Arduino Uno hat zwar einen 16MHz Quarz, aber wie er intern zu den Millis kommt ist mir unklar, das ist nirgenwo brauchbar dokumentiert und so ganz genau ist das nicht. [...] Wenn man Datalogging machen möchte oder gar ne ODL-Sonde selber bauen will,  und die Uhr nicht ständig neu stellen will, sind so RTC-Shields für den Arduino meiner Meinung nach ganz sinnvoll.

Auf die Gefahr hin, dass das immer weiter "off topic" führt:

- Zum einen könnte es sein, dass die millis() im Arduino-Laufzeitsystem nicht nur quarzbedingt systematisch ungenau sind, sondern je nachdem, wie weit man den µController ausnutzt, beispielsweise mit eigenen Interruptroutinen, auch erratisch beim Zählen ,,gestört" werden könnten.

- Eine Möglichkeit, sehr genau zu messen, stellt ein GPS-Modul dar. Die üblichen Miniboards für Arduino & Co. mit u-blox NEO bieten einen PPS-Ausgang (pulse per second) an, der sehr exakt 1x pro Sekunde eine fallende (und eine steigende) Flanke liefert. Wenn man damit einen Interrupt im Controller triggert, kann man sehr genaue Zeit- oder Frequenzmessungen vornehmen. Ich nutze das an einem ESP32-Controller, um die Netzfrequenz mit ihren Schwankungen zu überwachen. Man kann dann auch schön die Schwankungen der quarzgenerierten Prozessor-Taktfrequenz im PPM-Bereich beobachten, die beispielsweise von der wechselnden Temperatur des Quarzes verursacht werden. Auf einem seriellen Ausgang liefert das GPS-Modul übrigens (neben der Geoposition, die hier mal gar nicht interessiert) auch noch die Uhrzeit (als UTC), so dass das RTC-Modul damit überflüssig wird. Kostenmäßig tun sich beide auch nicht allzuviel.

[NuclearPhoenix]

- Eine Möglichkeit, sehr genau zu messen, stellt ein GPS-Modul dar. Die üblichen Miniboards für Arduino & Co. mit u-blox NEO bieten einen PPS-Ausgang (pulse per second) an, der sehr exakt 1x pro Sekunde eine fallende (und eine steigende) Flanke liefert. Wenn man damit einen Interrupt im Controller triggert, kann man sehr genaue Zeit- oder Frequenzmessungen vornehmen. Ich nutze das an einem ESP32-Controller, um die Netzfrequenz mit ihren Schwankungen zu überwachen. Man kann dann auch schön die Schwankungen der quarzgenerierten Prozessor-Taktfrequenz im PPM-Bereich beobachten, die beispielsweise von der wechselnden Temperatur des Quarzes verursacht werden. Auf einem seriellen Ausgang liefert das GPS-Modul übrigens (neben der Geoposition, die hier mal gar nicht interessiert) auch noch die Uhrzeit (als UTC), so dass das RTC-Modul damit überflüssig wird. Kostenmäßig tun sich beide auch nicht allzuviel.

Ein RTC Modul wie eine DS3231 ist auch eigentlich mehr als genau für sowas und weniger overkill, findest du nicht? Dort hat man auch die Uhrzeit und kann sich selbst Interrupts auf bestimmte Uhrzeiten und Zeitabstände legen, hat einen direkten 32 kHz Ausgang und einen einstellbaren Rechteckspulsausgang. Außerdem ist man nicht von Satelliten abhängig und es verbraucht viel weniger Strom. Der (wenn auch grobe) Temperatursensor ist auch ganz nett.

[kater]

Ein RTC Modul wie eine DS3231 ist auch eigentlich mehr als genau für sowas und weniger overkill, findest du nicht?

Absolut. Die Genauigkeit ist da völlig ok. Vorteil beim GPS ist dann höchstens, dass die Zeit nicht eingestellt werden muss, falls denn das Modul den Himmel sehen kann. Stromverbrauch ist aber auch ein wichtiger Aspekt bei Batteriebetrieb.

[Dsl71]

Gibts da GPS Module welche mit Empfang in Innenräumen keine Probleme (oder wenige) mehr haben?

[opengeiger.de]

Es ist definitiv richtig, dass man kaum genauer eine Zeit bekommt als von einem der Satellitennavigationssysteme. Die bleiben eben auch langzeitstabil. Aber grösster Nachteil sind die vereinbarten Frequenzen zwischen 1200und 1500MHz. Da hat ein Signal kaum noch eine Durchdringungskraft von fester Materie. Ich sehe da auch kaum Chancen ohne externe Antenne die Empangsbedingungen in Innenräumen zu verbessern. Und wenn man kein zusätzliches Mobilfunkmodul hinzufügt, wartet man teilweise auch ewig auf den Almanach weil der ja nur mit 50bit/s übertragen wird. Das sind so meiner Meinung nach die Hauptnachteile. Ich denke, wenn man ein Steckernetzteil hat ists gar kein Problem mit der Leistungsaufnahme. Für meine Datenlogger mit GPS nehme ich LiPo Modellbau-Akkus, die halten in der Regel nen Tag, da ists dann egal, aber mit Batterie und wenns klein werden soll, dann kanns schon kritisch werden, vor allem wenn es dann noch einen leistungshungrigen Detektor oder Prozessor gibt. Deswegen, wenn ich keine Strecke aufzeichnen will, habe ich auch Real Time Clocks, meist die von Adafruit. Was da dann lästig ist, dass man bei denen die Uhr halt immer mal wieder stellen muss, weil sie über lange Zeit davonlaufen. Aber statt sie zu stellen fotografiere ich oft einfach die Displays mit Uhrzeit vor der Messung und rechne dann einen Offset später drauf zum synchronisieren.